bug的描述

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

• 标题

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

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

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

• 环境配置

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

• 前置条件

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

• 重现步骤

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

• 结果

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

  W：你错了没？

  M：我哪儿错了？

  W：你自己哪儿错了你都不知道？！

• 优先级

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

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

• 附件

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

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

• 发生原因分析

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

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

难以重现的 BUG

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

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

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

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

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

提出 BUG 的四重境界

就如同我们打游戏一样，同样一个英雄，在不同的玩家手里可以用出不一样的效果，测试亦然。同样是发现 BUG，不同的 tester 同样会有不同的境界。

第一重：筑基。

顾名思义，这一重境界还是铸造基础阶段，我们能够找出问题，但是可能描述不太清楚。如：

在进行添加购物车、结算操作时，报错。上述的 BUG 描述仅仅能够做到发现问题，至于是什么操作，什么报错，并不能够指引开发人员去具体复现和定位。所以如果要打分的话，这样的 BUG 我可以给打 30 分。

第二重：灵寂。

在武侠中，这是能力大提升后的平稳阶段，也是步入更高殿堂的前阶段。在这重境界中，我们开始不但能够找到问题，也能够描述清楚问题。

添加商品进入购物车，点击结算未发生跳转，错误信息页面提示：“error:null”。截图及日志见附件。

这样的描述加上附件已经基本能够达到让开发人员看懂并着手解决了，在没有代码能力的前提下，可以算是将功能测试做到了不错的境界。所以，这样的描述可以打到 60 分。

第三重：元婴。

这是真正步入修真殿堂的一步，对于测试来说，也是更进一步的体现。在这重境界中，我们开始去阅读、去审查代码，去尝试找出代码存在的问题。

添加商品进入购物车，点击结算未发生跳转，错误信息页面提示：“error:null”。截图及日志见附件。根据日志排查，在 XX 类中 XX 行位置，报空指针异常，可能由于前边对 XX 参数未赋值。

这样我们做到的不仅仅是发现问题，描述问题，同时定位错误发生的原因。这样我们可以达到 80 分。

第四重：大乘。

巩固修为的果实，慢慢累积力量，直到圆满，也就意味着我们测试能力的大成，对我们的要求也就更高了，基本可以做到：教开发人员写代码。这也是我觉得测试的最高境界了。

添加商品进入购物车，点击结算未发生跳转，错误信息页面提示：“error:null”。截图及日志见附件。根据日志排查，在 XX 类中 XX 行位置，报空指针异常，分析由于前边对 a 参数未赋值。建议修改：从前边调用用户信息查询接口的返回对象中，将其中的 b 参数赋值到 a 参数中，再调用结算接口。

在这重境界里，对我们的要求是：找到问题、描述清楚、定位问题且提供解决思路。能做到这样的话，我们可以打个 99 分了。教开发写代码，是我们做功能测试的巅峰，也是大家不断提升自己能力的体现。