咱们都在应用麻利开发，麻利测试，保护着咱们的我的项目，咱们写着大量的 test case，甚至不写一条 case，麻利宣言其中一条准则是工作的软件“高于”详尽的文档，详解文档包含各种计划书，总结报告，详尽测试用例等，咱们将大量工夫用在自动化测试以及手工探索性测试下面，而咱们的用例则以 BDD 模式存在于代码之中，这样来帮忙尽可能早的发现问题。
但最近我发现几个客户在品质问题，存在一些共性，这些基于黑盒测试的我的项目在测试过程中存在以下几个独特的问题：
- 大量的黑盒测试用例，有的我的项目甚至用例数超过 5w，测试工作大都是手工为主，受主观人为因素影响太大：每次版本公布，QA 全凭集体教训来确定改变对系统影响范畴，通常状况，要么测试范畴定小了，造成漏测，要么测试范畴过大，付出的代价过高，造成我的项目不能如期按时交付。
- 代码与测试没有数据可掂量：没有单元测试，其余类型测试对代码笼罩水平，品质高下，没有数据可能掂量，例如咱们说 api 测试覆盖率是 100%，这个数据大多都是依据用例业务场景估算出的。QA 只能减少更多的黑盒测试，而理论功能测试覆盖率随着工夫和用例增多，便会触达覆盖率的天花板，更多的是反复的有效测试。
- 自动化测试无奈发挥作用：对于 web/api 或 app 后端服务零碎，测试人员对除手工测试外，咱们将大量的工夫与精力投放在 api 接口测试的实现上，随着我的项目的迭代，自动化用例积攒越来越多，从几百到上千，这时候咱们须要思考测试稳定性，运行时长，大量反复测试场景与代码，整个测试 ROI 并不是随着用例数增多而回升，反而保护和排查问题成为 QA 日常工作的重任，疲于应酬，没有精力将工夫投入到更有用的探索性测试和剖析工作中，进而造成 bug 频出，整个团队便对自动化失去信赖，直至废除，这也是很多传统行业无奈规模化施行麻利测试起因之一。
那么如何帮忙团队建立信念，精确定位到变更影响的范畴？精准测试。这个概念是最近几年逐步衰亡的话题。
一、先来谈谈什么是精准测试？
定义：利用技术手段对测试过程产生的数据进行采集存储，计算，汇总，可视化最终帮忙团队晋升软件测试的效率、并对我的项目整体品质进行改良和优化的这一系列操作。
艰深点讲：外围基于源代码变更剖析，联合剖析算法，确定影响范畴，晋升测试效率。
精准测试并没有改变传统的软件测试方法论，只不过是帮忙咱们将测试用例与程序代码之间的逻辑映射关系建设起来，而这个过程则是通过算法和工具去采集测试过程执行的代码逻辑及测试数据，在测试过程退出采集过程，造成正向和逆向的追溯。
- 正向追溯，开发人员能够看到 QA 执行用例的代码细节，例如用例执行过程中，调用具体方法与实现类，不便进行缺点的修复与定位。
- 逆向追溯，测试人员通过 release 前的增量代码疾速确定测试用例的范畴，极大缩小回归测试的盲目性和工作量，晋升 ROI，达到测试覆盖率最大化。
二、精准测试原理
上图是我基于业界通用精准测试架构画出的架构图与流程图。
这套精准测试架构既能够用作手工测试，也可用在任意自动化测试上。
整个架构分为以下几局部：
- 建设用例与代码覆盖率之间的映射关系
- 影响面评估，剖析辨认增量与变更代码
- 测试范畴评估，用例筛选，链路剖析
2.1 建设用例与代码覆盖率之间的映射关系
目前建设用例与代码之间的关系通过统计调用产生的覆盖率与门路进行关联。
1）在线模式
- 功能测试关联计划
目前通用的解决方案是利用 Jacocoon-the-fly 模式基于 On-the-fly 形式毋庸入侵应用服务代码，启动脚本时，只需在 JVM 中通过 -javaagent 参数指定 jar 文件以启动 Instrumentation 的代理程序，该代理程序通过 Class Loader 装载一个 class 前判断是否须要注入 class 文件，再将统计代码插入 class，测试覆盖率剖析就能够在 JVM 执行测试的过程中实现。Jacoco 提供了本人的 Agent，实现插桩的同时，还提供了丰盛的 dump 输入机制，如 File,Tcp Server,Tcp Client。覆盖率信息能够通过文件或是 Tcp 的模式输入。通过内部服务在任意机器上通过 api 申请获取被测程序的覆盖率与执行门路。
对性能测试用例，咱们能够通过执行单个用例，通过上述步骤后拿到该条用例影响代码的覆盖率与执行门路。在通过关联服务，将具体用例的 ID 与生成的覆盖率信息（类，办法，行等）建设映射关系，最初将关联数据存到数据库中保留。
基于 Jacocoon-the-fly 模式获取单个用例覆盖率建设映射关系的流程如下：
以上是基于 java 语言来关联用例与代码间接的关系，前端也有相似原理的工具，利用 istanbul-middleware 也能够实现同样的性能，具体请查阅一下这两篇文章，这里不再复述。
- 自动化测试关联计划
利用 AOP 原理，在自动化框架的执行器加一个拦截器，在覆盖率收集开关关上时，申请执行前，这个过程相似于测试框架中的 before hook：reset 被测服务桩数据，也就是上一次测试产生的 dump 文件，申请执行后，这个过程相似于测试框架中的 after hook：用 api 导出内存中的覆盖率数据，咱们利用反射拿到用例办法名，利用关联服务将之与对应的 dump 后果关联起来，实现主动插桩性能，疾速帮忙咱们建设自动化用例与覆盖率之间的关系。
2）Offline 模式（unit test 采纳模式，不是本文）
在测试前先对文件进行插桩，而后生成插过桩的 class 或 jar 包，测试插过桩 的 class 和 jar 包后，会生成动静笼罩信息到文件，最初对立对笼罩信息进行解决，并生成报告。
Offline 模式实用于以下场景：
- 运行环境不反对 java agent
- 部署环境不容许设置 JVM 参数
- 字节码须要被转换成其余虚拟机字节码，如 Android Dalvik VM
- 动静批改字节码过程中和其余 agent 抵触
- 无奈自定义用户加载类
2.2 影响面评估，剖析辨认增量与变更代码
咱们有了代码与用例间接的关系的映射，咱们须要将之用在开发流程中，首先咱们须要得悉咱们的改变是什么，最间接的是通过 git diff 得悉具体改变代码，但过于沉重，且太多烦扰例如正文，空行等，最好的办法是实现比对算法，通过降噪解决，打消烦扰，进而拿到解决后变更数据。
2.3 测试范畴评估，用例筛选，链路剖析
咱们有了用例与代码之间的关系映射，有了提交增量代码差别记录，就能够实现逆向回溯。
利用代码的差别，通过查问服务就能够在下面提到关联关系数据库中反推影响的用例，以及下层的业务。这样能够帮忙 QA 疾速划分测试范畴，缩小适度测试。
三、总结精准测试的长处
这种代码与用例，业务之间的关联关系，可能加深咱们对被测系统及架构的理解，在一直的版本迭代过程中，可能实时理解任何类型测试对于以后版本的覆盖率，是否有脱漏的场景等，帮忙团队更好的建设信念，使品质真正走上可继续化路线。
精准测试在我的项目的中后期不在不依赖集体能力以及业务相熟度等特点，大幅升高了团队测试的老本，使得团队 QA 可能有大量的工夫做探索性测试以及品质度量上，进步 QA 对于团队的 ROI，带给团队更清晰的品质数据。
但事物总是存在对立面的，取得微小的收益同时，必然相应的存在毛病。否则也该当像 UI 自动化测试一样风行于各个公司以及团队中。
四、精准测试存在的问题
- 基于手工测试的精准测试建设映射关系繁冗，如果需要扭转频繁，用例保护以及之间的关系保护须要消耗大量工夫精力。
- 精准测试须要肯定的自动化测试的笼罩，这样做起来更有意义，例如 api 自动化测试，如果自身用例过少，与代码之间关联关系不多时，变更代码后可能不会得出什么后果。
- 最好有对应的用例管理系统，可能不便的帮忙咱们建设与代码之间的关系。
- 须要投入开发能力强的 QA 或者测试开发建设整套零碎环境，但久远思考，将精准测试嵌入整个公司的品质平台中，不论对于新我的项目还说保护我的项目来说都是一种晋升。
- 我的项目生命周期须要较长，短期我的项目破费微小精力开发和保护整套精准测试零碎得失相当。短期我的项目能够利用精准测试以 api 测试覆盖率作为衡量标准。不去建设繁冗的关系，只监控 UI API 测试覆盖率迭代时的变更来达到目标。
精准测试不是银弹，须要微小的投入，用的好，可能成倍的晋升品质，生产效率，用不好的话，就成了领导的 KPI 我的项目，弃之可惜，食之无味，鸡肋也。
起源：Thoughtworks 洞见
作者：齐磊 前 Thoughtworks 高级品质分析师，现任 HSBC 测试征询专家，善于麻利测试，测试开发，DevOps 等畛域。
申明：文章取得作者受权在 IDCF 社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。
IDCF 社区共创读书会 首期汇报，每周四晚 8 点， 冬哥有话说 收费直播，关注公众号回复“共读”获取直播地址
- 8 月 19 日，共读《思考，快与慢》
- 8 月 26 日，共读《DevOps 实际指南》
- 9 月 2 日，共读《麻利无敌之 DevOps 时代》