作者 | 阿里文娱测试开发专家 正辰
出品 | CSDN（ID：CSDNnews）
对比测试的原理和现状
引流对比测试是目前阿里内部常用的一种回归测试手段，它基于线上真实流量做采集、回放、对比，通过对比结果评估代码变更是否影响了线上链路和功能。通过这种方案，极大地降低了手工构造测试数据的成本：
1）基于用户真实请求，对于复杂业务的接口，降低了模拟用户场景的成本；
2）采集流量足够多的时候，可以对业务场景做全覆盖测试，减少测试遗漏；
3）测试环境稳定，结果明确可靠，并且不需要手工测试执行。目前线上请求采集策略主要是按比例随机采集，从使用情况来看，存在一些问题：
1）从测试的角度，我们并不清楚采集到的流量是否覆盖了核心场景。用测试的话来说：这些流量到底覆盖了哪些用例？无法有效度量；
2）线上持续采集的情况下，回放请求要及时手工维护，排除失效或者重复请求；
3）采集配置多个接口时，由于大流量接口占比很高，导致小流量接口采集不到有效流量， 需要手动调整采集配置。
基于以上这些问题，不难发现，采集请求的有效性和覆盖度是对比测试能持续发挥作用的关键问题。如何破解？优酷在对比测试中引入热度链路覆盖率，实现了一套基于线上热度链路覆盖的精准对比测试方案。
如何有效度量测试覆盖率？
1．代码覆盖率
传统的测试覆盖率统计方法，测试之前先对代码文件进行插桩，生成插过桩的 class 文件或 者 jar 包，测试执行后，会自动收集走到的代码路径，生成覆盖率信息到文件，最后统一对覆盖 率信息进行处理，生成覆盖率报告。度量覆盖率的主要指标有：代码行覆盖、代码分支覆盖、 方法覆盖等等。
1）代码覆盖率的优点：
a）原理和方案比较成熟，有很多现成的工具，实现成本比较低；
b）度量维度比较多，能结合多个指标全面评估代码覆盖率。
2）代码覆盖率的问题：
a）无法有效评估业务场景的覆盖率。代码覆盖率高只能说明代码被执行到了，并不能说明 业务场景被覆盖了，业务场景的覆盖率还需要手工评估；
b）覆盖率分析成本比较高。由于代码质量问题（无效代码或者冗余代码），很多代码不会 被真实的业务场景调用到，这部分代码很难做到测试覆盖，覆盖的价值也不高，并不一定需要 覆盖。
2．子调用链路覆盖率
通过在中间件代码中插桩，统一实现对外部子调用的代码路径采集，从而聚合出代码走过 的子调用链路，然后通过聚合链路请求得出每条子调用链路的热度，从而获得线上真实用户场 景的链路分布情况。子调用链路精准反馈了业务场景的链路和热度，这种基于线上真实请求得
出的覆盖率评估方案，目前在阿里内部被广泛使用。度量覆盖率的主要指标是：子调用链路覆 盖率。
1）相比传统的代码覆盖率：
a）基于线上真实用户请求分析代码执行路径，通过子调用链路代表用户场景，能准确评估业务场景的覆盖情况；
b）统一在中间件代码中插桩，业务代码无需改动，接入成本比较低。基于子调用链路覆盖率评估，是否可以解决对比测试提出的覆盖率评估难题呢？是否也能适合优酷的业务场景？在试运行一段时间后，我们发现优酷一些业务采集到的子调用链路特别少，和业务的体量、复杂度不一致。带着这个疑问，我们看看下面两个请求的代码运行链路：
2）基于以上代码运行链路分析：
a）部分业务外部依赖比较少，主要逻辑在应用内部，导致代码运行的外部子调用完全一样，但内部方法链路不一样；
b）评估业务内部逻辑覆盖的话，内部方法链路覆盖要比子调用链路覆盖更有效。如果能聚合出内部方法链路，对优酷业务场景的覆盖率评估会更有指导意义。于是优酷和集团 JVM-SANDBOX 团队深入合作，提出了一套内部方法链路覆盖率的评估方案：热度链路覆盖率。
基于热度链路推荐的对比测试
通过收集一段时间内的线上真实请求，并记录下请求执行过的方法路径，即为链路。线上不同的真实请求很多都是走的同一个链路，这样不同的链路就有不同的热度，根据链路热度可 以自动评估出需要优先覆盖的链路，即为热度链路。
1．方法链路感知
要采集方法路径，首先需要感知到每个方法的执行。利用 JVM-SANDBOX 底层模块的能 力，能统一在每个内部方法做代码增强，感知到每个方法“运行前”、“返回前”、“异常后”三 个事件，从而收集到代码执行到的方法数据，聚合成方法链路。
1）BEFORE 事件：感知和改变入参；直接返回；
2）RETURN 事件：感知和改变返回值；重新构造返回结果；抛异常；
3）THROWS 事件：重新构造异常；模拟正常返回。
2．采集模块部署
在模块部署环节，最大的挑战是配置需要增强的代码逻辑类。最开始由各个业务方自己配 置，但由于配置范围没有统一标准，导致采集的链路不完成，很难获取比较。根据优酷的业务 特性，我们统一提供了一套代码逻辑类扫描服务，支持优酷各个业务的代码解析和逻辑类扫描， 为每个业务方提供统一的代码增强配置标准。接入过程如下：
1）TraceModule：采集运行链路；2）Repeater：采集请求和返回结果，录制回放；3）MockModule：服务端动态 Mock。
3．链路采集和热度计算
线上模块激活后，就可以根据配置的采样比率，持续采集线上流量，并聚合方法链路。
有了应用链路数据做参考后，通过采集线上请求，并识别出请求的链路，就可以按照热度 链路或者全部链路推荐对比请求，通过扩大请求采集周期（推荐采集周期为 7 天），最后推荐的 请求可以覆盖线上全部业务链路，不仅提升了对比测试的有效覆盖率，而且推荐过程高效且全自动化，全程不需要人工干预，可以快速推广到服务端所有应用的对比测试。
回顾&展望
基于热度链路分析，可以辅助测试更具体地理解真实的业务场景，除了用于推荐对比测试请求，在优酷服务端回归体系中，也用于评估回归测试的覆盖率，相比传统的代码覆盖率评估，业务指导意义更明确。
当然，对于高热度的链路，可能包含了大量的用户请求，也包含了不同的业务含义，如果只覆盖其中一条请求，虽然链路覆盖了，但会造成业务覆盖损失，后期我们可以通过机器学习，智能聚类，让机器来筛选出覆盖更完整、更精确的测试集，深度挖掘线上请求数据的价值，辅助测试建设更有意义的质量保障体系。
閱讀更多 CSDN 的文章
