一个信心十足的测试人员可以是“霸气侧漏”的：“相信我！都测过了！”。但不幸的是，一上线，发现“漏测”了！不是需求理解的遗漏，而是代码级别的漏测，防不胜防啊！那有没有办法避免“漏测”呢？
让我们先来看一个关于测试的核心问题：QA测的, DEV改的，用户用的，这3者是什么关系？
我认为的理想关系是这样的：
但实际上的关系往往是这样的：
图2中：
•黄色部分代表：“DEV改的”但没有被 “QA测的”
•红色部分代表：“DEV改的”且“用户用的”但没有被“QA测的”。它可以被包括在上面黄色的部分，只是测试优先级更高
•橙色部分代表：“用户用的”且没有被“QA测的”
那么如何避免这些”漏测“呢？
1. 针对“DEV改的”但没有被 “QA测的”（黄色部分）
•目标：
• 通过提供“本轮DEV改过，但测试环境没有跑到的代码”的报告，指导QA补测这些地方，实现“凡改动过，必测过”。
•思路：
•通过GIT 拿到当前正在开发的DEV branch和产品的Release branch之间的差别，识别出改动过的代码
•通过jacoco得到测试环境的累计的代码覆盖情况
•比较得出：本轮改动过，但没有被测试覆盖过的代码报告。
•QA根据报告，补测
•参考资料： •https://testerhome.com/articles/16982
2. 针对“用户用的”且没有被“QA测的”（橙色部分）
•目标：
•通过提供“用户常用的，但测试环境没有跑到的代码”的报告，指导QA补充自动化测试用例，实现“用户常用的，必被自动化测试时刻保护”。
•思路：
•识别什么是“用户常用的”？(通过静态和动态结合的方法）
•功能级别：BA提供VIP客户的业务流程/数据；QA分析VIP客户的真实数据
•方法级别：ART report （提供被访问的方法列表（带累计访问次数））（这个是我们内部的一个报表）
• 代码行级别：产品环境的Jacoco report
•方案：
•理想方案：到代码行级别
•产品环境jacoco report 覆盖到，但QA环境自动化测试后的jacoco report里没有覆盖到的方法/行。
•*需要测试jacoco report对性能的影响
•现实方案：到方法级别
•产品环境ART report 里按照调用次数排名，没有被QA环境自动化测试后的jacoco report覆盖到的方法列表。
