51Testing软件测试论坛

标题: RPC服务接口测试自动化初探 [打印本页]

作者: lsekfe    时间: 2021-4-7 09:59
标题: 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框架的基础上做了一些对应的调整,整体示意图如下:
  简要示意图

  测试页面

  流程解析
  1、当一个分支的代码在Beetle编译成功后,Beetle会发编译成功的MQ,接口测试服务在收到MQ消息后,会触发代码下载、扫描、编译contract、保存接口信息入库等操作;
  2、测试人员在接口测试页面选择自己想要测试的接口,检查接口的详细信息是否符合期望,修改入参模板为自己想要的入参;
  3、点击执行,前端会把接口信息、入参、环境IP等传给后端服务;
  4、后端服务需要执行3个操作;
  生成唯一ID uniqID,连同前端传递过来的信息一起入库,表中主键为uniqID,返回uniqID给前端,根据传递过来的信息,修改模板文件,然后编译执行,修改表中执行结果。
  5、前端根据uiqID轮询等待执行结果。
  调用对应机器上的RPC服务的功能。
  难点攻克
  JSON String转Java Bean、代码扫描等关键点在之前的文章中已经详细叙述过,本次简要概括。
  接口入参的获取,分两种场景:
  1、已经上线的接口;
  线上有大量的可用日志,可以借助公司的大数据平台,进行数据的采集和清洗,还可以通过logid等关键字获取到出参,这样还可以做到校验接口测试时,返回的结果是否和线上的格式一致。
  2、新接口/接口入参发生变更。
  目前转转的环境平台分为测试环境、沙箱环境、线上环境,当一个分支的代码想要上线时,Beetle会校验该分支的部署记录,只有测试、沙箱都存在成功部署记录时,才可以上线,结合代码覆盖率功能的存在,可以做到当一个分支提测时,RD一定测试过新增/变更的接口,这样新接口/变更接口的入参也可以获取到。
  JSON String转为Java对象:
  JSON格式的字符串也应该可以逆向转为对应的JavaBean;
  测试代码的生成:
  借鉴Velocity的思想,提前准备一个模版文件,替换预留的占位符。
  后续扩展

  目前的人工参与的操作还有很多,为了会朝着简化操作,快速执行的方向努力。





欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2