接口测试 通用流量录制回放工具 jvm-sandbox-repeater 尝鲜 (四)——新版带界面 console 的使用

陈恒捷 · 2020年12月27日 · 最后由 蓝天伟 回复于 2020年12月30日 · 6854 次阅读
本帖已被设为精华帖!

前言

在去年 repeater 刚出来的时候,就已经简单体验了一下,也有在公司试用。但由于各种原因,最终没有落地。现在刚好有机会再研究一下,看官方记录 console 终于加上了界面,所以也试用并记录下来。

其它文章链接传送门:

通用流量录制回放工具 jvm-sandbox-repeater 尝鲜记录 (0716 跑通基于 console 的录制回放)
通用流量录制回放工具 jvm-sandbox-repeater 尝鲜 (二)——repeater-console 使用 (已完成)
通用流量录制回放工具 jvm-sandbox-repeater 尝鲜 (三)—— repeater plugin 开发 (完成度 50%)

步骤

由于官方源码有做了比较多调整,所以这次记录还是从零开始。

  • 1、安装 repeater

运行官方仓库下的 bin/install-repeater.sh 即可

  • 2、调整 repeater 模式配置,改为用 console

修改 ~/.sandbox-module/cfg/repeater.properties 的值,repeat.standalone.mode 改为 false

  • 3、调整 console 工程中对应配置

repeater-console/repeater-console-start/src/main/resources/application.properties ,调整 mysql 相关配置,改为和自己本地 mysql 数据库一致

同时请初始化数据库内容,初始化的 sql 文件在:repeater-console/repeater-console-dal/src/main/resources/database.sql

初始化成功,应该会创建了 repeater 这个数据库,且包括下面四个表:

  • 4、启动 console 和被测服务

启动被测服务:

4.1、下载示例项目:https://github.com/chenhengjie123/gs-rest-service
4.2、启动示例项目:

