作者 | 阿里文娱测试开发专家 正辰
出品 | CSDN(ID:CSDNnews)
对比测试的原理和现状
引流对比测试是目前阿里内部常用的一种回归测试手段,它基于线上真实流量做采集、回放、对比,通过对比结果评估代码变更是否影响了线上链路和功能。通过这种方案,极大地降低了手工构造测试数据的成本:
1)基于用户真实请求,对于复杂业务的接口,降低了模拟用户场景的成本;
2)采集流量足够多的时候,可以对业务场景做全覆盖测试,减少测试遗漏;
3)测试环境稳定,结果明确可靠,并且不需要手工测试执行。目前线上请求采集策略主要是按比例随机采集,从使用情况来看,存在一些问题:
![](/qrcode.jpg)
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 天),最后推荐的 请求可以覆盖线上全部业务链路,不仅提升了对比测试的有效覆盖率,而且推荐过程高效且全自动化,全程不需要人工干预,可以快速推广到服务端所有应用的对比测试。
回顾&展望
基于热度链路分析,可以辅助测试更具体地理解真实的业务场景,除了用于推荐对比测试请求,在优酷服务端回归体系中,也用于评估回归测试的覆盖率,相比传统的代码覆盖率评估,业务指导意义更明确。
当然,对于高热度的链路,可能包含了大量的用户请求,也包含了不同的业务含义,如果只覆盖其中一条请求,虽然链路覆盖了,但会造成业务覆盖损失,后期我们可以通过机器学习,智能聚类,让机器来筛选出覆盖更完整、更精确的测试集,深度挖掘线上请求数据的价值,辅助测试建设更有意义的质量保障体系。
【End】
推荐阅读
☞GitHub 疑遭中间人攻击,无法访问,最大暗网托管商再被黑!
☞为何你的 SaaS 想法总是失败?没想清楚这 4 个原因可能会继续失败!
☞万字好文:智能合约编写之Solidity的编程攻略,建议收藏!
你点的每一个在看,我认真当成了喜欢