怎樣才能提交一個讓開發人員拍手叫好的bug單
軟件測試人員寫得最多的文檔就是測試用例和BUG，現在測試用例和BUG都沒有標准的模板，每個公司使用的缺陷管理工具都有可能不一樣，如果你換了一家公司就有可能接觸到新的缺陷管理工具，但提交bug的方式卻是大同小異，今天這篇文章主要講解怎樣才能提交一個高質量的BUG單。
目錄
為什么要提交BUG單
缺陷管理工具
編寫高質量的BUG單
為什么要提交BUG單
其實要提交BUG單的原因很簡單，就是在測試過程中程序中出錯了，那么測試人員就要提交BUG單，以便開發人員能夠早時修改。
為什么一定要提交BUG單?直接跟開發面對面交流或者通過即時通訊傳遞了不就可以么？答案肯定是不行。
王豆豆總結了幾點：
- 提交清楚明了的bug單，有利於開發人員快速分析和定位bug
- 在缺陷管理工具上提交bug單，有利於研發人員對bug的跟蹤和管理
- 在測試活動結束后，可以通過分析bug的級別、每天提交bug的數量、每天修改bug的數量、每個功能模塊的bug數量等等因素，從而達到評估軟件質量
缺陷管理工具
以下是目前企業中比較流行的缺陷管理工具：
王豆豆目前的公司用的是騰訊的Tapd，以前沒用過，現在用起來覺得和其他的缺陷管理工具一樣，並不會出現難以上手的情況。
編寫高質量的BUG單
今天這個bug就是今日頭條的發文模塊的bug，前幾天在發文章的過程中發現的，估計這是一個概率性的bug，今天發文的時候重試好幾次也沒有發現。
01
缺陷管理工具
今天給大家演示在Tapd上如何提交高質量的bug
02
什么是高質量的bug
王豆豆以為如果拋開提交的bug單是否是一個真正的缺陷，一個高質量的bug就是取決於這個bug是否能被研發團隊其他人看懂並且能准確復現出來。畢竟提交的bug並不是給測試人員自己看的，而是給開發人員和團隊其他成員看的。
有些公司bug修改完成后，並不是提交人回歸，有可能是組內其他成員，如果寫得不清不楚會給大家帶來麻煩，需要更多的時間去檢查和重試。
故，一個高質量的bug是多么重要，一個高質量的bug應該具備標題清楚合適、操作步驟條理清晰明了、結果明確，同時有相應的截圖和日志。
03
缺陷的模板
軟件測試人員在測試新版本提交bug之前，會在缺陷管理工具中去創建一個本次迭代的模板，將一些公共點包含進去，避免測試人員在提交缺陷時進行重復地輸入、減少測試人員提交缺陷的時間、並能統一缺陷的格式。
缺陷的模板如下：
04
提交BUG
只要寫好一個bug最重要的幾個要素，那這個bug質量應該不會差的。
首先是缺陷標題，對缺陷標題的要求很簡單---》看到缺陷標題就知道這個bug單是提的什么bug。
王豆豆喜歡寫bug標題使用bug的實際結果，例如：【IOS】12位的手機號成功注冊為會員 ；【XXXX結算】發起換卡API，報錯銀行卡號不存在。。。。等等
【今日頭條發文模塊】發布文章時添加內部鏈接，輸入正確的標題和鏈接，點擊確定提示請選擇插入文章
第二點應該是重現步驟，重現步驟清楚可以極大地提高bug重現的機率，如果開發人員能自己一次性就復現出來，那就可以避免與開發人員進行多方的溝通和復現操作。
前置條件: 1.今日頭條發文功能正常 2.添加的文章在今日頭條存在 重現步驟描述： 1.在發表文章界面-》文章編輯欄-》點擊文章鏈接 2.點擊“選擇文章” 3.輸入不存在的已發表文章標題關鍵詞，點擊搜索，查詢結果為空 4.點擊“內部鏈接” 5.輸入已存在的鏈接文字和鏈接地址 6.點擊確定 重現頻率： 50% 實際結果： 1.彈出提示界面，顯示“請選擇插入的文章” 期望結果： 1.在文章中添加內部鏈接成功
bug編輯中的截圖：
一個bug中最好是能附上相應的截圖和日志，特別是截圖，清晰和正確的截圖能使開發更快速地重現bug，而且開發人員會更喜歡，這是因為人更喜歡看圖片而非文字，圖片顯示更加直觀。
如果有日志更好，一般不管是測試前端界面還是沒有界面的后台，只要進行了操作都會打印出日志，那么報錯時就更有（這個可以通過操作日志級別來控制），如果日志比較少，可以用截圖的方式來顯示，如果日志比較多，那就最好以附件的方式上傳上去，附上相應的日志能更方便開發人員快速定位bug和解決bug，所以日志也是必不可少的元素。
但是如果是界面上的錯誤，一眼就能看出是錯誤是什么和如何解決，可以省略日志。
05
其他元素
（1）關聯需求
Tapd可以關聯需求，這是指bug是出自哪一個需求，可以關聯也可以不關聯，有些工具沒有這欄選擇，所以我們忽略它吧。
（2）預計開始和預計結束
這二個選項級別也不是很重要，可以不填。
（3）當前處理人
這個選項是必填項，可以指派給這個bug下一個處理人，可以指定多個處理人，王豆豆現在一般是指派給對應的開發人員。
有些工具這里可以不用選擇，可以根據工具的bug處理流程，自動指定給下一個處理人，如果是自動指定一般是測試經理。
（4）模塊
選擇此bug出自哪個模塊
（5）優先級
根據bug的級別選擇優先級。
bug的優先級有緊急、高、中、低，根據bug的優先級可以確定bug修復的優先級。
（6）嚴重程序
選擇bug的等級
bug等級有致命、嚴重、一般、提示、建議，bug等級指定此bug的重要性，與bug的優先級共同確定bug修復的順序。
（7）發現版本
這個一般是確定在模板中，指明此bug出自哪一個版本，有利於后期的回歸和bug review。
寫到這里就可以點擊提交，將bug提交給下一個處理人，那這個bug開始它的一生了（bug的生命周期），直到再次回歸到測試人員的手里被關閉。
這是王豆豆實際提交的bug，已被修復關閉了，已經隱去了敏感信息。
