【落叶343】【周问日答】（8）好的缺陷报告应该是什么样的？

作者: 秋之川 | 来源:发表于2017-10-27 10:37 被阅读49次

文/秋之川

这是《落叶》文集里第 343 片落叶，希望你能喜欢，不为别的，只为这份坚持。

好的 Bug Report 应该是什么样的？

很多测试工程师非常擅长找 bug，我也是其中一员，但 Bug Report，也就是报 bug 时的描述，写的好的人就没有那么多了。

我先对我之前认为好的 Bug Report 做一个画像：

在接触到更多类型的测试对象和项目管理之后，我对上述的 Bug Report 画像做了一些补充：

Bug Report	要求	目的
标题	一目了然	看标题就清楚是什么 bug，方便读者快速了解存在哪些问题
发生概率	准确	让读者知道这个 bug 是百分之百会发生，还是有一定的发生概率
复现步骤	清楚、有序	让开发能轻松重现问题，加快 bug 的修复，同时减少开发测试之间的来回补充信息损耗
实际结果	准确、清晰	明白错误的结果是什么样的
期望结果	明确、无二义性	明白正确的结果应该是什么样的
严重级别	从对用户的影响判断	是决定该 bug 是否应该被修复的依据
优先级别	从对后续测试的影响判断	是决定该 bug 是否应该被尽快修复的依据
测试环境	详细的环境描述	对于有多个测试环境的产品来说，要说明是测试环境还是预上线测试环境
前置条件	正确且完整的组合条件	有些 bug 只存在于某种特定的组合条件之下
测试输入	能重现 bug 的数据或账号	方便开发人员快速重现问题
性质	基于上一个测试版本来定性	便于质量数据分析，统计分析新发现的（New Discovery）、回归性的（Regression）、滞后发现的（Later Discovery）

作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵

相关文章