有赞精准测试实践
共 3185字,需浏览 7分钟
·
2020-11-16 21:46
一、背景介绍
对于分布式系统中的绝大部分应用,随着业务发展,自身应用代码复杂度会不断增加,如何准确、全面判定代码修改影响范围会越来越重要;
一些领域设计不太合理的业务架构,会发现任一应用接口变动会使多个应用受影响。测试过程中会发现只是自身应用代码一个修改,会导致对外暴露的接口逻辑发生很大变动,此时测试人员需要判定出这个对外暴露的接口对上层应用到底有多大影响;
业务快速迭代导致测试时间不断压缩,全量回归是一个很困难的事情,那么测试范围需要开发测试人员根据代码和业务熟悉程度精确把控,风险容易失控;
基于上述背景,我们研发了精准测试工具,作为应用上线质量的参考维度之一,集成到测试工具平台上供技术部门所有同事使用。
二、整体方案设计
识别变更的代码:上线代码和master代码采用抽象语法树分析,去除噪音后,比对方法体即可获取到新增/修改/删除的方法;
分析影响的自身应用对外暴露的接口,采用动静结合。静态分析采用字节码分析,同时补充了桥接来解决部分多态问题;动态分析采用了和主流调用链技术一致的javaagent来对代码进行织入,为了防止大量织入导致性能变差,只在qa环境进行织入;
对于应用间链路查询,由于有赞内部很早就有一个调用链系统,可以实时查看应用接口之间调用详情,借助这个系统,使用大数据spark或者MR进行离线任务,汇总处理所有的链路信息即可获取应用间所有链路信息,上层业务方影响范围只要查询链路即可获得。
PS:对于没有现成调用链的公司可以参考成熟的开源工具skywalking,github地址如下:https://github.com/apache/skywalking
三、重点模块
3.1 代码比对
3.2 静态分析逻辑
对于字节码分析,有很多字节码操作工具,ASM/bcel/Javassist都可以,使用方法都类似,随便选择一个就行;
对于invokedynamic指令,单纯按照字节码指令指向的是一个引导方法(Bootstrap Method),需要判定真正执行的方法,进而获取真正的调用链;
为了加快速度,减少后期处理,需要剔除掉不感兴趣的父子节点,比如调用三方包/jdk的API/get方法/set方法;
调用接口指令是invokeinterface方法,但实际上真正执行的是接口的实现类代码,如果接口只有一个实现类,那么我们就可以判定执行的就是这个实现类,从而可以进行桥接;
匿名内部类编译过程中会生成一个类似A$1的class文件,根据字节码文件中的EnclosingMethod字段可以判定上层调用方的类名和方法名,从而可以完成方法和匿名内部类方法的桥接;
动态分析&动静结合
性能问题:大量织入会导致性能损耗,首先判定当前环境,是否是qa环境,qa环境再织入,不要对线上有影响;
织入范围:只对com.youzan的包进行织入且排除掉二方包(二方包包名一般也为com.youzan.*),排除掉所有的get/set方法,排除掉private方法(子类重写不了父类私有方法),排除掉这些会大大加快代码织入速度,且对分析无影响;
对于每次请求到结束返回,整个调用过程可以看作是不断入栈出栈的过程,调用一个方法是入栈,方法结束为出栈,当栈为空,即表示请求结束,出入栈的顺序反映了代码的调用逻辑,从而形成内部调用链;
根据动态分析和静态分析,分别获取了一系列内部调用链,把这些内部调用链的节点打散后重新组合得到包含动态和静态数据的内部调用链;
根据新增/修改的方法名称和方法入参类型,匹配出包含此方法的内部调用链,内部调用链根节点就是改动点影响的对外暴露接口;
3.3 应用间影响分析
3.4 效果
3.5 不足
对于新增代码的影响面大部分都是依靠字节码分析,而字节码分析在多态和AOP方面存在天然短板,影响面会有所丢失
应用内链路跟踪存在大规模代码织入,对性能和内存资源会造成一定损耗,对于代码量很大的工程,损耗尤其严重;
对于大规模代码重构或者底层公用方法的变动,影响面分析会覆盖很多接口,此时依然需要人工评估是否可以缩小测试范围;
目前应用内代码分析只支持java语言,缺少其他语言的范围评估。
- - 时人莫小池中水, 浅处不妨有卧龙 - -
作者:
Kevin Cai, 江湖人称蔡老师。
两性情感专家,非著名测试开发。
技术路线的坚定支持者,始终相信Nobody can be somebody。
· 猜你喜欢的文章 ·