51Testing软件测试论坛

标题: 改Bug的乐趣在于源码修改 [打印本页]

---

作者: lsekfe    时间: 2022-9-14 13:46
标题: 改Bug的乐趣在于源码修改
　前言
　　因目前公司内部对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这个配置也无需使用人员去配置。
[attach]142861[/attach]
但是当我填入对应的参数，请求dubbo接口的时候，问题就出现了

1. Failed to check the status of the service xxx.xxx.xxx . No provider available for the service
   

复制代码

一直报错找不到对应的服务，而我用现有的脚本请求是能够成功的，确认了环境没有问题之后，我想可能是Dubbo版本的原因。
　　定位问题：dubbo版本
　　先来看两张图：
[attach]142862[/attach]
[attach]142863[/attach]
我在maven仓库里面搜出来结果可以发现，Dubbo是在2.7.x版本被apache收录，2.6.x的版本 groupId是com.alibaba。
　　于是在项目中找到对应依赖，果然版本对不上，我们系统目前使用的Dubbo是2.5.x，阿里的版本。而这两个版本连接ZK的方式也不同，老版本是通过：

1. <dependency>
   
2.             <groupId>com.101tec</groupId>
   
3.             <artifactId>zkclient</artifactId>
   
4.         </dependency>

复制代码

新版本则是使用：

1. <dependency>
   
2.             <groupId>org.apache.curator</groupId>
   
3.             <artifactId>curator-framework</artifactId>
   
4.         </dependency>

复制代码

确定问题就是版本问，于是便开始了改源码。
　　解决问题：修改jmeter-plugins-for-apache-dubbo插件代码
　　Jmeter支持Dubbo接口需要jmeter-plugins-for-apache-dubbo这个三方插件支持，官方目前使用的是2.7.12不适合我们系统：

1.   <dependency>
   
2.             <groupId>io.metersphere</groupId>
   
3.             <artifactId>jmeter-plugins-dubbo</artifactId>
   
4.             <version>2.7.12</version>
   
5.         </dependency>

复制代码

于是我将其修改为官方提供的1.3.x，发现调用Dubbo接口还是失败，无法找到对应的服务。
　　最后我将1.3.x三方包下载到本地，研究其泛化调用的代码，发现其中很大一部分代码其实是对不同注册中心如：zookeeper、nacos、redis的支持，而公司目前使用的zookeeper，我完全可以将这些不用的代码注释掉，自己封装一套泛化调用的逻辑：

1. @SuppressWarnings({"unchecked", "rawtypes"})
   
2.     private Object callDubbo(SampleResult res) {
   
3. 
   
4.         try {
   
5.             ReferenceConfig<GenericService> reference = new ReferenceConfig<GenericService>();
   
6.             ApplicationConfig applicationConfig = new ApplicationConfig();
   
7.             applicationConfig.setName("remoteInvoke");
   
8.             applicationConfig.setVersion("");
   
9.             RegistryConfig registryConfig = new RegistryConfig();
   
10. 
    
11.             registryConfig.setFile("/tmp/dubbo.cachr");
    
12.             String address = getAddress();
    
13.             registryConfig.setAddress(address);
    
14.             registryConfig.setProtocol("zookeeper");
    
15.             reference.setApplication(applicationConfig);
    
16.             reference.setRegistry(registryConfig);
    
17. 
    
18.             // 弱类型接口名
    
19.             String interfaceName = getInterface();
    
20.             reference.setInterface(interfaceName);
    
21.             reference.setVersion("1.0.0");
    
22.             // 声明为泛化接口
    
23.             reference.setGeneric(true);
    
24.             reference.setProtocol("dubbo");
    
25.             //不重试，重试会造成数据重复执行
    
26.             reference.setRetries(0);
    
27.             reference.setTimeout(10000);
    
28. 
    
29.             String methodName = getMethod();
    
30.             if (StringUtils.isBlank(methodName)) {
    
31.                 res.setSuccessful(false);
    
32.                 return ErrorCode.MISS_METHOD.getMessage();
    
33.             }
    
34. 
    
35.             // 用org.apache.dubboinfo.rpc.service.GenericService可以替代所有接口引用
    
36.             GenericService genericService = reference.get();
    
37.             if (genericService == null) {
    
38.                 res.setSuccessful(false);
    
39.                 return MessageFormat.format(ErrorCode.GENERIC_SERVICE_IS_NULL.getMessage(), interfaceName);
    
40.             }
    
41.             String[] parameterTypes = null;
    
42.             Object[] parameterValues = null;
    
43.             List<MethodArgument> args = getMethodArgs();
    
44.             List<String> paramterTypeList =  new ArrayList<String>();;
    
45.             List<Object> parameterValuesList = new ArrayList<Object>();;
    
46.             for(MethodArgument arg : args) {
    
47.                 ClassUtils.parseParameter(paramterTypeList, parameterValuesList, arg);
    
48.             }
    
49.             parameterTypes = paramterTypeList.toArray(new String[paramterTypeList.size()]);
    
50.             parameterValues = parameterValuesList.toArray(new Object[parameterValuesList.size()]);
    
51.             Object result = null;
    
52.             try {
    
53.                 result = genericService.$invoke(methodName, parameterTypes, parameterValues);
    
54.                 res.setSuccessful(true);
    
55.             } catch (Exception e) {
    
56.                 log.error("RpcException：", e);
    
57.                 //TODO
    
58.                 //当接口返回异常时，sample标识为successful，通过响应内容做断言来判断是否标识sample错误，因为sample的错误会统计到用例的error百分比内。
    
59.                 //比如接口有一些校验性质的异常，不代表这个操作是错误的，这样就可以灵活的判断，不至于正常的校验返回导致测试用例error百分比的不真实
    
60.                 res.setSuccessful(true);
    
61.                 result = e;
    
62.             }
    
63.             return result;
    
64.         } catch (Exception e) {
    
65.             log.error("UnknownException：", e);
    
66.             res.setSuccessful(false);
    
67.             return e;
    
68.         } finally {
    
69.             //TODO 不能在sample结束时destroy
    
70. //            if (registry != null) {
    
71. //                registry.destroyAll();
    
72. //            }
    
73. //            reference.destroy();
    
74.         }
    
75.     }

复制代码

最后，将代码打成jar包，通过maven离线调用：

1. <dependency>
   
2.             <groupId>io.metersphere</groupId>
   
3.             <artifactId>jmeter-plugins-dubbo</artifactId>
   
4.             <version>1.3.8</version>
   
5.             <scope>system</scope>
   
6.             <systemPath>${project.basedir}/lib/jmeter-plugins-dubbo-1.3.8.jar</systemPath>
   
7.         </dependency>

复制代码

终于请求成功：
[attach]142864[/attach]
结语
　　正当我幻想着给MeterSphere提交issure，并提交pr，成为一个热门开源项目的贡献者，从此走上人生巅峰时。我发现MeterSphere项目上的提交记录赫然写着 ：
　　"fix: 修复dubbo客户端v2.7.7以上版本在进行泛化调用server端为v2.6.x以前版本时出现No Provider错误"。
[attach]142865[/attach]
BUG其实已经被解决了...
　　虽然没能成为MeterSphere 的贡献者，但是第一次通过修改源代码来解决BUG，还是很有成就感的。

---

作者: bellas    时间: 2022-11-21 11:33
大神

---

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)

Powered by Discuz! X3.2