测试工作中，经常会遇到一些低概率出现的问题，如果再是个严重问题，那测试人员的压力无疑是很大的，一方面是因为低概率难以复现，另一面则是来自项目组的压力。
如何在测试时减少此类问题的重复投入，我的思考如下：
一定要接上log
很多测试新人，发现个bug兴奋的直拍大腿，然后啪一下甩给研发，很快哈，研发接住一看，问：日志呢？此时你两眼蒙圈，表示大意了，没有抓。只能重新搭建下环境，开始复现~~ （还有一种情况，是接了日志，但是没开启时间记录，也不是正确出招的方式。）
记录问题出现的时间点
出现问题时，第一反应是看下当前日期，记录住问题出现的时间节点，做了什么操作；把相关的设备日志、APP日志、服务器日志等，都提供给研发，有一个准确的时间线。这样研发定位起来方便快捷，概率性问题可能不需要复现也能知道了bug的原因。
bug出现前后应该做点什么
反馈问题时，不能只反馈一个现象，而不告知前因后果。否则你必然拿下研发一血，主要是被气得吐血... 比如你发现设备突然重启了，反馈给研发问题的正确姿势是：
XX，刚刚我做了ABC操作，现象是设备重启了，重启后的结果是可恢复？或不可恢复（进而引发卡死问题），我相同步骤操作了3次，能/不能/概率出现；这是相关日志。这样梳理，有助于研发判断软件的设计逻辑是否正确；从现象判断原因。
有图有真相
对于低概率的问题，出现的时候也可以通过拍视频和图片，进行信息记录。有时候现象不一定描述得非常准确，有实际记录，也作为后续判断问题性质的依据。
自动化
在时间有限的情况下，尽量去使用自动化，跑一些业务脚本，测试某个功能线的稳定性；充分利用晚上时间，接好串口，设置好脚本，第二天就可以看结果，通过这种高密度的测试，一个模块的稳健性很容易判断。一个低概率bug也是相对容易复现。
共同关注
所谓低概率问题，往往是需要某个特定条件，才能勉强复现；你要问研发这是什么？他们表示也很玄学，毕竟软件的设计错综复杂，容错性低一点都能导致严重bug，在定位无果的情况下，只能通过优化某段代码逻辑，号称做了规避，其实这话有时候研发自己也不信。那怎么办呢？首先要抛出去，让产品线的相关人员知道有这么个问题，然后根据项目类型，请合作部门一起关注；通过使用数量的累加，看是否要再加大投入。