1、Bug分析為bug預防奠定基礎五 Bug分析：為bug預防奠定基礎Bug分析：為bug預防奠定基礎1引言：生產軟件的企業安排很多人來測試它們的軟件產品。測試的目的就是發現bug（缺陷defect）以便修正它們。正常情況是盡快處理可能的bug從而減少修正bug的成本。因為眾所周知bug越早被發現并修正所消耗的資源越少。問題是在很多情況下由于修正已發現的bug測試過程不得不停頓下來。那么以目前正忙于軟件產品測試的同樣資源來促進組織長期的質量目標不是更好？為了做到這一點我們應該盡快地提前發現可能的bug。就像克勞士比（hili Crosby）幾年前所說的那樣我們應該努力預防bug而不僅僅是修正它們。

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

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

4、僅僅導致重復工作直接帶來成本的增加而且會帶來一個長期效應而這將影響企業的業務。首先發布帶有bug的產品將給企業的聲譽造成影響并可能造成對潛在客戶的影響他們在是否建立合作關系上拿不定主意。另外由于企業需要資源來不斷解決現有產品中的問題那么開發新產品的資源勢必減少。對很多人來說零缺陷的 軟件產品似乎是不切實際的。我們總是聽到軟件開發者說：“軟件永遠有bug”。產品進入QC階段時含有bug并不奇怪因為我們“期望”開發人員制造bug。不幸的是發布一個包含很多bug的產品給客戶仍然不令人感到驚訝。甚至連客戶本身也不再感到驚訝。事實上每個軟件企業都可以通過一些簡單的方法在不增加任何額外資源的情況下預防bu

5、g。bug預防在于一個簡單的道理：最好的方法是適當借鑒我們自己的經驗。今天的發現就是明天的預防為了能夠預防bug我們必須首先了解bug的。軟件bug可以分為幾個類別（可能相互之間有所重疊）。第一類bug可能是隨機的它們通常是因為一時的疏忽造成的。盡管這些bug可能由于其隨機性很難預防但是適當的分析將有助于避免這些bug。另一類的bug來自于需求的誤解、開發環境的錯誤或者純粹由于缺乏解決問題的相關技術。這類bug共同的特點是都來自于開發人員。除非被發現否則這些bug將一直存在。例如一個還不完全理解需求的開發工程師在單測試階段可能無法發現這些問題只有當產品被其他組織（如QC組）測試時才會發現產品實

6、現與需求不一致。這使得在前期避免類似問題的出現更加重要。一個好消息是軟件中的bug往往傾向于重復出現即使是一個隨機出現的bug。軟件bug的不斷出現不僅表現在同一個開發人員的工作上而且表現在一個項目甚至是企業的層面上。這當然不是說公司中的每一個開發人員都會犯同樣的錯誤。但是至少其中一些的錯誤足以成為經常性出現的問題。所以為什么我們認為重復的錯誤是一個好消息？因為可以預見的bug更容易預防。事實是我們可以找到一些常見的問題并采取相應的措施去預防它（或至少減少類似錯誤出現的次數）。人為bug的子集？那么這些bug被預防的可能性更大。域bug？域bug和產品的問題域或解決方案域緊密相關。這樣的bug

7、有更大的機會重現因為開發人員、項目組甚至企業不斷地在這個域上工作。現在的問題是如何預防各種bug的產生。基于這次討論的目的我建議我們設定一個更加實際的目標。讓我不要考慮完全預防某個bug而是將目標設為預防我們已經知道有一定可能性產生的Bug。這意味著我們可以通過我們各種發現bug的活動來促進將來的bug預防。當某個bug被發現時我們就有了一個很好的機會來阻止類似問題的發生。前提：記錄bug前提條件是持續跟蹤發現的bug并正確地記錄它們離開了這個前提條件將不能將bug發現作為一個工具來預防bug。不論你使用bug跟蹤系統,還是只手寫了一個報告總結測試的結果 重要的是保存這些數據以便用于后來的分析

8、。在分析bug時bug記錄的問題值得注意。bug的定義越廣泛bug分析的數據越有用。報告bug的測試人員應該明白這一點并不限于狹義上的bug。可能的話測試人員應該運用他們的經驗對bug產生的原因做最初的假設。我們將稍后在闡述分析過程時討論這個問題。和記錄bug同樣重要的是bug分析的第一步。僅僅跟蹤過去的bug不能預防bug的發生因為許多不同的bug可能于同一個核心問題。不同于信息收集適當地分析bug的原因對bug預防非常有用。3缺陷分析目標在上一節我們說明了bug分析的理由。如上所述最終目標是預防bug而不是修正它們。然而我們可以定義一個重要的子目標這就使不斷提高整個開發團隊（包括QC組）的

9、技能和實踐經驗。當然這兩個目標是息息相關的。離開了不斷的知識累積也不能實現bug預防。不過我覺得有必要提及這個子目標以強調持續性的過程。bug預防并不是一個不切實際的目標。但是你不能期望它在一夜之間發生。你應該為開發小組提教育和知識以使他們逐漸改善他們的工作。策略本次討論的焦點bug預防策略非常簡單和容易實現。秘訣就是使用在大多數開發環境中已經存在的過程素。我們不會介紹任何新的花費昂貴的活動也不會引入一些新的角色到開發過程中。我們的策略是發現bug找出bug的根源然后尋找一個方法來預防類似的bug在將來出現。因為QC過程已經用于在目前的產品中發現bug因此該策略的大部分工作實際上已經執行大多數

10、開發過程缺少的正是分析在QC過程中發現的bug。正如你將看到盡管策略的這一部分并不需要昂貴的花費但是卻帶來了極大的額外價值。分析過程(1) Bug發現和初步分析如前所述bug分析的第一步是發現bug。然而發現bug的QC工程師（注：測試工程師）不應該滿足于記錄bug的表面癥狀。QC工程師的一個重要職責就是試圖發現bug的根本原因。QC小組在檢驗產品質量時不應該將產品看作一個黑盒而應該像開發人員那樣了解產品的內在包括深入源代碼理解產品的設計和實現。這些能力都是QC小組開始bug分析的基本要求。熟悉了產品的代碼QC工程師就可能推測出bug的根本原因。我要強調是下面這個短語的本質：bug的根本原因？

11、bug的根本原因并不是產生這bug的源代碼所在盡管這些信息可能和分析過程關系密切。但是發現bug的根本原因意味著找到造成這些錯誤的原因。通過一些實例來說明這個問題可能更清楚一些。讓我們看一個普遍存在的關于線程同步的問題。假設一個多線程的 應用程序需要同步地訪問某個數據結構。被指派測試這個產品的QC工程師發現在某種情景下應用程序盡管沒有Crash但是會停止響應。正常的QC過程是這個bug被記錄在bug跟蹤系統中并描述了測試情景和停止響應的實際結果。然而如果這個QA工程師熟悉源代碼就可以進行bug產生原因的初步分析。例如這個QC工程師可能斷定這個bug產生的原因是之前的線程沒有釋放mutex從而造

12、成了沖突。這些分析可以記錄在bug的詳細說明中作為bug分析的一個基礎。(2) Bug修訂和進一步分析一如既往發現一個bug之后開發人員應該負責處理它。但是如果bug的發現過程包含了bug根本原因的初步分析那么關于如何解決這個bug開發人員可能擁有了更多的信息。雖然這不是QC工程師bug初步分析的目的但是它可能為開發人員提了更多的觀點。除了修正缺陷以及記錄實現的具體步驟開發人員還應該對bug進行進一步的分析。這次分析應該著眼于導致bug產生的開發情景。在線程同步的例子中開發人員不應該僅僅記錄增加了一個調用來釋放mutex（注：Mutal Exclusion = 互斥鎖保證了共享數據不會同時被多

13、個線程訪問只向一個線程授予對共享資源的獨占訪問權）。反之開發人員應該找出沒有釋放mutex的原因。假設分析的原因是：因為需要同步的方法超過一個的返回點因此開發人員在某些控制徑上忘記清理代碼。這一類簡單的分析實際帶來了非常大的價值。不同于記錄具體問題的具體解決辦法我們現在有了可以解決許多情況的經驗有些情況甚至并不涉及到線程同步和釋放mutex。但是分析過程并沒有結束我們需要進一步的分析來將收集的所有數據轉換為實踐從而幫助在將來避免類似bug的發生。(3) bug預防分析分析的最后一步就是尋找一個預防類似錯誤的方法。這一方法不僅涉及到開發、QC工程師還涉及到不直接負責代碼編寫的資深開發人員。這一階

