看漏测的部分，是因为用例设计不全面导致的，还是用例全面测试时候遗漏了？
如果用例不全面导致，积累经验，补全用例；
如果用例全面，因人力不够导致漏测，就严格按照 case list 测试，避免漏测。同时，跟项目组申请更多的测试时间

你都自称 Testing King 了，还漏测？
首先漏测肯定是不可避免的，你得明白这一点。没有哪个测试或者测试团队敢 100% 保证产品上线后就不会有 bug。测试存在的意义是，尽可能减少线上出现的问题以及问题带来的损失。
其次，你是测试，问题肯定不是你搞出来的吧？那你应该去分析历次线上问题的原因，找规律总结，行程一系列的流程规范，比如冒烟测试的点、版本发布流程等等。通过做一些你能做的事情，来减少线上出现漏测问题的数量，这样起码就在朝好的方向发展。

就只有我一个测试，用例评审也无法避免上线后出现 BUG 呀

最好是列出一个 check list 主要是测试用例设计覆盖

1.拉产品交互开发一起用例 review
2.测试完成一轮测试后，交给产品、交互、视觉进行走查
3.上线前拉上所有项目组成员开一个 bugbash

多人评审测试用例

然后把以前出现过的问题，整个列表每次都检查一下

评审一定要测试吗？？把所有能叫上的都人叫上就行

偶尔漏测无所谓，经验积累，多总结复盘分析，缺陷根因分析持续做下去，还有记得主动扛锅别甩
如果同类型的问题反复出，那可以考虑转行了，别说 Testing King，就是 Testing Gold 也不好使

1、你在小公司，首先你要给项目组定好，用例评审之后，就是你们产品和开发共同敲定的用例，用例范围内的测完我就 OK，不在这个用例范围内到线上产生的 bug 一旦发生，就不是我测试的责任。要做到先小人后君子的精神！
2、bug 是永远找不完的，腾讯 QQ 已经 20 年了，到现在还有 bug。你首先要保证，线上明显的 bug 不要有，一点查询就报错的，那这也太扯了，而且一点查询按钮就搜索出数据，你测试用例的冒烟用例肯定涵盖了，如果不涵盖，只能说明你们产品、开发眼睛瞎，你这个测试也是二逼。你说对吧？
做到以上两点，我觉得没有像你这么多的漏测烦恼了！请参考！

不认同。什么敲定的测试用例测完就 ok！用例评审开发和产品，只是帮你检查和补充你没想到的点，而不是让他们来替你思考。除此之外的，如果线上出现的问题，发现用例文档没覆盖到，主责当然还是测试的。就是属于你漏测了

如果老是漏测，作为测试负责人，测试人员都得好好反思了。

1. 是测试人员的专业知识不够？还是态度问题？
2. 是否系统太难，有些场景大家都没想到？或者传统方法无法测试到？
3. 是否需求理解有误差？
4. 是否流程有问题，或者测试时间太少?
5. 是否有用例评审？交叉测试？发散测试？ 思考好这些问题，估计能减少一些误差

bug 无法完全避免，时间允许总归会发现问题。保证已有功能核心部分与迭代部分不发生较严重 bug 与界面 bug。测试流程完成交付测试报告，给研发负责人，产品，运营三方验收签字分责

测试用例的问题？
测试执行的问题？