我們在軟件測試過程中，發現了BUG后，如何提交一個高質量的BUG, 其實我們可以總結一下規范的，文章主要從以下幾方面討論：

Bug有效性

提交的Bug必須是有效的，就要求我們在提交Bug時，確認：
? ? 1、交付過程中測試者需按照設定好的模塊，對Bug進行歸類提交；
? ? 2、Bug的類型默認為UI問題、功能問題、崩潰問題，提交Bug時不能弄錯；
? ? 3、需求是否明確、前提條件是否滿足、輸入數據是否正確、操作步驟是否清楚、Bug是否唯一性；
? ? 4、避免提交設計如此、操作錯誤、重復的、已知的Bug；
? ? 5、盡量少花時間在邊界值、頁面顯示問題上，多提業務邏輯功能、交互測試方面的問題。

Bug標題

Bug標題要求簡明扼要的闡述問題本質，使查看人員能快速了解Bug內容。需要寫明在哪個頁面執行什么操作出現什么現象。
可以看一下下面的例子：
正確示例：
? ?【在我的設置頁面不填寫任何內容點擊保存后，客戶端崩潰】
錯誤示例：
? ? 【設置頁面保存問題（過于概括）】
? ? 【設置頁面崩潰（缺少導致現象的關鍵步驟）】
? ? 【客戶端崩潰（只有現象而無法定位問題位置）】
特別提醒：
? ? 1.標題中標點符號不能超過1個
? ? 2.標題中不能含有測試流程步驟和模塊信息

測試設備

提交Bug要表明測試使用的設備、設備操作系統版本、測試環境、網絡類型等等。

前提條件

明確指出所提交的Bug是在怎么樣的情況下出現的，當所發現Bug前提條件為空時，需要填【無】。
正確示例：
? ?【1.WIFI網絡正常
? ? ? 2.賬戶登錄正?！?br /> ? ?【1.已登錄
? ? ? 2.關注有發布視頻的用戶
? ? ? 3.開啟4G數據
? ? ? 4.WiFi關閉且不可用】

測試步驟

要簡明清晰分步驟描述如何復現Bug問題，步驟用序號編排。
要按照自己的操作的實際步驟寫清楚每一步是怎么操作的，最后操作到哪個頁面或者點擊哪個按鍵。
如在特定情況下發生的問題，還需明確提供以下信息：
? ? ?1.準確寫出連續點擊次數，點擊時長與上下滑動屏幕時長。
? ? ?2.對于特定數據產生的問題，提供具體數據。
? ? ?3.精準描述bug產生的路徑后，再描述現象。
正確示例：
? ?【1.打開客戶端進行首頁->點擊“我的”頁面->點擊用戶頭像進入個人資料頁】
? ?【2.個人資料頁點擊頭像選擇拍照->拍照后點擊保存頭像】
? ?【3.從個人資料頁返回 “我的”頁面，查看頭像是否更新】
錯誤示例：
? ?【左上角菜單欄->登錄->新用戶注冊->輸入手機號->輸入昵稱->輸入密碼->點擊“獲取驗證碼”】
特別提醒：測試步驟中的點擊要用【->】符號連接

期望結果

按照測試步驟應當得到的正確結果，按照產品需求的期望清晰準確的填寫預期結果。而且結果必須是肯定無疑義，可判定性的結果。
正確示例：我們以一個取消點贊功能為例
? ?【同步顯示已經取消點贊】
特別提醒：期望結果不要包含測試步驟，要是簡單的一個結果

實際結果

按照測試步驟實際出現的錯誤結果，避免使用“不正?！?#xff0c;“有誤”等模糊詞匯，需要直接描述實際現象。
正確示例：還是以上一個點贊功能為例，出現bug后我就可以寫
? ?【還顯示已點贊】
特別提醒：期望結果和實際結果要相互對應

復現步驟描述及概率

描述復現步驟中的頁面切換為避免出現描述不清晰或者有歧義，需用“->”符號連接
正確示例：
? ?【首頁->我的->我的訂單->未支付，點擊一個未支付訂單，進入訂單詳情頁】
關于復現概率一定要在多次測試的基礎之上填寫，若必定復現則填寫100%，若偶現，請執行多次后統計概率填寫。

截圖和附件

UI類型：Bug需要上傳截圖，并且增加相應的紅框標識；
功能類型：問題必須上傳視頻文件，上傳格式MP4為主；
崩潰類型：bug則需要上傳視頻和log并且log不得超過10分鐘。
特別提醒：
? ? 1.附件命名需與標題相呼應
? ? 2.log日志抓取不能超過10分鐘
? ? 3.文件名稱不能出現怪異冗長

這些就是我們提交Bug時注意的提交標準，當然不同公司，不同項目可能標準有點不同，但大體這些考慮到了，基本算是一個高質量的bug了。

總結

以上是生活随笔為你收集整理的【测试】提交BUG的标准规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。