1.1背景
最近，看到某技术群里面在讨论精准测试，没有弄明白到底什么是精准测试，听起来有点新鲜，作为测试难免有点好奇心，查了于些资料，看到一篇文章写得不错，也留下自己的心得体会
当我们测试时候，我们在想什么?
相同的系统，不同的测试人员针对相同的一个功能，A测试人员会写10个测试用例去测，B测试人员会写20个测试用例去测。
我们如何去评估一个系统的测试质量更好?
事后生产遗留缺陷越少，测试的质量越好?
测试案例写得越多、测试的时间越长，测试质量的越好?
自动化UI测试、接口测试、安全测试、性能测试，测试的种类越丰富，测试的质量越好?
当系统的测试用例不断堆积，成百上千甚至过万，每一个版本变更来临，我们该如何选择测试用例?
随着我们测试的越多，测试用例越来越多，工具技术越丰富，我们越来越困惑，我们怎样算是测完一个系统了?如何知道系统功能点测试没有遗漏?如何清晰知道一个系统内部调用流程、业务逻辑?测试效果和测试质量如何更好的体现?
1.2 精准测试理论介绍
根据对代码可见程度的不同，我们可以讲目前的测试活动区分为黑盒测试和白盒测试两类。
黑盒测试主要是一种面向功能的测试，针对软件的需求来编写用例，通过已运行起来的系统软件完成测试活动。在测试中，程序代码对于测试人员来说是一个不能打开的黑盒子，只能根据程序是否能够根据输入信息而产生正确的输出信息来测试。
白盒测试则与黑盒测试相反，测试人员需要深入到代码层面，根据代码逻辑结构和路径来编写用例，程序对于测试来说是可视的，测试需要检查程序的内部结构，从程序逻辑入手，得到测试数据，并进行测试案例设计。
在平安内部，目前主要依然是以黑盒测试为主导。对于黑盒测试，测试人员在完成针对需求故事的用例测试后，系统覆盖率一般能达到70%左右。但是若需要达到最终100%的目标，还需要花费大量的时间和人力补充案例，同时由于黑盒测试中，系统代码对测试人员是不可见的，通常会产生大量重复冗余的测试用例，冗余导致测试用例难以选择和浪费紧张的测试时间，并最终导致用例库难以维护。
针对这种情况，白盒测试在提升测试覆盖率上的效果就相当明显，由于对代码层的掌握，测试人员每增加一个测试用例，测试覆盖率都会有一个跳跃式的增长。然而，由于白盒测试需要测试人员对代码的逻辑结构、调用关系、数据流等等内容都有了解，对人员的技能提出了很高的要求。对于普通测试人员来说，白盒测试并不容易掌握。
因此，针对这样的情况，产生了穿线测试的理论。即通过技术手段，将黑盒测试与白盒测试穿插结合起来，通过黑盒测试搜集数据，并指导用户通过白盒测试补充案例。
基于穿线测试的理论，我们扩展出精准测试工具。它基于源代码变更与覆盖率来指导用户的整个测试过程。它先通过传统的黑盒测试把基本的功能都测试一轮，覆盖率达到70%，同时这个过程受到精准测试工具的监控，并获取该阶段的测试结果数据。之后再通过上一阶段得到的白盒结果，快速定位剩下的30%的代码进行针对性的测试。
精准测试平台便是基于这样的理论开发而成，同时增加了对增量代码的分析，并引入了影响案例推进的功能。
当我们已有老系统进行测试时候，往往全量代码测试用例覆盖率结果会偏低，由于有大量无效功能和冗余代码的存在，且系统历史悠久，每提高1%的代码覆盖可能需要200%的测试投入。对此，对于老系统，我们一般建议更着重观察变更代码覆盖率情况，从现在做起，面向未来。
1、 基于每一次代码的变更，由精准测试平台会给出此次增删改的代码行数和具体情况
2、 当运行测试案例后，精准测试平台给出测试案例运行后，此次变更的代码被测试用例覆盖的情况。
1.3 方法链路&覆盖率监控原理简介
方法链路监控和覆盖率监控需要对系统代码的运行情况进行实时的监控和记录，因此采用了相同的原理对系统进行监控。
方法链路与覆盖率监控便是通过这种方法对运行环境的JVM进行监控，记录各项数据，并统一同步到神兵精准测试平台。
1.4 案例推荐原理简介
由于持续验证平台将测试案例与系统代码进行了关联映射，因此平台还提供了针对变更代码造成的影响案例推荐功能。
通过将请求与方法执行链路以及代码覆盖率的匹配，形成案例与代码的映射表，并通过获取版本间的代码变更差异，进行反推。实现案例推荐的功能。
1.5 应用场景简介
精准测试理论与以往的测试思路有所不同，提供一些结果应用的场景供大家参考。
1、覆盖率监控
平台提供测试过程中环境累积的覆盖率情况，可以帮助测试人员掌握测试活动完成后整体的测试情况，并辅助测试人员就覆盖率较低的部分补充案例，增加关注。
2、 代码差异对比
查看系统整体代码行数，代码各版本间的差异情况，包含增删改代码行数，详细到代码行的结果报告可以避免夹带移交并帮助测试人员快速定位关键测试点。
3、 变更覆盖率分析
通过变更代码的覆盖率以及查看未覆盖的变更代码，帮助测试人员快速找到风险点，确认漏测的变更代码，降低故障风险。
4、 受影响案例推荐
通过方法链路和覆盖率提供的影响案例推荐功能，可以帮助测试人员有效定位回归测试范围，并帮助开发理解和查找变更代码涉及的影响点，减少bug的产生。
在以往的使用中，测试人员通过平台也发现了一些系统隐藏bug。一个典型的案例如下：
测试人员执行案例后，发现相关方法中的分支和代码行没有被覆盖。（标示绿色的为分支覆盖充分，标黄色的为部分分支覆盖，标红色的为未执行该分支）
发现该问题后，测试人员同开发一同确定是案例设计问题还是代码问题。开发反馈覆盖分支的条件后，测试再次进行执行，发现分支依然没有被覆盖到。至此，测试人员可以断定此处存在代码问题，后确定是LIST的取值本身就存在问题。
经过开发修复后，分支实现了覆盖。
总结：
在项目中有段时间使用过代码覆盖率，但没有想到代码覆盖率是精准测试的一部分，之前做代码覆盖率比较粗糙，主要缺少分析，做的不够彻底，当然这个要做好，肯定的花精力，也需兼顾测试时间是否有风险。
参考：http://baijiahao.baidu.com/s?id=1579774970020465666&wfr=spider&for=pc
