我們該如何去描述一個Bug？在此之前我們首先要清楚一個概念，軟體的生命周期。
軟體的生命周期有如下五個階段：需求分析——>測試計劃——>測試設計、測試開發——>測試執行——>測試評估；
需求階段
這是測試人員了解需求、對需求進行分解，得出測試需求；
計劃階段
根據需求編寫測試計劃、測試方案；
設計階段
測試人員适當的了解設計，對于設計測試用例是很有幫助的，測試人員搭建測試用例架構，根據需求和設計編寫一部分測試用例；
編碼階段
測試人員一般不需要編碼的，但已經編碼的子產品，專業的白盒測試人員可以計劃執行單元測試，完善、細化測試用例以及調整測試計劃和方案。
測試階段
測試階段是軟體測試人員最為重要的工作階段，根據測試用例和計劃執行測試，在執行過程中記錄、管理缺陷、測試完成後編寫測試報告；
運作維護
測試人員需要參與項目實施工作，測試人員對項目産品業務和操作非常了解，加上測試人員的溝通表達能力一般都比較強，是以測試人員可以參與使用者使用軟體的教育訓練，在試運作項目是收集問題并及時回報給相關的負責人。
描述Bug
我們在測試過程中，不可避免bug的出現，那麼當其出現時，我們該如何正确的描述出并及時的回報給開發人員呢？
我們通常從以下幾個方面進行描述：測試的平台（環境），測試資料、操作步驟、預期效果、實際結果對bug進行完整的描述。
一個合格的Bug應該包含以下幾個部分：
-
發現問題的版本
開發人員需要知道出現問題的版本，才能夠擷取對應版本的代碼來重制故障，并且版本的辨別也有利于統計和分析每個版本的品質；
-
問題出現的環境
環境分為硬體環境和軟體環境，如果是web項目，需要描述浏覽器的版本，客戶機作業系統等，如果是app項目，需要描述機型、分辨率、作業系統版本等，詳細的環境描述有利于故障的定位；
-
錯誤重制的步驟
描述問題重制的最短步驟；
-
預期行為的描述
要讓開發人員指導怎麼樣才是正确的，尤其要以使用者的角度來描述程式的行為是怎麼樣的，如果依據需求提出的故障，能寫明需求的來源是最好的；
-
錯誤行為的描述
描述錯誤的現象，crash等上傳log，UI問題可以有截圖
-
其他
某些公司會有一些其他的要求，例如故障的分類:功能故障、界面故障、相容性故障等，有些優先級的分類，嚴重影響到測試需要開發人員優先修改的，可以設定優先級為高
-
不要把bug放到一起
在無法确認是同一段代碼造成的故障時，不要将bug放在一起送出。
Bug的級别
在開發和測試時，我們對Bug怎樣去劃分他們的程度等級呢？
我們一般将Bug的級别劃分為四類：崩潰、嚴重、一般、次要。每個公司對bug的定義都不一緻，在定義級别之前需要檢視公司規範。
-
崩潰（Block）
阻礙開發或測試工作的問題；造成系統崩潰、司機、死循環，導緻資料庫或資料丢失，與資料庫連結錯誤，主要功能喪失，基本子產品缺失等問題。如：代碼錯誤、死循環、資料庫發生死鎖、重要的一級菜單功能不能使用（此類問題在測試過程中很少遇到，一旦出現應當立即終止）
-
嚴重（Critical）
系統主要功能部分喪失、資料庫儲存調用錯誤、使用者資料丢失，一級功能菜單不能使用，關聯程式間調用沖突，安全問題，穩定性等。如：軟體中資料儲存後資料庫中顯示錯誤，使用者所要求的功能缺失，程式接口錯誤，數值計算統計錯誤等（該等級問題出現在不影響其他功能測試的情況下可以繼續該版本的測試）
-
一般（Major）
功能沒有完全實作但是不影響使用，功能菜單存在缺陷但不會影響系統的穩定性。如：操作時間長、查詢時間長、格式錯誤、邊界條件錯誤、删除沒有确認框、資料庫表中字段過多等（該類問題在實際問題中占絕大部分）
-
次要（Minor）
界面、性能缺陷，建議類問題，不影響操作功能的執行，可以優化性能的方案等，如：錯别字、界面格式不規範、頁面顯示重疊、不該顯示的要隐藏、描述不清楚，提示語丢失，文字排列不整齊，光标位置不正确，使用者體驗感受不好，可以優化性能的方案等（此類問題在測試初期較多，優先程度比較低；在測試後期出現較少，應及時處理）
Bug的生命周期
每個公司、每一個工具對bug的生命周期的定義都是不一緻的
- new：新發現的Bug，未經評審決定是否指派給開發人員進行修改；
- Open：确認是Bug，并且認為需要進行修改，指派給相應的開發人員；
- Fixed：開發人員進行修改後辨別成修改狀态，有待測試人員的回歸測試驗證；
- Rejected:如果認為不是Bug，則拒絕修改；
- Delay：如果認為暫時不需要修改或暫時不能修改，則延後修改；
- Closed：修改狀态的Bug經測試人員的回歸測試驗證通過，則關閉Bug；
-
Reopen：如果經過驗證的Bug仍然存在，則需要重新打開Bug，開發人員重新修改；
Bug的追蹤應該遵循的原則：
- 測試人員對每一個缺陷的修改必須重新取一個包含更改後代碼的新版本進行回歸測試，確定相同的問題不會再出現，才能關閉缺陷；
- 對于拒絕修改和延遲修改的Bug，需要經過包含測試人員代表和開發人員代表、使用者方面的代表進行評審。
簡單的流程就總結為以下三類：
怎樣才能夠發現更多的Bug
- 軟體測試同樣也存在二八原則，80%的故障集中于20%的子產品，如果某部分問題比較多，加強測試廣度和深度；
- 開發人員也存在二八原則，80%的故障集中于20%的開發人員，如果某些開發人員的bug比較多，加強他開發模式塊的測試廣度和深度
- 多進行逆向思維和發散性的思維；
- 不要局限于測試用例和需求文檔；
- 盡早的介入項目，不要等到開發的差不多了才介入項目