如何写一个完美的软件缺陷报告（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啊！！！（毕竟测试时最忙的！）

个人认为没有必要每个都这么写，毕竟写缺陷报告对客户来说没有value。缺陷报告是缺陷的信息载体，它存在的意义是用于更好、更清楚的进行开发团队之间的沟通和以后的回顾，写到什么程度还是需要根据实际情况有所取舍。（比如Root cause analysis在时间不富裕的情况下可以忽略等）

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