本文探讨了在软件测试中遇到低概率、难以复现的Bug时，测试工程师如何有效处理。建议包括记录日志、问题时间点、前因后果、提供证据和自动化测试，以及与团队共同关注和解决问题。
前言
当找到bug
如果开发人员不修改的话，无非就是几个问题。
第一个，就是需求不明确，而导致开发说我理解的需求就是这样子的，或者说需求没有明确的写出来，我认为这样子设计就OK了。
那么对于需求不明确的问题我们去找谁？
我们去找产品经理去进行一个确定，产品经理确定了需求是什么样子的，那开发要改就必须要修改。
第二个，就是技术问题，现在的技术无法去修改。或者有一些问题不是通过开发人员就可以去修改的，可能还涉及到一些底层，或者说涉及到第三方公司需要提供的一些技术。对于这一类型问题，我们拿出来进行评审，之后由上面的领导出具一个解决方案。
第三个，就是随机性bug，是有时突然出现的bug，复现不到的bug。这就让我们测试人很难受。
测试工作中，经常会遇到一些低概率出现的问题，如果再是个严重问题，那测试人员的压力无疑是很大的，一方面是因为低概率难以复现，另一面则是来自项目组的压力。
低概率Bug，研发敷衍说复现不到
如何在测试时减少此类问题的重复投入？
1、一定要接上log
很多测试新人，发现个bug兴奋的直拍大腿，然后啪一下甩给研发，很快哈，研发接住一看，问：日志呢？此时你两眼蒙圈，表示大意了，没有抓。
只能重新搭建下环境，开始复现~~ （还有一种情况，是接了日志，但是没开启时间记录，也不是正确出招的方式。
最低0.47元/天 解锁文章
572
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
