3.2.6　单位缺陷成本度量

前面提到过，单位缺陷成本对质量是不利的，因为对于bug最多的软件来说单位缺陷成本的度量结果是最低的。随着质量的提升和缺陷的减少，单位缺陷成本提高了，而且当达到零缺陷的时候，单位缺陷成本会变得无穷大。

尽管被广泛使用了超过50年之久，单位缺陷成本度量方法是非常不可靠的，并且在一些条件下在经济上是无效的。流行的软件秘闻“发布后bug修复成本是开发时修复成本的100倍”和它的诸多变种已经变得很普通，但是它们在很多情况下是不准确的。更准确的说法是，单位缺陷成本度量方法在数学上是有效的，但是在经济上是无效的。这看上去像是一个悖论，因此需要一些解释和例子。

单位缺陷成本度量方法的一个问题是它忽略了固定成本，因此可能产生违反直觉的波动。这里有两个简化的例子来说明这个问题。

案例1：假设有一个开发得比较差的Java程序在被测试中，它具有25000LOC，测试中发现了500个bug。假设测试准备成本是5000美元，测试执行成本是20000美元，bug修复成本是25000美元。整个测试周期的成本是50000美元，于是这500个bug的单位缺陷成本是100美元。

案例2：假设应用程序使用了现代的缺陷预防方法和测试前静态分析方法，于是测试中发现的bug数目只有50个，而不是500个，这是一个数量级的提升。这里，测试准备成本是5000美元，测试执行成本是17500美元，bug修复成本仅为2500美元。但是，这50个bug的单位缺陷成本提高到了500美元，也就是低质量例子中的5倍！

很明显，测试用例准备是固定成本，测试用例执行也比较没有弹性且只部分依赖于遇到的缺陷数目。

正如我们看到的那样，单位缺陷成本度量方法随着质量的改进而逐步上升，并没有反映高质量真实的经济优势。

单位缺陷成本随着缺陷数目的减少而上升的基本原因是固定成本的存在。即使发现的缺陷更少甚至是没有发现缺陷，你还是必须创建测试用例和运行测试用例。

一个较大的例子可以说明固定成本的影响，以及单位缺陷成本和单位功能点缺陷修复是如何对相同数目的缺陷和相同的修复进行响应的。

假设有一个软件项目的规模为100个功能点，恰好含有100个缺陷。假设你会使这个项目进入一系列连续的6个测试步骤中，每个步骤有50%的效率并且能找出一半的缺陷。

假设对于这6个测试步骤中的每一个，测试用例的准备成本都是500美元，测试用例的执行或运行成本也是500美元。这些是固定成本，而且在这个案例研究的例子中不发生变化。

现在再假设对于遇到的每个缺陷，都要花费100美元来修复。这也是该例中的固定成本。当准备和执行成本是情景中的一部分时，让我们考查一下这6个阶段的测试。在这里你可以清楚地看到软件传奇“在开发周期末期缺陷的修复成本是开发开始时修复成本的10倍”的起源。

准备和执行的固定成本逐步遮蔽了可变的修复成本。这意味着一方面，随着发现的缺陷的减少，单位缺陷成本会增加。另一方面，总成本和单位功能点成本符合真实的经济观察，即成本随着缺陷数目的下降而下降。

当项目发布给客户和维护开始时，单位缺陷成本会变得更大，因为至少需要培训一个人来维护该软件。而且，这个人必须花费一些时间来回答客户的问题和在安装和初始化阶段协助客户完成工作。

下面的数据假设在使用的第一年中，只报告了一个bug或缺陷，但是为客户提供了一个培训过的支持人员，他负责在第一年中协助客户进行安装和回答初始化的问题。

我们可以看到这个系列的数据流，单位缺陷成本随着缺陷数目的降低而增加了。受固定成本的影响，这个现象与真实的经济情况是相反的，真实的经济情况是缺陷修复成本降低了。

刚才展示的数据对每个修复的缺陷使用了100美元的常量。但是，当包含了固定和无弹性的成本时，表面的单位缺陷成本从清除周期早期的120美元变化到发布后的3600美元，后者与前者之比为30：1。如果项目是商业软件，要考虑领域服务的问题，那么这个比值很容易达到100：1。

相比之下，使用“单位功能点缺陷修复成本”分析测试和维护的经济效果，能更加清楚地看到质量的真实价值以及固定成本和可变成本是如何互相作用的。

尽管单位缺陷成本度量方法有经济学的缺点，但是关于下游的缺陷修复成本稳定增长的报告，常常会导致人们使用测试前的审查、静态分析，以及改进的测试用例设计和测试方法。这个方法很有趣，它有缺陷但产生了一些有益的结果。