作为测试同学，我们经常在工作中会有这样的困惑：我写的用例真的有效且全面吗，我的测试真的做到有效覆盖了吗？回归阶段我到底需要回归什么，回归验证充分吗？这次的改动到底影响范围有多大？针对以上问题，精准测试应运而生，其目的是为了使得测试过程更加可视化、智能化、精准化。本文通过对精准测试的简单介绍，希望可以在以后的项目测试中，多思考，多向精准测试靠近，提升测试效率以及测试准确性。
什么是精准测试
精准测试产生的背景
传统测试的痛点：
- 测试效率低下： 常规的测试类型包括功能测试、回归测试、自动化测试、接口测试等，非常依赖于测试人员的测试经验，基于人工主观分析的黑盒测试，借助常规的用例设计方法来确保产品质量。
- 测试范围无法评估：多分支代码合并到主分支，修改哪个文件哪个行，测试不可控；代码更新影响哪些功能无感知；大部分的测试还是基于对业务的理解，与真实业务数据还有差距，准确性难以保证，盲测，风险大；
- 测试过程中的质量标准无法衡量： 怎么样判定测试完成，怎么样判定测的怎么样？质量控制贯穿于整个质量保障流程。 难道测试用例执行完了，回归测试执行完了，就算测试完成了吗？
- 敏捷模式和分布式微服务架构下的挑战：迭代周期短，需求频繁变更，软件系统越来越复杂
基于上述痛点，我们期望从以下方面解决：
科学地评估代码变更影响到的功能点，需要对这部分代码做准确的针对性的测试；对代码的逻辑进行深刻的理解，哪些分支代码被覆盖到，哪些分支代码没有被覆盖到，进行详细的分析，找出漏测的地方
精准测试的概念
精准测试是一套计算机测试辅助分析系统。精准测试的核心组件包含的软件测试示波器、用例和代码的双向追溯、智能回归测试用例选取、覆盖率分析、缺陷定位、测试用例聚类分析、测试用例自动生成系统，这些功能完整的构成了精准测试技术体系
精准测试的目的
精准测试的核心思想就是使用非常精确和智能的软件来解决传统软件测试过程中存在的问题，从根本上引领从经验型方法向技术型方法的转型。质量的评估不再完全靠个人经验和业务熟悉度，而是通过精准的数据来判定。在测试资源有限的前提下，将用例精简到更加有针对性，提高测试效率，有效的减少漏测风险。
精准测试的核心
精准测试由软件去采集测试过程执行的代码逻辑及测试数据的过程，自动建立测试用例与程序代码之间的逻辑关系。在测试过程加入软件的采集过程，可以形成正向和逆向的追溯：
通过正向追溯，开发人员可以看到测试人员执行用例的代码细节，以方便进行缺陷的修复，测试数据可以直接为开发调试提供依据，快速定位并修复缺陷。
通过逆向追溯，测试人员通过修改的源代码快速确定测试用例的范围，极大减少回归测试的盲目性和工作量，快速修订测试用例，达到测试覆盖率最大化。
精准测试思路
精准测试的核心是一自动化的软件对软件测试过程数据进行记录，从而实现精准测试用例推荐。通过精准测试，我们可以实现软件质量的实时监控，回归用例的智能筛选，测试覆盖率的精准分析以及软件缺陷的快速定位
我们希望的
- 一眼过去就可以看出差异点(本次改动的逻辑)
- 脑海中就有了差异的影响范围(缩小需要测试的范围)
- 再一扫就看出哪些测试覆盖到了(确认测试覆盖率)
差异化分析
查看系统整体代码行数，代码各版本间的差异情况，包含增删改代码行数，详细到代码行的结果报告可以避免夹带移交并帮助测试人员快速定位关键测试点。
智能用例推荐
知识库构建
通过如图所示流程，构建知识库
获取推荐用例
在知识库里包含着测试用例和开发代码的关联关系，代码改动后，推荐改动关联的相应测试用例，争取做到，改哪里测哪里，达到精准测试境界；
执行用例
覆盖率统计
说到覆盖率统计，目前用的比较多的jacoco. 但是 jacoco代码覆盖率统计的是全量代码覆盖率，报告冗余，影响我们对报告的分析和查看，为了更精准衡量测试范围和评估影响面，所以需要对jacoco进行二次改造，使jacoco报告计算增量代码覆盖率 。
执行完推荐用例后，我们可以手动执行一下覆盖率统计，获得增量代码覆盖率报告，报告会对变更的方法进行覆盖率统计，效果如图，包括从包、类、方法、代码各个级别的报告：
报告中：
- 红色背景：这一行没有任何指令被执行；
- 黄色背景：这一行有部分指令被执行；
- 绿色背景：这一行的所有指令都被执行了；
通过对报告的分析，可以很明显的看到哪些没有覆盖，需要补充测试等。
小结：
精准测试是一个完整的质量体系架构，传统的黑盒测试与白盒测试相结合的模式，通过不断的对人的行为的分析得出不足点和漏洞点，引导开发和测试有针对性的改正纠偏，逐步的完善整个质量保障体系。
