1、为什么要求有效的缺陷报告

缺陷报告是测试过程中最重要的部分，对产品的质量有较大的影响，是测试人员价值的终极体现。好的缺陷报告可以减少研发部门的二次缺陷率、提高研发修改缺陷的速度、提高测试部门的信用度、增强测试和研发部门的协作。Bug 写的越好，在实际中为了修改这个 bug 花费的时间相对来说就会越少，测试人员的信誉度和产品的贡献度也会很好的提升。

2 衡量优秀缺陷报告的质量指标

对于管理层来说，是清晰明了的，特别是在主题摘要这一级。

对于研发人员来说，是有用的。提供能够让研发人员高效的调试问题的相关信息，使其很快的将 bug 从 “打开” 状态转变成 “关闭” 状态，提高测试和开发的工作效率。

对于后期的维护，能够有效的从 bug 信息查询出问题的描述和解决办法

说来容易，在实践中需要测试人员仔细用心

3 如何编写缺陷报告

缺陷报告作为测试和研发之间的沟通的桥梁，测试人员在报告 bug 的时候，有效的 bug 描述，会更加容易帮助开发解决问题。写有效的缺陷报告不要求有较好的文字功底，关键是覆盖了研发所关注的要点。作为一个优秀的缺陷报告，应该包括以下内容：

摘要：简明扼要的对 bug 进行一个概述，目的是让人看了就知道大概出了什么问题。Bug 标题必须简短而且要求描述和传达出准确的信息。这个摘要一般比较短，所以使用一些精炼的关键词是很必要的。比如：用户登录时，密码显示为明文。

以下是一些较差的摘要：

摘要太模糊：在用户登录界面，在输入框中能看到输入的内容。

分析：这个摘要太模糊，没有准确的描述出现了什么问题，反而将问题出现时的状态写了上去。在一些标准中，密码输入框应显示为密文，并且也没有说明是在用户名输入框中还是密码输入框中显示输入的内容。

修正：用户登录时，密码框中显示输入内容。

不足够的信息：密码框问题。

分析：这个 bug 摘要信息很不充足，不知道出了什么问题

太长的摘要：在用户登录界面，在输入框中，输入正确的用户名和密码。在密码框中，显示密码信息。

分析：此摘要有太多冗余信息，把步骤添加到了摘要中。如 “在输入框中，输入正确的用户名和密码” 等这些完全可以放置到 bug 描述步骤中去，

修正：用户登录时，密码框中显示输入内容。

备注：有些测试人员将其命名为 “标题”，这里以我们的 QC 为准，名为 “摘要”

2、bug 属性

在编写 bug 缺陷报告时应该尽可能全面的描述 bug 的属性。以 QC 为例，bug 属性包含如下：

产品模块：发现的 bug 所属的模块

测试版本：当前的测试版本

严重级别

所属项目

是否可重现

3、负责人：负责解决此问题的研发人员

4、检测者：发现此问题的测试人员

5、根据公司的实际情况，增加了 “部门” 和 “迭代周期” 两项，“部门” 是必填项，“迭代周期” 可选。

6、Bug 的详细描述

Bug 的详细描述要达到让研发人员清晰这是一个什么问题，看了能够自己复现的程度，所以要详细但要避免冗余。要包含以下几点：

测试配置：主要是产品的配置，如被测试软件的配置。或者是其他如交换机或路由器等的配置

测试环境：测试所搭建的网络拓扑环境。对于不需要搭建网络环境的测试，可省略，如升级安装包等。

测试步骤：这是比较关键的，目的是帮助研发重现。在有多条步骤的情况下组号列出 1、2、3 等步骤

预期结果和实际结果：这两个实际上都应该写的描述中，不但能够做对比，而且能够有效的证明这确实是一个 bug。例如这样的 bug 描述：

1：使用浏览器访问登陆界面。

2：输入正确的用户名和密码。

3：在密码输入框显示密码信息。

上述 bug 的描述在很熟悉测试产品的情况下或许可以看懂，但都会犹豫一下他想表达什么意思，正确的结果是什么，错误的结果是什么。

在这种情况下若加上 “预期结果” 和 “实际结果”，会使意思表达的更加明确。第二个 bug 将步骤和结果混杂在一起，可以这样修改一下：

1：使用浏览器访问登陆界面。

2：输入正确的用户名和密码。

3：然后点击 “登录” 按钮。

预期结果：密码输入框，显示信息为密文。

实际结果：密码输入框内容为明文。

4 其他注意事项

在报告缺陷的过程中，除了上述描述外还应注意如下：

1、一个 bug 报告只能描述一个 bug，如果将几个问题都写在一个 bug 报告中，开发人员很难发现自己的问题并解决，或者导致某些优先级高的 bug 没有及时得到解决

2、Bug 的唯一性：在提交 bug 报告之前，要确认这个 bug 是否已经被其他人发现并报告（搜索功能）

重现：有些 bug 很容易就重现，有些就很难。如果你能重现一个 bug，应该准确的解释必须的条件。应该列出所有的步骤，包括精确的组合，文件名以及你碰到或重现这个问题的操作顺序。如果你能够确认这个问题在任何文件，任何的操作顺序等条件下都会发生，那也做好能够给出一个明确的示例来帮助开发重现。如果发现一个不能重新的 bug，就尽可能多的提供有效的信息给你的开发人员。截图、日志，抓包等对捕获这个 bug 有帮助的信息可以包含在你的 bug 报告中

3、定位：对于一个测试人员来说，应该做一些有效的事情来帮助定位问题。要多想会不会是外部的什么特殊原因引起的这个问题？会不会是因为网络的问题导致数据不通？或者是应用软件配置错误导致数据不通？如果实在不能定位问题原因，是否可以想办法缩小出错的范围？尽量避免是由于测试人员的问题导致误报了 bug。测试人员定位 bug 的能力，一定程度上是测试人员附加值的体现，能够节省项目组相关人员的时间，缩短了回归 bug 的时间。

4、报告 bug 时要使用中性语言，不要带有感情色彩。不要带有幽默也不要带有任何不满情绪，尽量考虑一下研发的情绪。

5、报告 bug 时要使用中性语言，不要带有感情色彩。不要带有幽默也不要带有任何不满情绪，尽量考虑一下研发的情绪。