论高质量BUG

朴灿烈づ我的快乐病毒、 2022-10-26 04:58 190阅读 0赞

捉虫”、找 BUG 是测试人员必须具备的能力，无论在任何公司，测试人员在执行测试任务的过程中，发现 BUG、提出BUG 以及跟踪 BUG 都是十分必要且重要的工作。

可以说，BUG 是我们`tester`与开发人员沟通的必备桥梁，但是呢，总是会有这样一种现象发生：我们提出的 BUG 质量不高，让开发人员无法一下子弄明白。

经常就会出现开发者要求测试人员线下重述BUG，但是开发人员可能还不能直接get到测试人员的描述。又要求测试人员重新操作，展示BUG…

如此一来折腾也增加了沟通成本，浪费了时间，光是讲明白一个问题大概半个小时就过去了。所以提 BUG 不仅仅是我们测试人员的技能，更应该考虑我们 BUG 的面向对象：开发人员。开发人员需要什么信息，我们就自然应该在提出时候包含。

那到底如何来编写高质量的BUG呢？

### 编写高质量的BUG ###

我们先换位思考一下，假如我们是开发，会让我们觉得无法理解弄清楚的几种情况：

*  BUG过于简单，只有一句话，描述不清
 *  发现BUG的场景过程没有完全保留，重现困难
 *  多个问题合并成一个，开发不容易定位，也有可能漏过问题

我们知道了自身的症状，那么就从这里开始，一起聊一聊一个优秀的 BUG，应该包含哪些方面的内容呢？

#### 标题 ####

其实每一个 BUG 也都是一个小的文档，既然是文档，我们首先就要做好一个“标题党”。作为一只优秀的标题，要清晰明确简洁地说明两个“W”：

*  **Which**： 哪个系统的哪个功能？
 *  **What happened**：出现了什么样的问题？

也记住另外一个规范：每条缺陷报告只包括一个缺陷。就像刚刚说的，这样可以让开发认真的定位和对待单一的BUG，对于测试人员自己来说，也只需要每次校验一个 BUG 是否修正。

#### 环境配置 ####

如果涉及环境因素的话，比如，有些兼容性问题只在某个浏览器、某个手机系统甚至是某个型号的机器上等等，就需要指明问题复现所在的环境配置信息。

#### 前置条件 ####

有时候，有些问题是需要在某些特殊条件、特殊操作或者特殊数据下才会引发的，这时候最好添加上这部分的描述，便于问题的复现。

#### 重现步骤 ####

从用户角度出发来描述重现步骤，步与步之间不应该有太大的业务跳跃。每一个步骤尽量只记录一个操作，保证快速准确的重复缺陷，确认步骤完整，准确，简短：“完整”就是说没有缺漏，“准确”是步骤正确，“简短”则是要没有多余的步骤，直指问题的核心。

#### 结果 ####

这里的结果其实包含两方面，一是“期望结果”，二是“实际结果”，之所以会产生 BUG，一定是实际结果不符合期望而导致的，所以对于结果一定要描述清楚，否则的话就会变成：

*  老Amy：你错了没？
 *  张三：我哪儿错了？
 *  老Amy：你自己哪儿错了你都不知道？

#### 优先级 ####

凡事都有轻重缓急，所以对于 BUG 来说也是一样，表示自己对于该 BUG 的紧急程度的评估。一般情况下，我们分为下边几级：

*  Critical：非常紧急，需要开发人员立即解决的 BUG，大多数情况下是阻断性的 BUG，不解决的话无法继续测试
 *  High：高优先级 BUG，希望尽快解决，一般属于比较大的核心业务功能缺陷，但暂时不影响后续测试。
 *  Medium：一般优先级，大多数情况下是非核心业务缺陷，建议在发布前要解决的 BUG。
 *  Low：低优先级 BUG，如果能够在发布前解决更好，实在工时紧张可以酌情向后推迟修改，大多数属于优化、用户体验等建议。

#### 附件 ####

