標題

　　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)

描述或總結

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

影響

　　　這部分用以描述該缺陷對用戶實際應用中的影響?！?/p>

前置條件

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

重現步驟

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

　　例如：

　　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，相應產品版本等。