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

事由

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

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

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

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

反思

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

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

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

结论

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

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