如何写一个完美的软件缺陷报告（Defect）
本帖最后由 测试的味道 于 2017-6-2 14:07 编辑编写缺陷报告是测试人员的日常工作，好的缺陷报告能够让开发人员更容易理解，更快速的定位问题；不好的缺陷报告可能会误导调查方向，增加沟通成本。那么一个好的缺陷报告应该
编写缺陷报告是测试人员的日常工作，好的缺陷报告能够让开发人员更容易理解，更快速的定位问题；不好的缺陷报告可能会误导调查方向，增加沟通成本。那么一个好的缺陷报告应该包括哪些方面呢？
请看我的mindmap：
http://images2015.cnblogs.com/blog/54848/201604/54848-20160424121808945-820867989.png
标题
1. 首先要做一个“标题党”（此标题党非彼标题党）。标题一定要清晰简洁易理解，不应该臃长
2. 尽量前缀要规范，例如模板： __，这样描述会很清晰，也方便查找
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: __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:
:D
页:
[1]
