文/秋之川
這是《落葉》文集里第 343 片落葉，希望你能喜歡，不為別的，只為這份堅持。
【提問】
好的 Bug Report 應該是什么樣的？
【舊識】
很多測試工程師非常擅長找 bug，我也是其中一員，但 Bug Report，也就是報 bug 時的描述，寫的好的人就沒有那么多了。
我先對我之前認為好的 Bug Report 做一個畫像：
- 一目了然的 bug 標題，讓讀者從標題就能清楚這是個什么樣的 bug；
- Bug 的發生概率，讓讀者清楚這個 bug 是百分之百能發生，還是有一定的發生概率；
- 清楚和有序的復現步驟，讓開發能夠復現這個 bug；
- 準確和清晰的期望結果和實際結果；
- 選擇了正確的模塊分類和對應開發，不會導致相應的開發搜不到正確的 bug；
【新知】
在接觸到更多類型的測試對象和項目管理之后，我對上述的 Bug Report 畫像做了一些補充：
| Bug Report | 要求 | 目的 |
|---|---|---|
| 標題 | 一目了然 | 看標題就清楚是什么 bug，方便讀者快速了解存在哪些問題 |
| 發生概率 | 準確 | 讓讀者知道這個 bug 是百分之百會發生，還是有一定的發生概率 |
| 復現步驟 | 清楚、有序 | 讓開發能輕松重現問題，加快 bug 的修復，同時減少開發測試之間的來回補充信息損耗 |
| 實際結果 | 準確、清晰 | 明白錯誤的結果是什么樣的 |
| 期望結果 | 明確、無二義性 | 明白正確的結果應該是什么樣的 |
| 嚴重級別 | 從對用戶的影響判斷 | 是決定該 bug 是否應該被修復的依據 |
| 優先級別 | 從對后續測試的影響判斷 | 是決定該 bug 是否應該被盡快修復的依據 |
| 測試環境 | 詳細的環境描述 | 對于有多個測試環境的產品來說，要說明是測試環境還是預上線測試環境 |
| 前置條件 | 正確且完整的組合條件 | 有些 bug 只存在于某種特定的組合條件之下 |
| 測試輸入 | 能重現 bug 的數據或賬號 | 方便開發人員快速重現問題 |
| 性質 | 基于上一個測試版本來定性 | 便于質量數據分析，統計分析新發現的（New Discovery）、回歸性的（Regression）、滯后發現的（Later Discovery） |
作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵
