第29回 软件质量度量

软件产品质量度量是软件质量度量重要组成之一，其度量的对象是软件产品，测量其软件平均失效时间、缺陷密度、适用性、可靠性等产品的质量属性，用于对软件产品进行评价，并在此基础之上不断优化产品设计、产品制造和产品服务。

 
       软件产品质量度量包括软件复杂度、客户满意度的度量，由于篇幅所限，在此略去。 软件产品质量度量，则主要集中在软件缺陷的度量，而且这和软件测试有直接的关系。

质量是反映软件与需求相符程度的指标，而缺陷被认为是软件与需求不一致的某种表现，所以通过对测试过程中所有已发现的缺陷进行评估，可以了解软件的质量状况。也就是说，软件缺陷评估是评估软件质量的重要途径之一，软件缺陷评估指标可以看作是量度软件产品质量的重要指标，而且缺陷分析也可以用来评估当前软件的可靠性或预测软件产品的可靠性变化。

软件评估首先是建立基线，为软件产品的质量、软件测试评估设置起点，这个基准线上再设置测试的目标，作为对系统评估是否通过的标准。缺陷评测的基线是对某一类或某一组织的结果的一种度量，这种结果可能是常见的或典型的，如10000行源程序(LOC)是程序规模的一个基准，每一千行代码有3个错误是测试中错误发现率的基准。基准对期望值的管理有很大帮助，目标就是相对基准而存在，也就是定义可接受行为的基准，如表1所示。

表1某个软件项目质量的基准和目标

条目

目标

低水平

缺陷清除效率

>95%

<70%

缺陷密度

每个功能点 <4

每个功能点 >7

超出风险之外的成本

0%

>=10%

全部需求功能点

<1% 每个月平均值

>=50%

全部程序文档

每个功能点页数 <3

每个功能点页数 >6

 

软件缺陷评估的方法相对比较多，从简单的缺陷计数到严格的统计建模，基于缺陷分析的产品质量评估方法有以下几种：

• 缺陷密度——软件缺陷在规模上的分布
• 缺陷率——缺陷在时间上的分布
• 整体缺陷清除率
• 阶段性缺陷清除率
• 缺陷趋势、预期缺陷发现率
• 软件产品性能评估技术
• 借助工具的其他方法

1．缺陷密度

Myers有一个关于软件测试的著名的反直觉原则：在测试中发现缺陷多的地方，还有更多的缺陷将会被发现。这个原则背后的原因在于：如果缺陷发现缺陷多的地方、漏掉的缺陷可能性也会越大，或者告诉我们测试效率没有被显著改善之前，那么在纠正缺陷时将引入较多的错误。这条原理的数学表达就是缺陷密度的度量——每KLOC或每个功能点（或类似功能点的度量——对象点、数据点、特征点等）的缺陷数，缺陷密度越低意味着产品质量越高。

• 如果缺陷密度跟上一个版本相同或更低，就应该分析当前版本的测试效率是不是降低了？如果不是，意味着质量的前景是乐观的；如果是，那么就需要额外的测试，还需要对开发和测试的过程进行改善。
• 如果缺陷密度跟上一个版本高，那么就应该考虑在此之前为显著提高测试效率进行了有效的策划并在本次测试中得到实施？如果是的，虽然需要开发人员更多的努力去修正缺陷，但质量还是得到更好的保证；如果没有，意味着质量恶化、质量很难得到保证。这时，要保证质量，就必须延长开发周期或投入更多的资源。

2．缺陷率

缺陷率的通用概念是一定时间范围内的缺陷数与错误几率（OFE，opportunities for error）的比值。前面我们已经讨论过软件缺陷和失败的定义，失败是缺陷的实例化，可以用观测到的失败的不同原因数目来近似估算软件中的缺陷数目。

软件产品缺陷率，即使对一个特定的产品，在其发布后不同时段也是不同的。例如，对应用软件的角度来说，90%以上的缺陷是在发布后两年内被发现出来，而对操作系统，90%以上的缺陷通常在产品发布后需要四年的时间才能被发现出来。

 

3．整体缺陷清除率

　　让我们先引入几个变量，F为描述软件规模用的功能点；D1为在软件开发过程中发现的所有缺陷数；D2为软件发布后发现的缺陷数；D为发现的总缺陷数。因此，D=D1+D2。

