出现漏测的原因、解决方法
在产品周期的任何阶段，都有可能出现测试遗漏，测试无法保证百分之一百的穷举覆盖，只能根据一定的测试方法，比如边界值，进行抽取测试
而这边的漏测主要指的是在业务上，由于业务分析不全面导致的漏测
出现的原因可能有以下几点：
①、需求评审阶段：对业务需求了解不透彻，没有深入挖掘隐藏的需求点；
>>>改进方法：
需求评审前，提前了解需求文档与原型，先形成自己对产品的思考，可以借助脑图来列出对产品设计的疑问点，产品设计的缺点，可以从测试或者产品或者用户的角度来点评产品功能；
其次，需求评审期间，针对自己的疑问提出，与开发、产品，多问为什么，多确认....比如功能如何实现，超过预期如何处理数据来源、逻辑处理是客户端处理还是服务端处理、缓存机制、是否新增接口或新增字段、是否存在新旧版
兼容问题
需求评审会后，整理开会梳理的疑问点，开始接下来的需求分析阶段.....
②、需求分析阶段：测试用例设计不全面，导致场景遗漏
>>>改进方法：
需求评审后，根据梳理的疑问点，对需求进行分模块，再将模块拆分成功能点，再根据合理使用测试用例的设计方法，来进行需求分析。
测试用例或分析完毕后，有必要进行组织用例评审（或组内用例评审）：一方面是组内如果有业务老司机，可以在用例评审上快速指出遗漏之处，有助于测试人员打开思路，
尽可能多的覆盖测试点，评审过程中，如果有发现不确定的，一定要及时记录下来，不要盲目猜测，因此如果有产品在场就更好了。
根据测试用例执行上线后，若发现有用户反馈问题，首先要确认是否必现、偶现，如果是必现，就要考虑是否是用例设计时场景没有考虑全面引起的，如果是必现，
我们可以通过和技术接口人沟通，确认该场景的一些具体复现步骤，确认引入原因，解决方案。然后进行测试用例完善：除了补充该场景case外，考虑一些和该场景相关联的场景，
将多种场景下测试用例及时完善、评审，增加到用例库中去。
③、测试阶段：未完全按照测试用例执行
>>>改进方法：
测试用例无法保证百分之百覆盖所有的场景和细枝末节，但是可以最大程度的保证产品质量，尽量避免出现缺陷，前提是要严格按照测试用例执行。
其次，执行时，要养成边记录边执行的习惯，一轮执行下来，哪些通过、失败（原因）、阻塞（原因）、有些实际结果与预期结果不一致，但产品不予解决，也要标注
这样，在回归测试复盘时，才能更有目的的测试回归，确保修复bug导致关联功能引入的新bug也能被发现。
同时，这一份用例执行记录，也就是很好的体现你这个模块的覆盖程度+完成度
④、测试阶段：由于测试资源、测试环境限制，导致无法覆盖场景
>>>改进方法：
部分场景，在正式环境无法模拟（无法造数据），但测试环境又不能准确模拟，因此，就需要开发一个灰度发布环境（预览环境），既能满足测试任意造数据最大限度模拟线上，但又不影响线上正式数据
⑤、回归阶段：开发人员引入新bug
>>>改进方法
开发方面：从代码管理层面，及时review代码，开发修复一个bug提交代码自测通过准备提测时，开发团队提交代码进行代码review，引入新BUG的可能性较小。
测试方面：精准回归，通过diff代码的方式，了解代码改动点，精准分析改动点对相关联的功能点的影响，将开发人员修复的BUG确认验证，并将相关联的功能点尽可能在app测试阶段通过遍历回归测试到。