附件是非常非常重要的！为了更加方便开发人员定位修改问题，也是方便测试人员自己去回归测试 BUG，适当的附件内容是很有益处的，附件的内容可以多种多样，比较常见的包括：

*  截图：发生问题时的截图对于重现问题有着很重要的意义，也是问题真实存在的证据。
 *  视频：有很多时候，单单依靠截图也很难重现 BUG，这时候如果在缺陷发生或者测试重现的时候能够录制一个短视频，那么对于开发人员来说，简直就是一场“及时雨”。
 *  错误日志：如果你能够找到 BUG 发生时候的具体日志，那对于你自身的提升和开发人员定位问题的好处都是显而易见的。开发人员可以通过此找出报错的打码，测试人员也可以学到更多关于服务器、中间件包括项目业务和部署深入的内容。

#### 发生原因分析 ####

这里就需要大家有一定的代码基础了。如果我们可以自己通过日志等内容定位发生问题的代码和大体原因，我们对于当前系统的理解和测试就可以算是更上了一层楼。当然，这不是必须的，需要大家量力而为。

如果你能够完美地做到上边几点，那么这就诞生了一个个出自于你的高质量的 BUG 了，不仅仅有助于提高项目组中定位和修复问题的效率，同样也锻炼体现了你自己的能力，也更容易得到开发和领导的认可。那么问题来了，刚刚提到了那么多方面，如果每个都这么做，这要耗费多少精力啊？所以，回到我们最初的想法，提出缺陷的意义是更好、更有效地服务于开发和测试团队之间的沟通和未来的回顾，大可不必拘泥于某种特定的格式，适合你的适合当前缺陷的才是最好的，并不是每一个项目都需要覆盖完美，只是一旦需要，我们希望能够看到它们。

#### 难以重现的BUG ####

在漫长的测试生涯中，我们总会碰上一些难以理解的“诡异”事情。偶尔我们发现了一个问题，又按照之前的步骤重新操作了一遍，咦，发现很诡异的事情发生了：刚刚的问题无法重现了！再次尝试多次，仍无法重现。于是，我们心安理得地骗自己：可能是刚才网络异常了吧。可是不知道什么时候，又偶遇了同样的问题，可是又难以重现，这时候该怎么办呢？

首先，尽量在第一时间截图留痕，如果在问题第一次偶发时候没有在意，那么一旦重现失败后续又再次出现的时候，一定要截图存档。

其次，尝试多次（我们暂定20次左右）仍然不能重现，不要继续浪费时间，尽快地去看当时发生问题时的日志，通过日志来追溯当时可能发生的情况，例如多人同步操作，数据库死锁，服务器断线等情况。

接下来，通过当时的数据、环境、配置、特殊操作等再尽量多尝试几次，同时，可以与组内其他测试人员交叉测试，不管是否可以发现，都要把问题提出，并且通知开发，标识该问题为难以重现的 BUG，请开发人员与自己一同通过白盒或代码走查的方式尝试定位。

最后，如果仍难以发现并修改，那么就需要及时评估该问题的影响范围，影响较小的留存后续跟踪，影响较大的则上报项目经理协调解决。

#### BUG的后续跟踪 ####

BUG 提交完不是结束，只是一个流程的开始。你仍然需要实时跟踪 BUG 的进展，甚至对于一些优先等级高的 BUG，还需要去关注修改的进度。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDM1Mjk4MQ_size_16_color_FFFFFF_t_70]  
所以，按照上边来说，我们的状态变化就会是：New -> Open -> Fixed -> Close 。

当然，除此之外，任何一个大型项目结束后，还需要对 BUG 进行分析和汇总，分析问题出现的原因及未来避免方案。总结开来，BUG 是我们测试生涯中不可缺少的一部分，同时也不是非常简单的工作，我们需要不断磨砺自己的技术能力，提出高质量的 BUG，也让我们未来的测试道路越走越好，越走越宽。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDM1Mjk4MQ_size_16_color_FFFFFF_t_70]: /images/20221024/636d3d42e2b347fa9d1cfa45e2f1191b.png