AREX 是一款开源的基于真实请求与数据的自动化回归测试平台,利用 Java Agent 字节码注入技术,通过在生产环境录制和存储请求、应答数据,并在测试环境回放请求和注入 Mock 数据,存储新的应答,实现了自动录制、自动回放、自动比对,为接口回归测试提供便利。

AREX Mock 功能十分强大,不仅支持各种主流技术框架的自动数据采集和 Mock,还支持了本地时间、缓存数据以及各种内存数据的采集和 Mock,可以做到在回放时精准还原生产执行时的数据环境,且不会产生脏数据。

这篇文档将从代码实现的角度简单介绍下 AREX 是如何实现在流量回放时自动 Mock 数据的。

示例

让我们先以一个简单的函数为例,理解⼀下其实现原理。假定我们有下面⼀个函数,用于将给定的 IP 字符串转换成整型,代码如下:

public Integer parseIp(String ip) {
    int result = 0;
    if (checkFormat(ip)) { // 检查IP串是否合法
        String[] ipArray = ip.split("\\.");
        for (int i = 0; i < ipArray.length; i++) {
            result = result << 8;
            result += Integer.parseInt(ipArray[i]);
        }
    }
    return result;
}

我们将从两个方面说明如何实现该函数的流量回放功能:

  • ecord(流量采集)

当这个函数被调用时,我们把对应的请求参数和返回结果保存下来,供后面流量回放使用,代码如下:

if (needRecord()) {
    // 数据采集,将参数和执⾏结果保存进DB
    DataService.save("parseIp", ip, result);
}
  • Replay(流量回放)

在进行流量回放时,就可以用之前采集的数据来自动实现这个函数的 Mock,代码如下:

if (needReplay()) {
    return DataService.query("parseIp", ip);
}

通过查看完整的代码,我们可以更好地理解其实现逻辑:

public Integer parseIp(String ip) {
    if (needReplay()) {
        // 回放的场景,使⽤采集的数据做为返回结果,也就是 Mock
        return DataService.query("parseIp", ip);
    }
 
    int result = 0;
    if (checkFormat(ip)) {
        String[] ipArray = ip.split("\\.");
        for (int i = 0; i < ipArray.length; i++) {
            result = result << 8;
            result += Integer.parseInt(ipArray[i]);
        }
    }
 
    if (needRecord()) {
        // 录制的场景,将参数和执⾏结果保存进到数据库
        DataService.save("pareseIp", ip, result);
    }
    return result;
}

AREX 中的具体实现

AREX 实现的原理类似,不过会更复杂⼀些,不需要开发人员手动在业务代码中添加录制和回放的代码。arex-agent 会在应用启动时,在需要的代码块中自动添加相应的代码来实现这个功能。这里以 MyBatis3 的 Query 为例,看看 AREX 中的具体实现。

阅读过 MyBatis 源码的应该都了解,Query 的操作都会收束在 org.apache.ibatis.executor.BaseExecutor 类的 query 方法上(Batch 操作除外),这个方法的签名如下:

public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException

这⾥包含了执行的 SQL 和参数,函数的结果包含了从数据库中查到的数据,显然在这里执行数据采集是合适的,在回放的时候也可以用采集的数据作为结果返回,从而避免实际的数据库操作。看看 AREX 中的代码,为了便于理解,这里做了⼀定的简化,如下:

public class ExecutorInstrumentation extends TypeInstrumentation {
    @Override
    protected ElementMatcher<TypeDescription> typeMatcher() {
        // 需要进行代码注入的类全名
        return named("org.apache.ibatis.executor.BaseExecutor");
    }
 
    @Override
    public List<MethodInstrumentation> methodAdvices() {
        // 需要进行代码注入的方法名,因为query方法存在多个重载,所以带上了参数验证
        return Collections.singletonList(new MethodInstrumentation(
                        named("query").and(isPublic())
                                .and(takesArguments(6))
                                .and(takesArgument(0, named("org.apache.ibatis.mapping.MappedStatement")))
                                .and(takesArgument(1, Object.class))
                                .and(takesArgument(5, named("org.apache.ibatis.mapping.BoundSql"))),
                        QueryAdvice.class.getName())
        );
    }
 
    // 注入的代码
    public static class QueryAdvice {
 
        @Advice.OnMethodEnter(skipOn = Advice.OnNonDefaultValue.class, suppress = Throwable.class)
        public static boolean onMethodEnter(@Advice.Argument(0) MappedStatement var1,
                                            @Advice.Argument(1) Object var2,
                                            @Advice.Argument(5) BoundSql boundSql,
                                            @Advice.Local("mockResult") MockResult mockResult) {
            RepeatedCollectManager.enter(); // 防止嵌套调用导致的数据重复采集
            if (ContextManager.needReplay()) {
                mockResult = InternalExecutor.replay(var1, var2, boundSql, "query");
            }
            return mockResult != null;
        }
 
