导语
针对58自主研发RPC服务的测试平台，功能主要包含接口测试、接口文档自动生成、服务MOCK以及自动化用例管理等。
简介
API管理平台是集接口管理、文档管理、接口测试、MOCK、接口自动化和接口性能于一体的全新平台，致力于提升接口在接口设计、开发、测试和上线等整个生命周期各个环节的执行效率。 API管理平台整体系统设计在前面文章《API管理平台之系统设计篇》已经做过介绍，本文主要是介绍58自主研发的RPC服务的接口测试相关内容。背景
随着58自主研发的SCF服务(关于SCF内容可以参考往期文章《58RPC框架SCF的设计与实践》)日益成熟，集团各个业务线的服务都在SCF服务上做迁移；由于SCF服务对外的接口是RPC类型，接口测试比较繁琐，开发和测试同学希望可以通过API管理平台简化此类接口的测试环节，提高工作效率。
SCF测试平台方案设计
1、SCF类型接口测试遇到问题
相比于RESTFUL的接口，基于RPC类型的接口不能直接进行测试，需要编码去构建测试CLIENT来获取结果，测试环节比较耗时；
接口文档需要单独编写，编写比较耗时且不能及时更新；
接口多且分散在各自部门的文档里，没有统一管理的平台，不方便接口检索；
没有对应的SCF自动化用例管理平台，不能很好管理自动化用例，影响测试效率。
2、希望达成的效果
- 可以像RESTFUL接口那样进行测试，保存测试记录，接口管理等；
- 文档可以及时更新和查阅；
- 自动化用例可以统一管理和执行。
3、业务架构图
整个系统架构主要由JARInterpreter、CLIENT Builder、DataServices和USER UI等模块构成。
- JARInterpreter: jar包解释器，主要是封装了对jar包的解释和过滤，解释主要包含类、方法、参数和注释等；
- CLIENTBuilder：client构造器，主要用来动态生成SCF Client；
- DataServices：接口、文档、用例和MOCK等功能通过封装成独立服务对外输出数据；
- USERUI 是用户操作界面，采用了前后端分离的方式来实现；
- DB主要是采用了MYSQL和集团自主研发的WTable来进行组合存储。
平台测试界面图
：
遇到的问题和解决办法：
4.1、背景由于平台是通过解释接口定义JAR包来获取到服务对应的方法，在接口定义包中只有接口定义类，而平台构造CLIENT时需要方法对应的实现类，平台默认是通过”接口定义类+Impl”来组成CLIENT请求服务时需要的实现类。
4.2、难点
开发同学没有遵守”接口定义类+Impl”的规范来写实现类，测试服务时会提示找不到对应的方法。
4.3、方案
在调研解决方案时，了解到服务名、实现类、方法名和参数这些内容都会注册到服务管理平台。
拿到平台的类名和服务管理平台提供的类名，通过字符相似度算法来匹配相似度最高的类名作为实现类名来降低错误。
字符相似度通过莱文斯坦距离来进行计算，主要代码如下:
public static int levenshteinDistance(String str, String target) { int s = str.length(); int t = target.length(); if (s == 0) { return t; } if (t == 0) { return s; } int d[][]; // 矩阵 int i; //遍历str的 int j; //遍历target的 char strChar; char targetChar; int temp; // 记录相同字符,在某个矩阵位置值的增量,不是0就是1 d = new int[s + 1][t + 1]; for (i = 0; i <= s; i++) {// 初始化第一列 d[i][0] = i; } for (i = 1; i <= s; i++) { strChar = str.charAt(i - 1); for (j = 1; j <= t; j++) {// 初始化第一行 targetChar = target.charAt(j - 1); if (strChar == targetChar) { temp = 0; } else { temp = 1; } d[i][j] = min(d[i - 1][j] + 1, d[i][j - 1] + 1, d[i - 1][j - 1] + temp); } } return d[s][t];}文档生成
关于文档生成，初始方案是引入Swagger插件，后期经过跟各个业务线讨论，发现该插件侵入较大，可能需要开发同学有额外工作量，较难推动。通过调研后，解决方案是直接解释开发的接口定义代码和注释来生成文档。该方案避免了开发的额外工作量，生成的接口文档丰富程度取决于开发代码注释的多少。 实现方案时，首先想通过代码逐行遍历和正则匹配的方式去解释代码生成文档，执行时发现难度较高，由于不同开发代码风格各异，通过这种方式解释代码的成本比高，后期也难以维护。受到静态代码扫描工具实现方案的启发，针对遇到的问题，可以通过把源代码生成语法树的方式来进行解释并生成接口文档，很好避免受开发不同注释风格的影响，可以很稳定地解释代码中的注释。考虑到AST抽象语法树很自然就想到 JavaParser， 对于JavaParser在这里不做过多的介绍。 文档主要包含三个部分，方法名、输入参数和返回参数，生成文档样例如下图所示。
自动化用例
传统的接口自动化会有以下问题：
- 接口测试和编写自动化用例是分离的，造成工作成本增加影响效率；
- 开发在自动化用例执行和编写环节参与效果不佳；
- 用例的可复用度和可执行度不高。
- 在执行接口测试时记录入参和返回结果，测试的同学可以根据需要把测试结果转化成测试用例，同时也可以在测试时直接转化成测试用例；
- 可以通过构建测试用例集合来选择自己需要的测试用例，一条用例可以复用在不同的业务回归场景且不相互响应；
- 支持手动、定时和代码提交来触发自动化用例的执行。
用例管理界面:
用例集合执行列表：
用例执行详情：
SCFMOCK
在调研SCFMOCK功能时，知道其它事业线已经在做并且会通过open api的方式对外提供mock服务(关于SCFMOCK内容可以参考往期文章 《 SQC服务质量之SCFMOCK 》 )； 考虑到 成本问题，决定在现有的服务基础上封装服务。 创建SCFMOCK的方式有两种。 1、用户只需要关注需要MOCK的方法和方法对应的内容即可，不需要了解实现类或者版本分支之类的信息，有效节省时间成本； 2、根据执行历史记录来执行,这种方式的优点是你可以直接用服务返回的结果来创建MOCK，不需要自己从头到尾构造返回结果。
提供OPENAPI接口
考虑到平时会有其他测试工具需要调SCF服务，而这些工具的实现会采用不同的语言，语言的转换使得调用SCF 服务难度加大；针对这种情况，解决方案是提供HTTP协议的接口供其他方调用，降低开发成本。 使用OPENAPI的人员只需要关注请求的服务、方法和入参，不需要关注网络协议和序列化等内容，很大程度上节省调用成本。平台使用效果
测试接口的时间成本从原来10min+ 缩短到1min以下；
通过批量CASE执行与验证来缩短业务功能回归时间，效率提升1.5倍；
目前CASE的维护量已经达到1800+，涉及小区信息、贴子推广和贴子展示等多个应用场景；
维护接口数量达到8000+，接口每天执行次数1000+ 并且每天以100+的速度在增加，使用范围覆盖集团房产事业群、商业产品技术部、技术工程平台群和商业智能中心等多个事业线。
后期计划
优化现有功能，提升用户体验；
- 增加依据现有接口的基础上组装新的接口，方便用户根据自身实际业务的情况来构建自己想要的接口。
作者简介
朱传波，房产技术部安居客质量保障部资深测试工程师，主要负责经纪人业务测试、测试环境维护和测试效率工具开发等工作。
END
阅读推荐
开源｜Magpie可视化圈选埋点实践 开源｜Magpie：组件库详解 详解站点压测利器——nGrinder 开源｜Magpie：Magpie在安居客有料业务的落地实践 开源｜Magpie：混合开发工程化框架
476
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
