分类： IT技术

墨测，全自动化接口测试平台

1. 自动化测试面临的挑战

在软件开发周期中，测试是保障产品质量至关重要的一环，但也是往往容易被忽视的一环，测试的工期置后、重复回归执行等各种因素都影响着测试的效率，影响着高质量的产品发布。

自动化测试被认为是提高测试质量和效率的法宝，通过自动化测试平台，可以实现用例的编写、数据的准备、测试执行、结果验证，将测试工作通过脚本的方式重复执行，但是仅仅如此是不够的，测试还面临着如下的挑战，

  1. 用例的编写：测试在软件开发周期中，由于处于项目排期偏后，经常导致测试只有时间来了解新功能，却没有足够的时间来写自动化用例脚本，工期紧，自动化只能等下一次排期，进而一拖再拖。
  2. 用例的维护：软件产品的功能繁多、变化频繁，用例不是写一次就结束，用例的维护也需要花费测试人员相当多的时间，即使对一个资深软件测试工程师，也难以记住所有需要测试的功能接口，上个月刚测完的功能接口，本月再看，估计又需要大半天来上手的时间。
  3. 问题的定位：在微服务系统中，一不小心就会拆分出上百个应用，每个功能接口涉及的应用多、调用链路长。自动化测试跑完后，需要对失败的用例进行查看，其到底是不是软件bug？是用例的数据问题、或环境应用部署问题？面对失败的用例一个个调查时，查看运行日志，有时候还得需要开发人员的加入，一起来定位问题。自动化测试执行容易，用例失败问题定位困难重重。
  4. 环境的稳定性：测试环境本身就是不稳定的，每天需要测试的产品部署配置频繁，加上团队对测试环境的共享，会造成很多由于测试环境的不稳定导致的无效测试，很多时候等到测试到一半的时候，才发现环境不对。

Java字节码增强技术Bytebuddy探路篇二（NoClassDefFoundError问题）

图片来自pixabay.com的NickRivers会员

最近为了实现Java应用RPC调用的录制和Mock回放，需要以无侵入方式获取到RPC方法的出入参数和返回响应消息等数据，于是踏上了Java字节码增强技术的道路摸索。技术路径上选择了Java Agent + Bytebuddy框架，但是在应用实践过程中，对tomcat/dubbo/rocketmq进行类切面增强时出现了NoClassDefFoundError的问题，本文针对这个关键问题的出现原因进行分析讨论，提供相应的解决思路。

1. 演示代码工程

为了方便讨论，请先下载演示代码工程，整个工程结构如下，

+ phantom-core 演示基础类。
+ phantom-demo 演示web应用，这是一个简单的sprint boot应用，运行在端口18080。
+ phantom-agent 一个Java agent，里面通过ByteBuddy对指定类以无侵入方式切面增强，在演示工程中主要对Tomcat web的请求进行切面处理。
+ phantom-agent-plugin 一个增强类插件，这个是为了解决NoClassDefFoundError问题而提供的一个插件解决方案，应用于phantom-agent的TransformerV3.tranform()中，项目构建后需要复制构建包到路径/tmp/phantom-agent-plugin.jar上。

下载后，分别对项目进行构建、启动和测试，命令如下，

# 使用mvn工具编译构建
mvn clean package

1. 启动演示web应用
java -jar ./phantom-demo/target/phantom-demo.jar

1. 测试web请求命令
curl -X POST http://127.0.0.1:18080/api/hello

若上面的web应用启动成功，则测试web请求将会收到“hello,world”的消息响应，这个简单的测试请求已经走过web服务的完整路径。工程中的Transformer将通过java agent方式对tomcat web请求进行切面处理，获取所有http请求的执行前、执行后、执行异常相关情况并打印到日志中，tomcat切点定义为，

# 切点：tomcat核心类StandardHostValve的invoke方法
org.apache.catalina.core.StandardHostValve.invoke(Request request, Response response);

演示工程中Transformer类有三个，

  1. com.phantom.agent.trace.TransformerV1 ：用于演示问题的复现和定位
  2. com.phantom.agent.trace.TransformerV2 ：用于演示问题的解决思路1
  3. com.phantom.agent.trace.TransformerV3 ：用于演示问题的解决思路2

Java字节码增强技术Bytebuddy探路篇

图片来自pixabay.com的Alexas_Fotos会员

最近为了实现Java应用RPC调用的录制和Mock回放，需要以无侵入方式获取到RPC方法的出入参数和返回响应消息等数据，于是踏上了Java字节码增强技术的道路摸索，这个非常类似Trace所使用的相关技术，不过需要深入到RPC方法级别，对指定方法进行无侵入方式切面处理。先后对ASM/Javaassist/Bytebuddy等技术进行了调研等，本文是对所做摸索探路工作的总结，若读者有类似Trace场景需求，可以进行借鉴参考。

在众多比较之后最后选择的是Bytebuddy技术。

1. Java字节码简介

Java字节码是众多字节码增强技术的知识基础。Java语言写出的源代码首先需要编译成class文件，即字节码文件，然后被JVM加载并运行，每个class文件具有如下固定的数据格式，