        @Advice.OnMethodExit(onThrowable = Throwable.class, suppress = Throwable.class)
        public static void onMethodExit(@Advice.Argument(0) MappedStatement var1,
                                  @Advice.Argument(1) Object var2,
                                  @Advice.Argument(5) BoundSql boundSql,
                                  @Advice.Thrown(readOnly = false) Throwable throwable,
                                  @Advice.Return(readOnly = false) List<?> result,
                                  @Advice.Local("mockResult") MockResult mockResult) {
            if (!RepeatedCollectManager.exitAndValidate()) {
                return;
            }
 
            if (mockResult != null) {
                if (mockResult.getThrowable() != null) {
                    throwable = mockResult.getThrowable();
                } else {
                    result = (List<?>) mockResult.getResult();
                }
                return;
            }           
 
            if (ContextManager.needRecord()) {
                InternalExecutor.record(var1, var2, boundSql, result, throwable, "query");
            }
        }
    }
}

其中 QueryAdvice 是需要在 query 方法中注入的代码。通过 onMethodEnter 注入的代码会在方法最开始地位置执行,而 onMethodExit 注入的代码则会在函数返回结果之前执行。

单纯地看这个可能比较难于理解,我们把注入代码后的 BaseExecutor 的 query 方法的代码 dump下来进行分析,如下:

public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
        MockResult mockResult = null;
        boolean skipOk;
        try {
            RepeatedCollectManager.enter();
            if (ContextManager.needReplay()) {
                mockResult = InternalExecutor.replay(ms, parameter, boundSql, "query");
            }
 
            skipOk = mockResult != null;
        } catch (Throwable var28) {
            var28.printStackTrace();
            skipOk = false;
        }
 
        List result;
        Throwable throwable;
        if (skipOk) {
            // 重放的场景,不再执行原来的 query 方法体
            result = null;
        } else {
            try {
                // BaseExecutor query 方法的原代码,此处省略,唯一会被调整的就是原方法里 return 的代码,会被修改为将结果赋值给 result
                result = list;
            } catch (Throwable var27) {
                throwable = var27;
                result = null;
            }
        }
 
        try {
            if (mockResult != null) {
                if (mockResult.getThrowable() != null) {
                    throwable = mockResult.getThrowable();
                } else {
                    result = (List)mockResult.getResult();
                }
            } else if (RepeatedCollectManager.exitAndValidate() && ContextManager.needRecord()) {
                InternalExecutor.record(ms, parameter, boundSql, result, throwable, "query");
            }
        } catch (Throwable var26) {
            var26.printStackTrace();
        }
 
        if (throwable != null) {
            throw throwable;
        } else {
            return result;
        }
    }

可以看到 onMethodEnter 和 onMethodExit 里的代码被插⼊到了开头和结尾,再来理解下这段代码:

  • 录制的场景

AREX 会判断这次访问数据是否需要录制(服务收到请求时,AREX 会根据配置的录制频率决定是否对这个请求进行录制,如果判断为需要录制,则这个请求执行过程中所有的外部依赖都会被录制,具体实现细节这里不做介绍了)。录制过程中,AREX 会调用 InternalExecutor.record(ms, parameter, boundSql, result, throwable, "query") 方法,将本次数据库访问的结果、核心参数等信息存入AREX的数据库中,完成对该数据库访问的录制。

  • 回放的场景

从上面的代码可以看到,当把前面录制的请求再次发送给对应服务时,AREX 会将其视为回放,此时不会再执行原函数的代码了,而是直接返回之前录制下来的结果(包括当时异常的还原),通过调用 InternalExecutor.replay(ms, parameter, boundSql, "query”) 可以获取之前保存的录制数据。

内存数据的 Record\&Replay(动态类)

当然,前面示例的函数是幂等的,对于幂等函数而言,由于每次调用时,其返回结果始终相同,不会受到外部因素的影响,因此在录制和回放过程中并不需要进行数据的采集和 Mock。

相反,对于非幂等的函数,每次调用的结果可能会受到外部环境的影响,并且执行结果会影响服务输出(例如各种本地缓存,不同的环境数据可能不同,从而影响输出结果)。在这种情况下,AREX 也提供配置动态类这种机制来实现这部分数据的 Record 和 Mock 功能,具体可以在 Setting 子菜单的 Record 配置项中配置:

mock原理.png

在这里依次配置类名、方法名(非必需,不配置的话将会应用于所有有参数和返回值的公共方法)、参数类型(非必需)。配置完成后,arex-agent 将会自动在对应的方法中注入类似上面的 Record\&Replay 代码,从而实现数据的采集和回放时的 Mock 功能。


AREX_中文社区
1 声望3 粉丝

AREX 是一个基于真实请求与数据的自动化回归测试平台。通过复制线上真实流量到测试环境进行自动化回归测试,解决回归测试的难题。