为什么说缺陷去除效率比测试缺陷率更适合软件质量度量？

很多实施了GJB5000A的组织的测量指标体系中，只有基于代码行的测试缺陷例，组织同时也把它作为衡量软件质量的指标。比如，在质量目标中要求软件测试缺陷率应小于2Bug/Loc。

但是，测试缺陷率作为衡量软件质量的指标，存在很多问题，比如：

• 基于代码行的测试缺陷率可能并不准确。

代码行数作为软件规模的度量指标本身就不准确，这直接导致测试缺陷率也不准确。代码行数不准确，至少有以下两个情况：一种情况是对于某些编程语言，使用物理行数和逻辑语句数的计算结果是相同的．但对其他编程语言来说，这两种方法的计算结果差异可能会高达5倍。另一种情况是，对于许多编程语言，如VB，大量编程工作使用按钮和下拉式菜单的方法完成。因此，编程是在没有涉及程序源代码的情况下完成的。目前，还没有有效规则来计算这种语言的源代码数量。

• 测试缺陷率只能反映对应测试活动的水平

测试级别有单元测试、集成测试、配置项测试、系统测试、验收测试等。每种测试级别都有它的缺陷率。测试缺陷率只能表明每种测试活动发现的缺陷数的多少，即使是第三方测评。

另一方面，缺陷去除方法不只几种测试。需求、设计的审查也是缺陷去除方法，而且是比测试更有效的方法。测试缺陷率这个定义却度量不了需求和设计审查的水平。

• 测试缺陷率这一指标没有站在用户视角

对于用户来说，他不关心软件研制过程中发现多少缺陷，他只关心，使用软件的过程中，软件会不会出问题。测试缺陷率对于用户来说并没有什么实际意义。

在《软件工程最佳实践》书中，认为应使用潜在缺陷和缺陷去除效率，来衡量软件质量水平。

先让我们来了解下什么是缺陷去除效率。

缺陷去除效率（DRE，Defect Removal Efficiency ），顾名思义，就是度量缺陷去除方法去除缺陷的绩效。通过下面的例子，可以更好地理解缺陷去除效率的具体含义。

其中用户发现的缺陷数一般是在使用90天后所发现的缺陷。

这个例子中，整个系统的DRE=（13+10+12+23）/63=92%(即：整个系统的缺陷去除效率就是软件研制过程中从需求阶段开始使用的各种缺陷去除方法去除的缺陷总和除以总的缺陷数)。

度量DRE，眼见的就有以下好处：

• DRE可以衡量不同的缺陷去除方法的缺陷去除效率，而不仅仅是测试

• DRE可以用于软件质量水平的预测和控制

关于缺陷预测，有很多复杂的模型算法。比较简单的预测是积累经验数据。通过度量DRE，可以积累不同规模不同种类的软件缺陷数据，通过这些经验数据可以预算软件的质量水平。假设预测软件的缺陷数据为63个，依据经验数据需求分析审查应该去除13个缺陷，而实际上只去除了5个缺陷，那就可能是需求分析审查的绩效出了问题。这时就应该采取一些补救措施，比如找领域专家、其他专家来补充审查。

缺陷去除效率度量的价值包括以下几点：

• 发现利修复缺陷是任何软件开发中最昂贵的活动，因而降低这些成本将带来巨大的投资回报。

• 过多缺陷是造成软件项目进度延误的主要原因，因而在所有可交付物中降低缺陷将缩短开发周期。

• 交付缺陷是发布之后头两年软件维护的主要工作．故提高缺陷去除效率可以降低软件维护成本。

• 客户满意度与交付缺陷数目成反比关系，故降低交付缺陷数目将直接取悦客户。

• 团队士气与有效的缺陷预防和缺陷去除水平成正比关系。

如前所述，度量软件缺陷去除效率的方法并不复杂。实际上，仅需如下12步就能量化缺陷去除效率：

与这些信息的价值相比，度量缺陷去除效率水平所需要付出的努力和成本微不足道。

这正是：

缺陷度量意义大，指标不当也抓瞎

质量评估和控制，缺陷去除必有它

参考书目：《软件工程最佳实践》