CN104111887A - 基于Logistic模型的软件故障预测***及方法 - Google Patents

Abstract

本发明公开了一种基于Logistic模型的软件故障预测***及方法，所述***包括三个模块：测试周期故障管理模块、Logistic模型度量模块、质量分析与评价模块。所述方法如下：采用测试周期故障管理模块把所述***测试过程按照一定的周期进行划分，采用Logistic模型度量模块度量出每个周期内发现的故障数；利用Logistic模型计算出软件中含有的故障总数和下一个测试周期发现的故障数；采用质量分析与评价模块用软件中已经发现的故障数与软件含有的故障总数的比值作为软件的可信度，用于判断软件是否达到了发布要求；通过上述三个步骤计算出软件的故障总数，进而对软件是否需要继续进行测试做出判断，并用于下一周期的质量评价。

Description

基于Logistic模型的软件故障预测***及方法

技术领域

本发明涉及一种软件的故障预测技术，更具体的说是利用Logistic模型对软件含有的故障总数以及在下一个测试周期发现的故障数进行预测，进而评估最终的软件产品是否达到了规定的质量要求的技术。 

背景技术

软件在***测试过程中会不断地发现故障，故障的解决又可能会引入新的问题，如果一个版本测试的不够充分就发布出去，可能会导致版本的质量太低，给使用者造成损失；如果对一个版本测试的时间过于充分，就会导致所谓的过度测试，造成测试资源的浪费。那么软件在测试过程中的质量如何进行评价？什么时候发布才能够满足对质量的要求？这个问题的解决就依赖于软件的故障预测技术。 

软件故障预测技术是一种在软件发布之前对软件中尚未发现的故障进行估计的技术，可以帮助测试人员在软件发布之前及时调整测试策略，发现更多故障，进而减少软件维护成本，有效提高软件的质量。目前较有影响的故障预测方法有基于贝叶斯方法的故障预测模型和基于随机森林算法的故障预测模型。 

基于贝叶斯方法的预测模型包括贝叶斯网络和朴素贝叶斯分类器，朴素贝叶斯分类器的基础假设为：给定目标值、属性之间相互条件独立和每个实例x由属性值的特征向量表示。目标函数根据现有的集合V中的可能取值进行取值，根据一系列得到目标函数的训练样本集以及新实例的特征向量来预测新实例的目标值。Menzies根据朴素贝叶斯算法与决策树算法的预测模型进行分类性能对比，对数据采取对数处理后实验结果显示朴素贝叶斯算法构建的模型比决策树算法构建的模型具有更好的分类性能。贝叶斯网络不确定性处理问题的能力很强大，可以高效地进行多元信息的融合与表达，已经被广泛地用于软件故障预测。Fenton等人基于贝叶斯网络提出在不同生命模型中合适的软件故障预测模型以及遗留故障预测模型，对贝叶斯网络在生命周期早期预测故障的效果进行了分析。 

2001年LEO Breiman提出了随机森林(Random Forest，RF)算法，森林中决策树的训练 样本是对原始训练样本进行随机采样产生的，在随机森林中决策树内部节点的候选分割属性集是所有属性的一个非空真子集，该子集是从所有特征属性中随机选取一定数目的属性作为候选属性集，使用属性***衡量函数来对候选属性集中属性的分类能力进行判别，最终选取最优***属性。随机森林算法的故障预测通过计算软件项目的多个属性集的值来度量软件项目，对训练数据集进行平衡化处理，构造随机森林模型时根据模型的预测准确率以及查全率来筛选符合性能指标的预测模型。 

上述软件故障预测的基本原理是如果当前正在开发的模块与之前已开发好的某模块具有相似的软件质量属性则说明当前的软件模块与之前的已经测试过的模块具有相似的故障倾向。因此软件故障预测中要用到之前开发的软件模块的故障记录来对当前的模块进行预测。这种故障预测方法有两个问题：一、软件模块的相似度不容易度量，如果找不到相似的模块，则无法进行故障预测；二、由于开发人员的技术进步，相似的模块可能表现出不同的故障趋势，导致预测失效。 

发明内容

有鉴于此，本发明解决的技术问题在于提供一种基于Logistic模型的软件故障预测***及方法，该方法不依赖于其他的软件模块，把***测试过程按照一定的周期进行划分，度量出每个周期内发现的故障数，然后以此为输入利用Logistic模型计算软件中含有的故障总数及下一个测试周期发现的故障数，用软件已经发现的故障数与软件含有的故障总数的比值作为软件的可信度，如果软件没有达到要求的可信度，则需要继续测试下去；如果软件已经达到了要求的可信度，则无需继续测试，可以发布。 

