Bug分析：為bug預防奠定基礎

　　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更容易預防。事實是我們可以找到一些常見的問題，并采取相應的措施去預防它(或至少減少類似錯誤出現的次數)。

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