一、前言
提交bug是個既愉快又痛苦的過程。成功的發現一個有效bug是很有成就感的，但是如果bug提交的不規範不清楚，導致開發反覆找你確認或者一段時間後自己都忘了是個什麼bug那就很痛苦了。特別是有時候bug會很多（尤其是項目前期，bug爆發的階段）。所以好的bug能避免很多麻煩，避免了開發找你的麻煩，也避免了自己給自己找的麻煩。
所以什麼樣的bug纔是好bug？主要從兩方面：一、提高bug的有效性；二、養成這樣的好習慣。
幾年前，曾經面試的時候被問到同樣的問題，我忘怎麼回答的了，但是印象最深的是他提到了一點，有截圖的bug是好bug。是的，截圖這一點我很贊同。這印證了“有圖有真相”這句網絡術語。確實用圖表說明比純文字描述的bug要好理解的多，特別是場景複雜復現困難的bug。能讓開發一目瞭然，提供了最原始的視覺衝擊，再配以明確的文字描述，定位起來也更容易些。
那麼如何提高bug的有效性：
（1）關於標題，語言描述始終是個難題，如果bug的標題能讓開發正確理解80%那是很成功的一個bug。
作爲一個測試團隊，標題可以配置一些標籤，約定俗成，如“【平臺】”、“__模塊__”等，而且要有“條件”、‘在哪裏’、‘做了什麼’、‘導致出現了什麼問題’這幾個要素。
（2）關於截圖，要有截圖（如果有日誌更好，如果條件允許錄像也是可以的），截圖很有說明性，相當於事發現場的拍照，可以說明絕大部分情況，如果場景複雜，建議把每個步驟進行截圖並配以簡單的文字描述。便於跟蹤。
（3）關於偶現/必現，必現的bug可以通過反覆試驗，將最短路徑找出來，寫成步驟提交上去。如果是偶現的bug，一定要先提交！因爲有的偶現bug其實影響還是很大的，既然發現了，就說明是有問題的，不可放過。對於偶現bug的跟蹤，最好是跟蹤幾個版本（如三個版本），在每個版本上對該bug進行測試驗證並記錄到該bug上，復現了最好，如果最終沒有復現那麼在第三個版本進行關閉。
（4）關於修改，有時候提交bug會漏掉一些信息或者後面發現bug沒寫清楚，爲了開發能更好的定位問題，一定要將這些信息補上。
（5）關於迴歸，迴歸環境、版本、結果（通過、不通過、變相通過、場景不存在...）、步驟，應該要有，做到有理有據。
（6）關於項目週期很緊，很多情況是因爲bug太多，提交bug會佔據很多時間，所以很多同事就簡單幾句，就把bug提交了，爲後面埋了很多坑，這樣做後患無窮。其實截個圖，把標題的要素習慣養起來，形成習慣之後，提交bug並不會慢的。
對於bug嚴重等級、優先級這些問題如下，這是基本的東西。
二、BUG提交規範：
提交模板
用例標題：【Android /IOS/Web/服務器/生產環境】_模塊名_問題描述
【測試環境】 （手機型號操作系統/系統版本/瀏覽器版本等等）
【前置條件】
【步驟】（應該和用例步驟是一致，如不一致，爲用例缺失，需要補充用例）
1、文字/截圖
2、文字/截圖
3、文字/截圖
【期望結果】
1、
【實際結果】
文字/截圖
【出現機率】
必現/80%/50%/20%
迴歸模板
【測試結論】通過/不通過/變相通過/場景不存在/重複bug/無效bug
【迴歸環境】
【迴歸版本】
【步驟】
1、文字/截圖
3、文字/截圖
3、文字/截圖
重要的事情說三遍：
最好有截圖！有截圖！有截圖！
三、BUG的嚴重等級劃分：
BUG分爲5個嚴重等級，分別是：1致命，2嚴重，3一般，4次要，5建議/提示。
缺陷嚴重程度 | 定義 | 示例 |
致命 | 缺陷產生後，產品主要功能會失效，業務陷入癱瘓狀態，關鍵數據損壞或丟失，且故障無法自行恢復（無法自動重啓） | （1）產品功能失效/和需求期望不符，用戶無法使用 （2）無法正常啓動、異常退出、Crash、資源不足、死循環、崩潰或嚴重資源不足等 （3）安全問題：支付漏洞、被劫持、信息被盜取、被注入等 （4）核心功能/頁面：無法訪問 （5）數據：損壞或丟失且不可恢復 |
嚴重 | 缺陷產生後，產品主要功能無法使用，核心功能無法完成、功能報錯、數據錯誤等，但不會影響程序運行 | （1）產品重要功能不穩定 （2）由程序引起的非法退出、重啓等（但能自行恢復） （3）產品與需求嚴重不符、缺失，或存在關鍵性錯誤 （4）產品難於理解和操作； （5）產品無法進行正常的維護性; （6）產品升級後功能出現丟失、性能下降等 （7）性能達不到系統規格； （8）產品不符合標準規範，存在嚴重兼容性問題 |
一般 | 缺陷發生後，系統在功能、性能、可靠性、易用性、可維護性、可安裝性等方面的一般問題 | （1）產品一般性功能失效或不穩定 （2）產品未進行輸入限制（如正確和錯誤值的界定） （3）一般性的文檔錯誤 （4）產品一般性的規範性和兼容性問題 （5）系統報表、日誌、統計信息顯示錯誤 （6）次要功能未顯示或無法使用，但不影響程序其他功能 （7）系統調試信息難於理解或存在錯誤 |
次要 | 缺陷發生後，對用戶只會造成輕微影響，這些影響在用戶可接受的範圍內 | （1）產品輸出正確，但不夠規範 （2）產品提示信息不夠清晰，難以理解 （3）文檔中存在錯別字、語句不通等 （4）長時間操作未給用戶提供進度提示等 （5）頁面排版不整齊 |
建議 | 對用戶體驗造成影響的問題，可以提升用戶體檢的建議 | （1）不符合常規用戶習慣，不符合行業規範 （2）引導不夠明確等 |
四、BUG的優先級劃分
BUG分爲5個優先等級，分別是：1立即解決，2急需解決，3重要不緊急，4正常處理，5不緊急不重要。
優先級 | 定義 | 解釋 |
1 | 立即解決(now) | 表示問題必須馬上解決，否則系統根本無法達到預定的需求 |
2 | 急需解決(當天) | 表示問題的修復很緊要，很急迫，關係到系統的主要功能模塊能否正常 |
3 | 重要不緊急(不超過3天) | 表示有時間就要馬上解決，否則系統偏離需求較大或預定功能不能正常實現 |
4 | 正常處理（不超過5天） | 表示問題不影響需求的實現，但是影響其他使用方面，比如頁面調用出錯，調用了錯誤的等。 |
5 | 不緊急不重要 | 即問題在系統發佈以前必須確認解決或確認可以不予解決，如建議性bug |
五、對應關係
（1）、嚴重性和優先級並不總是一一對應。有時候嚴重性高的軟件缺陷，優先級不一定高，甚至不需要處理，而一些嚴重性低的缺陷卻需要及時處理，具有較高的優先級。
（2）、嚴重等級和優先級可隨測試策略的變化而有所調整。提交的bug可能在不同的測試階段而變得不一樣。如前期的測試重點是功能點的實現，這個時候提交的建議性的bug則顯得不那麼重要，但是到了後期項目功能業務穩定後，測試重點有所改變，這些建議性的bug則更能優化產品，給產品潤色，所以可以將bug優先級和嚴重等級進行調整。
六、怎樣處理走回來的bug
怎麼應對走回來的bug，這是在實際測試中往往會遇到的問題。走回來的bug狀態一般分幾種：
已解決（代碼修復）、外部原因、設計如此——每個公司會有不同，具體根據部門間的約定而定，但大同小異。
（1）已解決代碼修復的情況，這種是最好處理的，直接走正常的驗證流程即可，驗證不通過的走reopen的流程。
（2）外部原因這種情況，一般是因爲無法復現、場景不存在了、條件不滿足了等等一些第三方的原因或不可抗的因素。遇到這種情況可以在測試團隊約定一個流程：轉給測試leader——leader確認——再轉給測試人員進行處理。這麼做的原因是這種bug一般測試人員不好評估影響，但作爲leader則更能把握質量和權衡利弊。
（3）設計如此的情況，這種bug一般是開發找了產品（UE/UI）進行確認的。在跟蹤記錄中如果有產品人員的確認記錄，即達成了三方一致的情況，可以予以關閉；在跟蹤記錄中如果沒有產品的確認記錄只是開發的單方面說明，則需要找產品進行線下確認，並備註到bug上。
（4）還有一種是重複bug，這種測試人員要儘量避免。提交bug之前要在管理平臺進行確認是否重複。
（5）關於開發給的處理原因，這是一個很頭疼的問題，每個開發不一樣，在返回的bug中進行的說明也千差萬別，最差的就是僅會簡單的寫幾個字：“已解決”、“已修復”這種惜墨如金的做法。這也是我們最不希望看到的，從項目質量管理上也是不好的做法，對於開發來說時間久了他也不知道錯在哪裏，無法進行追溯和提高，對於測試人員則會感到莫名其妙，也很難對bug進行分類分析。一旦出現這種情況需要leader和開發項目經理進行溝通，對開發人員的這種行爲進行約束和規範。一旦約定後遇到這種情況可以予以打回，要求開發說明問題原因。