編寫優秀Bug報告的藝術及案例分析

作者：不詳　　　　文章來源：Kiki個人BLOGS

　前言

在99年的Quality week上的一次演講中，微軟的一個測試經理，Roger Sherman指出了由於“不可重現”導致bug關閉的主要原因。這是一個非常可惜的情況，因爲這樣的bug report浪費了緊張的開發計劃中的寶貴時間，增加了對產品質量完全是無關緊要的事情，同時導致了在開發人員和測試之間的挫敗感和差的感覺。有時，bug report是由於短暫的或隨機的事件，測試和開發之間不一致的工具和配置，或者在測試的環境下對正確的行爲的模糊定義而產生的，但是許多的由於不可重現而被關閉的測試報告是因爲描述不清晰，被誤解，或者只是文字的錯誤。

幸運的是，我學習到一些能夠引起管理層注意，更清楚的和開發人員溝通並得到修復的編寫優秀bug report的訣竅。這些技巧不僅僅提供了是在被修復的問題的比例方面得到了可靠的回報，而且在同開發人員和管理層的通過中也得到了回報。在我管理的項目中使用這種方法編寫bug report，8份bug report中大約只有一個沒有被修復。

這篇文章的思想只有當你的報告針對的測試執行過程是專業的質量工作纔可以發揮作用。聰明地執行完整的測試包是產生可靠的測試狀況信息的基礎的其中一個因素。在許多的測試文獻中廣泛地介紹了多種多樣的關於如何構建這樣的測試包的方法。選擇和你質量風險管理需求相一致的技術並且使之適應你的具體情況，敏捷地監督已計劃的測試的執行過程，這樣你就可以擁有可靠的測試執行過程。

另外一個關鍵的因素－bug report，卻沒有得到太多的關注。這是非常令人遺憾的，因爲優秀的bug report對反映測試小組真實的和可理解的工作質量同測試本身一樣都是非常重要的。試想一下：如果你不能用開發人員能夠理解的術語和能夠用於調試的方法給開發人員解釋一個錯誤，他怎麼能夠修復問題呢？如果你不能夠在bug report中提出象“保險桿標籤”（bumper sticker）一樣的錯誤總結來引起管理層的注意，你又如何讓他們關心你們發現的問題呢？

Bug report的核心是對錯誤的描述。表格1中是一個關於好和差的錯誤描述的例子。編寫好的bug report是一種好的藝術形式。採用以下的10條技巧可以幫助你的小組提高編寫bug report的質量：

組織Structure：測試人員應該採用深思熟慮的，小心謹慎的方法執行測試，並且做詳盡的記錄。這樣可以促使他們對測試下的系統有很好的認識。當錯誤發生的時候，一個有組織的測試人員能夠知道最早出現問題的地方。

重現Reproduce：測試人員在編寫bug report之前必須在檢查問題是否可重現。如果錯誤不可再重現，仍然應該寫下來，但是必須說明問題的偶然性。一個好的處理原則就是在編寫bug report之前反覆嘗試3次。

隔離Isolate：在嘗試編寫bug report之前，必須試着隔離錯誤。可以採用改變一些變量的方法，如系統的配置，它可能可以改變錯誤的症狀。這些信息可以爲開發人員着手調試提供思路。

歸納Generalize：在測試人員發現了一個已隔離的，可重現的問題後，應該對問題進行歸納。同一個問題是否出現在其他的模塊或其他的地方？同一個故障是否有更加嚴重的問題？

對比Compare：如果測試人員以前曾經驗證過現在出錯的測試用例，那麼他就應該檢查以前的測試結果以檢查相同的條件是否通過以前的測試。如果是的話，那麼這個問題就象是一個迴歸的錯誤。注意由於同一測試條件有可能出現在多個測試用例中，這個步驟就不僅僅只是檢查一個測試用例在以前的多個結果。

總結Summarize：在bug report的第一行寫上錯誤的總結是非常關鍵的。測試人員要花些時間思考已發現的錯誤對客戶有何影響。這不僅僅要求測試人員編寫的報告要能夠吸引讀者，使和管理層的溝通清晰，還要能夠幫助設置錯誤修復的優先級別。

精簡Condense：在bug report的初稿完成後，測試人員應該反覆閱讀它，集中剔除那些沒有關係的步驟或詞語。隱含的或模糊的說明和那些由於對沒有任何關係的細節或者那些在重現錯誤過程中不需要的步驟而消磨報告歡迎程度的無窮嘮叨都不是bug report的目標。

消除歧義Disambiguate：測試人員在精簡空話的同時或其之後隨即應該再仔細檢查報告是否有會產生誤解的地方。測試人員應該儘量避免使用模糊的，會產生歧義的和主觀的詞語。目標是使用能夠表述事實，清楚的，不會產生爭執的詞語。

中立Neutralize：如文中所述，作爲壞消息的傳遞人，和善地提交消息是一個挑戰。如同所有的錯誤總結一樣，獨立的bug report在措辭方面應該保持公正。攻擊開發人員，指責潛在的錯誤，企圖詼諧或使用挖苦將引起開發人員的憎惡，並且使注意力從“提高產品質量”這個大的目標上轉移開了。謹慎的測試人員只用Bug report來描述事實。

檢查Review：一旦測試人員感覺bug report是他能夠編寫的最好版本，他應該將報告再給一個或多個同行進行檢查。他的同事們也應該給出一些建議，爲了澄清問題不斷地提問，如果適當的話，甚至可以挑戰“錯誤成災”的結論。在允許的時間裏，測試小組應該儘可能提交最好的bug report。

以上10條技巧可以幫助你和你的小組提交準確簡潔的，徹底校訂的，精心構思的，高質量的技術文檔。測試小組應該集中編寫bug report的任務，測試組長和經理應該讓測試組成員清楚地認識到編寫優秀的bug report是一項首要的工作任務。衡量優秀的bug report的質量指標應該包括如下：

1：對管理層來說，是清晰明瞭的，特別是在概要這一級；
　2：對於開發部門是有用的，主要是給出能夠讓開發人員高效地調試問題的相關信息
　3：可以很快的將bug從“Opened”狀態轉變成“Closed”狀態，減少爲得到更多的信息從開發人員打回的差的bug report並導致測試人員返工的時間。

改進bug報告的流程是需要花費一些時間的，但是也給予了效果顯著的回報。首先，簡單的流程改進了測試小組和高層、平行管理層之間的溝通，增強小組的信任度，名望和鼓勵管理層給測試投資更多的資源。第二，平穩地遞交報告給開發人員促進了測試和開發人員之間積極的關係。第三，更短的bug生命週期是更加有效的，在時間上之前花費在編寫優秀bug report上的時間和後期由於返工差的bug report花費的時間相抵消。這些回報幫助開發流程通過有效的溝通和高效率的流程獲得更好的產品質量。
　
　案例分析：SpeedyWriter
　SpeedyWriter －－
　· 用Java開發的字處理器（word processor）
　· 支持常見的字處理器功能
　· 在案例分析中，用“italics”字體突出顯示內容的描述上有差異