RPC服务接口测试自动化初探
作者|申言方
引言
目前测试行业提起接口自动化测试，一般都默认是HTTP/HTTPS接口自动化测试，我想主要原因有两点：
1、HTTP/HTTPS请求比后端服务更贴近实际用户；
2、Java、Python都有丰富的第三方扩展，可以方便快速的搭建一套HTTP/HTTPS测试框架，并且还可以拓展到功能回归、线上监控等场景。
近些年微服务的兴起让更多的人了解到RPC框架，当然不同的RPC框架，在设计、实现和使用上存在巨大差异，这也让RPC服务在接口测试方面具有一定的难度，针对每一个RPC接口都编写对应的测试代码是最直接的方式，在实际实施过程中会有两个主要问题：
1、测试代码需要花费大量时间开发，容易拉长项目节奏；
2、测试代码需要大量人力来维护。
在本篇文章中，我们交流一下在RPC服务接口测试的自动化方向上的一些尝试。
整体流程
在实现RPC diff框架过程中，就在思考能不能把这些能力也应用到RPC 接口测试上，这样就不需要对每一个RPC 接口编写测试代码，当RPC 接口发生变更时，也不需要同步修改测试代码，即解放了人力，又提高了效率。早些时间公众号上有一篇《RPC服务测试新思路》，本篇是在使用场景上做了一些扩展，有兴趣的同学也可以阅读一下前篇的内容。RPC接口测试在RPC Diff框架的基础上做了一些对应的调整，整体示意图如下：
简要示意图
测试页面
Beetle：公众号文章《Beetle双活实践》
流程解析
1、当一个分支的代码在Beetle编译成功后，Beetle会发编译成功的MQ，接口测试服务在收到MQ消息后，会触发代码下载、扫描、编译contract、保存接口信息入库等操作；
2、测试人员在接口测试页面选择自己想要测试的接口，检查接口的详细信息是否符合期望，修改入参模板为自己想要的入参；
3、点击执行，前端会把接口信息、入参、环境IP等传给后端服务；
4、后端服务需要执行3个操作
生成唯一ID uniqID，连同前端传递过来的信息一起入库，表中主键为uniqID
返回uniqID给前端
根据传递过来的信息，修改模板文件，然后编译执行，修改表中执行结果
5、前端根据uiqID轮询等待执行结果。
调用对应机器上的RPC服务的功能，见公众号《测试环境rpcclient动态调用RPC服务实践》
难点攻克
JSON String转Java Bean、代码扫描等关键点在之前的文章中已经详细叙述过，本次简要概括。
接口入参的获取，分两种场景：
1、已经上线的接口
线上有大量的可用日志，可以借助公司的大数据平台，进行数据的采集和清洗，还可以通过logid等关键字获取到出参，这样还可以做到校验接口测试时，返回的结果是否和线上的格式一致。
2、新接口/接口入参发生变更
目前转转的环境平台分为测试环境、沙箱环境、线上环境，当一个分支的代码想要上线时，Beetle会校验该分支的部署记录，只有测试、沙箱都存在成功部署记录时，才可以上线，结合代码覆盖率功能的存在，可以做到当一个分支提测时，RD一定测试过新增/变更的接口，这样新接口/变更接口的入参也可以获取到。
JSON String转为Java对象：
JSON格式的字符串也应该可以逆向转为对应的JavaBean；
测试代码的生成：
借鉴Velocity的思想，提前准备一个模版文件，替换预留的占位符。
后续扩展
目前的人工参与的操作还有很多，为了会朝着简化操作，快速执行的方向努力。