軟體測試學習教程——如何寫出高質量的缺陷報告

1.為什麼要寫缺陷報告

當我們發現Bug 後，需要通知開發人員，缺陷報告是一種溝通的介質，它的主要目的是讓開發人員能夠親眼看到這個 Bug 是什麼，如果不提供足夠詳細的說明來幫助開發人員重現 Bug ，那麼他們就沒法確定問題的根源。缺陷報告是一種用來說明期望結果和實際結果之間的差異以及描述 bug 如何重現的文件。發現 Bug, 最好是一發現並確認了 bug 就立即填寫缺陷報告，而不要等到當天測試結束再和其他 bug 一起填，因為那時就有可能遺漏一些要點，甚至是遺漏某個 bug 。花點時間分析一下造成 Bug 的根本原因是什麼，你可能會因此發現更多的 Bug ，最好能把你的任何有用的證據都寫到缺陷報告上。缺陷報告提交之前自己再讀一遍，可能會有錯別字或者什麼寫錯的地方需要重寫。

2. 填寫缺陷報告時應注意的幾個地方

2.1 標題

缺陷報告的“標題”部分是一個缺陷報告帶給讀者的最初印象，它在瀏覽大量 Bug 時起著非常重要的作用，每個缺陷報告都應該有一個能夠突出重點的“標題”，就好像做廣告一樣。好的標題應該控制在措辭，要據實反應情況，不要誇大或縮小 Bug 的影響。有時候會發現一些令人不可思議的低階 Bug ，但還是要儘量使用較為委婉的詞語來表述，免得傷害開發人員的自尊心。

2.2 描述

描述越簡單直接越好，要考慮到目標讀者，他們可能是開發人員、測試人員、管理人員或者其他人，所以要讓目標讀者都能看得懂Bug 描述。

2.3 重現的步驟

每一步以及所有步驟組合起來應該是符合邏輯的。清晰地列出所需的前置條件。

步驟應儘量詳細，例如，我們要描述透過excel 儲存一個表格，那麼有兩種 方式，一是說得細點兒，即“從 [ 表格 ] 選單裡單擊 [ 儲存 ] ，另一種就是說得簡單點，即“儲存表格”，但請記住，並非所有人都知道如何從 excel 儲存表格，或者說所有人都會使用同樣的方式儲存表格，所以描述的時候最好還是採用第一種方式。寫完之後自己用新的測試資料或者在新的系統上按照步驟親自執行一遍，或許能夠發現缺陷報告裡有一些是遺漏的或多餘的步驟。

2.4 測試資料

開發人員重現Bug 時可能不會訪問測試環境，有些 Bug 可能只能用一定的測試資料才能重現，所以儘量把測試資料附在缺陷報告上。

2.5 螢幕截圖

螢幕截圖是缺陷報告裡非常重要的組成部分，有時一張圖能勝過千言萬語，但也不能養成習慣不管有用沒用的圖都往上貼，或者是隻貼圖而缺少文字描述。附圖能夠使開發人員結合你的描述快速地重現Bug 是最理想的：所附圖片的尺寸和佔用空間不要太大，儘量用 jpg 或 gif 格式，而不要用 bmp 格式。在圖中出問題的地方標註一下，更利於開發人員快速定位。

2.6 嚴重程度 / 優先順序

設定Bug 的嚴重程度之前，應該全面地分析 Bug 的影響，如果我們認為這個 Bug 的優先順序很高，那麼應該在缺陷報告裡說明優先順序高的原因。

2.7 日誌

如果可以的話一定要把程式報錯的日誌附上，這會讓開發人員比較容易進行分析和除錯。很多不能重現的Bug 都是因為缺少日誌，開發人員就會返回去找測試人員要日誌資訊。如果日誌檔案不大的話，比如十幾行，那麼可以直接把日誌資訊粘到缺陷報告裡，如果日誌很大的話，那麼最好單獨粘到一個檔案裡，然後當作缺陷報告的附件就可以了。