14、段的成果是一些有用的實踐經驗開發人員可以通過這些實踐預防bug而不是修正bug。這些實踐不應該是某個具體問題的解決方案。在我們線程同步的例子中可能得到這樣一個實踐：是否有審計范圍機制來獲取和釋放資源？這種實踐 （不一定適合所有編程語言）可以指導開發人員用一個類（class）封裝資源, 這樣構造(constructor)函數容易分配和而與析構(destructor) 函數釋放資源。如果遵守這樣的約定, 當程序結束這方法時不管控制徑是怎樣的資源（上述例子中獲得的mutex）總能被釋放。Bug預防分析是整個bug分析過程的核心。這一階段總結出的實踐可以在更廣泛的范圍內預防潛在 的缺陷。由于分析結果的

15、廣泛應用性分析某個具體問題的投入將很容易被收回。非常重要的是我們前面所舉的例子是一個隨機性的bug。開發人員由于疏忽而忘記了釋放資源。在代碼實現時這樣的bug是隨機產生的但是類似bug產生的幾率卻非常高。所以盡管這一類bug是隨機的但仍然可以被預見并防止發生。(4) 發布經驗分析得出的實踐經驗應該被記錄并發布這樣其他的開發人員就可以通過學習這些經驗避免類似的錯誤。一個發布經驗最好的辦法就是知識庫。這將使得新的知識在組織內流動并被相關的開發人員所學習。如果不將分析結果傳達給組織內相關的其他人員那么分析的目的就沒有達到。避免下一個bug出現的唯一辦法就是讓開發人員知道如何避免它并鼓勵他們這么做。B

16、ug分析實例讓我們研究另外一個例子以便更好地理解bug分析的益處。在這個事例中QC工程師進行了如下的操作：當輸入一個長字符串到應用程序時造成其崩潰(crash)。這一結論本身就需要一定程度的分析但這個QC工程師并不滿足于這樣的分析進一步研究了相關的代碼發現crash的原因是輸入字符串時的處理有問題。其中一個步驟是將輸入的字符緩存在一個固定大小的數組中而這個數組有時候顯得太小了。和線程同步的例子一樣QC工程師的初步分析帶來了很大的價值開發可以更容易的發現和修正這個bug。此外記錄缺陷的真正原因而不是表象將幫助其他人避免類似的bug。接著開發人員開始修正這個bug。當修正的時候她不僅記錄了解決措施

17、并說明了導致缺陷產生的原因。在這個例子中造成bug的原因是在操作未經處理的C/C+緩沖區時沒有經常檢驗緩沖區的大小是否不夠。然而這個結論甚至可以被進一步總結為更廣泛應用的經驗以便幫助開發人員在以后避免類似的缺陷發生。所以在分析的最后階段開發人員在組內更資深的開發人員的幫助下得到了下面的實踐經驗：避免使用未經處理的C/C+緩沖區盡量使用安全的collections和strings如標準模版數據庫中提的可用collections和strings。這樣就完全可以避免前面發現的這個bug。益處Bug分析帶來了很多的好處。第一個好處就是幫助產生錯誤的開發人員總結經驗并使他在將來避免類似的錯誤。有時只修正

18、一個具體的bug而不去分析它產生的原因并不會幫助在日后得到提高。在這種情況下只有深入分析和資深開發人員的指導才能使開發人員成長和提高能力。更廣泛的好處是使得其他開發人員從同事的錯誤中吸取教訓。分析總結的實踐經驗可以預防bug的產生這樣的知識 在組織內的成員間共享。某個開發人員產生的bug可以幫助組織內的其他人避免類似的bug出現。從更一般的角度來看發布最佳實踐（如bug分析總結的實踐）促進了組織內成員的學習和自我提高。這樣看來Bug分析的價值還不僅僅是缺陷的預防。另一個好處是通過從更廣的角度上記錄bug組織內的其他QC工程師將知道如何發現類似的錯誤。除了組織內的測試知識和經驗bug分析過程可以促進開發更好的測試技術和工具從而幫助發現類似的bug。所以就算缺陷沒有被完全預防也能更容易被發現。作為上面所有好處的結果QC在一輪測試中將有更多的時間來測試更復雜的情景并發現更“狡猾的”bug。如果類似的bug都已經被預防而不容易產生而且QC都有更好的技術來發現類似的bug就有了更充裕的時間來進行更高級的測試。當然組織所生產的產品的質量也將得到提高。最后我想強調的是bug分析不僅收集了執行中的問題而且從這些問題中總結了實踐經驗。舉例來說導致一個bug產生的原因可能是需求不夠清楚。這樣通過bug分析得到的經驗提了一種方法來預防需求不清楚。這個經驗可能不會對組織中的開發人員產生效果。所以