1. 缺陷的定義

　　產品不滿足用戶的需求或者測試執行時實際結果和預期結果不一致都屬于缺陷。

　　2. 缺陷的判定標準及產生原因

　　軟件不滿足下述任何一種都算作是軟件的缺陷，缺陷的概念是包括bug概念的。

　　未達到需求說明書指明的功能

　　出現了需求說明書指明不應該出現的錯誤

　　實現了需求說明書之外的功能

　　未達到需求說明書雖未明確提及但是應該實現的目標(如：性能要求等)

　　用戶角度發現的各種問題與錯誤

　　缺陷產生的原因是多方面的，可以總結為以下幾種：

　　需求文檔存在錯誤

　　程序代碼存在錯誤

　　同一個項目組的成員信息不同步，比如需求發生變更，但是沒有同步到項目組所有成員

　　3. 缺陷報告

　　測試人員發現缺陷之后，需要將缺陷同步給項目組的其他成員，為了讓其他成員能夠清晰的知道軟件目前存在的缺陷，就需要對軟件缺陷的描述進行規范化，通常來講測試人員需要將發現的缺陷整理成缺陷報告然后通過一些平臺比如禪道或者jira指定給項目組的指定成員，然后由他們進行解決。

　　缺陷報告首先必須有以下幾個核心的內容：

　　標題：描述缺陷的基本信息，如(輸入密碼長度為5時，注冊成功。)

　　前置條件：描述缺陷出現依賴的相關基礎條件，如(未注冊手機號)

　　復現步驟：測試用例里面的執行步驟

　　實際結果：執行被測試軟件過程中，系統給出的結果

　　預期結果：參照需求說明書，在測試用例中設計的預期結果

　　附件：方便開發定位bug的關鍵信息，包含圖片、日志log等

　　有了上述幾個核心內容之后，開發人員基本上可以根據所給信息去定位缺陷，然后進行解決，當然缺陷報告還有一些其他的基本要素：

　　ID編號：缺陷的唯一編號

　　模塊：根據產品進行具體的劃分，如登錄、注冊

　　缺陷狀態：表明缺陷處理進度，通常會使用禪道等工具進行管理，缺陷狀態有以下幾種

　　new：新建的缺陷

　　open：打開的缺陷

　　fix：已修復的缺陷

　　close：關閉的缺陷

　　reopen：重新打開

　　reject：被拒絕解決的缺陷

　　postpone：延期處理

　　嚴重程度：從技術維度來衡量，bug的破壞力

　　優先級：從業務的角度，決定bug修改的先后順序

　　缺陷類別：用于分類整理缺陷，通常缺陷類別可以從以下幾個角度進行區分：

　　功能性錯誤

　　非功能性錯誤

　　界面錯誤

　　兼容性

　　易用性

　　...

　　缺陷報告非常重要，合格的缺陷報告可以幫助解決缺陷的開發人員更快的復現和定位缺陷，因此缺陷報告必須保證能夠讓開發人員復現缺陷。通常在編寫缺陷報告時可以遵循以下書寫規范：

　　標題：應保持簡短、準確，提供缺陷的本質信息

　　復現步驟：應包含如何使別人能夠很容易的復現該缺陷的完整步驟

　　實際結果：是執行復現步驟后軟件的現象和產生的行為

　　預期結果：通常需要列出期望的結果是什么

　　附件：對缺陷描述的補充說明

　　4. 缺陷跟蹤流程

　　使用禪道或者jira進行缺陷跟蹤時，根據不同的場景會產生不同的缺陷狀態。下圖是缺陷跟蹤流程圖，每一條流程表示一種場景。

　　場景1：確認BUG解決

　　測試【new】》開發【open】》開發【fix】==》測試【close】

　　場景2：驗證未通過，缺陷仍存在

　　測試【new】》開發【open】》開發【fix】==》測試【reopen】

　　場景3：開發延期處理

　　測試【new】》開發【open】》開發【postpone】

　　場景4：拒絕處理

　　測試【new】》開發【open】》開發【reject】