為了發現數量眾多的Bug而歡呼？

        英文原文：Seth Eliot，編譯：一淘 – 惠如

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

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

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

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

        安息吧，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 在不同階段出現的數量及其原因，我也非常愿意加入到你們之中，并樂于接受這個結果。