基于Logistic模型的软件故障预测***，包括三个模块：测试周期故障管理模块、Logistic模型度量模块、质量分析与评价模块； 

测试周期故障管理模块：划分测试周期，并统计各个测试周期内发现的故障数，该模块同时负责可信度预期结果的输入； 

Logistic模型度量模块：负责Logistic模型的迭代算法，计算出软件中含有的故障总数和下一个测试周期预计发现的故障数； 

质量分析与评价模块：负责软件可信度的计算，并根据计算结果对软件是否可以发布做出判断；通过比较Logistic模型中计算的下一个测试周期的故障数和实际测试中发现的故障数，对一个测试周期的质量进行评价，输出评价结果。 

基于Logistic模型的软件故障预测***的预测方法包括如下步骤： 

A、采用测试周期故障管理模块把所述***测试过程按照一定的周期进行划分，并度量 

出每个周期内发现的故障数； 

B、利用Logistic模型计算出软件中含有的故障总数和下一个测试周期发现的故障数； 

C、采用质量分析与评价模块用软件中已经发现的故障数与软件含有的故障总数的比值作为软件的可信度，用于判断软件是否达到了发布要求； 

通过上述三个步骤计算出软件的故障总数，进而对软件是否需要继续进行测试做出判断，并用于下一周期的质量评价。 

所述步骤B进一步包括： 

B1、把A步骤中的故障数输入Logistic模型； 

B2、利用迭代算法计算Logistic模型的最大值，作为软件中含有的故障总数的估计； 

B3、计算出下一个测试周期发现的故障数。 

所述步骤C进一步包括： 

C1、用已经发现的故障数除以故障总数计算出软件的可信度； 

C2、根据软件可信度的达成情况，来判断软件是否需要继续进行测试； 

C3、在下一个测试周期结束时，通过比较发现故障的预测值和实际值，对本测试周期的质量情况进行评价。 

有益效果 

软件测试过程的质量评价和版本是否满足发布要求一直是业界的一个难题，本发明通过对软件故障发现过程的分析展示了Logistic模型在故障预测方面的价值。包括两个方面：一、通过对测试结果的预测分析，在每一个周期结束后可以进行质量评价；二、对软件的可信度测量，用于版本发布时对整个版本发布的质量进行考核。这两个方面的价值完成了对测试过程的监督和测试结果的评价。 

附图说明

图1是本发明辅助故障预测***FPBL总体框图。 

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。 

本发明所述的基于Logistic模型的软件故障预测技术包括三个步骤：第一步，把***测试过程按照一定的周期进行划分，度量出已经进行的测试周期内发现的故障数；第二步，利用Logistic模型计算出软件中含有的故障总数和下一个测试周期发现的故障数；第三步，软件的质量分析与评价，用软件中已经发现的故障数与软件含有的故障总数的比值作为软件的可信度，用于判断软件是否达到了发布要求；在下一个测试周期结束时，通过比较发现故障的预测值和实际值，对该测试周期的质量情况进行评价。 

参考图1是本发明辅助故障预测***FPBL的总体框图，该***包括三个模块：测试周期故障管理模块、Logistic模型度量模块、质量分析与评价模块。 

测试周期故障管理模块：负责划分测试周期，并统计各个测试周期内发现的故障数，该模块同时负责可信度预期结果的输入； 

Logistic模型度量模块：核心模块，负责Logistic模型的迭代算法，计算出软件中含有的故障总数和下一个测试周期预计发现的故障数； 

质量分析与评价模块：负责软件可信度的计算，并根据计算结果对软件是否可以发布做出判断；通过比较Logistic模型中计算的下一个测试周期的故障数和实际测试中发现的故障数，对一个测试周期的质量进行评价，输出评价结果。 

下面结合辅助故障预测***FPBL说明本发明的具体实施过程。 

为实现所述第一步，也就是完成FPBL中的测试周期故障度量，我们按照5个工作日为一个测试周期，计算出已经测试的各个周期的故障数，为了保证后续估计的准确性，我们建议至少有三个周期的数据，才能进行预测。每个周期内的故障数按照故障严重程度的加权值进行度量，故障依照严重程度区分为：严重、重要、一般、轻微，其对应的加权值分别为15、9、3、1，以下是某个大型软件在进行了七个周期测试后的故障度量数据： 

Week1	Week2	Week3	Week4	Week5	Week6	Week7
							962	1596	1955	2344	2450	2549	2615

