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