缺陷報告編寫規範

1 文件目的
本文件目的在於編寫 bug 的定義，如何判斷 bug，bug 型別的劃分，bug 的狀態等進行定義，bug 被報告後，如何跟蹤 bug，如何關閉 bug，如何針對每一更新包做該測試包的測試總結（包括郵件和 bug 分析報告）進行規則約定。以便進一步知道我們的軟體測試工作。

2 bug 定義與內容要求
一個好的缺陷跟蹤系統包括了錯誤的必要資訊，如果做得不好，會造成迷惑，並誤導讀者。

好的缺陷描述主要包括以下 6 個基本部分：bug 標題、錯誤型別、嚴重程度、優先順序、解決方案和附件。

2.1 bug 標題
使用一兩句話來描述錯誤，告訴專案經理、產品經理、開發人員以及其他讀者為什麼應該關心該問題。好的標題應該著重於出現的 bug 現象。但是過於簡潔易引起誤導，使得原本重要的問題被忽視。因此必須應該採用簡潔、切中要害的概要，這樣才能引起讀者的重視。

2.1.1 內容定義
出錯描述應簡單概要，用簡潔、切中要害的語言去描述，描述的語言中應儘量用 “不應 XXX”，“應該要 XXX，而不是 XXX” 等描述；

2.1.2 例項
列表標籤名稱顯示不正確，名稱 “投資列表” 應改為 “投資記錄”，與該模組的名稱要一致。

2.2 嚴重程度
指因缺陷引起的故障對軟體產品的影響程度。

2.2.1 內容定義

2.3 優先順序
指缺陷必須被修復的緊急程度。“優先順序” 的衡量抓住了在嚴重性中沒有考慮的重要程度因素。

2.3.1 內容定義

2.4 錯誤型別
根據缺陷的自然屬性來劃分。

2.4.1 內容定義



2.6 附件
附圖以幫助讀者加深對 bug 的理解，提高工作效率，減少不必要的溝通工作 。

3 跟蹤 bug
缺陷跟蹤流程圖：

新增 bug：QC（測試人員）發現 bug 後新增，並將 bug 指向對應的開發人員；
接受\處理 bug：測試人員提交 bug 後，由開發組長或開發工程師對 bug 進行稽核，稽核 bug 的優先度，bug 修正，修改意見等；
已解決：開發人員修改問題之後，將 bug 回覆給對應的測試人員。測試人員進行驗證後，如果問題還沒解決，則將 bug 重新回覆給開發人員，bug 的狀態不被關閉；bug 的記錄不能被刪除；
已驗證：測試工程師迴歸 bug，透過則關閉處理，反之則重新開啟；
已關閉：測試人員驗證問題透過後，問題得到解決，則該 bug 關閉。