用户对该软件的质量要求为可信度达到95％，该值可以通过界面输入，也在测试周期故障度量模块进行管理。 

为实现第二步，也就是辅助故障预测***FPBL中的Logistic模型度量，需要对该模型进行一些变换，以便于进行迭代计算。 

逻辑增长曲线模型，俗称“S曲线”，由Verhulst于1845年提出，当时的主要目的是模拟人口的增长，其一般的形式为： 

其中后来经过逐步的简化，目前最常用的形式是： 

$y=\frac{1}{a+{\mathrm{be}}^{-x}}$

也称为狭义的Logistic增长曲线模型。 

Logistic增长曲线模型成立的前提条件：1.当人口较少的时候，自然资源足够的丰富，人口的增长不受到约束，因此假定人口的自然增长率是常数；2.当人口增加到一定数量时，自然资源、环境条件等因素对人口增长的限制作用越来越显著，因此假定人口的自然增长率会随着人口的增加而减小。 

软件测试过程与Logistic模型进行类比：(1)用软件中变化的代码量类比人口增长模型中的自然资源、环境条件等客观因素，变化的代码量包括两个方面：(a)当前的版本和它的基线版本的代码差异；(b)发现的Bug的修改导致的代码差异。这些变化了的代码是故障产生的客观因素，相当于一个外部的环境。测试的初始阶段，由于代码的变化量非常大(相当于资源非常丰富的状态)，故障的增长率不受约束，可以假定为一个常数；(2)发现的故障数类比当前的人口数量，这个数量随着代码量的变化而变化，同时又受到它的制约。当测试进行到一定的阶段，版本的变化越来越小，即代码的变化量越来越小，这个时候发现故障的速率就会受到约束，呈下降的趋势。以上分析可以看出软件测试过程发现的故障满足Logistic模型的前提条件，因此可以用Logistic模型进行度量。 

算法的基本思想是预设一个N_m，求得r的最优估计，然后把r作为已知，求出N_m的最优估计，这样交替循环迭代直到收敛为止。 

记：于是有： 

因存在模型误差，应以下述带误差的方程代替 

从而在N_m已知条件下，可得参数r最小二乘估计： 

同理应由下式代替上式： 

$N_t=N_m/(1+(\frac{N_m}{N_0}-2)e^{-\mathrm{rt}})+{\mathrm{\ϵ}}_t$

式中σ_t为独立，均值为0，等方程的随机变量，记 

$y_t\≡\frac{(e^{\mathrm{rt}}-1)N_0{N}_t}{N_0{e}^{\mathrm{rt}}-N_t},{\mathrm{\σ}}_t\≡\frac{N_0{e}^{\mathrm{rt}}+N_m-N_0}{N_0{e}^{\mathrm{rt}}-N_t}$

则y_t＝N_m+σ_tε_t，由此在r已知条件下可德增长极限N_m的极大似然估计： 

$\widehat{N_m}=\left(\underset{i=1}{\overset{n}{\mathrm{\Σ}}}\frac{1}{{{\mathrm{\σ}}_i}^2}{y}_i\right)/\left(\underset{i=1}{\overset{n}{\mathrm{\Σ}}}\frac{1}{{{\mathrm{\σ}}_i}^2}\right)$

这里σ_i中含有被估参数N_m，在迭代解法中，我们可用上一次的迭代值N_m代替它。 

最优估计N_m，r的具体算法步骤如下： 

1.取初始值N_m，r精度为ε，N_m代入： 

求得r⁽⁰⁾

2.令k:＝1,a:＝N_m ⁽⁰⁾,b:＝r⁽⁰⁾。b代入其中 ${\mathrm{\σ}}_t\≡\frac{N_0{e}^{\mathrm{rt}}+N_m-N_0}{N_0{e}^{\mathrm{rt}}-N_t},$ 求得N_m ^(k)，N_m ^(k)代入求得r^(k)。 

若|N_m ^(k)-a|+|r^(k)-b|≤ε，则停止，此时有N_m ^*＝N_m ^(k),r^*＝r^(k)；否则转“3”。 

3.a:＝N_m ^(k),b:＝r^(k)k:＝k+1,转“2”。 

通过以上算法，该步骤输出了软件的故障数N_m和下一个测试周期的故障数N_t+1。 

第三步、根据N_m和N_t+1进行软件的质量分析与评价。 

