一种基于瑞利缺陷模型的软件测试质量管控方法与系统与流程

1.本发明涉及软件测试管理领域，具体涉及一种基于瑞利缺陷模型的软件测试质量管控方法与系统。


背景技术：

2.当前生活在互联网技术非常普及的年代，用户的要求越来越高，希望能在规定甚至更短的时间内生产出优质的产品，这使产品的质量需要接受严峻的考验，而在一个软件的整个生命周期中，测试环节由于处于靠后的阶段，往往还会出现测试周期被压缩、测试人力不足、研发修复缺陷时间过迟等问题；且在测试过程中，测试策略若出现问题，经常在测试后期才会暴露，这时只能通过测试人员加班以增加测试时长或者和项目申请推迟发布时间进行补救，因此需要在测试前期，即可判断本次测试策略是否合理、测试人力是否足够，及早通过调整测试策略和增加测试人员等手段进行干预，以保证产品发布版本的质量。


技术实现要素：

3.本发明要解决的技术问题是一个软件的整个生命周期中，测试环节由于处于靠后的阶段，往往还会出现测试周期被压缩、测试人力不足、研发修复缺陷时间过迟等问题；且在测试过程中，测试策略若出现问题，经常在测试后期才会暴露，本发明提供一种基于瑞利缺陷模型的软件测试质量管控方法，本发明还提供一种基于瑞利缺陷模型的软件测试质量管控系统，能够通过比对根据千行代码缺陷率预估的缺陷数和根据瑞利缺陷模型计算的缺陷数，在测试前期即可知晓本次的测试策略是否合理，测试时间是否足够，及早通过调整测试策略和增加测试人员等手段进行干预，以保证产品发布版本的质量，用以解决现有技术导致的缺陷。
4.为解决上述技术问题本发明提供以下的技术方案：
5.第一方面，一种基于瑞利缺陷模型的软件测试质量管控方法，其中，包含以下步骤：
6.步骤1：获取上个迭代的千行代码缺陷率以及本次迭代制定的测试计划与测试策略，提取所述测试计划中的总测试时长记为t
总
；
7.所述测试计划与所述测试策略根据软件需求和项目的发布时间节点而制定；
8.所述测试计划是对测试全过程的组织、资源、原则等进行规定和约束，并制定测试全过程各个阶段的任务以及时间进度安排；
9.所述测试策略是通过采用有效的测试手段和方法，对产品模块进行划分，明确测试点和所采用的测试方法，指导测试工作的开展；
10.步骤2：软件进入测试阶段时，获取本次迭代需求的总代码行数，根据公式k2＝(总代码行数/1000)*千行代码缺陷率计算得到可能产生的缺陷数记为k2；
11.步骤3：软件测试过程中，记录每天真实产生的缺陷数记为d(t)和累计产生的缺陷数记为d(t),其中，t是天数；
12.步骤4：获取所述d(t)为峰值的一天记为tn，将d(tn)输入至瑞利缺陷模型中计算tn天时产生的缺陷总数记为k1，所述瑞利缺陷模型为k1＝d(tn)/40％，d(tn)为tn天累计产生的缺陷数；
13.步骤5：判断所述k1与所述k2的大小；
14.若所述k1小于所述k2，则重新定制所述测试策略使得当日缺陷数达到顶峰的时间后移并更新所述tn后重新计算k1，直到所述k1大于等于所述k2；
15.若所述k1大于等于所述k2，将所述k1与所述tn代入所述瑞利缺陷模型中得到累积分布函数与概率密度函数；
16.所述累积分布函数为
17.所述概率密度函数为其中，m为形状参数，m＝2,c是范围参数,t是天数，k是所有的缺陷数；
18.步骤6：将所述t
总
代入所述累积分布函数和所述概率密度函数中得到测试结束当天预计发现的缺陷数f(t
总
)和累计发现的缺陷数f(t
总
)；
19.步骤7：若所述f(t
总
)大于软件项目上使用可接受的缺陷数记为s时，则调整测试策略，增加测试人员，直到所述d(t
总
)大于等于所述f(t
总
)；
20.若所述f(t
总
)等于所述s时，则测试正常，无需调整测试策略；
21.若所述f(t
总
)小于所述s时，则测试效率提升，可适当减少测试人员。
22.上述的一种基于瑞利缺陷模型的软件测试质量管控方法，其中，步骤1中所述千行代码缺陷率的计算方法如下：
23.获取上个迭代开始时间和结束时间内提交的历史记录，对增加和删除的行数进行统计后获取软件发布时的总代码行数；
24.获取上个迭代测试过程中累计发现的缺陷数；
25.根据公式：缺陷数/(总代码行数/1000)计算得到所述千行代码缺陷率。
26.上述的一种基于瑞利缺陷模型的软件测试质量管控方法，其中，步骤1中依据软件的发布时间节点提取所述测试计划中的总测试时长记为t
总
。
27.上述的一种基于瑞利缺陷模型的软件测试质量管控方法，其中，步骤2中需要先确认本次迭代与上个迭代相比其研发人员未发生较大的调整。
28.上述的一种基于瑞利缺陷模型的软件测试质量管控方法，其中，步骤4中所述d(t)为峰值的判断方法为：
29.当每天真实产生的缺陷数出现第一个拐点时，视该天的缺陷数达到了峰值。
30.第二方面，一种基于瑞利缺陷模型的软件测试质量管控系统，其中，包含信息提取模块、缺陷预估模块、缺陷比对模块、数据处理模块、质量管控模块；
31.所述信息提取模块用于获取上个迭代的千行代码缺陷率以及本次迭代制定的测试计划与测试策略，还用于提取所述测试计划中的总测试时长记为t
总
；
32.所述缺陷预估模块用于在软件进入测试阶段时，获取本次迭代需求的总代码行数，并根据公式k2＝(总代码行数/1000)*千行代码缺陷率计算得到可能产生的缺陷数记为k2；还用于在软件测试过程中，记录每天真实产生的缺陷数记为d(t)和累计产生的缺陷数
记为d(t),其中，t是天数；还用于获取所述d(t)为峰值的一天记为tn，将d(tn)输入至瑞利缺陷模型中计算tn天时产生的缺陷总数记为k1，所述瑞利缺陷模型为k1＝d(tn)/40％，d(tn)为tn天累计产生的缺陷数；
33.所述缺陷比对模块用于判断所述k1与所述k2的大小；
34.若所述k1小于所述k2，则反馈至所述缺陷预估模块，所述缺陷预估模块重新定制所述测试策略使得当日缺陷数达到顶峰的时间后移并更新所述tn后重新计算k1，直到所述k1大于等于所述k2；
35.若所述k1大于等于所述k2，将所述k1与所述tn代入所述瑞利缺陷模型中得到累积分布函数与概率密度函数；
36.所述累积分布函数为
37.所述概率密度函数为其中，m为形状参数，m＝2,c是范围参数,t是天数，k是所有的缺陷数；
38.所述数据处理模块用于将所述t
总
代入所述累积分布函数和所述概率密度函数中得到测试结束当天预计发现的缺陷数f(t
总
)和累计发现的缺陷数f(t
总
)；
39.所述质量管控模块用于根据所述f(t
总
)与软件项目上使用可接受的缺陷数记为s进行比对并生成处理意见；
40.若所述f(t
总
)大于所述s时，则生成调整测试策略，增加测试人员的意见，直到所述d(t
总
)大于等于所述f(t
总
)；
41.若所述f(t
总
)等于所述s时，则生成测试正常，无需调整测试策略的意见；
42.若所述f(t
总
)小于所述s时，则生成测试效率提升，可适当减少测试人员的意见。
43.第三方面，一种芯片，其中，包括：处理器，用于从存储器中调用并运行计算机程序，使得安装有所述芯片的设备执行：如第一方面中任一项所述方法。
44.依据上述本发明一种基于瑞利缺陷模型的软件测试质量管控方法与系统提供的技术方案具有以下技术效果：
45.通过比对根据千行代码缺陷率预估的缺陷数和根据瑞利缺陷模型计算的缺陷数，在测试前期即可知晓本次的测试策略是否合理，测试时间是否足够，及早通过调整测试策略和增加测试人员等手段进行干预，以保证产品发布版本的质量。
附图说明
46.图1为本发明一种基于瑞利缺陷模型的软件测试质量管控方法的流程图；
47.图2为本发明一种基于瑞利缺陷模型的软件测试质量管控系统的结构图。
48.其中，附图标记如下：
49.信息提取模块100、缺陷预估模块200、缺陷比对模块300、数据处理模块400、质量管控模块500。
具体实施方式
50.为了使发明实现的技术手段、创造特征、达成目的和功效易于明白了解，下结合具
体图示，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。
51.基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
52.须知，本说明书所附图式所绘示的结构、比例、大小等，均仅用以配合说明书所揭示的内容，以供熟悉此技术的人士了解与阅读，并非用以限定本发明可实施的限定条件，故不具技术上的实质意义，任何结构的修饰、比例关系的改变或大小的调整，在不影响本发明所能产生的功效及所能达成的目的下，均应仍落在本发明所揭示的技术内容得能涵盖的范围内。
53.同时，本说明书中所引用的如“上”、“下”、“左”、“右”、“中间”及“一”等的用语，亦仅为便于叙述的明了，而非用以限定本发明可实施的范围，其相对关系的改变或调整，在无实质变更技术内容下，当亦视为本发明可实施的范畴。
54.本发明的第一实施例是提供一种基于瑞利缺陷模型的软件测试质量管控方法，第二实施例是提供一种基于瑞利缺陷模型的软件测试质量管控系统，目的是通过比对根据千行代码缺陷率预估的缺陷数和根据瑞利缺陷模型计算的缺陷数，在测试前期即可知晓本次的测试策略是否合理，测试时间是否足够，及早通过调整测试策略和增加测试人员等手段进行干预，以保证产品发布版本的质量。
55.瑞利缺陷模型为rayleigh缺陷模型，是weibull分布的一种特殊形式,是一种常用的模型，weibull分布最重要的一个特点就是概率密度函数的尾部趋近于零,但永远不会到零。
56.如图1所示，第一方面，第一实施例，一种基于瑞利缺陷模型的软件测试质量管控方法，其中，包含以下步骤：
57.步骤1：获取上个迭代的千行代码缺陷率以及本次迭代制定的测试计划与测试策略，提取测试计划中的总测试时长记为t
总
；
58.测试计划与测试策略根据软件需求和项目的发布时间节点而制定；
59.测试计划是对测试全过程的组织、资源、原则等进行规定和约束，并制定测试全过程各个阶段的任务以及时间进度安排；
60.测试策略是通过采用有效的测试手段和方法，对产品模块进行划分，明确测试点和所采用的测试方法，指导测试工作的开展；
61.步骤2：软件进入测试阶段时，获取本次迭代需求的总代码行数，根据公式k2＝(总代码行数/1000)*千行代码缺陷率计算得到可能产生的缺陷数记为k2；
62.步骤3：软件测试过程中，记录每天真实产生的缺陷数记为d(t)和累计产生的缺陷数记为d(t),其中，t是天数；
63.步骤4：获取d(t)为峰值的一天记为tn，将d(tn)输入至瑞利缺陷模型中计算tn天时产生的缺陷总数记为k1，瑞利缺陷模型为k1＝d(tn)/40％，d(tn)为tn天累计产生的缺陷数；
64.步骤5：判断k1与k2的大小；
65.若k1小于k2，则重新定制测试策略使得当日缺陷数达到顶峰的时间后移并更新tn后重新计算k1，直到k1大于等于k2；
66.若k1大于等于k2，将k1与tn代入瑞利缺陷模型中得到累积分布函数与概率密度函
数；累积分布函数为
67.概率密度函数为其中，m为形状参数，m＝2,c是范围参数,t是天数，k是所有的缺陷数；
68.步骤6：将t
总
代入累积分布函数和概率密度函数中得到测试结束当天预计发现的缺陷数f(t
总
)和累计发现的缺陷数f(t
总
)；
69.步骤7：若f(t
总
)大于软件项目上使用可接受的缺陷数记为s时，则调整测试策略，增加测试人员，直到d(t
总
)大于等于f(t
总
)；
70.若f(t
总
)等于s时，则测试正常，无需调整测试策略；
71.若f(t
总
)小于s时，则测试效率提升，可适当减少测试人员。
72.软件项目：是指为企业开发或者部署实施一套专用的系统，或在特定的行业领域做一些系统之间的集成，在进入项目之前必须与用户进行具体需求分析和讨论，明确用户心目中的产品或项目预期是什么样子，然后立项、招投标、签订合同、实施交付。
73.上述的一种基于瑞利缺陷模型的软件测试质量管控方法，其中，步骤1中千行代码缺陷率的计算方法如下：
74.获取上个迭代开始时间和结束时间内提交的历史记录，对增加和删除的行数进行统计后获取软件发布时的总代码行数；
75.获取上个迭代测试过程中累计发现的缺陷数；
76.根据公式：缺陷数/(总代码行数/1000)计算得到千行代码缺陷率。
77.上述的一种基于瑞利缺陷模型的软件测试质量管控方法，其中，步骤1中依据软件的发布时间节点提取测试计划中的总测试时长记为t
总
。
78.上述的一种基于瑞利缺陷模型的软件测试质量管控方法，其中，步骤2中需要先确认本次迭代与上个迭代相比其研发人员未发生较大的调整。
79.上述的一种基于瑞利缺陷模型的软件测试质量管控方法，其中，步骤4中d(t)为峰值的判断方法为：
80.当每天真实产生的缺陷数出现第一个拐点时，视该天的缺陷数达到了峰值。
81.如图2所示，第二方面，第二实施例，一种基于瑞利缺陷模型的软件测试质量管控系统，其中，包含信息提取模块100、缺陷预估模块200、缺陷比对模块300、数据处理模块400、质量管控模块500；
82.信息提取模块100用于获取上个迭代的千行代码缺陷率以及本次迭代制定的测试计划与测试策略，还用于提取测试计划中的总测试时长记为t
总
；
83.缺陷预估模块200用于在软件进入测试阶段时，获取本次迭代需求的总代码行数，并根据公式k2＝(总代码行数/1000)*千行代码缺陷率计算得到可能产生的缺陷数记为k2；还用于在软件测试过程中，记录每天真实产生的缺陷数记为d(t)和累计产生的缺陷数记为d(t),其中，t是天数；还用于获取d(t)为峰值的一天记为tn，将d(tn)输入至瑞利缺陷模型中计算tn天时产生的缺陷总数记为k1，瑞利缺陷模型为k1＝d(tn)/40％，d(tn)为tn天累计产生的缺陷数；
84.缺陷比对模块300用于判断k1与k2的大小；
85.若k1小于k2，则反馈至缺陷预估模块200，缺陷预估模块200重新定制测试策略使得当日缺陷数达到顶峰的时间后移并更新tn后重新计算k1，直到k1大于等于k2；
86.若k1大于等于k2，将k1与tn代入瑞利缺陷模型中得到累积分布函数与概率密度函数；
87.累积分布函数为
88.概率密度函数为其中，m为形状参数，m＝2,c是范围参数,t是天数，k是所有的缺陷数；
89.数据处理模块400用于将t
总
代入累积分布函数和概率密度函数中得到测试结束当天预计发现的缺陷数f(t
总
)和累计发现的缺陷数f(t
总
)；
90.质量管控模块500用于根据f(t
总
)与软件项目上使用可接受的缺陷数记为s进行比对并生成处理意见；
91.若f(t
总
)大于s时，则生成调整测试策略，增加测试人员的意见，直到d(t
总
)大于等于f(t
总
)；
92.若f(t
总
)等于s时，则生成测试正常，无需调整测试策略的意见；
93.若f(t
总
)小于s时，则生成测试效率提升，可适当减少测试人员的意见。
94.第三方面，一种芯片，其中，包括：处理器，用于从存储器中调用并运行计算机程序，使得安装有芯片的设备执行：如第一方面中任一项方法。
95.例如，存储器可以包括随机存储器、闪存、只读存储器、可编程只读存储器、非易失性存储器或寄存器等；
96.处理器可以是中央处理器(central processing unit，cpu)等，或者是图像处理器(graphic processing unit,gpu)存储器可以存储可执行指令；
97.处理器可以执行在存储器中存储的执行指令，从而实现本文描述的各个过程。
98.可以理解，本实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者；
99.其中，非易失性存储器可以是rom(read-onlymemory，只读存储器)、prom(programmablerom，可编程只读存储器)、eprom(erasableprom，可擦除可编程只读存储器)、eeprom(electricallyeprom，电可擦除可编程只读存储器)或闪存。
100.易失性存储器可以是ram(randomaccessmemory，随机存取存储器)，其用作外部高速缓存；
101.通过示例性但不是限制性说明，许多形式的ram可用，例如sram(staticram，静态随机存取存储器)、dram(dynamicram，动态随机存取存储器)、sdram(synchronousdram，同步动态随机存取存储器)、ddrsdram(doubledatarate sdram，双倍数据速率同步动态随机存取存储器)、esdram(enhanced sdram，增强型同步动态随机存取存储器)、sldram(synchlinkdram，同步连接动态随机存取存储器)和drram(directrambusram，直接内存总线随机存取存储器)。本文描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
102.在一些实施方式中，存储器存储了如下的元素，升级包、可执行单元或者数据结
构，或者他们的子集，或者他们的扩展集：操作系统和应用程序；
103.其中，操作系统，包含各种系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；
104.应用程序，包含各种应用程序，用于实现各种应用业务。实现本发明实施例方法的程序可以包含在应用程序中。
105.本领域技术人员可以明白的是，结合本文中所公开的实施例描述的各示例的单元及算法步骤能够以电子硬件、或者软件和电子硬件的结合来实现；
106.这些功能是以硬件还是软件方式来实现，取决于技术方案的特定应用和设计约束条件；
107.本领域技术人员可以针对每个特定的应用，使用不同的方式来实现所描述的功能，但是这种实现并不应认为超出本技术的范围。
108.在本技术实施例中，所公开的系统、装置和方法可以通过其它方式来实现；
109.例如，单元或模块的划分仅仅为一种逻辑功能划分，在实际实现时还可以有另外的划分方式；
110.例如，多个单元或模块或组件可以进行组合或者可以集成到另一个系统中；
111.另外，在本技术实施例中的各功能单元或模块可以集成在一个处理单元或模块中，也可以是单独的物理存在等等。
112.应理解，在本技术的各种实施例中，各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术的实施例的实施过程构成任何限定。
113.功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在机器可读存储介质中；
114.因此，本技术的技术方案可以以软件产品的形式来体现，该软件产品可以存储在机器可读存储介质中，其可以包括若干指令用以使得电子设备执行本技术实施例所描述的技术方案的全部或部分过程；
115.上述存储介质可以包括rom、ram、可移动盘、硬盘、磁盘或者光盘等各种可以存储程序代码的介质。
116.综上，本发明的一种基于瑞利缺陷模型的软件测试质量管控方法与系统，能够通过比对根据千行代码缺陷率预估的缺陷数和根据瑞利缺陷模型计算的缺陷数，在测试前期即可知晓本次的测试策略是否合理，测试时间是否足够，及早通过调整测试策略和增加测试人员等手段进行干预，以保证产品发布版本的质量。
117.以上对发明的具体实施例进行了描述。需要理解的是，发明并不局限于上述特定实施方式，其中未尽详细描述的设备和结构应该理解为用本领域中的普通方式予以实施；本领域技术人员可以在权利要求的范围内做出各种变形或修改做出若干简单推演、变形或替换，这并不影响发明的实质内容。