如何写有效的缺陷报告

介绍

缺陷报告是测试过程中可以提交的最重要的东西。它的重要性丝毫不亚于测试计划，并且比其他的在测试过程中的产出文档对产品的质量的影响更大。所以很有必要学习如何写出有效的缺陷报告。有效的缺陷报告将能够：

l         减少开发部门的二次缺陷率

l         提高开发修改缺陷的速度

l         提高测试部门的信用度

l         增强测试和开发部门的协作

 

为什么测试人员从开发那里得到的反馈比从其他部门得到的更多？一定程度上这个答案就是缺陷报告，依照一些简单的规则可以使整个过程更加顺畅。但是我们的目标并不是写一个非常完美的缺陷报告，而是能够传达正确的信息，让工作得以完成并且能够简化流程的有效的缺陷报告。

这篇文章主要讲述缺陷报告的两个方面：1）描述的注释；2）摘要。首先我们先来看注释。

 

缺陷注释

下面是确保你下一篇缺陷报告是有效的几个关键点：

l         Condense－精简，清晰而简短

l         Accurate－准确，这到底是不是一个bug？还是用户操作错误，或者是理解错了，等等？

l         Neutralize－用中性的语言描述事实，不带偏见，不用幽默或者情绪化的语言。

l         Precise－精确，这到底是什么问题？

l         Isolate－定位，这到底是个什么样的问题？尽量缩小这个问题的范围。

l         Generalize－还有没有其他的某些地方存在这样的问题？

l         Re-Create－如何引发和重现这个bug？（环境，步骤，前提条件）

l         Impact－影响，这个缺陷对客户有何影响？对测试有什么影响？

l         Debug－怎么做才可以让开发更容易来修改这个bug？（跟踪，截图，日志，直接访问等等）

l         Evidence－证据，如何证明确实存在这个bug？

 

写有效的缺陷报告并不需要很好的文字功底，只要确认你正确回答了上面的问题，关键就是确认你覆盖了所有的你的缺陷报告的查看者关注的要点就好了。

 

有效缺陷注释的要点

精简

清晰而简短。首先，去掉不必要的词；其次，不要添加无关的信息。包含相应的信息是最重要的，但是确保这些信息都是有用的。不管什么原因，对于那些没有描述清楚如何重现或者难以理解的问题，你都应该提供更多的信息。写过多的不必要的信息也是问题的一种。

精简的例子	缺陷注释
不要这样写： TMI（Too Much Information）	当我正在专心测试的时候，报内存错误，这时我发现一个我不熟悉的GUI，我试了好多边界值以及错误的条件，但是运行正常。最后我请空了数据，并且点击了前进按钮，这时系统异常中止了，多次的反复尝试证明，在任何情况下，只要“产品描述”这个字段没有数据，点击前进或者退出甚至取消，系统都会中止。
要这样写：	在产品信息页面，如果产品的描述字段为空，前进，退出和取消的功能会使系统意外中止。

 

准确

确信你正在提交的确实是一个bug，如果你因为安装问题或者理解错误，操作错误错报了bug的话，你将会很快失去你的信誉。所以在提交一个bug前，一定要考虑：

l         是否会因为安装的某个原因导致这个问题？例如，是否安装了正确的版本而且各种先决条件也已经满足？是否你登陆，安全设定，命令或者操作的顺序有错误？

l         是否存在清除不干净，或者结果不完整，或者因为上次测试的某些更改导致？