2.5　估计软件缺陷检测和缺陷清除

在20世纪70年代IBM首先开始研究缺陷检测效率（DDE）和缺陷清除效率（DRE）时，这两个主题几近于同义词。能够找出缺陷的方法很多，如审查和测试。找出的缺陷会在应用程序交付给客户之前修复。那时候，软件应用程序的平均规模小于1000个功能点。

随着应用程序规模和复杂度的增长，缺陷检测效率和缺陷清除效率逐渐分离。对规模在100000个功能点的宏大应用程序而言，存在更多的缺陷。缺陷修复和回归测试变得更加费时。

为了能赶在交付日期完工，许多在测试周期后期发现的bug不会被修复，或者至少不会在应用程序发布之前做全面的回归测试。在发现的100个bug中可能有25个不能在交付日期前彻底修复。其结果是，像IBM这样的软件厂商总会在最初发布版本后紧跟着发布第二个版本，其中修复了那些之前未修复的bug。

实际上，IBM和一些其他公司发展出一种发布编号的方法，用来指示一个发布版本是主要针对新特性的，还是主要针对缺陷修复的。发布版本号为整数的，（如1.0、2.0、3.0等），主要是针对新特性。而发布版本号为小数的（如1.1、2.1、3.1等），则主要是针对bug修复。这不是一条定规，两种编号都有可能含有两种类型的更新，但其基本理念已为客户所熟知。

IBM对质量和及时修复的缺陷有着良好的跟踪记录，但并不是所有的提供商都是这样。其结果是，软件应用程序的最初版本在客户和顾客眼中成为高度不可信版本，因为他们都知道最初版本往往会有大量的潜在缺陷。

确实，有些客户由于怀疑潜在缺陷而不会租借或购买1.0版的软件包。一些厂商会将其软件的第1个版本命名为“2.0版”，试图避免客户的这种不情愿心理，但是这种做法谁也骗不了。

要让软件更有效地用于商业目的，大部分潜在缺陷都需要修复。很多大公司拥有相当成熟的维护团队来支持商用现成产品（COTS）。这些客户维护团队能够修复在安装和验收测试中遇到的严重缺陷。

因此，某些商业软件厂商在应用程序测试和集成的最后3个月中，修复发现的缺陷时开始漫不经心。其想法是留下应用程序中一些潜在bug可以加快交付速度。此外，由客户维护组来修复bug的成本比内部人员修复同样的bug的成本更低。

其结果是，2011年缺陷检测效率（DDE）和缺陷清除效率（DRE）之间有时会有非常大的差异。表2-14按应用程序规模说明了缺陷检测和缺陷清除间的现代差异。

如表2-14所示，缺陷检测效率和缺陷清除效率之间的差距随着软件应用程序总体规模的增长而不断增大。

这种检测和清除相脱节的结果是大型应用程序在几个月内不是非常可靠，直到交付时的大多数潜在缺陷被客户或开发人员（或两者)修复。

对质量估计和质量度量都很重要的问题是，既要知道测试前清除活动中的缺陷清除效率，又要知道测试中的缺陷清除效率。测试从来都无法非常高效地找出bug，而且单独使用时其成本也比较高。测试前的审查和静态分析的效率大概比测试要高25%。进一步的审查和静态分析能把测试效率提高5%左右。表2-15展示了一个测试前活动和测试活动样例的缺陷清除效率范围。

所有只有测试的组合都极少能达到85%以上的累计缺陷清除效率。要让累计缺陷清除效率达到95%以上，需要同时使用测试前缺陷清除活动和至少8种正式的测试。好在缺陷清除效率达到95%后比只进行测试的成本更低，工期更短。也就是说，不只是质量提高了，开发速度也加快了。