说到bug相信大家都不陌生，在过去的互联网行业中，相信你一定听到开发会说这样一句话“我写的代码没问题，一定没有bug”。然后每次交付给测试手中都能让那些信心满满的开发处在崩溃的边缘.....
有人说测试就是为了bug而生的，也有人说测试行业那么容易，除了点点点不就是给开发提bug吗？但是如果我说提交bug也是一门技术活，你们怎么看？啊，什么？提交bug还不简单，怎么就是门技术活了.....提交bug难道比开发写代码还困难吗？你一定是在忽悠我们......
别急，我们接着往下看。
在我觉得提交高质量bug往往会比开发写代码的关注度更值得留意，你需要从多重因素去考虑bug的出现原因、出现场景、解决方案等。
相信你们在出入测试的时候肯定会遇到开发问这样一个问题：
**dev：来来来，那个测试，你给我说说你提的这个bug是什么意思？怎么复现的？**
** test：BALABALA.......（此处省略200字） **
** dev：你有日志吗？报错信息我看看.....（此处省略100字）**
** test：等会啊，我回去发给你。**
** dev：算了， 我在我本地操作下看看吧。**
如此一来折腾也增加了沟通成本，浪费了时间，光是讲明白一个问题大概 5 到 10 min 就过去了，更重要的是，在非常忙碌的情况下，大家也会感到很烦躁，影响心情。所以提 BUG 不仅仅是我们测试人员的技能，更应该考虑我们 BUG 的面向对象：开发人员。开发人员需要什么信息，我们就自然应该在提出的时候包含相关信息。
根据上述所说我们今天说说我们的关注点，如何提交高质量的bug，那么什么bug算高质量的bug？
我们先换位思考一下，假如我们是开发，会让我们觉得无法理解弄清楚的几种情况：
1、BUG 过于简单，只有一句话，描述不清
开发人员最怕的就是这种类型的 BUG，举个例子：
这时候内心就有了“灵魂三问”：有什么问题？怎么操作出来的问题？给个问题的截图好不好？
2、发现 BUG 的场景过程没有完全保留，重现困难
3、多个问题合并成一个，开发不容易定位，也有可能遗漏问题
我们知道了自身的症状，那么就从这里开始，我们来说一说优秀的 BUG，应该包含哪些方面的内容呢？
标题其实每一个 BUG 也都是一个小的文档，既然是文档，我们首先就要做好一个“标题党”，当然，此“标题党”非彼标题党。作为一只优秀的标题，要清晰明确简洁地说明两个“W”：1. Which： 哪个系统的哪个功能？2. What happened：出现了什么样的问题？也记住另外一个规范：每条缺陷报告只包括一个缺陷。就像刚刚说的，这样可以让开发认真的定位和对待单一的BUG，对于测试人员自己来说，也只需要每次校验一个 BUG 是否修正。像我上述说的那些就是反面教材。
环境配置如果涉及环境因素的话，比如，有些兼容性问题只在某个浏览器、某个手机系统甚至是某个型号的机器上等等，就需要指明问题复现所在的环境配置信息。
前置条件有时候，有些问题是需要在某些特殊条件、特殊操作或者特殊数据下才会引发的，这时候最好添加上这部分的描述，便于问题的复现。
重现步骤从用户角度出发来描述重现步骤，步与步之间不应该有太大的业务跳跃。每一个步骤尽量只记录一个操作，保证快速准确的重复缺陷，确认步骤完整，准确，简短：“完整”就是说没有遗漏，“准确”是步骤正确，“简短”则是要没有多余的步骤，直指问题的核心。（如果想训练bug的质量提交推荐云测众测登录-Testin众测bug探索武试考核登录-Testin众测）
结果这里的结果其实包含两方面，一是“期望结果”，二是“实际结果”，之所以会产生 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 提交完不是结束，只是一个流程的开始。你仍然需要实时跟踪 BUG 的进展，甚至对于一些优先等级高的 BUG，还需要去关注修改的进度。通常情况下一个 BUG 的生命周期是：
所以，按照上边来说，我们的状态变化就会是：New -> Open -> Fixed -> Close 。
提出 BUG 的四重境界
就如同我们打游戏一样，同样一个英雄，在不同的玩家手里可以用出不一样的效果，测试亦然。同样是发现 BUG，不同的 tester 同样会有不同的境界。
第一重：筑基
顾名思义，这一重境界还是铸造基础阶段，我们能够找出问题，但是可能描述不太清楚。如：
在进行添加购物车、结算操作时，报错。上述的 BUG 描述仅仅能够做到发现问题，至于是什么操作，什么报错，并不能够指引开发人员去具体复现和定位。
第二重：金丹
在武侠中，这是能力大提升后的平稳阶段，也是步入更高殿堂的前阶段。在这重境界中，我们开始不但能够找到问题，也能够描述清楚问题。
添加商品进入购物车，点击结算未发生跳转，错误信息页面提示：“error:null”。截图及日志见附件。
这样的描述加上附件已经基本能够达到让开发人员看懂并着手解决了，在没有代码能力的前提下，可以算是将功能测试做到了不错的境界。
第三重：元婴
这是真正步入修真殿堂的一步，对于测试来说，也是更进一步的体现。在这重境界中，我们开始去阅读、去审查代码，去尝试找出代码存在的问题。
添加商品进入购物车，点击结算未发生跳转，错误信息页面提示：“error:null”。截图及日志见附件。根据日志排查，在XX类中XX行位置，报空指针异常，可能由于前边对XX参数未赋值。
这样我们做到的不仅仅是发现问题，描述问题，同时定位错误发生的原因。
第四重：大乘
巩固修为的果实，慢慢累积力量，直到圆满，也就意味着我们测试能力的大成，对我们的要求也就更高了，基本可以做到：教开发人员写代码。这也是我觉得测试的最高境界了。
添加商品进入购物车，点击结算未发生跳转，错误信息页面提示：“error:null”。截图及日志见附件。根据日志排查，在XX类中XX行位置，报空指针异常，分析由于前边对a参数未赋值。建议修改：从前边调用用户信息查询接口的返回对象中，将其中的 b 参数赋值到 a 参数中，再调用结算接口。
在这重境界里，对我们的要求是：找到问题、描述清楚、定位问题且提供解决思路。能做到这样的话，我们也算是在测试中脱颖而出了。教开发写代码，是我们做功能测试的巅峰，也是大家不断提升自己能力的体现。
祝大家在测试的道路上越走越宽，早日成神！！！
你们的关注和点赞就是我前进的动力！！！
自我介绍一下吧！我是降谷零，只做最有干货的测试教学哦！！！
版权归原作者 绝世降谷零 所有， 如有侵权，请联系我们删除。