1.为什么要写缺陷报告

当我们发现Bug 后，需要通知开发人员，缺陷报告是一种沟通的介质，它的主要目的是让开发人员能够亲眼看到这个 Bug 是什么，如果不提供足够详细的说明来帮助开发人员重现 Bug ，那么他们就没法确定问题的根源。缺陷报告是一种用来说明期望结果和实际结果之间的差异以及描述 bug 如何重现的文档。发现 Bug, 最好是一发现并确认了 bug 就立即填写缺陷报告，而不要等到当天测试结束再和其他 bug 一起填，因为那时就有可能遗漏一些要点，甚至是遗漏某个 bug 。花点时间分析一下造成 Bug 的根本原因是什么，你可能会因此发现更多的 Bug ，最好能把你的任何有用的证据都写到缺陷报告上。缺陷报告提交之前自己再读一遍，可能会有错别字或者什么写错的地方需要重写。

2. 填写缺陷报告时应注意的几个地方

2.1 标题

缺陷报告的“标题”部分是一个缺陷报告带给读者的最初印象，它在浏览大量 Bug 时起着非常重要的作用，每个缺陷报告都应该有一个能够突出重点的“标题”，就好像做广告一样。好的标题应该控制在措辞，要据实反应情况，不要夸大或缩小 Bug 的影响。有时候会发现一些令人不可思议的低级 Bug ，但还是要尽量使用较为委婉的词语来表述，免得伤害开发人员的自尊心。

2.2 描述

描述越简单直接越好，要考虑到目标读者，他们可能是开发人员、测试人员、管理人员或者其他人，所以要让目标读者都能看得懂Bug 描述。

2.3 重现的步骤

每一步以及所有步骤组合起来应该是符合逻辑的。清晰地列出所需的前置条件。

步骤应尽量详细，例如，我们要描述通过excel 保存一个表格，那么有两种 方式，一是说得细点儿，即“从 [ 表格 ] 菜单里单击 [ 保存 ] ，另一种就是说得简单点，即“保存表格”，但请记住，并非所有人都知道如何从 excel 保存表格，或者说所有人都会使用同样的方式保存表格，所以描述的时候最好还是采用第一种方式。写完之后自己用新的测试数据或者在新的系统上按照步骤亲自执行一遍，或许能够发现缺陷报告里有一些是遗漏的或多余的步骤。

2.4 测试数据

开发人员重现Bug 时可能不会访问测试环境，有些 Bug 可能只能用一定的测试数据才能重现，所以尽量把测试数据附在缺陷报告上。

2.5 屏幕截图

屏幕截图是缺陷报告里非常重要的组成部分，有时一张图能胜过千言万语，但也不能养成习惯不管有用没用的图都往上贴，或者是只贴图而缺少文字描述。附图能够使开发人员结合你的描述快速地重现Bug 是最理想的：所附图片的尺寸和占用空间不要太大，尽量用 jpg 或 gif 格式，而不要用 bmp 格式。在图中出问题的地方标注一下，更利于开发人员快速定位。

2.6 严重程度 / 优先级

设置Bug 的严重程度之前，应该全面地分析 Bug 的影响，如果我们认为这个 Bug 的优先级很高，那么应该在缺陷报告里说明优先级高的原因。

2.7 日志

如果可以的话一定要把程序报错的日志附上，这会让开发人员比较容易进行分析和调试。很多不能重现的Bug 都是因为缺少日志，开发人员就会返回去找测试人员要日志信息。如果日志文件不大的话，比如十几行，那么可以直接把日志信息粘到缺陷报告里，如果日志很大的话，那么最好单独粘到一个文件里，然后当作缺陷报告的附件就可以了。