多人评审测试用例

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

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

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

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

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

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

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

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

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

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

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

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

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

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