大叔大婶带你走一条接地气的测试进阶之路

【周问日答】(8)好的缺陷报告应该是什么样的?

上一篇 / 下一篇  2017-10-27 10:51:08 / 个人分类:测试问答

【提问】

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

【旧识】

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

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

  1. 一目了然的 bug 标题,让读者从标题就能清楚这是个什么样的 bug;
  2. Bug 的发生概率,让读者清楚这个 bug 是百分之百能发生,还是有一定的发生概率;
  3. 清楚和有序的复现步骤,让开发能够复现这个 bug;
  4. 准确和清晰的期望结果和实际结果;
  5. 选择了正确的模块分类和对应开发,不会导致相应的开发搜不到正确的 bug;

【新知】

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

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

TAG: 测试知识 测试问答

 

评分:0

我来说两句

日历

« 2024-04-17  
 123456
78910111213
14151617181920
21222324252627
282930    

数据统计

  • 访问量: 72496
  • 日志数: 82
  • 建立时间: 2017-09-03
  • 更新时间: 2018-01-11

RSS订阅

Open Toolbar