因目前公司内部对http接口自动化,dubbo接口自动化都是使用脚本来管理,技术栈还分java 和python ,内部对接很不方便,为了降低使用门槛,提升接口测试效率,所以决定在原有的功能用例管理平台添加接口自动化来统一管理。
MeterSphere
首先吹一波MeterSphere,个人觉得目前最好,功能最完善的接口自动化平台,项目还在持续更新,并且有开源版,大家有兴趣可以看一下项目代码
https://github.com/metersphere/
个人对于这个平台Http接口测试的部分理解:
通过前端的入参将其封装成JMeter能识别的 .jmx文件,再通过JMeter的开放API去执行.jmx文件。这里不得不说 该项目成员对JMeter非常熟悉,抛弃了jmeter难用的GUI,实现了一套非常好用UI,MeterSphere牛皮。
移植MeterSphere部分功能
因为只需要接口测试的功能,所以只移接口测试部分。首先要做的就是在本地部署MeterSphere,官方文档只有docker部署教程,没有windows下搭建的教程,而且sql文件还分别放在不同的文件下面,这无疑增加了二次开发 的成本。
最后我在linux下部署项目,然后将sql导出,在application.properties添加数据库配置,注释了原项目中的部分代码,在windows 下成功启动,并且移植了接口测试模块的功能,然后,在测试的时候发现Dubbo接口无法成功调用,于是便有了第一次修改源码的操作……
发现问题:dubbo接口测试报错
MeterSphere这里对Dubbo的配置很多,原本想简化测试,这一套配置填下去,感觉比原有的方式还要麻烦,于是这里我便将配置默认写死,因为公司目前使用zk做注册中心,其他的consumer&Service、Config Service这个配置也无需使用人员去配置。
在这里插入图片描述
但是当我填入对应的参数,请求dubbo接口的时候,问题就出现了
Failed?to?check?the?status?of?the?service?xxx.xxx.xxx?.?No?provider?available?for?the?service
一直报错找不到对应的服务,而我用现有的脚本请求是能够成功的,确认了环境没有问题之后,我想可能是Dubbo版本的原因
定位问题:dubbo版本
先来看两张图
在这里插入图片描述
在这里插入图片描述
我在maven仓库里面搜出来结果可以发现,Dubbo是在2.7.x版本被apache收录,2.6.x的版本 groupId是com.alibaba。
于是在项目中找到对应依赖,果然版本对不上,我们系统目前使用的Dubbo是2.5.x,阿里的版本。而这两个版本连接ZK的方式也不同,老版本是通过
????????
????????????com.101tec
????????????zkclient
????????
新版本则是使用
????????
????????????org.apache.curator
????????????curator-framework
????????
确定问题就是版本问,于是便开始了改源码
解决问题:修改jmeter-plugins-for-apache-dubbo插件代码
Jmeter支持Dubbo接口需要
jmeter-plugins-for-apache-dubbo这个三方插件支持,官方目前使用的是2.7.12不适合我们系统
????????
????????????io.metersphere
????????????jmeter-plugins-dubbo
????????????2.7.12
????????
于是我将其修改为官方提供的1.3.x,发现调用Dubbo接口还是失败,无法找到对应的服务。
最后我将1.3.x三方包下载到本地,研究其泛化调用的代码,发现其中很大一部分代码其实是对不同注册中心如:zookeeper、nacos、redis的支持,而公司目前使用的zookeeper,我完全可以将这些不用的代码注释掉,自己封装一套泛化调用的逻辑,
????@SuppressWarnings({"unchecked",?"rawtypes"})
????private?Object?callDubbo(SampleResult?res)?{
????????try?{
????????????ReferenceConfig?reference?=?new?ReferenceConfig();
????????????ApplicationConfig?applicationConfig?=?new?ApplicationConfig();
????????????applicationConfig.setName("remoteInvoke");
????????????applicationConfig.setVersion("");
????????????RegistryConfig?registryConfig?=?new?RegistryConfig();
????????????registryConfig.setFile("/tmp/dubbo.cachr");
????????????String?address?=?getAddress();
????????????registryConfig.setAddress(address);
????????????registryConfig.setProtocol("zookeeper");
????????????reference.setApplication(applicationConfig);
????????????reference.setRegistry(registryConfig);
????????????//?弱类型接口名
????????????String?interfaceName?=?getInterface();
????????????reference.setInterface(interfaceName);
????????????reference.setVersion("1.0.0");
????????????//?声明为泛化接口
????????????reference.setGeneric(true);
????????????reference.setProtocol("dubbo");
????????????//不重试,重试会造成数据重复执行
????????????reference.setRetries(0);
????????????reference.setTimeout(10000);
????????????String?methodName?=?getMethod();
????????????if?(StringUtils.isBlank(methodName))?{
????????????????res.setSuccessful(false);
????????????????return?ErrorCode.MISS_METHOD.getMessage();
????????????}
????????????//?用org.apache.dubboinfo.rpc.service.GenericService可以替代所有接口引用
????????????GenericService?genericService?=?reference.get();
????????????if?(genericService?==?null)?{
????????????????res.setSuccessful(false);
????????????????return?MessageFormat.format(ErrorCode.GENERIC_SERVICE_IS_NULL.getMessage(),?interfaceName);
????????????}
????????????String[]?parameterTypes?=?null;
????????????Object[]?parameterValues?=?null;
????????????List?args?=?getMethodArgs();
????????????List?paramterTypeList?=??new?ArrayList();;
????????????List
最后,将代码打成jar包,通过maven离线调用
????????
????????????io.metersphere
????????????jmeter-plugins-dubbo
????????????1.3.8
????????????system
????????????${project.basedir}/lib/jmeter-plugins-dubbo-1.3.8.jar
????????
终于请求成功
在这里插入图片描述
结语
正当我幻想着给MeterSphere提交issure,并提交pr,成为一个热门开源项目的贡献者,从此走上人生巅峰时。我发现MeterSphere项目上的提交记录赫然写着 :
"fix: 修复dubbo客户端v2.7.7以上版本在进行泛化调用server端为v2.6.x以前版本时出现No Provider错误"
BUG其实在两个月前被解决了…
虽然没能成为MeterSphere 的贡献者,但是第一次通过修改源代码来解决BUG,还是很有成就感的。
本文暂时没有评论,来添加一个吧(●'◡'●)