這不是一篇關(guān)于軟件測試人員的工作評論方面的文章。最近參加了一個測試總結(jié)會，至少在兩個項目匯報過程中發(fā)現(xiàn)，開發(fā)管理者感興趣的一個度量指標是：你們發(fā)現(xiàn)了多少個bug？然后，當?shù)玫降幕卮鹗且粋€很高的數(shù)目或是一個很嚴重的缺陷（如：3個嚴重的bug?。?，就會得到熱烈的鼓掌。

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

“在我們的產(chǎn)品中，我們在設(shè)計和實現(xiàn)過程中出現(xiàn)了多少嚴重的缺陷？”“僅僅3個？”“太棒啦?。ü恼疲?rdquo;

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

[[97427]]

安息吧，bug！ 

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

三個階段

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

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

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

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

階段1的質(zhì)量

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

階段1的質(zhì)量指標：

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

階段2的質(zhì)量

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

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

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

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

階段3的質(zhì)量

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

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

結(jié)論

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

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