人為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初步分析的目的,但是它可能為開發人員提供了更多的觀點。
原文轉自:http://www.uml.org.cn/Test/200611295.htm