除了修正缺陷以及記錄實現的具體步驟,開發人員還應該對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而不去分析它產生的原因并不會幫助在日后得到提高。在這種情況下,只有深入分析和資深開發人員的指導才能使開發人員成長和提高能力。
原文轉自:http://www.uml.org.cn/Test/200611295.htm