怎麼提交一個漂亮的Bug？

Bug管理工具有很多，jira、禪道、git、mantis等等，有些公司，甚至會用Word、Excel等來記錄Bug，不論是工具或者文檔，只要能記錄問題，都是可以的

那麼如何報一個Bug才對呢，首先來看什麼是漂亮的Bug：

1、根據Bug步驟能重現bug

2、其他人看到你的Bug，心情沒有變糟糕，要記住，你報的Bug，閱讀對象可能是其他測試、開發、產品經理、甚至可能是你的領導

3、開發看到你的Bug後，基本上95%知道問題出在什麼地方了

一個好的Bug包括了簡潔的標題，詳細的步驟，明了的截圖等

標題（摘要）：

力求精簡，表達清楚，避免出現寫作文似的標題，一個好的標題應該盡量不超過50個字

優先順序：

在時間不夠的情況下，開發會根據優先順序來修復Bug，標好優先順序，方便開發處理問題，提高整個團隊的效率，原則上，在上線之前所有提交的Bug都應該被修復，最次也要達到Major及以上級別的Bug都被修復

較通用標準：

Blocker（P0）：整個模塊功能不能用、准入沒有通過、測試無法繼續工作；

Critical（P1）：崩潰、閃退等、主要功能無法實現、實現與需求嚴重不符、數據丟失；

Major（P2）：操作界面錯誤、次要功能無法實現或實現與需求不符、邊界條件出現的錯誤、提示信息錯誤；

Minor（P3）：錯別字、產品建議、不影響使用的易用性問題；

環境：

發生bug的環境是什麼，比如瀏覽器是Chrome60.0.0.1、360 8.1、Android4.0 小米4、ios11 iPhone8等，標明了Bug發生的環境，更能幫助開發在特定的環境快速定位問題

賬號：

Bug是否發生在特定的賬號里，想復現Bug是否需要非常複雜的步驟，如果是，給出復現的賬號吧，開發只要登錄，找到對應的位置，就可以輕鬆復現解決

描述：

一個好的Bug描述，決定了其他人拿到這個Bug之後，是否能準確復現Bug，不要漏掉任何一個步驟

操作步驟：

步驟1：xxxxx

步驟2：xxxxx

實際結果：

比如：實際結果：刪除文件失敗。對於實際現象表現較複雜的，可以分子項來寫，比如：實際結果：a.xxx；b.xxx

期望結果：

比如：期望結果：刪除文件成功。期望信息較多的也可以分子項來寫，力求信息全面，表達清楚。

附件：

貼上Bug的截圖，開發就會很明了，不會在去重複詢問，有的時候，一張圖更能傳達bug的意，問題不好用文字描述，使用錄屏可以讓開發很好的理解並重現Bug

log：

客戶端崩潰了，客戶端發生了一個不能重複的Bug，貼上崩潰的Crash，發生問題時候的log，開發一看就很明了

不要對一個程序員說：你的代碼有Bug。

他的第一反應是：1，你的環境有問題吧；2，傻逼你會用嗎。

如果你委婉地說：你這個程序和預期的有點不一致，你看看是不是我的使用方法有問題。

他本能地會想：操，是不是出Bug了！

更多精彩內容：

攻防實戰：入侵某傳銷網站案例解析

成人插畫，第1幅我就看呆住了

「多重職業」成為互聯網時代生存新趨勢

Linux磁碟管理常用操作命令

震驚！大部分的測試經理都不太合格

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！