关于测试漏测bug的一些反思

事由

最近新迭代了一个app版本,上线的前几天一帆风顺,没有任何客户反馈bug。我们整个团队不禁开心,看来这个月的OKR(因测试漏测的bug小于1个)能实现了。结果就在昨天,啪啪的开始打脸,而且是打我自己的脸。

iPhone端昨天集中暴露出来3个问题,虽然是不同模块的问题,但却都是我负责的模块,正常严格按照封板执行的话,我是能发现问题的。但是很遗憾,这些问题都是用户反馈出来的。

因为觉得这些模块上个版本并没有功能点的改动,所以走封板用例的时候我并没有按照用例去严格执行(1、时间不够;2、自己比较大意,觉得没有改动应该不会出问题),结果因为开发合并代码、开发测试代码忘记注销掉就出问题了。

于是昨天下午客户端紧急发包,修复这几个问题;结果,提交app store审核后,又有用户反馈一个覆盖安装的问题,虽然覆盖路径有点深,但这个属于新需求的点,按常理我应该也是能想到的,结果并没有。于是开发赶紧追回之前的包,又重新提交了一个包。

反思

一天集中爆发出4个问题,尤其是有2个是很浅显的问题,虽然开发方面有原因,但更重要的原因应该在我,确实属于我漏测了,于是今天一整天我都在思考该如何规避这些漏测问题。我想到一些解决方法。

1. 目前的封板用例都是一个同事写的,评审的时候我是参与了的,但实际执行的时候我并没有严格参与,于是我自己梳理了一份自己负责模块的封板用例,按照自己的测试习惯都罗列了下来,场景也核对过不会有遗漏,下次封板准备就按我自己的这个来执行。

2.针对有改动的功能(比如sdk升级、flutter升级),即使开发只是云淡风轻的说一句看下页面即可,我还是要按严谨的态度,将功能全部覆盖一下,而且要多发散下思维,进行探索式测试。

结论

虽然领导没有怎么批评,但自己心里还是不太好受。出现漏测问题,不管是哪方原因,最终也都会有测试的原因在里面,这是自己的工作内容,确实是疏忽了。

希望以后能吸取教训,工作中态度还是要严谨,不要再出现类似问题吧。

你可能感兴趣的