軟件測試管理中bug預防的重要性及其分析

軟件測試管理中bug預防的重要性及其分析 　

1．引言：

　　生產軟件的企業安排很多人來測試它們的軟件產品。測試的目的就是發現bug（缺陷，defect）以便修正它們。正常情況是盡快處理可能的bug，從而減少修正bug的成本。因為，眾所周知，bug越早被發現并修正，所消耗的資源越少。問題是在很多情況下，由于修正已發現的bug，測試過程不得不停頓下來。

　　那么，以目前正忙于軟件產品測試的同樣資源來促進組織長期的質量目標不是更好？為了做到這一點，我們應該盡快地提前發現可能的bug。就像克勞士比（Philip Crosby）幾年前所說的那樣，我們應該努力預防bug，而不僅僅是修正它們。這就是真正的質量。

　　2．目標：預防bug

　　預防的重要性:

　　正如我們所知，bug應該盡早地在開發過程中被發現。修正處于開發階段產品的bug的成本遠遠低于修正處于QC（Quality Control，質量控制）階段的產品的bug，而相對與修正已經發布給客戶的產品的bug的成本更是可以忽略不計。原因就是當你修正一個bug的時候，相當于把你之前做的事情重做一次。因此，越晚修正bug，你所重做的事情就越多。如果bug修正是在產品測試之前，那么重做的工作只有代碼實現。如果bug修是在測試階段，那么重做的工作就包括代碼實現和測試。另一個導致成本增加的因素是依賴的組件和流程（process），隨著項目的進行，產品依賴的組件和流程也會隨之增加。

　　接下來，從另一個層面來討論這個問題。如果bug發現和修正越早，開發成本越少，那么在第一時間就避免bug引入是不是成本消耗得更少？如果bug可以被完全預防，那么在開發過程中就不會出現重復工作的情況。這個被克勞士比極力推薦的觀點非常有意義，而且在很多情況下已得到嚴密的證實。然而，并不是所有的生產軟件產品的組織都試著去避免bug。它們花費了大部分的精力在產品發布給客戶之前發現和修正其中的bug。在某些情況下，軟件企業并不試著去達到這樣的目標。在產品發布之后，企業通過迅速修正產品中的bug來處理客戶的抱怨。這是因為，這樣的企業始終處于“問題解決模式”，它們并不試圖發現問題的根本原因，而只是把局部的大火撲滅。

　　這種模式并不僅僅導致重復工作直接帶來成本的增加，而且會帶來一個長期效應，而這將影響企業的業務。首先，發布帶有bug的產品將給企業的聲譽造成影響，并可能造成對潛在客戶的影響——他們在是否建立合作關系上拿不定主意。另外，由于企業需要資源來不斷解決現有產品中的問題，那么開發新產品的資源勢必減少。

　　對很多人來說，零缺陷的軟件產品似乎是不切實際的。我們總是聽到軟件開發者說：“軟件永遠有bug”。產品進入QC階段時含有bug并不奇怪，因為我們“ 期望”開發人員制造bug。不幸的是，發布一個包含很多bug的產品給客戶仍然不令人感到驚訝。甚至連客戶本身也不再感到驚訝。

　　事實上，每個軟件企業都可以通過一些簡單的方法，在不增加任何額外資源的情況下預防bug。bug預防在于一個簡單的道理：最好的方法是適當借鑒我們自己的經驗。

　　今天的發現就是明天的預防

　　為了能夠預防bug，我們必須首先了解bug的來源。軟件bug可以分為幾個類別（可能相互之間有所重疊）。第一類bug可能是隨機的，它們通常是因為一時的疏忽造成的。盡管這些bug可能由于其隨機性很難預防，但是，適當的分析將有助于避免這些bug。

　　另一類的bug來自于需求的誤解、開發環境的錯誤或者純粹由于缺乏解決問題的相關技術。這類bug共同的特點是都來自于開發人員。除非被發現，否則這些bug將一直存在。例如，一個還不完全理解需求的開發工程師在單元測試階段可能無法發現這些問題，只有當產品被其他組織（如QC組）測試時才會發現產品實現與需求不一致。這使得在前期避免類似問題的出現更加重要。

　　一個好消息是，軟件中的bug往往傾向于重復出現，即使是一個隨機出現的bug。軟件bug的不斷出現不僅表現在同一個開發人員的工作上，而且表現在一個項目甚至是企業的層面上。這當然不是說公司中的每一個開發人員都會犯同樣的錯誤。但是，至少其中一些的錯誤足以成為經常性出現的問題。所以，為什么我們認為重復的錯誤是一個好消息？因為可以預見的bug更容易預防。事實是我們可以找到一些常見的問題，并采取相應的措施去預防它（或至少減少類似錯誤出現的次數）。

　　人為bug的子集？那么這些bug被預防的可能性更大。域bug？域bug和產品的問題域或解決方案域緊密相關。這樣的bug有更大的機會重現，因為開發人員、項目組甚至企業不斷地在這個域上工作。

　　現在的問題是如何預防各種bug的產生?；谶@次討論的目的，我建議我們設定一個更加實際的目標。讓我不要考慮完全預防某個bug，而是將目標設為——預防我們已經知道有一定可能性產生的Bug。這意味著我們可以通過我們各種發現bug的活動來促進將來的bug預防。當某個bug被發現時，我們就有了一個很好的機會來阻止類似問題的發生。

　　前提：記錄bug

　　前提條件是持續跟蹤發現的bug并正確地記錄它們，離開了這個前提條件將不能將bug發現作為一個工具來預防bug。不論你使用bug跟蹤系統,還是只手寫了一個報告總結測試的結果，重要的是保存這些數據以便用于后來的分析。

　　在分析bug時，bug記錄的問題值得注意。bug的定義越廣泛，bug分析的數據越有用。報告bug的測試人員應該明白這一點，并不限于狹義上的 bug?？赡艿脑?，測試人員應該運用他們的經驗對bug產生的原因做最初的假設。我們將稍后在闡述分析過程時討論這個問題。

　　和記錄bug同樣重要的是bug分析的第一步。僅僅跟蹤過去的bug不能預防bug的發生，因為許多不同的bug可能來源于同一個核心問題。不同于信息收集，適當地分析bug的原因對bug預防非常有用。

　　3．缺陷分析

　　目標

　　在上一節，我們說明了bug分析的理由。如上所述，最終目標是預防bug而不是修正它們。然而，我們可以定義一個重要的子目標，這就使不斷提高整個開發團隊（包括QC組）的技能和實踐經驗。當然，這兩個目標是息息相關的。離開了不斷的知識累積，也不能實現bug預防。不過，我覺得有必要提及這個子目標以強調持續性的過程。bug預防并不是一個不切實際的目標。但是，你不能期望它在一夜之間發生。你應該為開發小組提供教育和知識，以使他們逐漸改善他們的工作。

　　策略

　　本次討論的焦點——bug預防策略非常簡單和容易實現。

　　秘訣就是使用在大多數開發環境中已經存在的過程元素。我們不會介紹任何新的花費昂貴的活動，也不會引入一些新的角色到開發過程中。

　　我們的策略是發現bug，找出bug的根源，然后尋找一個方法來預防類似的bug在將來出現。因為QC過程已經用于在目前的產品中發現bug，因此該策略的大部分工作實際上已經執行，大多數開發過程缺少的正是分析在QC過程中發現的bug。正如你將看到，盡管策略的這一部分并不需要昂貴的花費，但是卻帶來了極大的額外價值。

原文轉自：http://www.anti-gravitydesign.com