# 在示例项目 clone 后的根目录中运行
cd complete 
mvn install && java -jar target/*.jar

启动成功后,应该有类似如下日志:

...
2020-12-28 07:40:45.949  INFO 32158 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context path ''
2020-12-28 07:40:45.952  INFO 32158 --- [           main] hello.Application                        : Started Application in 2.062 seconds (JVM running for 2.448)

4.3、修复官方仓库里 console 一些代码问题。

4.3.1、把 repeater-console/repeater-console-start/src/main/resources/velocity 下面的所有文件,查找 #parse("/blocks ,统一改替换为 #parse("blocks 。原有代码最前面带上 / 会导致引用找不到报错
4.3.2、修改 repeater-console/repeater-console-start/src/main/java/com/alibaba/repeater/console/start/controller/page/ReplayController.java 中的 return "/replay/detail"; ,改为 return "replay/detail"; ,去掉双引号里面第一个 /
4.3.3、修改 repeater-console/repeater-console-start/src/main/java/com/alibaba/repeater/console/start/controller/test/RegressPageController.java 中的 return "/regress/index"; ,改为 return "regress/index";,去掉双引号里面第一个 /

4.4、启动 console:

# 在 repeater 项目根目录进行
mvn install -DskipTests && java -jar repeater-console/repeater-console-start/target/*.jar

启动成功,应该出现类似下面的日志:

...
2020-12-28 07:40:27.259  INFO 32116 --- [           main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8001 (http)
2020-12-28 07:40:27.265  INFO 32116 --- [           main] c.a.repeater.console.start.Application   : Started Application in 7.532 seconds (JVM running for 8.065)
  • 5、使用界面化的 console 进行录制回放

打开此 url 即可打开 console 的界面:http://127.0.0.1:8001/regress/index.htm

现在,借助界面来做一次录制回放吧。基本套路还是一样的:

5.1、在 console 增加配置,用于对接应用(注意这个和之前纯命令行有点不同,命令行是先完成第二步)
5.2、让 repeater 注入到被测应用,上报数据到 console
5.3、在 console 中操作,进行录制和回放

接下来,一步一步操作。

5.1、在 console 增加配置,用于对接应用

点击左侧的【配置管理】,添加如下配置:

应用名:unknown
环境:unknown
配置信息

{
  "useTtl" : true,
  "degrade" : false,
  "exceptionThreshold" : 1000,
  "sampleRate" : 10000,
  "pluginsPath" : null,
  "httpEntrancePatterns" : [ "^/greeting.*$" ],
  "javaEntranceBehaviors" : [ {
    "classPattern" : "hello.GreetingController",
    "methodPatterns" : [ "greeting" ],
    "includeSubClasses" : false
  } ],
  "javaSubInvokeBehaviors" : [],
  "pluginIdentities" : [ "http", "java-entrance", "java-subInvoke", "mybatis", "ibatis" ],
  "repeatIdentities" : [ "java", "http" ]
}

点击【保存】,存下配置

5.2、让 repeater 注入到被测应用

sh ~/sandbox/bin/sandbox.sh -p `ps -ef | grep "target/gs-rest-service-0.1.0.jar" | grep -v grep | awk '{print $2}'` -P 12580

然后进入 console 的【在线模块】,应该能看到增加了当前这个被测应用的心跳记录:

5.3、开始录制。给这个被测应用输送一些流量

# 手动发出2条请求
$ curl -s 'http://localhost:8080/greeting'
{"id":1,"content":"Hello, World!"}%
$ curl -s 'http://localhost:8080/greeting?name=User'
{"id":2,"content":"Hello, User!"}%

然后打开 console 的【在线流量】,能看到刚发出的两条请求已经录制下来了:

5.4、回放请求。直接点击第一行末尾的回放按钮,进行回放:

然后,就可以看到回放结果了。稍等几秒后刷新下回放结果界面,就能看到执行结果

由于被测应用实际上 id 自增逻辑没有依赖任何外部服务,每次请求都会自动 +1 ,所以回放记录是失败的。

总结

官方的文档还是一如既往的少,代码里面也有点坑(对 velocity 不熟悉,上面的代码只是按自己理解改的,如果有更正确的修改姿势欢迎分享),界面和技术栈都用的比较小众和比较久远的的(spring-boot 17 年已经去掉对 velocity 模板引擎的支持了)。 而且一个批量回放功能还是只有按钮实际没做的。。。

不过也算是给到大家一个真正示例控制台该有的样子,把需要的元素和界面设计都基本给出了。如果想要开箱即用,对 http 接口进行简单的录制回放,可以使用这个带界面的 console 来试用一下。

附录:过程中的报错及解决

1、注入 repeater 到被测应用后,console 报错:

2020-12-28 23:37:28.822 ERROR 39333 --- [nio-8001-exec-4] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is java.lang.NullPointerException] with root cause

java.lang.NullPointerException: null
    at com.alibaba.repeater.console.start.controller.api.ConfigFacadeApi.getConfig(ConfigFacadeApi.java:34) ~[classes!/:na]
    at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source) ~[na:na]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_25]

原因:上报心跳包后,appName 和 environment 和配置对不上。
解决:请确认有至少一个配置,appName 和 environment 都是 unknown

2、报错 org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource '/blocks/pager.vm'] with root cause ,且界面打不开

原因:没有按照前面所述修改 console 源码,导致引用其他模板的部分根目录不正确。
解决:按照前面描述,把 #parse("/blocks ,统一改替换为 #parse("blocks 即可。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 16 条回复 时间 点赞

期待大佬分享实际落地的效果,上次 mtsc 大会上酷乐家的分享,他们在 repeater 之外做了很多东西,目前个人感觉流量录制回放还有点蛮干的味道😂

小酷 回复

今年换了公司,暂时新公司还没落地。预计明年再分享吧。

另外,你说的 “蛮干” 是什么意思,可以详细说下不?我也有听酷家乐分享以及他们在社区的实践分享,结合各项降噪工具,看起来已经做得挺不错了呀。

小公司玩不起,写请求的处理始终是个难点。
读请求也要考虑数据一致性的问题,搭建一比一的测试环境成本太高。
我想把流量录制用于线上问题跟踪,现在的日志系统采集率不足,全链路也没做起来,作为临时替代方案感觉还行。

恒温 将本帖设为了精华贴 12月29日 10:27

之前照着楼主和 ELes 大神的几篇帖子,已经把这套给玩起来了,真的是非常感谢两位大神的攻略帖。但是部分场景不知道该怎么处理,比如 某接口中会新起一个线程去异步处理一些事情,这种情况下除了把这个子调用 mock 掉之外,还有更好的处理方法么?主要是被 mock 掉的那部分功能就没法回放到了。

陈恒捷 回复

说下两点感受吧
1、线上流量采样,采样出来的数据分布是什么样的,有没有代表性
2、diff 降噪,降噪过滤掉的数据是不是不重要的,不需要关心
这个对于输入和输出的都没有明确的预期,感觉就是一把梭哈,能跑出来啥是啥

也有想过在公司落地,技术层面还好说,但对这项工程的收益与风险还是存疑

风险

  1. 既然最终要拉线上的数据,多多少少会影响到线上服务的性能,甚至功能,这块怎么能将风险降到最低
  2. 敏感数据如何解决,涉及到用户敏感信息、金钱相关的,很多大公司这块审计的比较严

收益
主要体现在目前回放过程中的上游服务,数据,缓存层层 mock,覆盖面肯定比较有限,那是不是说明通过这种方式回放必然存在局限性,还是有其他解决途径?

今年一月份南琛上传的直播回放里就有 console 相关的界面了,本地跑了一下,加载速度实在太慢就放弃了。

我准备用来回放和录制测试环境,生产没有条件。

小酷 回复

1、线上流量采样,采样出来的数据分布是什么样的,有没有代表性

我理解所有的测试都是为了尽可能模拟真实用户,线上流量的采样用最简单的百分比其实分布就能做到和真实情况比较一致。而且看酷家乐后面的分享文章,为了不至于只有高频接口,还额外做了一些处理,让低频接口也能被采样到

2、diff 降噪,降噪过滤掉的数据是不是不重要的,不需要关心

diff 这种降噪方式,不是要过滤掉不重要的数据,而是要过滤掉回放一定会不一致引起误判的数据。如果业务中确实有存在回放一定不一致,但实际是需要关心的数据(比如 insert 时,直接在代码基于时间戳生成数据的唯一 id ),可以用其它方式去进行自动化,不一定要通过录制回放。

录制回放背后的思想是,线上的结果是对的。所以线上的输入 + 输出就是测试用例的输入 + 输出,回放的时候直接校验新的代码是否和线上的一致。我理解应该不至于是 “对于输入和输出的都没有明确的预期” ?

tlhymm42 回复

既然最终要拉线上的数据,多多少少会影响到线上服务的性能,甚至功能,这块怎么能将风险降到最低

之前官方有分享对线上服务的性能影响,具体数值忘记了,但只要采样率设置得当,影响不会太大。要对线上抱有敬畏感是对的,但只要做好足够的测试以及对原理足够熟悉,风险相对还是可控的。

敏感数据如何解决,涉及到用户敏感信息、金钱相关的,很多大公司这块审计的比较严

我理解可以在录制回放的平台上加脱敏?原始流量脱敏就不能用了,所以存储的流量不能脱敏,那就只能在录制回放平台上做脱敏了。我理解保障普通用户看到的数据都是脱敏后的,就不影响审计。

那是不是说明通过这种方式回放必然存在局限性,还是有其他解决途径

我理解是有局限性的。其实类似于单元测试,我这个小的单元没问题,不能代表集成起来没问题(脑补一下最经典的 2 扇对外打开的窗,刚好安装时成 90 度,变成一个开着的时候另一个无法开。单元测试来说两扇窗都是可以打开的,但集成起来就出问题了)。线上追求的是服务集成起来后没问题,单元没问题只是一个前提条件。
目前了解到大部分录制回放使用的场景都是回归本身项目中预期应该是没有变动的或者不受影响的部分,最能发挥威力的使用场景是客户端不会动的服务端重构或服务整合。至于日常版本里新增接口甚至是多个服务一起联合改动,这个不是录制回放能发挥威力的地方,这个应该用普通的接口测试做集成测试,会比较有效。

陈恒捷 回复

diff 这种降噪方式,不是要过滤掉不重要的数据,而是要过滤掉回放一定会不一致引起误判的数据。

这样的数据可以举个栗子吗?

陈恒捷 回复

1、数据采样问题,假如一个接口提供三个场景的查询,线上采样回来的数据能不能覆盖这几个场景。
2、diff 降噪是要过滤掉不一致的数据,这里面的数据跟哪些场景相关也不太清楚
回放完一轮之后,能得到的数据是去掉环境差异后前后不一致的数据,对于覆盖了什么说不清楚;而且现在只能回放 get 请求,局限性太大,只能作为接口自动化的补充,实施成本也不小

Thirty-Thirty 回复

比如 createTime 、updateTime 这类和时间有关的参数。

小酷 回复

个人理解,录制回放主要好处是能以比较低成本的方式直接验证线上出现最频繁的场景。它不追求全,追求的是有限资源下尽可能保障不出大问题。

所以对于问题 1,如果线上这 3 个场景的查询使用频率都不低,那应该可以覆盖(也可以手动做一些采样方面的调整,尽可能确保 3 个场景只要有触发都有录制)

对于问题 2,不实际针对业务做一次 diff 降噪是不知道的。笼统点讲就是会去掉没有和外部服务关联的那部分数据(如我正文里的示例项目,id 是程序自己生成的,没有依赖任何外部服务),但这部分数据具体和哪些场景有关得看具体系统情况了。

接口测试工具可以试用一下国产的接口测试和接口文档生产工具 apipost:https://www.apipost.cn/?dt=2020

我们目前是在测试环境稳定版下录制,在新版本回放,还是能发现一些 BUG;目前感觉美中不足的还是采样,如何采样到最完整的样本,估计还是要编写录制规则或者通过代码覆盖率来控制;

大胡子 jvm-sandbox-repeater 流量录制回放 中提及了此贴 02月02日 15:04
3楼 已删除
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册