模板
教程
環境
性能
功能
管理
編寫優秀Bug報告的藝術
前言 在 Quality week 上的一次演講中，微軟的一個測試經理， Roger Sherman 指出了由于“不可重現”導致 bug 關閉的主要原因。這是一個非?？上У那闆r，因為這樣的 bug report 浪費了緊張的 開發 計劃中的寶貴時間，增加了對產品 質量 完全是無關緊要的事情
前言
在Quality week上的一次演講中，微軟的一個測試經理，Roger Sherman指出了由于“不可重現”導致bug關閉的主要原因。這是一個非?？上У那闆r，因為這樣的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的質量指標應該包括如下：
o??????? 對管理層來說，是清晰明了的，特別是在概要這一級；
o??????? 對于開發部門是有用的，主要是給出能夠讓開發人員高效地調試問題的相關信息
o??????? 可以很快的將bug從“Opened”狀態轉變成“Closed”狀態，減少為得到更多的信息從開發人員打回的差的bug report并導致測試人員返工的時間。
?
改進bug報告的流程是需要花費一些時間的，但是也給予了效果顯著的回報。首先，簡單的流程改進了測試小組和高層、平行管理層之間的溝通，增強小組的信任度，名望和鼓勵管理層給測試投資更多的資源。第二，平穩地遞交報告給開發人員促進了測試和開發人員之間積極的關系。第三，更短的bug生命周期是更加有效的，在時間上之前花費在編寫優秀bug report上的時間和后期由于返工差的bug report花費的時間相抵消。這些回報幫助開發流程通過有效的溝通和高效率的流程獲得更好的產品質量。
?
Good |
Bad |
|
概要（Summary）
Arial, Wingdings和 Symbol字體破壞了新文件。
重現問題的步驟（Steps to Reproduce）：
1. 啟動SpeedyWriter編輯器, 接著創建了一個文件.
2. 輸入4行文字, 每次重復輸入“The quick fox jumps over the lazy brown dog”,
3. 選中4行文字，點擊字體的下拉菜單，選擇Arial.
4. 所有的文字轉變成了控制字符，數字和其他一些二進制的數據.
5. 嘗試了3次，每次都可以重現這個問題。
隔離（Isolation）
這個問題是新出現在build 1.1.018;相同的測試用例是在builds 1.1.007 (System Test entry) 和 1.1.017中通過測試的.
使用Wingdings和Symbol字體也可以重現這個問題，但Times-Roman, Courier New和Webdings字體都沒有這個問題。
基于模糊的猜測，這個可能只是一個關于格式化的問題。保存此文件再關閉它，然后再打開文件，這個錯誤還是存在。
在轉換字體之前保存文件，將不會產生這個錯誤。
在已經存在的文件里，不會產生這個錯誤。
? |
在格式一些文字成Arial字體時，我創建的新文件中所有的內容被毀壞了。 |
?
原文轉自：http://www.anti-gravitydesign.com
