软件测试，随机bug开发敷衍不修改？我.......差点又背锅了

目录：导读

前言
1、一定要接上log
2、记录问题出现的时间点
3、bug出现前后应该做点什么
4、有图有真相
5、自动化测试
6、共同关注
7、总结

前言

当找到bug
如果开发人员不修改的话，无非就是几个问题。

第一个，就是需求不明确，而导致开发说我理解的需求就是这样子的，或者说需求没有明确的写出来，我认为这样子设计就OK了。

那么对于需求不明确的问题我们去找谁？
我们去找产品经理去进行一个确定，产品经理确定了需求是什么样子的，那开发要改就必须要修改。

第二个，就是技术问题，现在的技术无法去修改。或者有一些问题不是通过开发人员就可以去修改的，可能还涉及到一些底层，或者说涉及到第三方公司需要提供的一些技术。对于这一类型问题，我们拿出来进行评审，之后由上面的领导出具一个解决方案。

第三个，就是随机性bug，是有时突然出现的bug，复现不到的bug。这就让我们测试人很难受。

测试工作中，经常会遇到一些低概率出现的问题，如果再是个严重问题，那测试人员的压力无疑是很大的，一方面是因为低概率难以复现，另一面则是来自项目组的压力。

低概率Bug，研发敷衍说复现不到

如何在测试时减少此类问题的重复投入？

1、一定要接上log

很多测试新人，发现个bug兴奋的直拍大腿，然后啪一下甩给研发，很快哈，研发接住一看，问：日志呢？此时你两眼蒙圈，表示大意了，没有抓。

只能重新搭建下环境，开始复现~~ （还有一种情况，是接了日志，但是没开启时间记录，也不是正确出招的方式。）

2、记录问题出现的时间点

出现问题时，第一反应是看下当前日期，记录住问题出现的时间节点，做了什么操作；把相关的设备日志、APP日志、服务器日志等，都提供给研发，有一个准确的时间线。

这样研发定位起来方便快捷，概率性问题可能不需要复现也能知道了bug的原因。

3、bug出现前后应该做点什么

反馈问题时，不能只反馈一个现象，而不告知前因后果。否则你必然拿下研发一血，主要是被气得吐血… 比如你发现设备突然重启了，反馈给研发问题。

正确姿势是：
XX，刚刚我做了ABC操作，现象是设备重启了，重启后的结果是可恢复？或不可恢复（进而引发卡死问题），我相同步骤操作了3次，能/不能/概率出现；这是相关日志。这样梳理，有助于研发判断软件的设计逻辑是否正确；从现象判断原因。

4、有图有真相

对于低概率的问题，出现的时候也可以通过拍视频和图片，进行信息记录。有时候现象不一定描述得非常准确，有实际记录，也作为后续判断问题性质的依据。

5、自动化测试

在时间有限的情况下，尽量去使用自动化，跑一些业务脚本，测试某个功能线的稳定性；充分利用晚上时间，接好串口，设置好脚本，第二天就可以看结果。

通过这种高密度的测试，一个模块的稳健性很容易判断。一个低概率bug也是相对容易复现。

6、共同关注

所谓低概率问题，往往是需要某个特定条件，才能勉强复现；

你要问研发这是什么？
他们表示也很玄学，毕竟软件的设计错综复杂，容错性低一点都能导致严重bug，在定位无果的情况下，只能通过优化某段代码逻辑，号称做了规避，其实这话有时候研发自己也不信。

那怎么办呢？
首先要抛出去，让产品线的相关人员知道有这么个问题，然后根据项目类型，请合作部门一起关注；通过使用数量的累加，看是否要再加大投入。

7、总结

经验环境和遗传造就了你的面目，无论是好是坏，你都得耕耘自己的园地；无论是好是坏，你都得弹起生命中的琴弦。

钢是在烈火和急剧冷却里锻炼出来的，所以才能坚硬和什么也不怕。我们的一代也是这样的在斗争中和可怕的考验中锻炼出来的，学习了不在生活面前屈服。

宝剑锋从磨砺出，梅花香自苦寒来。如果你是一把宝剑，生活就是磨刀石，你需要磨；如果你是一朵梅花，就需要经历寒冬。我祝福你如梅花一样清新迷人，如宝剑一样所向无敌。