2.8.6　案例C：零缺陷

在这第3个案例中，假定测试者花费15个小时来编写测试用例，并用10个小时来运行它们：总计25个小时。没有发现bug或缺陷，所以缺陷修复的实际成本为0。

因为没有发现缺陷，所以单位缺陷成本度量方法就根本无法使用。但是25个小时的实际工作量花在了编写和运行测试用例上。如果软件工程师没有其他任务，他还是会一周工作40小时，成本是2500美元。

如果不计入那闲散的15个小时，保留25个小时来做实际的测试，那么成本将是1893.75美元。不计闲散的时间，每个功能点的成本是18.38美元。但由于是零缺陷，单位缺陷成本无法计算。

缺陷修复的时间和行为研究无法支持格言“发布后修复bug的成本是发布前修复成本的100倍”。无论在哪里发现bug，修复它需要的时间通常都在15分钟到6小时之间。

（某些bug代价高昂，可能需要几天甚至更长的时间才能修复。IBM称之为暂缓的（abeyant）缺陷。暂缓的缺陷是那种客户报告的、在修复中心由于缺少客户现场某些特定硬件和软件的组合而无法重现的缺陷。暂缓的缺陷占客户报告缺陷的比例小于5%。）

考虑到单位缺陷成本成为使用最广泛的质量度量方法的时间已经超过50年，但关于什么活动会被纳入单位缺陷成本度量方法，文献却惊人地含糊不清。使用了单位缺陷成本的文章和书籍超过75%都没有明确说明准备和执行成本是计入还是排除。实际上，大部分文章根本没有作任何解释，而仅仅是给出数字，也没有讨论其涵盖了哪些活动。

另外一个主要不足是文献都不提及不同严重级别的缺陷的单位缺陷成本差异。一位IBM专家的研究表明了与严重级别相关的缺陷修复时间的差异。

表2-26展示了该研究结果。因为这些都是客户报告的缺陷，所以“准备和执行”是由客户来做的，其花费的时间也没有报告给IBM。

可以看到，虽然分布相对广泛，但总平均值近似为5个小时。

表2-26中，严重度1的缺陷意味着软件不能工作了，严重度2意味着主要的功能失效了，严重度3是指较小的缺陷，严重度4的缺陷是那些装点门面的功能缺陷，不影响使用，无效缺陷是指被无意中误报为缺陷的硬件问题或客户错误。处理无效缺陷所花费的时间和工作量令人吃惊，尽管在质量文献中鲜有提及。有时几个小时的研究发现某个缺陷并不是软件而是由其他因素引起的，如硬件、竞争性的其他软件或者电力激增。