爲什麼大家就不能寫一份像樣的Bug報告？不是說像樣的報告就比蹩腳的報告冗長或者更難寫，也不是說在Bug報告中爲每個事物做個確切的定義是不可能的。呵呵，團隊間的那些定義確實不同而且還互相矛盾。那在Bug報告中什麼纔是最確切的定義呢？我希望聽到你的回答。
作者注：軟件的每一小部分都會有成千上萬的Bug，這取決於它的規模與複雜程度。有些Bug並無大礙，像“我希望關閉按鈕更大一點。”有些Bug則是誤解了，像“我不能爲我的遊戲匿稱起個下作的名字。”但有些Bug就是討厭的臭蟲，無論如何都必須加以改進，像泄漏用戶信息。因爲Bug往往是開發團隊的局外人發現的，必須等到所有問題修正爲止，Bug報告才告完結——通常使用工作項目跟蹤數據庫，像Product Studio（微軟經典的開發工具）或者Team Foundation Server。
Bug剖析
- 所有的Bug報告有以下的基本要求：
- 標題。要簡略。
- 指派。誰來處理這個問題。
- 重現步驟。問題再次出現的相關步驟。
- 優先級別。問題的緊迫性與重要性。
- 嚴重程度。問題所產生的後果。
- 解決方案。怎麼解決問題。
其他很多方面對修復問題及明白其深層次原因也很有幫助，但以上基本準則簡練得多。下面我們來對每條準則逐一展開討論，消除這些疑惑。
標題及指派
標題應該簡明扼要，一句話就詳盡說明問題的唯一性，使Bug報告的檢索及標識變得簡單。“點擊取消按鈕，屏幕就清空了”是個差勁的標題。“關閉編輯框，清空屏幕”就是個很好的標題。後者簡短得多，而且對問題的出處及發生時間提供了具體的信息。
當你要創建一份新的Bug報告時，你必須指定具體人選來解決其中問題。但是，即使你這個團隊的每個人都很瞭解，你也不應該將一個Bug指定給其中某一位，除非你是開發團隊的一員。相反，你應該將此任務交給這整個團隊。通常的做法是在Bug報告中指定責任方或團隊作爲默認選擇。默認的選擇通常是“主導”或“會診”團隊。不會再有更好的了。要相信這些團隊，他們會知道問題由誰來解決。
作者注：有些團隊希望將所有Bug都指派給團隊中的某些個人，這樣可保證沒有Bug被遺漏。但是，他們還是必須確認將Bug指派給“主導”或“會診”團隊以確保Bug未被遺漏。畢竟，團隊外部人員並不知道軟件還有其他什麼功能。
作爲慣例，所有Bug必須指派給能對其進行經常性檢查的個人或團隊。因爲，大多數優先團隊會每天開例會，我還是偏好將Bug指定給“主導”或“會診”團隊爲默認選擇。
重現步驟
沒什麼比一份Bug報告沒有清晰的重現步驟更讓人鬱悶了。就像你的親友對你說：“你知道該怎麼辦！”，沒有給你更多解釋。這讓我很茫然，不知道怎麼辦。悲催了。
Bug重現步驟應是言簡意賅——一言中的。同時要包含軟件創建編號（通常是單獨列出的），你的工作環境（操作系統版本、所用瀏覽器及其他相關的細節）以及一些先備條件（像先註冊個Xboxcom金牌賬號等）。
有時你不能確定Bug是怎麼發生的，因爲它有時是間歇性的或跟某種特定的狀態相關。這種情況下，列出創建編號、運行環境及配置等信息，接着描述下當時的情況，以說明具體的Bug重現步驟無法確定。
作者注：我們有些內部工具，如Watson與Autobug，它們可以自動生成Bug報告。誠然，用這些工具生成Bug重現步驟有其侷限性，但是它們通常仍可以提供些堆棧跟蹤信息、創建編號、環境及其他相關的信息，且它們對隔離問題有幫助。
在簡潔的Bug重現描述後，你必須指出什麼是你希望發生的（“期望”），及事實發生了什麼（“事實”）。所有的重現步驟包括這三方面——配置、期望結果及實際結果。這樣當別人在看這份Bug報告時就知道到底哪裏出錯了及怎麼重現它。
通常一張圖、一段視頻頂上千句文字，有很多工具可以對屏幕進行圖片及視頻抓取。將這些文件附到Bug報告中，這些文件就是一份能妥善修復Bug的報告與含糊不清的報告之間的區別。
作者注：如果一個問題可以用4個步驟講清楚而你在Bug報告裏卻用了15個步驟，這是讓人相當惱火的。不僅僅是因爲4步很簡單，容易理解，而且這樣可以使開發者及測試者快速找到Bug。重現Bug用的時間越少，在確認Bug的原因上所花時間也越少（可能出現Bug的步驟少了），同樣在確認Bug已被修復上所用的時間也越少。
優先級別
對於優先級別意義的討論一直沒完沒了，這種級別的範圍值通常爲0～3。說實在的，你可以把時間更好地用到其他地方去。這裏還是說些簡單的準則，以此爲基礎闡明優先級別。
- 優先級別一旦設定則不宜再改，除非Bug本身角色變換了。如果級別1意味着：“在目前的衝刺階段或里程碑期間修復”，級別2意味着：“到下一個衝刺階段或里程碑期間再修復，”那麼在每個衝刺結束時，你必須更新Bug的優先級別，這樣不僅很浪費時間，而且改變了Bug的“最後一次變更時間”，這會喪失很多重要信息。
- 優先級別必須容易指定並區分。你不會想讓你的團隊花大量的時間爭論每一個Bug的優先級別吧。它必須是顯而易見的，不管是在寫Bug報告或讀Bug報告的時候。
- 優先級別必須易記且易操作。人們不需要問：“下一個Pri 2是什麼？”，人們也不需要問哪種級別需要做什麼。
基於以上三條準則，一般普遍接受以下優先級別的定義。
|
優先級別 |
描述 |
修復時間點 |
| Pri 0 | 一個需引起嚴重關注的致命錯誤。不存在變通辦法，是一個不可逾越的Bug | 只有解決了這個問題或找到了變通辦法，你才能安心 |
| Pri 1 | 一個需引起嚴重關注的致命錯誤 | 必須在當前的衝刺階段或里程碑期間解決 |
| Pri 2 | 一個嚴重的錯誤 | 必須在產品發佈前解決 |
| Pri 3 | 一般性錯誤或建議 | 最好在產品發佈前解決 |
作者注：確實有開發團隊對優先級別有非常多的定義。有的從Pri 1開始，而不是Pri 0；有的不遵從我在本章開始時列出的準則，或者在一個單獨的區域提示Bug信息。
如果你查看另一個團隊的工作項目數據庫，確定你使用的是他們的定義。這些定義通常顯示在工具提示上或幫助窗口中。
嚴重程度
嚴重程度比優先級別簡單得多，但是它還是經常被搞混。嚴重程度指的是問題所產生的影響範圍，不關乎“有多麼嚴重”這樣的問題。其定義是：
- 嚴重程度1。某問題引起系統崩潰或客戶數據丟失。
- 嚴重程度2。某問題引起的故障阻斷了後續操作。
- 嚴重程度3。某問題引起操作不便或界面顯示不完整。
解決方案
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應被重新激活。
作者注：我第一次爲我的團隊制定解決方案是在10年前。回顧之前的郵件，以上定義至今仍然有效。
過猶不及
Bug報告中還有很多其他區域。我說過用“創建”及“環境”兩個區域記錄Bug相關信息以及用“等待修復”區域來說明什麼時候處理Bug。還有一些區域用來跟蹤記錄底層原因，這個Bug是怎麼被發現的，Bug是在產品或服務的哪個方面發生的，潛在的安全威脅以及其他信息。
設定好Bug報告的必要條件，少則缺，多則無益。要求太多人們會怨聲四起而拒絕完成Bug報告——兩種極端都會對你及你的客戶不利。
Bug報告要易寫且易讀，這樣會促使他們在發現問題的時候制定清晰的Bug報告。使用一些Bug模板對於一些內容的編寫是很有幫助的。對於我們在乎的工程師及客戶來說，規範的Bug報告使一個問題在用戶發現前消滅於萌芽狀態，沒有比這更好的禮物了。
作者Eric Brechner，微軟公司“卓越開發”部門的總監，在軟件行業已經積累了20多年的經驗。他從2001年開始寫“HardCode”欄目，作爲一種資源 提供給微軟的員工。自那以後，其觀點欄目在微軟內部成千上萬的軟件開發者之間，激起了無休無止的關於最佳實踐的討論——如今。這些觀點走出了微軟，走向了 整個開發社區。
本文選自《代碼之殤》，Eric Brechner 著，林鋒譯，由機械工業出版社出版。
