如何寫一個完美的軟件缺陷報告（Defect）(2)

　　2. Copy username from enternal file

　　3. Paster username to username field of Login Screen

結果

　　結果可以分為“期望結果”和“實際結果”，結果可以有多個，也可以穿插在重現步驟之間（比如重現步驟中有多個缺陷的問題）

優先級

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

重現頻率　　

　　當然，大部分的缺陷是可以100%重現的，對于少數缺陷可能很難重現，或者不太容易重現，這就要標明重現的幾率，比如50%。往往這種缺陷需要提供詳細的日志文件，以便從日志角度獲取重現或者解決突破口。

附件

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

變通方案（Workaround）

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

發生原因分析（Root Cause Analysis）

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

環境配置

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

那么，問題來了！缺陷包括這么多方面，如果每個缺陷都這么寫，要耗費多少effort?。。。。ó吘箿y試時最忙的?。?/p>

個人認為沒有必要每個都這么寫，畢竟寫缺陷報告對客戶來說沒有value。缺陷報告是缺陷的信息載體，它存在的意義是用于更好、更清楚的進行開發團隊之間的溝通和以后的回顧，寫到什么程度還是需要根據實際情況有所取舍。（比如Root cause analysis在時間不富裕的情況下可以忽略等）

原文轉自：http://www.cnblogs.com/AlwinXu/p/5427520.html