錯誤

錯誤列舉

主觀評價

使用“我”、“你”等人稱代詞?？梢灾苯邮褂脛釉~或必要時使用“User（用戶）”代替

主觀評價

使用情緒化的語言和強調符號，例如黑體、全部字母大寫、斜體、感嘆號、問號等。只要客觀地反映出缺陷的現象和完整信息即可，不要對軟件的質量優劣做任何主觀性強烈的批評、嘲諷

語意模糊

“與**不同”、“有錯誤”、“不對”、“出錯”等字眼等含義模糊的詞匯，而需要報告確定的缺陷結果

主觀評價

使用諸如“似乎”、“看上去可能”、“應該”等字眼

描述口語化

“程序后臺直接down掉，沒有反映”

語意模糊

例如“選擇停止執行后，程序開始抽取”，“監控狀態統計默認的是統計最近8天的告警信息”

缺陷未隔離

一個缺陷中記錄了一個以上的問題

缺乏可讀性

缺陷描述包含的內容，因為讀者的文化、觀念或崗位不同，很多內容在別人看來，往往難以準確理解，甚至可能引起誤解。只需客觀地描述缺陷的信息即可

習慣提交

將不確定的測試問題提交缺陷中。
如果對測試軟件的某個現象不確定是否是軟件缺陷，可以通過電子郵件或口頭交流，確認是缺陷后再報告到數據庫中。避免查詢和統計結果的不準確性

建議模糊/主觀評價

對于UI或者UE覺得不合理的地方，給出建議看法， 以“需調整”、“不合理”、“需要優化”去描述

檢查項

改進

對于多人同時測試同一模塊的情況，報Bug前先檢查是否已有類似的Bug

Bug嚴重程度(Severity)必須準確

填寫Subject字段，便于Dev Manager 分配給相應的開發人員；

項目中共性的問題，應及時納入專項測試用例試行

多個相同的問題，如是一個Dev負責完成的，撰寫一個缺陷報告就可以，但須指出問題發生的多個位置

對于Reject的有爭議的Bug，盡可能保持開發人員溝通

自查

缺陷報告已經向讀者包含完整、準確、必要的信息了嗎？

一個缺陷報告中是否只報告了一種缺陷？

讀者是否能容易的搜索該缺陷？

步驟是否可以完全復現而且表達清楚嗎？

是否包含了復現該缺陷需要的環境變量或測試所用的數據文件？

讀者是否能容易的搜索該缺陷？