(翻譯)編寫優秀Bug報告的藝術
? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?----------http://blog.csdn.net/imlogic/
前言

在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的質量指標應該包括如下：
o? ?? ???對管理層來說，是清晰明了的，特別是在概要這一級；
o? ?? ???對于開發部門是有用的，主要是給出能夠讓開發人員高效地調試問題的相關信息
o? ?? ???可以很快的將bug從“Opened”狀態轉變成“Closed”狀態，減少為得到更多的信息從開發人員打回的差的bug report并導致測試人員返工的時間。

改進bug報告的流程是需要花費一些時間的，但是也給予了效果顯著的回報。首先，簡單的流程改進了測試小組和高層、平行管理層之間的溝通，增強小組的信任度，名望和鼓勵管理層給測試投資更多的資源。第二，平穩地遞交報告給開發人員促進了測試和開發人員之間積極的關系。第三，更短的bug生命周期是更加有效的，在時間上之前花費在編寫優秀bug report上的時間和后期由于返工差的bug report花費的時間相抵消。這些回報幫助開發流程通過有效的溝通和高效率的流程獲得更好的產品質量。

[[i] Last edited by eatmouse on 2005-6-1 at 08:44 [/i]]

===

這里還有一篇，參考下。

你有沒有為了要更多的信息而被返回 bug report 的經歷呢？有沒有碰到過你發現的一個非常嚴重的錯誤被推遲到下一個版本才去修復的情況呢？ 你提交的每一個 bug report 都是和項目組就正在測試中的軟件質量問題的一種書面溝通方式。通常，你用于溝通程序錯誤的能力－不是體現在錯誤本身的內在嚴重程度－而是體現在確定這個錯誤是否需要修復。 如果這是一個可怕的想法，你可能會想， “ 等等！我討厭寫作，我并不擅長寫作。怎么樣才能夠通過編寫 bug report 來決定錯誤的命運呢？ ” 它要吸引大家相信錯誤是為他們說話的－任何一個頭腦正常的人都應該主動地查看一個特定的錯誤是足夠可怕的以致要被修復。不幸的是，事實并不是這樣。 但是好消息是：有效的和軟件開發人員、項目組溝通的能力不是由你在高校英語課程中的表現所決定的。 這不是關于用有趣的詞語編寫流暢散文，也不是關于優秀語法和拼寫的方法。它是有關僅用能夠表達你觀點的詞語明白地表述錯誤的方法。太多地話將會使你的觀點陷入茫然無措中。太少地話又會使他人用自己的假設去填補隔閡－通常是對軟件有害的部分。如果你不是很確信是什么樣的錯誤，那么不管你的 bug report 寫得怎么好，也沒有人知道那是什么樣的錯誤。 這篇文章主要討論你現在能夠開始著手提高人們傾聽你發現的錯誤的機會的 4 個方法。 ?? ? ? ? 了解你的聽眾 毋庸置疑，任何寫作課都會告訴你必須了解你是為誰編寫 bug report 。 每份 bug report 至少有兩個聽眾：必須要修復錯誤的人和決定錯誤命運的人或團體。有時一個人會同時負責這兩份工作，但是仍然是兩個不同的聽眾，只是一起發生在同一個人身上罷了。 你的第一個聽眾－那個必須修復錯誤的人需要清楚，明確的步驟以重現錯誤。信息越多越好。針對這個目的，我們稱這個人為 “ 開發人員 ” 。開發人員需要關于我們操作了什么和我們看見了什么的準確信息。 你的第二個聽眾－決定錯誤命運的人或團體需要知道如果不修復此錯誤的后果。這個聽眾需要精練的語句以抓住他們的注意力并且引發對錯誤的相關連問題的討論。基于這個目的，我們稱他為 “ 錯誤審核委員會 ” 。在使錯誤得以修復的過程中你的角色是幫助錯誤審核委員會了解不修復錯誤的風險遠遠超過修復錯誤可能發生的風險。 你越了解你的開發人員和錯誤審核委員會如何工作，你就越可以根據他們的需要裁減你的 bug report 。盡力在私底下設法了解你的聽眾。如果你能夠出席錯誤審核委員會會議，嘗試這樣做。你將學習到許多關于你的聽眾是如何思考的知識。 ?? ? ? ? 選擇一個好的標題 一般把用于描述錯誤的短句稱為錯誤的標題或描述。這是 bug report 中最重要的部分。錯誤審核委員會成員經常通過它來決定錯誤是否可以推遲修復。如果標題沒有力度，委員會成員可能認為它是不值得花費太多的時間。（畢竟，在接下來的 2 個小時里還有 145 個以上的錯誤要審核。） 以下是一些示例： 好的 ： 超時后在退出時崩潰了 太長的 ： 在數據庫不可用后你又保存記錄的更改 , 然后從文件菜單中選擇退出時程序崩潰了 不足夠的信息 ： 程序崩潰了 太模糊 ： 當數據庫離線時出現問題 標題變成了一種給項目組提供檢查和調查錯誤的方法。和數據相比，人們更容易記詞語。人們更愿意記得 “ 在 windows2000 下不能夠安裝 ” 的錯誤，而不是類似 “ ＃ 23423” 錯誤，而且在以后人們還會利用這些關鍵詞搜索錯誤。 編寫一個好的，簡明的錯誤標題是不容易的。和編寫 bug report 的其他部分相比，應該多花些時間構造理想的錯誤標題。要確信標題是足夠短以便能夠在顯示錯誤的屏幕上和由缺陷跟蹤系統生成的報表中顯示完全（不會折行）。標題不必是完美的語法，而應簡短并一針見血。 ?? ? ? ? 書寫清楚，明確的步驟 你提交給開發人員的步驟應該提供如何產生錯誤的信息，這樣錯誤就能夠被發現并且修復。它也需要給錯誤審核委員會提供錯誤發生的環境。 唯一正確 ： 1 ．運行客戶端 2 ．找出一個記錄 3 ．更改記錄但不存盤 4 ．使數據庫服務器脫機 5 ．嘗試保存記錄 6 ．收到一個超時的錯誤 7 ．退出客戶端 結果：崩潰 馬虎的（有很大空間讓人產生誤解的 ）： 使數據庫服務器脫機，保存，然后退出，崩潰了。 太多冗余的信息（不能夠指出什么是引發錯誤的最關鍵原因） 1 ．運行客戶端 2 ．為輸入新的條目查詢數據庫 3 ．打開一個瀏覽器 4 ．在 yahoo.com 上瀏覽新聞 5 ．關閉瀏覽器 6 ．選擇一個條目 7 ．把種類從 “ 蔬菜 ” 更改到 “ 水果 ” 8 ．使數據庫服務器脫機 9 ．嘗試保存記錄 10 ．收到一個超時的錯誤 11 ．退出客戶端 結果：崩潰

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的编写优秀Bug报告的艺术 ----转载自CSDN（imlogic的专栏）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。