什麼是BUG
只有在規格說明存在並且正確的前提下，程序與規格說明不匹配之處纔是錯誤（BUG）。
如何描述一個BUG
我們在描述一個BUG時，應當說明以下幾點：
1、發現問題的版本（在哪兒發生的）
2、問題出現的環境（在怎樣的環境下發生的）
3、錯誤重現的步驟（怎麼操作會產生這樣的錯誤）
4、預期行爲的描述（本來我們是想得到怎樣的結果）
5、錯誤行爲的描述（結果卻出現了什麼樣的結果）
6、其他（錯誤的優先級，錯誤的分類）
BUG分類
大體分爲：崩潰（Blocker）、嚴重（Critical）、一般（Major）、次要（Minor）。具體看公司的劃分標準。
崩潰（Blocker）：該類BUG一旦產生，將會阻礙開發或者測試的工作。可能是造成了系統的崩潰，死機，死循環，數據庫數據丟失，與數據庫連接錯誤，主要功能或基本模塊的缺失等這些問題。比如：代碼錯誤，死循環等
嚴重（Critical）：系統的主要功能部分缺失，用戶數據丟失，一級功能無法使用（但不影響其他功能模塊的測試工作），功能的設計與需求不符合，模塊無法啓動或調用，自動重啓，安全問題，穩定性等。比如：用戶要求的功能部分沒有實現，數值上的計算、統計、存儲錯誤。
一般（Major）：功能沒有完全實現但是不影響我們的使用，某些功能存在一定的不足但不會影響到系統的穩定性。比如：刪除沒有確認框，操作、查詢時間長，邊界條件錯誤等。
次要（Minor）：性能方面的優化，建議類的問題，都不會影響到操作功能的執行。比如：錯別字，排版問題，描述不清楚，沒有提示語。
常說，軟件測試就是找Bug。那麼我們找到一個Bug之後怎麼辦呢？？？
下面就來學習一下缺陷的管理流程。
從圖中我們可以看到一個BUG的生命週期大體有以下7個狀態：
New：新發現的BUG
Open：確認是BUG，就打開
Fixed：確認是需要修改的BUG，進行修改
Rejected：認爲不是BUG，拒絕修改
Delay：認爲暫時不需要修改，延時修改
Closed：修改之後，測試人員進行迴歸測試，迴歸測試通過後關閉BUG
Reopen：修改完成經驗證BUG依舊存在，則重新打開，再次進行修改