ClassFile {
    u4             magic;           // 魔数，固定为0xCAFEBABE
    u2             minor_version;   // 次版本
    u2             major_version;   // 主版本，常见版本：52对应1.8，51对应1.7，其他依次类推
    u2             constant_pool_count;                     // 常量池个数
    cp_info        constant_pool[constant_pool_count-1];    // 常量池定义
    u2             access_flags;    // 访问标志：ACC_PUBLIC, ACC_INTERFACE, ACC_ABSTRACT等
    u2             this_class;      // 类索引
    u2             super_class;     // 父类索引
    u2             interfaces_count;
    u2             interfaces[interfaces_count];
    u2             fields_count;
    field_info     fields[fields_count];
    u2             methods_count;
    method_info    methods[methods_count];
    u2             attributes_count;
    attribute_info attributes[attributes_count];
}

可以看到，class文件总是一个魔数开头，后面跟着版本号，然后就是常量定义、访问标志、类索引、父类索引、接口个数和索引表、字段个数和索引表、方法个数和索引表、属性个数和索引表。

class文件本质上是一个字节码流，每个字节码所处的位置代表着一定的指令和含义。如何对class文件中定义的指令和字节码进行解读、增强定义、编排，这是字节码增强技术所要完成的事情。

了解Java字节码有助于字节码增强的开发，但并不是实现字节码增强开发的必要条件，最新主流的众多字节码增强工具框架类库都将字节码的编排进行了不同程度封装，在可读性、易编排性、排错性上提供开发便利性，学习曲线和开发难度得到了较好的改善。

2. Java字节码增强支持

对于字节码增强的开发来说，JVMTI是一个在实践中应该被熟悉的工具技术。JVM从1.5版本开始提供JVM Tool Interface，这是JVM对外的、用于Java应用监控和调试的一系列工具接口，是JVM平台调试架构的重要组成部分。

下图是JVM平台调试架构图，

The Java™ Platform Debugger Architecture is structured as follows:
           Components                          Debugger Interfaces

                /    |--------------|
               /     |     VM       |
 debuggee ----(      |--------------|  <------- JVM TI - Java VM Tool Interface（Jvm服务端调试接口）
               \     |   back-end   |
                \    |--------------|
                /           |
 comm channel -(            |  <--------------- JDWP - Java Debug Wire Protocol （Java调试通信协议）
                \           |
                     |--------------|
                     | front-end    |
                     |--------------|  <------- JDI - Java Debug Interface （客户端调试接口和调试应用）
                     |      UI      |
                     |--------------|

JVM启动支持加载agent代理，而agent代理本身就是一个JVM TI的客户端，其通过监听事件的方式获取Java应用运行状态，调用JVM TI提供的接口对应用进行控制。

我们可以看下Java agent代理的两个入口函数定义，

// 用于JVM刚启动时调用，其执行时应用类文件还未加载到JVM
public static void premain(String agentArgs, Instrumentation inst);

// 用于JVM启动后，在运行时刻加载
public static void agentmain(String agentArgs, Instrumentation inst);

这两个入口函数定义分别对应于JVM TI专门提供了执行字节码增强（bytecode instrumentation）的两个接口。

  • 加载时刻增强，类字节码文件在JVM加载的时候进行增强，。
  • 动态增强，已经被JVM加载的class字节码文件，当被修改或更新时进行增强，从JDK 1.6开始支持。

这两个接口都是从JDK 1.6开始支持。

我们无需对上面JVM TI提供的两个接口规范了解太多，Java Agent和Java Instrument类包封装好了字节码增强的上述接口通信。我们需要了解的是，上述入口函数传入的第二个参数Instrumentation实例，即Java Instrument类java.lang.instrument.Instrumentation，查看其类定义，可以看到其提供的核心方法只有一个addTransformer，用于添加多个ClassFileTransformer，

// 说明：添加ClassFileTransformer
// 第一个参数：transformer，类转换器
// 第二个参数：canRetransform，经过transformer转换过的类是否允许再次转换
void Instrumentation.addTransformer(ClassFileTransformer transformer, boolean canRetransform)

而ClassFileTransformer则提供了tranform()方法，用于对加载的类进行增强重定义，返回新的类字节码流。需要特别注意的是，若不进行任何增强，当前方法返回null即可，若需要增强转换，则需要先拷贝一份classfileBuffer，在拷贝上进行增强转换，然后返回拷贝。

// 说明：对类字节码进行增强，返回新的类字节码定义
// 第一个参数：loader，类加载器
// 第二个参数：className，内部定义的类全路径
// 第三个参数：classBeingRedefined，待重定义/转换的类
// 第四个参数：protectionDomain，保护域
// 第五个参数：classfileBuffer，待重定义/转换的类字节码（不要直接在这个classfileBuffer对象上修改，需拷贝后进行）
// 注：若不进行任何增强，当前方法返回null即可，若需要增强转换，则需要先拷贝一份classfileBuffer，在拷贝上进行增强转换，然后返回拷贝。
byte[] ClassFileTransformer.transform(ClassLoader loader, String className, Class classBeingRedefined, ProtectionDomain protectionDomain, byte classfileBuffer)

下面简单的演示样例，通过Java agent打印出JVM加载的类列表，

  1. 下载演示代码，见这里。
  2. 编译项目 mvn clean package
  3. 运行命令