編寫缺陷報告是測試人員的日常工作，好的缺陷報告能夠讓開發人員更容易理解，更快速的定位問題；不好的缺陷報告可能會誤導調查方向，增加溝通成本。那么一個好的缺陷報告應該包括哪些方面呢？
請看我的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在時間不富裕的情況下可以忽略等）
綜合以上的方面，下邊是一個模板，希望對大家有所幫助。