為bug預防奠定基礎[2] 軟件測試
我要強調是下面這個短語的本質：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出現的唯一辦法就是讓開發人員知道如何避免它，并鼓勵他們這么做。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
