提交bug的內容書寫規範

1.標題：【專案名稱——簡短的bug說明】

描述bug的最主要關鍵詞，如xx專案——資料庫輸入輸出資料不一致

2.專案名稱：【專案名稱+專案版本號】

3.Bug所屬專案/模組：Bug所屬專案和模組，最好能較精確地定位至模組；

4.嚴重等級：【緊急，嚴重，一般，微小】

緊急Bug：造成系統或應用程式崩潰(Crash)、當機、系統懸掛，或者造成資料丟失、主要功能完全喪失等。

嚴重的Bug：功能或者特性沒有實現，主要功能部分喪失，次要功能完全喪失，或者致命錯誤宣告。

一般的Bug：不太嚴重，雖然不影響系統的基本使用，但沒有很好地實現功能，沒有達到預期效果。如：次要功能喪失，提示資訊不太準確，或使用者介面差，操作時間長等。

微小的Bug：對功能幾乎沒有影響，產品及屬性仍可使用，如有個錯別字、文字排列不整齊等。

5.優先順序：【P1，P2，P3，P4】

P1：立即解決，導致系統幾乎不能使用或測試不能繼續，需要立即修復；

P2：高優先順序，嚴重，影響測試，需要優先考慮；

P3：正常排隊，需要正常排隊等待修復；

P4：可以在開發人員有時間的時候再糾正；

6. Bug狀態：【New，Open， Fixed， Rejected， Delay ，Closed， Reopen】

New: 新發現的bug，開發人員尚未確認；

Open：確實是bug，並認為需要修改，指派給相應的開發人員；

Fixed：開發人員進行修改後標識成修改狀態，有待測試人員的迴歸測試驗證；

Rejected：如果認為不是bug，則決絕修改；

Delay：暫時不修改或者暫時不能修改，則延後修改；

Closed：fixed狀態的Bug經測試人員迴歸測試驗證透過，則關閉Bug；

Reopen：fixed狀態的Bug經驗證仍然存在，則需要重新開啟Bug，開發人員重新修改；

新夢想技術分享

7.測試環境：【硬體裝置環境，軟體裝置以及配置環境，具體到使用的版本號，型別號】

測試人員要充分說明測試環境的情況，以便開發人員可以快速定位錯誤，防止出現因開發環境與測試環境不符，而無法重現bug的情況。

8.重現步驟：【詳細、精煉的描述bug出現的操作過程，一步一步地描述】

提供如何重複當前Bug的準確描述，應該簡明而完備、清楚而準確；錄入之前要多做幾次嘗試，儘量把操作步驟縮減到必須要執行才能重現錯誤的幾個步驟；

9.期望結果：【需求給出的輸出結果，即正常結果】

按照設計規格說明書和使用者需求，在上述步驟之後，所期望的結果，即正確結果；要描述清楚產品需求制定的正確結果是什麼，避免開發人員因產品需求不明，而產生不必要的溝通開銷；

10.實際結果：【實際測試輸出的結果，即錯誤的結果】

客觀反映事實。如：程式丟擲異常資訊如下…

11.出現頻率：【必現，通常，有時，很少】描述bug出現的可能性1%~100%；

必現：總是出現這個Bug，產生頻率為100%；

通常：按照測試用例，通常情況下回產生這個Bug，頻率大概80%~90%；

有時：按照測試用例，有的時候會產生這個Bug，頻率大概30%~50%；

很少：按照測試用例，很少產生這個Bug，頻率大概是1%~5%；

12.問題隔離：【描述環境的版本，型別等的單一變化和組合狀態下，是否出現】

13.必要的附件：【圖片，Log檔案】

對於某些只用文字描述還不足夠清楚的Bug，使用圖片，錯誤日誌等必要的附加；對於軟體崩潰等現象，需要捕捉到日誌檔案作為附件提供給開發人員。