假定已经进行了I(I>＝3)个周期的测试，现在要对第I+1个周期进行预测和质量分析。故障单数预测从第四个周期开始，即我们至少要有三个周期的数据，少于三个数据时，预测结果偏差太大，无法使用。用已经统计出的I个值进行拟合，按照第二步的方法获得Logistic计算公式的各个参数值，以t＝I+1的公式计算值作为第I+1个周期的预测最小值min，以公式最大值作为第I+1个周期的预测最大值max，那么到第I+1个周期发现的故障总数应该落在区间[min，max]内。质量分析与评价的步骤如下： 

1.第I+1个周期测试结束后的质量分析。第I+1个周期测试结束后，假定发现的故障总数为Bugs，制定这样一个规则：(1)如果Bugs>＝max*0.98，则第I+1个周期测试质量为优；(2)如果min<＝Bugs<0.98*max，则第I+1个周期测试质量为良；(3)如果Bugs<min，则第I+1个周期测试质量为不合格。 

2.第I(I>＝3)个周期的可信度计算。用截止第I个周期实际发现的故障总数除以软件中故障总数的预测值作为第I个周期的软件的可信度，即Ri＝N(i)/N_m。软件是否满足发布要求的流程如下： 

a)给定可信度R′，R′的值根据对软件的要求而定； 

b)进行I轮测试，并计算该轮测试之后的软件的可信度R_i； 

c)如果R_i≥R′，则停止测试，软件即可发布；如果R_i<R′，则I＝I+1，转(b) 

通过上述三个步骤即可完成软件测试过程的质量评价和可信度度量，本发明通过对软件故障发现过程的分析展示了Logistic模型在故障预测方面的应用。包括两个方面：一、通过对测试结果的预测分析，在每一个周期结束后可以进行质量考核；二、可信度用于版本是否满足发布条件的判断，同时杜绝了过度测试造成的资源浪费。这两个方面实际上是对测试过程的监督和测试结果的评价。 

综上，本发明通过迭代算法计算出了Logistic模型的最大值和变化率，进而对软件含有的故障总数和下一个测试周期发现的故障数进行了预测，该两项预测值可以保障软件的测试质量，并有效降低软件测试成本。 

上述仅以优选实施例对本发明进行说明，非因此即局限本发-7-明的权利范围，利用Logistic模型对软件含有的故障总数和下一个测试周期发现的故障数进行预测是本发明的核心思想，因此，在不脱离本发明思想的情况下，凡运用本发明说明书及附图内容所为的等效变化，均理同包含于本发明的权利要求范围内。 

Claims (4)

1.一种基于Logistic模型的软件故障预测***，其特征在于所述***包括三个模块：测试周期故障管理模块、Logistic模型度量模块、质量分析与评价模块；

测试周期故障管理模块：划分测试周期，并统计各个测试周期内发现的故障数，该模块同时负责可信度预期结果的输入；

Logistic模型度量模块：负责Logistic模型的迭代算法，计算出软件中含有的故障总数和下一个测试周期预计发现的故障数；

质量分析与评价模块：负责软件可信度的计算，并根据计算结果对软件是否可以发布做出判断；通过比较Logistic模型中计算的下一个测试周期的故障数和实际测试中发现的故障数，对一个测试周期的质量进行评价，输出评价结果。

2.一种如权利要求1所述的基于Logistic模型的软件故障预测***的预测方法，其特征在于所述方法包括如下步骤：

A、采用测试周期故障管理模块把所述***测试过程按照一定的周期进行划分，并度量

出每个周期内发现的故障数；

B、利用Logistic模型计算出软件中含有的故障总数和下一个测试周期发现的故障数；

C、采用质量分析与评价模块用软件中已经发现的故障数与软件含有的故障总数的比值作为软件的可信度，用于判断软件是否达到了发布要求；

通过上述三个步骤计算出软件的故障总数，进而对软件是否需要继续进行测试做出判断，并用于下一周期的质量评价。

3.基于权利要求2所述的基于Logistic模型的软件故障预测***的预测方法，其特征在于所述步骤B进一步包括：

B1、把A步骤中的故障数输入Logistic模型；

B2、利用迭代算法计算Logistic模型的最大值，作为软件中含有的故障总数的估计；

B3、计算出下一个测试周期发现的故障数。

4.基于权利要求2所述的基于Logistic模型的软件故障预测***的预测方法，其特征在于所述步骤C进一步包括：

C1、用已经发现的故障数除以故障总数计算出软件的可信度；

C2、根据软件可信度的达成情况，来判断软件是否需要继续进行测试；

C3、在下一个测试周期结束时，通过比较发现故障的预测值和实际值，对本测试周期的质量情况进行评价。