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系統測試成本更實際的估算。
文章來源于領測軟件測試網 http://www.kjueaiud.com/