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

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

1、根據(jù)Bug步驟能重現(xiàn)bug

2、其他人看到你的Bug，心情沒有變糟糕，要記住，你報的Bug，閱讀對象可能是其他測試、開發(fā)、產(chǎn)品經(jīng)理、甚至可能是你的領(lǐng)導(dǎo)

3、開發(fā)看到你的Bug后，基本上95%知道問題出在什么地方了

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

標題（摘要）：

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

優(yōu)先級：

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

較通用標準：

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

Critical（P1）：崩潰、閃退等、主要功能無法實現(xiàn)、實現(xiàn)與需求嚴重不符、數(shù)據(jù)丟失；

Major（P2）：操作界面錯誤、次要功能無法實現(xiàn)或?qū)崿F(xiàn)與需求不符、邊界條件出現(xiàn)的錯誤、提示信息錯誤；

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

環(huán)境：

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

賬號：

Bug是否發(fā)生在特定的賬號里，想復(fù)現(xiàn)Bug是否需要非常復(fù)雜的步驟，如果是，給出復(fù)現(xiàn)的賬號吧，開發(fā)只要登錄，找到對應(yīng)的位置，就可以輕松復(fù)現(xiàn)解決

描述：

一個好的Bug描述，決定了其他人拿到這個Bug之后，是否能準確復(fù)現(xiàn)Bug，不要漏掉任何一個步驟

操作步驟：

步驟1：xxxxx

步驟2：xxxxx

實際結(jié)果：

比如：實際結(jié)果：刪除文件失敗。對于實際現(xiàn)象表現(xiàn)較復(fù)雜的，可以分子項來寫，比如：實際結(jié)果：a.xxx；b.xxx

期望結(jié)果：

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

附件：

貼上Bug的截圖，開發(fā)就會很明了，不會在去重復(fù)詢問，有的時候，一張圖更能傳達bug的意，問題不好用文字描述，使用錄屏可以讓開發(fā)很好的理解并重現(xiàn)Bug

log：

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

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

他的第一反應(yīng)是：1，你的環(huán)境有問題吧；2，傻逼你會用嗎。

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

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