Press "Enter" to skip to content

阿里文娱测试实战:机器学习+基于热度链路推荐的引流,让对比测试更精准

本站内容均来自兴趣收集,如不慎侵害的您的相关权益,请留言告知,我们将尽快删除.谢谢.

作者 | 阿里文娱测试开发专家 正辰

 

 

一、对比测试的原理和现状

 

引流对比测试是目前阿里内部常用的一种回归测试手段,它基于线上真实流量做采集、回放、对比,通过对比结果评估代码变更是否影响了线上链路和功能。通过这种方案,极大地降低了手工构造测试数据的成本:

 

 

1)基于用户真实请求,对于复杂业务的接口,降低了模拟用户场景的成本;

 

2)采集流量足够多的时候,可以对业务场景做全覆盖测试,减少测试遗漏;

 

3)测试环境稳定,结果明确可靠,并且不需要手工测试执行。

 

目前线上请求采 集策略主要是按比例随机采集,从使用情况来看,存在一些问题:

 

1)从测试的角度,我们并不清楚采集到的流量是否覆盖了核心场景。用测试的话来说:这 些流量到底覆盖了哪些用例?无法有效度量;

 

2)线上持续采集的情况下,回放请求要及时手工维护,排除失效或者重复请求;

 

3)采集配置多个接口时,由于大流量接口占比很高,导致小流量接口采集不到有效流量, 需要手动调整采集配置。

 

基于以上这些问题,不难发现,采集请求的有效性和覆盖度是对比测试能持续发挥作用的关键问题。如何破解?优酷在对比测试中引入热度链路覆盖率,实现了一套基于线上热度链路覆盖的精准对比测试方案。

 

二、如何有效度量测试覆盖率?

 

 

1.代码覆盖率

 

传统的测试覆盖率统计方法,测试之前先对代码文件进行插桩,生成插过桩的 class 文件或 者 jar 包,测试执行后,会自动收集走到的代码路径,生成覆盖率信息到文件,最后统一对覆盖 率信息进行处理,生成覆盖率报告。度量覆盖率的主要指标有:代码行覆盖、代码分支覆盖、 方法覆盖等等。

 

1)代码覆盖率的优点:

 

原理和方案比较成熟,有很多现成的工具,实现成本比较低;

 

度量维度比较多,能结合多个指标全面评估代码覆盖率。

 

2)代码覆盖率的问题:

 

无法有效评估业务场景的覆盖率。代码覆盖率高只能说明代码被执行到了,并不能说明 业务场景被覆盖了,业务场景的覆盖率还需要手工评估;

 

覆盖率分析成本比较高。由于代码质量问题(无效代码或者冗余代码),很多代码不会 被真实的业务场景调用到,这部分代码很难做到测试覆盖,覆盖的价值也不高,并不一定需要 覆盖。

 

 

2.子调用链路覆盖率

 

通过在中间件代码中插桩,统一实现对外部子调用的代码路径采集,从而聚合出代码走过 的子调用链路,然后通过聚合链路请求得出每条子调用链路的热度,从而获得线上真实用户场 景的链路分布情况。子调用链路精准反馈了业务场景的链路和热度,这种基于线上真实请求得

 

出的覆盖率评估方案,目前在阿里内部被广泛使用。度量覆盖率的主要指标是:子调用链路覆 盖率。

 

1)相比传统的代码覆盖率:

 

基于线上真实用户请求分析代码执行路径,通过子调用链路代表用户场景,能准确评估 业务场景的覆盖情况;

 

统一在中间件代码中插桩,业务代码无需改动,接入成本比较低。基于子调用链路覆盖率评估,是否可以解决对比测试提出的覆盖率评估难题呢?是否也能 适 合优酷的业务场景? 在试运行一段时间后,我们发现优酷一些业务采集到的子调用链路特别 少,和业务的体量、复杂度不一致。

 

带着这个疑问,我们看看下面两个请求的代码运行链路:

 

 

2)基于以上代码运行链路分析:

 

部分业务外部依赖比较少,主要逻辑在应用内部,导致代码运行的外部子调用完全一样, 但 内部方法链路不一样;

 

评估业务内部逻辑覆盖的话,内部方法链路覆盖要比子调用链路覆盖更有效。如果能聚合出内部方法链路,对优酷业务场景的覆盖率评估会更有指导意义。于是优酷和 集团  JVM-SANDBOX  团队深入合作,提出了一套内部方法链路覆盖率的评估方案: 热度链路 覆盖率。

 

 

三、基于热度链路推荐的对比测试

 

通过收集一段时间内的线上真实请求,并记录下请求执行过的方法路径,即为链路。线上不同的真实请求很多都是走的同一个链路,这样不同的链路就有不同的热度,根据链路热度可 以自动评估出需要优先覆盖的链路,即为热度链路。

 

 

1.方法链路感知

 

要采集方法路径,首先需要感知到每个方法的执行。利用 JVM-SANDBOX 底层模块的能力,能统一在每个内部方法做代码增强,感知到每个方法“运行前”、“返回前”、“异常后”三 个事件,从而收集到代码执行到的方法数据,聚合成方法链路。

 

 

1)BEFORE 事件:感知和改变入参;直接返回;

 

2)RETURN 事件:感知和改变返回值;重新构造返回结果;抛异常;

 

3)THROWS 事件:重新构造异常;模拟正常返回。

 

 

2.采集模块部署

 

在模块部署环节,最大的挑战是配置需要增强的代码逻辑类。最开始由各个业务方自己配 置,但由于配置范围没有统一标准,导致采集的链路不完成,很难获取比较。根据优酷的业务 特性,我们统一提供了一套代码逻辑类扫描服务,支持优酷各个业务的代码解析和逻辑类扫描, 为每个业务方提供统一的代码增强配置标准。接入过程如下:

 

 

1)TraceModule:采集运行链路;2)Repeater:采集请求和返回结果,录制回放;3)MockModule:服务端动态 Mock。

 

 

3.链路采集和热度计算

 

线上模块激活后,就可以根据配置的采样比率,持续采集线上流量,并聚合方法链路。

 

 

有了应用链路数据做参考后,通过采集线上请求,并识别出请求的链路,就可以按照热度 链路或者全部链路推荐对比请求,通过扩大请求采集周期(推荐采集周期为 7 天),最后推荐的 请求可以覆盖线上全部业务链路,不仅提升了对比测试的有效覆盖率,而且推荐过程高效且全自动化,全程不需要人工干预,可以快速推广到服务端所有应用的对比测试。

 

 

四、回顾&展望

 

基于热度链路分析,可以辅助测试更具体地理解真实的业务场景,除了用于推荐对比测试请求,在优酷服务端回归体系中,也用于评估回归测试的覆盖率,相比传统的代码覆盖率评估,业务指导意义更明确。

 

当然,对于高热度的链路,可能包含了大量的用户请求,也包含了不同的业务含义,如果只覆盖其中一条请求,虽然链路覆盖了,但会造成业务覆盖损失,后期我们可以通过机器学习,智能聚类,让机器来筛选出覆盖更完整、更精确的测试集,深度挖掘线上请求数据的价值,辅助测试建设更有意义的质量保障体系。

 

Be First to Comment

发表评论

您的电子邮箱地址不会被公开。