一、前言
提交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提交規範：
提交模板
【測試環境】 （手機型號作業系統/系統版本/瀏覽器版本等等）
【前置條件】
【步驟】（應該和用例步驟是一致，如不一致，為用例缺失，需要補充用例）
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和開發專案經理進行溝通，對開發人員的這種行為進行約束和規範。一旦約定後遇到這種情況可以予以打回，要求開發說明問題原因。
實際問題中的 if else 語句應用
完 楊建和 完成日期 2011 年 10 月 26 日 版 本號 對任務及求解方法的描述部分 輸入描述 個人月收入總額 問題描述 從2011年9月1日起，我國調整個人所得稅起徵點。基數上調為3500元，超出部分按以下7級計算。1 超過0至1500 稅率3 速算扣除數0 2 超過1500元至4500元...
實際問題引發的linux使用思考
動手一試，果然可以 既然如此，那麼肯定也可以統計乙個目錄下有多少檔案了 ls lr grep wc l，簡單分析一下 ls l 列表輸出當前資料夾下檔案資訊 包括目錄 鏈結 檔案 裝置等 grep 過濾檔案資訊，只保留一般的檔案，不包含目錄等其他檔案，如果只保留目錄 資料夾 則應該是 grep d ...
用訊號量及其PV操作處理實際問題
將生產者和消費者問題深入理解 融會貫通。1.書上課後練習p187 43 semaphore sugar,water,orange,s sugar 0 water 0 orange 0 s 1 process produce while true p s 放入原料 if 放入糖 than v suga...