本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。
RPC 接口
我所在的部门是技术中台，主要负责 toB 业务，上游是业务条线，包括 PC、APP、小程序等终端，这些端的后台是 HTTP 接口层，而在 HTTP 接口层之下，就是技术中台的 RPC 接口层。
HTTP 是一种超文本传输协议，基于 TCP/IP 来传输文本、图片、音频、视频等数据。数据包的传输能力不是 HTTP 提供的，而是 TCP/IP 干的。HTTP 的本质是客户端和服务端约定好的一种通信格式，是一种全世界认可的通用范本。
RPC 是一种远程调用，也就是进程间通信，既可以用 HTTP 协议，也可以用自定义协议。RPC 的好处是没有 HTTP 那么多约束，简化了写法，可以根据公司自定义规范，内部统一即可。 所以在公司内部特别流行，比如阿里的 Dubbo 接口就是一种 RPC 接口，我们公司用的 JSF 接口，自研的服务框架，简称杰夫。
举个例子，本地调用，是调用的本地方法：
public User getUserById(Long id) {
return userDao.getUserById(id); // 这叫本地调用
}
而 RPC 远程调用，调用的是另外一个服务的方法：
public User getUserById(Long id) {
return userConsumer.getUserById(id); // 这是远程调用，逻辑是用户小组的服务实现的。
}
本地调用和远程调用的比较如下图所示：
左边的本地调用，只在应用内部调用。右边的远程调用，会跨应用在应用之间调用。
RPC 和 HTTP 用法区别
HTTP 接口在调用时，输入 URL，Method，Headers，Body 等等等就可以发送请求了。
RPC 接口的调用大同小异，输入：
JSF 地址：方法引用路径，比如com.dongfanger.api.service.ShopProvider。
方法名：方法名称，比如queryShopList。
别名：既可以是分组别名，也可以直连 IP 地址。
方法入参：JSON 串。
等等等，就可以发起请求了。
从用法能看出来，RPC 和 HTTP 接口的结构体是差不多的，但是 RPC 不需要 Method 和 Headers，精简了许多。
接口自动化
首先需要考虑的是目录结构设计，HTTP 可以模块菜单创建用例目录，比如：
一级目录：管理端
二级目录：发票管理
三级目录：发票查询
而 RPC 是无页面的，一般存在很多业务线，所以可以按照功能域和业务线来组织目录，比如：
一级目录：发票
二级目录：提交申请
三级目录：分销
其次就得考虑技术实现了，公司基建比较完善，无论是 HTTP 还是 JSF 接口，都能在接口测试平台上编写自动化用例。虽然是 Web 平台写用例，但是得益于测试平台的优秀设计和使用体验，用起来很方便，效率也很高。交互方式跟 JMeter 大同小异，只是在细节上做了很多打磨。
然后就是参数构造了，建议是用流量回放的方式来做，省去手工编写参数的崩溃感。流量用例创建好以后，需要做一些参数化处理和接口关联。这样才能够把多个接口串起来。
对于测试数据，通过预设变量来统一管理，自动化用例也尽可能设计成闭环，增加，修改，查询，删除，用例跑完后产生的数据也跟着清理掉。
最后就是断言了。没有断言的自动化用例，不叫做自动化用例。断言一定要加上，否则定时任务跑出结果后，无法判断到底有没有问题。而断言内容不能只是简单的 code200，需要加上业务校验。
中台 RPC 接口自动化最难处理的是接口依赖问题，链路特别长，依赖特别多。我一般通过 Mock 来解决这个问题，公司的测试平台也提供了这个功能。
需要注意的是，核心用例定时运行监控起来，而一次性用例要及时维护或清理，防止变成僵尸用例。
最后，我准备基于 Vue+FastAPI 开发一套新的 pytest 脚本管理平台，集成流量录制创建用例和 Mock 等功能，并借鉴公司测试平台的设计，感兴趣的同学可以添加微信cekaigang加群讨论哟。
参考资料：
HTTP 的本质？HTTP 和 RPC 的区别？ https://www.jianshu.com/p/fe5ccfc5d7bd