Dan在一个有着其他四个成员的项目中做开发人员。他们在项目开始的前八个月只开发产品，不修复任何缺陷，除非缺陷阻塞他们继续开发。Dan和他的团队认为同时修复所有缺陷是更节省成本的。因此在第九个月，即预期发布的前一个月，他们觉得是时候修复缺陷了。
Avery在一个与市场实际同步的公司当项目经理。由于受到限制，所以每个客户都马上要一个β版本，这样他们可以尽快开始使用软件。考虑到一个有着许多缺陷的β版本将使他们的客户愤怒，Avery认为，让开发人员在系统测试之前就开始查找和修复严重缺陷是更节省成本并且是低风险的。
两个项目对于查找和修复缺陷使用两种完全不同的方法。我们对于修复缺陷都有不同的看法，尤其是什么时候修复哪些缺陷。选择是否修复缺陷取决于很多因素，如：开发的产品类型；携带已知或未知缺陷的风险；开发过程；当确定修复缺陷时，需要多少成本。
其中最容易理解的一个因素是修复一个缺陷的实际成本。这个成本反映到选择的开发生命周期、开发过程，并帮助你在可以承受的风险内决定提交或不提交产品。然而，事实上很多人都不知道修复一个缺陷需要花费多少成本。如果你也没有把握，那么这里有一个用来测量这项成本的估算方法。
在系统测试的时候，人们全身心投入于查找和修复缺陷，可以计算出缺陷的数量。你知道多少人（开发人员、测试人员以及其他任何人）在做这个项目，你也知道系统测试的持续时间。有了这些数据，你就可以计算出项目在这个阶段修复一个缺陷的成本。可以通过下面的公式计算查找和修复一个缺陷的平均成本。
修复一个缺陷的平均成本＝（人员数量×天数）×平均人日成本/修复的缺陷数量
注意：“发现”的缺陷数量不具备足够的信息，而应该使用“修复”的缺陷数量。发现缺陷只是第一个步骤。定位错误、决定如何修复、开发人员测试（又名单元测试）修复的内容、系统测试修复项、寻找由这个缺陷引起的其它缺陷，所有这些都是为什么使用“修复”数值是如此的重要。让我们看一些例子。在这些例子中，我假设每人日成本是500美元。
Dan的项目在系统测试时，暴露了大量的缺陷，虽然大部分缺陷是容易修复的，但是还有一些缺陷需要花很长时间。Avery的项目在系统测试时暴露出非常少的缺陷，但是由于发现每个缺陷的时间间隔是如此的长，所以似乎是花很长时间在修复一个缺陷。使用上面提到的计算公式，表1是Dan和Avery项目系统测试的数据。
只要你回顾一下项目的整个框架，就可以看出这项度量对系统测试修复缺陷成本的估算是有益的。但是，我们注意到Avery项目的修复成本是很高的。实际上，Avery的项目是以非常低的让客户失望的风险到达β发布日期（在系统测试的20个工作日）。Dan的项目花了两个月（40个工作日）的测试时间，虽然修复了125个缺陷，但是他们仍然有超过300个的缺陷没有修复。因为Dan的团队在系统测试前很努力地在预防缺陷，所以Avery的项目是节省成本的。因为Avery的团队预先发现并修复了大部分的缺陷，所以实际上使用上面的估算技术，他们修复缺陷的成本在系统测试中被大大放大。因为Avery的项目在系统测试之前发现并修复了大部分的缺陷，所以上述估算技术是不合理的。Avery项目能够用计算出实际查找和修复缺陷的成本来代替估算值。Avery平均使用了8个小时的系统测试时间来查找和修复一个缺陷。表2是对Avery系统测试成本更实际的估算。
文章来源于领测软件测试网 https://www.ltesting.net/