-
暫時沒有公告
為bug預防奠定基礎
發布: 2008-8-14 17:11 | 作者: 網絡轉載 | 來源: 本站原創 | 查看: 80次 | 進入軟件測試論壇討論
(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，而不是僅僅是盡快修正它，我們就可以從中得到經驗。這樣，因為一個缺陷所浪費的時間也可以轉化為投入：確保類似的錯誤永遠不會再發生。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
