1. 缺陷的定義

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

　　2. 缺陷的判定標準及產(chǎn)生原因

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

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

　　出現(xiàn)了需求說明書指明不應該出現(xiàn)的錯誤

　　實現(xiàn)了需求說明書之外的功能

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

　　用戶角度發(fā)現(xiàn)的各種問題與錯誤

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

　　需求文檔存在錯誤

　　程序代碼存在錯誤

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

　　3. 缺陷報告

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

　　缺陷報告首先必須有以下幾個核心的內(nèi)容：

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

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

　　復現(xiàn)步驟：測試用例里面的執(zhí)行步驟

　　實際結果：執(zhí)行被測試軟件過程中，系統(tǒng)給出的結果

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

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

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

　　ID編號：缺陷的唯一編號

　　模塊：根據(jù)產(chǎn)品進行具體的劃分，如登錄、注冊

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

　　new：新建的缺陷

　　open：打開的缺陷

　　fix：已修復的缺陷

　　close：關閉的缺陷

　　reopen：重新打開

　　reject：被拒絕解決的缺陷

　　postpone：延期處理

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

　　優(yōu)先級：從業(yè)務的角度，決定bug修改的先后順序

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

　　功能性錯誤

　　非功能性錯誤

　　界面錯誤

　　兼容性

　　易用性

　　...

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

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

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

　　實際結果：是執(zhí)行復現(xiàn)步驟后軟件的現(xiàn)象和產(chǎn)生的行為

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

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

　　4. 缺陷跟蹤流程

　　使用禪道或者jira進行缺陷跟蹤時，根據(jù)不同的場景會產(chǎn)生不同的缺陷狀態(tài)。下圖是缺陷跟蹤流程圖，每一條流程表示一種場景。

　　場景1：確認BUG解決

　　測試【new】》開發(fā)【open】》開發(fā)【fix】==》測試【close】

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

　　測試【new】》開發(fā)【open】》開發(fā)【fix】==》測試【reopen】

　　場景3：開發(fā)延期處理

　　測試【new】》開發(fā)【open】》開發(fā)【postpone】

　　場景4：拒絕處理

　　測試【new】》開發(fā)【open】》開發(fā)【reject】