編寫優(yōu)秀Bug報告的藝術(shù)

申請免費試用、咨詢電話：400-8352-114

在Quality week上的一次演講中，微軟的一個測試經(jīng)理，Roger Sherman指出了由于“不可重現(xiàn)”導致bug關(guān)閉的主要原因。這是一個非?？上У那闆r，因為這樣的bug report浪費了緊張的開發(fā)計劃中的寶貴時間，增加了對產(chǎn)品質(zhì)量完全是無關(guān)緊要的事情，同時導致了在開發(fā)人員和測試之間的挫敗感和差的感覺。有時，bug report是由于短暫的或隨機的事件，測試和開發(fā)之間不一致的工具和配置，或者在測試的環(huán)境下對正確的行為的模糊定義而產(chǎn)生的，但是許多的由于不可重現(xiàn)而被關(guān)閉的測試報告是因為描述不清晰，被誤解，或者只是文字的錯誤。 
　　幸運的是，我學習到一些能夠引起管理層注意，更清楚的和開發(fā)人員溝通并得到修復的編寫優(yōu)秀bug report的訣竅。這些技巧不僅僅提供了是在被修復的問題的比例方面得到了可靠的回報，而且在同開發(fā)人員和管理層的通過中也得到了回報。在我管理的項目中使用這種方法編寫bug report，8份bug report中大約只有一個沒有被修復。 
　　這篇文章的思想只有當你的報告針對的測試執(zhí)行過程是專業(yè)的質(zhì)量工作才可以發(fā)揮作用。聰明地執(zhí)行完整的測試包是產(chǎn)生可靠的測試狀況信息的基礎的其中一個因素。在許多的測試文獻中廣泛地介紹了多種多樣的關(guān)于如何構(gòu)建這樣的測試包的方法。選擇和你質(zhì)量風險管理需求相一致的技術(shù)并且使之適應你的具體情況，敏捷地監(jiān)督已計劃的測試的執(zhí)行過程，這樣你就可以擁有可靠的測試執(zhí)行過程。 
　　另外一個關(guān)鍵的因素－bug report，卻沒有得到太多的關(guān)注。這是非常令人遺憾的，因為優(yōu)秀的bug report對反映測試小組真實的和可理解的工作質(zhì)量同測試本身一樣都是非常重要的。試想一下：如果你不能用開發(fā)人員能夠理解的術(shù)語和能夠用于調(diào)試的方法給開發(fā)人員解釋一個錯誤，他怎么能夠修復問題呢？如果你不能夠在bug report中提出象“保險桿標簽”（bumper sticker）一樣的錯誤總結(jié)來引起管理層的注意，你又如何讓他們關(guān)心你們發(fā)現(xiàn)的問題呢？ 
　　Bug report的核心是對錯誤的描述。表格1中是一個關(guān)于好和差的錯誤描述的例子。編寫好的bug report是一種好的藝術(shù)形式。采用以下的10條技巧可以幫助你的小組提高編寫bug report的質(zhì)量： 
　　組織Structure：測試人員應該采用深思熟慮的，小心謹慎的方法執(zhí)行測試，并且做詳盡的記錄。這樣可以促使他們對測試下的系統(tǒng)有很好的認識。當錯誤發(fā)生的時候，一個有組織的測試人員能夠知道最早出現(xiàn)問題的地方。 
　　重現(xiàn)Reproduce：測試人員在編寫bug report之前必須在檢查問題是否可重現(xiàn)。如果錯誤不可再重現(xiàn)，仍然應該寫下來，但是必須說明問題的偶然性。一個好的處理原則就是在編寫bug report之前反復嘗試3次。 
　　隔離Isolate：在嘗試編寫bug report之前，必須試著隔離錯誤?？梢圆捎酶淖円恍┳兞康姆椒?，如系統(tǒng)的配置，它可能可以改變錯誤的癥狀。這些信息可以為開發(fā)人員著手調(diào)試提供思路。 
　　歸納Generalize：在測試人員發(fā)現(xiàn)了一個已隔離的，可重現(xiàn)的問題后，應該對問題進行歸納。同一個問題是否出現(xiàn)在其他的模塊或其他的地方？同一個故障是否有更加嚴重的問題？ 
　　對比Compare：如果測試人員以前曾經(jīng)驗證過現(xiàn)在出錯的測試用例，那么他就應該檢查以前的測試結(jié)果以檢查相同的條件是否通過以前的測試。如果是的話，那么這個問題就象是一個回歸的錯誤。注意由于同一測試條件有可能出現(xiàn)在多個測試用例中，這個步驟就不僅僅只是檢查一個測試用例在以前的多個結(jié)果。