如何寫一個好的缺陷（Defect）報告

編寫缺陷報告是測試人員的平常工做，好的缺陷報告可以讓開發人員更容易理解，更快速的定位問題；很差的缺陷報告可能會誤導調查方向，增長溝通成本。那麼一個好的缺陷報告應該包括哪些方面呢？

請看個人mindmap：

標題

　　1. 首先要作一個「標題黨」（此標題黨非彼標題黨）。標題必定要清晰簡潔易理解，不該該臃長

　　2. 儘可能前綴要規範，例如模板： [Product][Version]_[Feature]_[Title]，這樣描述會很清晰，也方便查找

　　3. 缺陷的標題必定要描述在什麼狀況下發生了什麼問題

　　4. 儘可能避免使用人稱（好比you, I等等）

　　缺陷標題的例子： DemoApp 1.0_Login_Cannot enter username by copy/paste enternal string

　　這個標題包含了產品名，版本號，模塊，發生了什麼（cannot enter username),什麼狀況下(copy/paste enternal string)

描述或總結

　　描述或總結這個模塊能夠用來描述標題不能容納的更詳細的內容，它能夠包括不少方面，好比相關、歷史版本是否重現、用戶操做等。目的是更清晰詳細的描述缺陷。

影響

　　　這部分用以描述該缺陷對用戶實際應用中的影響。　

前置條件

　　用以描述在重現缺陷以前環境、數據或者其餘的一些特殊需求。

重現步驟

　　從用戶角度出發來描述重現步驟，步與步之間不該該有太大的業務跳躍，最好是連貫的。

　　例如：

　　Repro Steps：

　　1. Open DemoApp to enter Login screen

　　2. Copy username from enternal file

　　3. Paster username to username field of Login Screen

結果

　　結果能夠分爲「指望結果」和「實際結果」，結果能夠有多個，也能夠穿插在重現步驟之間（好比重現步驟中有多個缺陷的問題）

優先級

　　凡事都有輕重緩急，缺陷也是，須要標明缺陷優先級和緊急程度，以便開發團隊決定先作仍是延後。

重現頻率　　

　　固然，大部分的缺陷是能夠100%重現的，對於少數缺陷可能很難重現，或者不太容易重現，這就要標明重現的概率，好比50%。每每這種缺陷須要提供詳細的日誌文件，以便從日誌角度獲取重現或者解決突破口。

 

附件

　　附件很是重要！附件的格式能夠多種多樣，圖片，日誌文件，視頻等。除了能夠提供直觀的認識（圖片，視頻），還能夠有更多的信息（缺陷討論郵件，日誌等）。

變通方案（Workaround）

　　變通方案是提供一種繞過當前問題而使用其它的產品功能的一種方式。這樣客戶就能夠在缺陷未解決的狀況下繼續使用產品。

發生緣由分析（Root Cause Analysis）

　　描述從代碼角度，該缺陷是如何發生的。能作到這一步的測試人員須要有較高的讀寫代碼的能力。

環境配置

　　用以描述測試環境的配置，好比OS，相應產品版本等。

 

那麼，問題來了！缺陷包括這麼多方面，若是每一個缺陷都這麼寫，要耗費多少effort啊！！！（畢竟測試時最忙的！）

我的認爲沒有必要每一個都這麼寫，畢竟寫缺陷報告對客戶來講沒有value。缺陷報告是缺陷的信息載體，它存在的意義是用於更好、更清楚的進行開發團隊之間的溝通和之後的回顧，寫到什麼程度仍是須要根據實際狀況有所取捨。（好比Root cause analysis在時間不富裕的狀況下能夠忽略等）

綜合以上的方面，下邊是一個模板，但願對你們有所幫助。

Title:   [Product][Version]_[Feature]_Title

 

Description/Summary:

 

Impact:

 

Priority/Severity:

      Critical

Frequency:

     100%

Precondition:

 

Repro Steps:

     step 1:

     step 2:

     Expected Result:

     Actual Result:

     step 3:

 

Expected Result:

 

Actual Result:

 

Root Cause Analysis:

 

Workaround:

 

Environment:

 

Attchment: