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