這不是一篇關于軟件測試人員的工作評論方面的文章。最近參加了一個測試總結會，至少在兩個項目匯報過程中發現，開發管理者感興趣的一個度量指標是：你們發現了多少個bug？然后，當得到的回答是一個很高的數目或是一個很嚴重的缺陷（如：3個嚴重的bug！），就會得到熱烈的鼓掌。

不過，我感覺這樣做是不對的！我的第一反應是，好吧，讓我換種說法……

“在我們的產品中，我們在設計和實現過程中出現了多少嚴重的缺陷？”“僅僅3個？”“太棒啦！（鼓掌）”

或者是：“哦，測試團隊，你找出了多少個我們程序的致命錯誤？”“才3個？”，帶著得意的笑容，“感謝測試團隊（鼓掌）”

[[97427]]

安息吧，bug！ 

這表明，詢問“多少個bug？”是種錯誤的方法，像這樣的事情，我一旦發現會嚴厲地批評。但后來我意識到，這個特有標準的誘惑也曾讓我深受其害，不僅在我過去無知的歲月中，甚至更多的是現在。為什么呢？對“多少個bug”的有效性來說，這意味著什么呢？ 下面是我的一些觀點。

三個階段

軟件開發的生命周期可以按多種不同的方式進行切分。在這里，按我的觀點，我會把它描述成3個階段（見上圖）。

•  階段1：設計、開發、單元測試
•  階段2：功能測試、上線前的評估測試：性能測試、壓力測試、使用場景模擬
•  階段3：線上監控、線上測試、客戶反饋

上面列出來的項目是我們在每個階段參與的以質量為中心的活動。

當我們詢問發現了多少bug的時候，我們是針對第二階段。所以問這個問題本身不是錯誤的，錯誤在于我們忽略了第一和第三階段質量的影響和貢獻。

階段1的質量

在這篇博客開頭，我開了一些玩笑，我現在想說的是第二階段的高bug數意味著第一階段質量下降。當開發總是主導設計，一個可靠的質量將會來自測試（系統的可用性和可測性）和項目管理（客戶至上）的貢獻。開發完成的質量不僅僅依賴于好的開發經驗，當測試驅動開發（TDD）被用上的時候，還跟單元測試緊密相關。除此之外，單元測試也能讓我們對“所得是否所需”有個最基本的了解。

階段1的質量指標：

• 開發和測試、PM一起展開設計評審（雙重檢查）；
• 需要結對review的代碼的百分比。我的觀點是--100%。這不僅是為了指出代碼中的錯誤，更是一種重要的方式，能讓高級開發人員指導更多初級開發人員使用更好的開發經驗，比如采用設計模式和代碼重用；
• 單元測試代碼覆蓋率。咦，我有提到過？一些人可能會想象這是一個有爭議性的論斷。但就像bug的數目沒有盡頭，而是一個未知數一樣，代碼覆蓋率也是；
• 代碼覆蓋率缺口分析：那些沒有覆蓋的代碼，我們是否遺漏了什么？
• 靜態代碼檢查；

階段2的質量

我想闡明的一個主要觀點是：當許多軟件專業人員想到軟件質量的時候，他們就會想到這個階段。這種觀念的錯誤可以用一句諺語來概括：“質量不是測試可以測出來的”（如果有人知道這句諺語是誰說的，請告訴我下）。
這只是整個過程的一個階段。有很多階段1的質量評估方法在這有對應的部分：

• 測試計劃是否被開發和PM review？
• 測試代碼結對review的百分比；
• 集成測試代碼的覆蓋率（和往常同樣的說明）；

然后是這個階段特有的部分：

• 有記錄的測試結果：這個對性能測試和壓力測試尤為重要，因為它提供了我們所知的能在生產中接受的基準指標。
• 所發現的bug數目和嚴重程度。重點就在這了，因為它是一個有效的質量/風險指示器。但它不能放在真空中，它必須和第1、第3階段的結果在一起才能說明問題。
• 難道發現大量的、很嚴重的bug，就意味著超級有效的第二階段會把這個產品所有的風險排除？或者意味著階段1質量非常糟糕時，我們可以期望更多的災難折磨我們的客戶？
• 難道一個很少的bug數意味著我們階段2的工具是在浪費時間？或者意味著階段1非常給力然后帶來了高質量的代碼？

階段3的質量

我之前講過線上測試（TiP），它是一個有效的針對軟件產品的測試方法。這種方法的接受程度（不是方法本身）還有點新。然而線上監控就不新鮮了。亞馬遜就是一個很好的例子，快速開發和良好支撐的監控工具，加上其它工具使得亞馬遜能對產品發布作出快速響應（也就是補丁），這已經成為亞馬遜各種服務的質量保證制度的一部分。你也許會問，即使你能找到線上缺陷并快速修復，難道就允許將這些缺陷帶到生產中？“質量”，是的，你只要問問亞馬遜的用戶他們是否遇到過問題，或者看看亞馬遜的用戶滿意分數就明白了。

既然我們承認產品有一個合理的質量階段，那為什么不在第2階段把所有的問題找出來，而不用管第3階段呢？問題的答案是成本。如果我們嘗試用第二階段的大規模預先測試找到所有的問題，那我們就會因為不斷增加的成本而得到越來越少的回報。在前面兩個階段的基礎上，用上第3階段是一個合理的、劃算的方式，能讓各種產品的質量最大化。那對第二階段的bug數這意味著什么呢？它意味著我們應該非常強烈地意識到找出那些bug我們所付出的代價，并確保它有所值。

結論

那些曾由于對Bug數目感興趣，而被我在會議中嚴厲責罵的伙計們，在整個軟件開發生命周期（SDLC）中， 只要你們能夠承認Bug在不同階段出現的數量及其原因，我也非常愿意加入到你們之中，并樂于接受這個結果。

原文鏈接：http://testing.etao.com/node/654