Bug提交的注意事項

1. 缺陷摘要（Summary）

簡單明了，便於理解

長度一般不超過30個單詞

盡可能講明：什麼情況，導致了什麼問題

便於他人定位Bug,杜絕不重復報相同的Bug

2. 缺陷描述（Descrīption）

重現步驟（Actions）

詳細描述重現該問題的關鍵步驟

省略無關的操作，力求做到：所有重現步驟是充分的和必要的

容易理解的常規步驟，可以一句話帶過，比如以管理員身份登錄，進入後台用戶管理頁面

和環境有關的問題，給出特定的條件，比如某某操作系統，某某浏覽器

實際結果（Actual Result）

描述實際出現的錯誤結果

可借助截屏來表達

不是總能重現的Bug,給出發生頻率或規律

期待結果（Expected Result）

可選，當Spec上沒有對實現方式做詳細要求時，用於測試人員表達自己的看法

3. 截屏/附件（Attachment）

針對文字難以表達的或UI方面的問題

圖片格式使用JPG格式；Windows畫圖工具的默認BMP圖片太大，不建議使用

在圖片上用醒目的顏色，標出問題所在區域

也可考慮配上簡短的文字

4. 其它

對於多人同時測試同一模塊的情況，報Bug前先檢查是否已有類似的Bug （TD提供了簡單的Find Similar Defects的功能）

Bug嚴重程度（Severity）必須准確

Bug優先級（Priority） 必須准確（具體請參考公司標准文檔）

填寫Module/Function字段，便於Dev Manager 分配給相應的開發人員

項目中共性的問題，納入Common Module

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

對於Reject的有爭議的Bug,盡可能和Dev當面溝通