　　对于一个应用软件项目，则有如下计算方程式（从不同的角度估算软件的质量）：

• 质量 = D2/F；
• 缺陷注入率 = D/F；
• 整体缺陷清除率= D1/D；

假如有100个功能点，即F=100，而在开发过程中发现了20个错误，提交后又发现了3个错误，则：D1 =20，D2 =3, D= D1+D2 =23

• 质量(每功能点的缺陷数)=D2/F= 3/100= 0.03 ( 3% )
• 缺陷注入率= D/F= 20/100= 0.20 ( 20%)
•  整体缺陷清除率= D1/D= 20/23= 0.8696 ( 86.96%)

有资料统计，美国的平均整体缺陷清除率目前只达到大约85%，而对一些具有良好的管理和流程等著名的软件公司，其主流软件产品的缺陷清除率可以超过98%。

众所周知，清除软件缺陷的难易程度在各个阶段也是不同。需求错误、规格说明、设计问题及错误修改是最难清除的，如表2所示。

表2 不同缺陷源的清除效率

缺陷源

潜在缺陷

清除效率(%)

被交付的缺陷

需求报告

1.00

77

0.23

设计

1.25

85

0.19

编码

1.75

95

0.09

文档

0.60

80

0.12

错误修改

0.40

70

0.12

合计

5.00

85

0.75

表3反映的是CMM五个等级是如何影响软件质量的，其数据来源于美国空军1994年委托SPR（美国一家著名的调查公司）进行的一项研究。从表中可以看出，CMM级别越高，缺陷清除率也越高。

表3 SEI CMM级别潜在缺陷与清除率

SEI CMM 级别

潜在缺陷

清除效率(%)

被交付的缺陷

1

5.00

85

0.75

2

4.00

89

0.44

3

3.00

91

0.27

4

2.00

93

0.14

5

1.00

95

0.05

 

4．阶段性缺陷清除率 

阶段性缺陷清除率是测试缺陷密度度量的扩展。除测试外，它要求跟踪开发周期所有阶段中的缺陷，包括需求评审、设计评审、代码审查。因为编程缺陷中的很大百分比是同设计问题有关的，进行正式评审或功能验证以增强前期过程的缺陷清除率有助于减少出错的注入。基于阶段的缺陷清除模型反映开发工程总的缺陷清除能力。

进一步分析缺陷清除有效性(DRE，Defect Remove Efficiency)，DRE可以定义为：

开发阶段清除的缺陷数/产品潜伏的缺陷总数 x 100％

因为潜伏缺陷的总数是不知道的，必须通过一些方法获得其近似值，如经典的种子公式方法。当用于前期的和特定阶段的时候，此时DRE相应地被称为早期缺陷清除有效性和阶段有效性，对给定阶段的潜伏缺陷数，可以估计为：

                   当前阶段的潜伏缺陷数 = 当前阶段排除的缺陷数＋以后发现的缺陷数

给定阶段的DRE度量值越高，遗漏到下一个阶段的缺陷就越少。

         缺陷是在各个阶段注入到阶段性产品或者成果中去，通过表4 描述的与缺陷注入和清除相关联的活动分析，可以更好地理解缺陷清除有效性。回归缺陷是由于修正当前缺陷时而引起相关的、新的缺陷，所以即使在测试阶段，也会产生新的缺陷。

 

表 4 与缺陷注入和清除相关联的活动

开发阶段

缺陷注入

缺陷清除

需求

系统/概要设计

详细/程序设计

编码和单元测试

集成测试

系统测试

验收测试

需求收集过程和功能规格说明书

设计工作

设计工作

编码

集成过程、回归缺陷

回归缺陷

回归缺陷

需求分析和评审

设计评审

设计评审

代码审查、测试

构建验证、测试

测试、评审

测试、评审

 

      清除的缺陷数等于检测到的缺陷数减去不正确修正的缺陷数。如果不正确修正的缺陷数所占的比例很低（经验数据表明，测试阶段大概为2％），清除的缺陷数就近似于检测到的缺陷数。

友情链接：http://www.csdn.net/community2006/vote/index.rails?id=1

预知后事如何，请读下回分解：第30回 总结

版权所有，软件测试演义^® ——系列讨论的目录，见： 软件测试演义——中高级系列（序）