本篇文章轉自：http://www.ltesting.net/html/95/n-169395.html
1MILY: 宋體">．引言：
生產軟件的企業安排很多人來測試它們的軟件產品。測試的目的就是發現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。正如你將看到，儘管策略的這一部分並不需要昂貴的花費，但是卻帶來了極大的額外價值。
分析過程
(1) Bug發現和初步分析
如前所述，bug分析的第一步是發現bug。然而，發現bug的QC工程師（注：測試工程師）不應該滿足於記錄bug的表面症狀。QC工程師的一個重要職責就是試圖發現bug的根本原因。QC小組在檢驗產品質量時，不應該將產品看作一個黑盒，而應該像開發人員那樣瞭解產品的內在，包括深入源代碼，理解產品的設計和實現。這些能力都是QC小組開始bug分析的基本要求。熟悉了產品的代碼，QC工程師就可能推測出bug的根本原因。
我要強調是下面這個短語的本質：bug的根本原因？bug的根本原因並不是產生這bug的源代碼所在，儘管這些信息可能和分析過程關係密切。但是，發現bug的根本原因意味着找到造成這些錯誤的原因。通過一些實例來說明這個問題可能更清楚一些。
讓我們看一個普遍存在的關於線程同步的問題。假設一個多線程的應用程序需要同步地訪問某個數據結構。被指派測試這個產品的QC工程師發現在某種情景下，應用程序儘管沒有Crash，但是會停止響應。正常的QC過程是，這個bug被記錄在bug跟蹤系統中，並描述了測試情景和停止響應的實際結果。然而，如果這個QA工程師熟悉源代碼，就可以進行bug產生原因的初步分析。例如，這個QC工程師可能斷定這個bug產生的原因是之前的線程沒有釋放mutex，從而造成了衝突。這些分析可以記錄在bug的詳細說明中，作爲bug分析的一個基礎。
(2) Bug修訂和進一步分析
一如既往，發現一個bug之後，開發人員應該負責處理它。但是，如果bug的發現過程包含了bug根本原因的初步分析，那麼關於如何解決這個bug，開發人員可能擁有了更多的信息。雖然這不是QC工程師bug初步分析的目的，但是它可能爲開發人員提供了更多的觀點。
除了修正缺陷以及記錄實現的具體步驟，開發人員還應該對bug進行進一步的分析。這次分析應該着眼於導致bug產生的開發情景。
在線程同步的例子中，開發人員不應該僅僅記錄增加了一個調用來釋放mutex（注：Mutal Exclusion =互斥鎖，保證了共享數據不會同時被多個線程訪問，只向一個線程授予對共享資源的獨佔訪問權）。反之，開發人員應該找出沒有釋放mutex的原因。假設分析的原因是：因爲需要同步的方法超過一個的返回點，因此開發人員在某些控制路徑上忘記清理代碼。
這一類簡單的分析實際帶來了非常大的價值。不同於記錄具體問題的具體解決辦法，我們現在有了可以解決許多情況的經驗，有些情況甚至並不涉及到線程同步和釋放mutex。但是，分析過程並沒有結束，我們需要進一步的分析來將收集的所有數據轉換爲實踐，從而幫助在將來避免類似bug的發生。
(3) bug預防分析
分析的最後一步就是尋找一個預防類似錯誤的方法。這一方法不僅涉及到開發、QC工程師，還涉及到不直接負責代碼編寫的資深開發人員。
這一階段的成果是一些有用的實踐經驗，開發人員可以通過這些實踐預防bug而不是修正bug。這些實踐不應該是某個具體問題的解決方案。在我們線程同步的例子中，可能得到這樣一個實踐：是否有審計範圍機制來獲取和釋放資源？這種實踐（不一定適合所有編程語言）可以指導開發人員用一個類（class）封裝資源,這樣構造(constructor)函數容易分配和而與析構(destructor)函數釋放資源。如果遵守這樣的約定,當程序結束這方法時，不管控制路徑是怎樣的，資源（上述例子中獲得的mutex）總能被釋放。
Bug預防分析是整個bug分析過程的核心。這一階段總結出的實踐可以在更廣泛的範圍內預防潛在的缺陷。由於分析結果的廣泛應用性，分析某個具體問題的投入將很容易被收回。
非常重要的是我們前面所舉的例子是一個隨機性的bug。開發人員由於疏忽而忘記了釋放資源。在代碼實現時，這樣的bug是隨機產生的，但是類似bug產生的機率卻非常高。所以，儘管這一類bug是隨機的，但仍然可以被預見並防止發生。
(4)發佈經驗
分析得出的實踐經驗應該被記錄併發布，這樣其他的開發人員就可以通過學習這些經驗避免類似的錯誤。一個發佈經驗最好的辦法就是知識庫。這將使得新的知識在組織內流動並被相關的開發人員所學習。
如果不將分析結果傳達給組織內相關的其他人員，那麼分析的目的就沒有達到。避免下一個bug出現的唯一辦法就是讓開發人員知道如何避免它，並鼓勵他們這麼做。
Bug分析實例
讓我們研究另外一個例子，以便更好地理解bug分析的益處。在這個事例中，QC工程師進行了如下的操作：當輸入一個長字符串到應用程序時造成其崩潰(crash)。這一結論本身就需要一定程度的分析，但這個QC工程師並不滿足於這樣的分析，進一步研究了相關的代碼，發現crash的原因是輸入字符串時的處理有問題。其中一個步驟是將輸入的字符緩存在一個固定大小的數組中，而這個數組有時候顯得太小了。
和線程同步的例子一樣，QC工程師的初步分析帶來了很大的價值，開發可以更容易的發現和修正這個bug。此外，記錄缺陷的真正原因而不是表象，將幫助其他人避免類似的bug。
接着，開發人員開始修正這個bug。當修正的時候，她不僅記錄瞭解決措施，並說明了導致缺陷產生的原因。在這個例子中，造成bug的原因是在操作未經處理的C/C++緩衝區時，沒有經常檢驗緩衝區的大小是否不夠。然而，這個結論甚至可以被進一步總結爲更廣泛應用的經驗以便幫助開發人員在以後避免類似的缺陷發生。所以，在分析的最後階段，開發人員在組內更資深的開發人員的幫助下，得到了下面的實踐經驗：避免使用未經處理的C/C++緩衝區，儘量使用安全的collections和strings，如標準模版數據庫中提供的可用collections和strings。這樣就完全可以避免前面發現的這個bug。
益處
Bug分析帶來了很多的好處。第一個好處就是幫助產生錯誤的開發人員總結經驗，並使他在將來避免類似的錯誤。有時，只修正一個具體的bug而不去分析它產生的原因並不會幫助在日後得到提高。在這種情況下，只有深入分析和資深開發人員的指導才能使開發人員成長和提高能力。
更廣泛的好處是使得其他開發人員從同事的錯誤中吸取教訓。分析總結的實踐經驗可以預防bug的產生，這樣的知識在組織內的成員間共享。某個開發人員產生的bug可以幫助組織內的其他人避免類似的bug出現。
從更一般的角度來看，發佈最佳實踐（如bug分析總結的實踐）促進了組織內成員的學習和自我提高。這樣看來，Bug分析的價值還不僅僅是缺陷的預防。
另一個好處是通過從更廣的角度上記錄bug，組織內的其他QC工程師將知道如何發現類似的錯誤。除了分享組織內的測試知識和經驗，bug分析過程可以促進開發更好的測試技術和工具，從而幫助發現類似的bug。所以，就算缺陷沒有被完全預防，也能更容易被發現。
作爲上面所有好處的結果，QC在一輪測試中將有更多的時間來測試更復雜的情景並發現更“狡猾的”bug。如果類似的bug都已經被預防而不容易產生，而且QC都有更好的技術來發現類似的bug，就有了更充裕的時間來進行更高級的測試。當然，組織所生產的產品的質量也將得到提高。
最後，我想強調的是bug分析不僅收集了執行中的問題，而且從這些問題中總結了實踐經驗。舉例來說，導致一個bug產生的原因可能是需求不夠清楚。這樣，通過bug分析得到的經驗提供了一種方法來預防需求不清楚。這個經驗可能不會對組織中的開發人員產生效果。所以儘管QC工程師開始驗證開發人員的實現結果，但是還需要改善開發流程，如需求收集、設計流程等。
4．總結
真正的質量是生產沒有bug的產品。任何其他目標都使組織內的成員從思想上接受軟件缺陷是正常工作流的一部分。所以，第一步就是防止相同的bug再次發生。我們可以很輕易地執行這個目標。我們可以通過某個開發人員產生的一個bug提高整個組織的實踐經驗。
通過深入產品分析一個bug，我們可以明白這個bug的機制：爲什麼會產生？如何去預防它？下一次我們如何更容易地發現它？只要花一點時間去理解我們的bug，而不是僅僅是儘快修正它，我們就可以從中得到經驗。這樣，因爲一個缺陷所浪費的時間也可以轉化爲投入：確保類似的錯誤永遠不會再發生。