經常聽說不知道BUG怎麼寫纔好，經常聽說描述的bug經常會被開發看不懂，等等一系列關於bug的問題，以下是我在測試工作經驗中的一些積累，我們公司用mantis來管理工具，以mantis的模版爲原型進行bug單描述整理，應該一通百通：
1. Id（BUG編號）：一般自動生成
2. 測試環境：機型、系統版本、分辨率、瀏覽器
3. 提交信息：BUG提交人，Bug接收人、接收部門，提交日期
4. 嚴重程度：系統崩潰、嚴重問題、次要問題、一般問題、文字錯誤問題、易用性問題、建議
5. 優先級：特急、加急、急、一般
6. 出現頻率：經常出現、偶然出現、有時出現
7. Bug之項目屬性：項目名稱，項目版本，所屬模塊
8. BUG描述：摘要描述：簡述BUG情況
步驟：Bug生產過程，以最短步驟去描述
錯誤表現：當前產生問題的表現
期望結果：描述期望修改爲的結果
可以寫上表明與用例的關聯（那條用力引起的BUG）
附件：包含錯誤截圖、錯誤log文件、錯誤視頻等一切可以描述BUG的附加文件。
修改建議：如果精通代碼可以把需要修改的代碼片斷附上
Bug描述常見問題：
1. 測試環境未寫完整，開發修改時會出現復現不成功，測試迴歸時無法精準定位
2. Bug描述不清晰，導致可閱讀性降低
3. 缺少期望結果（或結果不清晰）：導致增加多次溝通成本
4. Bug步驟冗餘：最短路線描述bug增加快速定位