开篇碎碎念：
18年的时候写过一篇《互联网服务端测试是个啥（入门科普）》（指路/wangyueshu/article/details/81944250），主要面向的是那些没有接触过服务端测试，尤其是已有端上测试经验、而面对服务端测试时急需转换测试思维的那部分读者。
3年过去了，转一圈再回来做服务端测试时，内容也有了扩展。原篇的接口更多的是指代HTTP接口，服务也更多的指代数据服务。而随着算法模型应用的逐渐深入，服务扩展到了模型、策略服务，RPC接口也变得更为普遍，成了服务端测试的对象之一。
正文将包含三部分，基础概念、服务输出（开发视角）和服务测试（测试视角）三个部分。
一、基础概念：
在正式介绍RPC接口测试之前，先明确几个基本概念，服务、语言、协议。
服务，即为达到一定的产品或技术目标而实现的一套软硬件系统或子系统。
语言，服务为了实现软件功能而采用的代码语言，如Java、php、python等。
协议，数据通信规范，可以是终端到服务端，也可以是服务端和服务端之间。两个软硬件各不相同的两个系统，只要采用相同的协议即可正常通信。
RPC（Remote Procedure Call Protocol)，远程过程调用协议，其允许像调用本地服务一样调用远程服务。相比HTTP或socket一类的通信协议，更多的是表示一种技术框架，可以通过HTTP、socket或其它封装的私有协议来实现。
二、服务输出：
现在假设你是一个服务提供者，先选定了开发语言A开发了一套系统，为了实现对外服务，就需要通过API封装把服务接口提供出去。这时候可选的方案就有HTTP的接口、RPC的接口或其它协议基础的通信接口，至于具体如何选择我们不在此作展开。
对于接口调用，这里有一个隐藏概念，即server端和client端的协议数据收发模块。对于HTTP类型的接口，大多数的终端、浏览器、语言代码包都提供了完备的HTTP request功能，因此服务提供者不需要考虑对方如何调用的问题。
但对于RPC接口就需要显性的去考虑别人怎么调用的问题。要让别人像调用本地服务一样调用自己的server端，就需要提供一个负责RPC协议数据收发的client代码包给对方。对方引入代码包后，根据client代码包的request对象结构拼接数据，调用client代码包的方法以使用server的接口服务，并用client代码包的response对象结构来解析返回数据。
且考虑到对方的开发语言是多样的，为了更多的支持服务调用者，client代码包也会有多个语言版本。也就是说，你自己的服务可能是java写的，提供出去的client代码包可能是java的、php的等等。当然RPC大多在公司内部的大系统内相互调用，因此技术栈范围是有限的，固定支持一种或几种即可。
三、服务测试：
下面我们再回到测试视角。
测试靠调用RPC接口完成RPC服务的测试。而测试是没有固定的语言要求的，不需要RPC服务端来适配我们。因此我们在选测试脚本语言的时候需要看开发提供的client代码包的语言是什么，我们就用什么，跟开发的技术栈保持一致。
选定语言后就可以进行测试代码开发了，基本流程如图所示。
先进行环境配置，主要包括3个方面：
- RPC运行环境配置，包括一些协议、referer等配置。
- Client代码包的安装，例如maven通过pom文件的depedencies安装。
- 服务器地址配置，包括group、直连地址等（RPC一般起的云服务）。
环境配置完成之后开始代码编写。先引入代码包，进行环境上下文Context初始化（rpc框架不同，这部分的工作也会不一样），然后按照Client代码包中的类和方法定义，进行Request数据准备、service服务调用和Response结果校验。
同样，调用方式不是最关键的，服务端不等同于简单的接口测试，接口调用只是手段，用来帮助我们进行服务及系统本身的测试验收。所以，重要的是对于被测服务的理解。例如RPC接口大多提供的是模型及策略服务，因此我们要明确的是被测对象。如果是模型，核心需要关注的指标是什么？如何评估？测试数据有什么要求（各类型数据的构成比例及数量等）？如果是策略，针对的是什么输入数据？输出的期望是什么？这些才是RPC测试的根本所在。