前言：

服务端接口测试介绍

什么是服务端？

什么是接口？

什么是接口测试？

为什么要做接口测试？

如何做接口测试？

接口测试自动化介绍

为什么是接口测试自动化？

为什么要做接口测试自动化？

接口测试自动化的规范

接口测试自动化框架选型

总结：

前言：

本文包含了我在接口测试领域的一些方法和心得，希望大家一起讨论和分享，内容包括但不仅限于：

服务端接口测试介绍
接口测试自动化介绍
接口测试自动化实践
关于接口测试自动化的思考和总结

服务端接口测试介绍

什么是服务端？

一般所说的服务端是指为用户在 APP 或 PC 使用的互联网功能提供数据服务的背后的一切。以天猫精灵智能音箱系列的产品链路为例，服务端便是网关（包括网关在内）之后的链路。

什么是接口？

官方点说，是计算机系统中两个独立的部件进行信息交换的共享边界。通俗点说，就是服务端对外提供数据服务最常用的信息交换方式。提供数据服务的服务端是个可大可小的机构，做的事大多不止一件，它做了这么多事，最终的目标是给 APP 或其它调用方使用，于是服务端就派出了几个代表，比如 API1 负责提供用户信息，API2 负责提供设备信息，API3 负责提供播放的音频信息等等。同事，服务端规定好跟 API1 通讯的接头暗号是param1，param2…，跟 API2 通讯的接头暗号是 param3，param4…，而 params 就是接口参数，就是用来告诉服务端你要什么服务，具体的要求是什么。接口一般由三个部分组成：协议、地址及参数。

什么是接口测试？

一般讲的接口测试指的是对某个给定接口进行功能测试，输入不同的参数时，接口返回值是否正确。下图是经典的测试金字塔模型。

在这个模型中，越往下比例会占的越高，也就是说在一个产品测试中，单元测试比例是最高的，依次是接口测试和 UI 自动化测试，最顶端是人工测试部分。服务端接口测试在中部，承上启下，由此可见其重要性。

为什么要做接口测试？

一般做接口测试有如下原因：

接口是服务端对外提供数据服务最常用的信息交换方式，接口大部分内容都是数据，通过数据对比我们可以推测到系统的逻辑，测接口其实也就是测逻辑。
接口测试相对容易实现自动化，也容易实现持续集成，且相对 UI 自动化也比较稳定，可以减少人工回归测试人力成本与时间，缩短测试周期，支持后端快速发版需求。

如何做接口测试？

前面提到，接口是由这几个组成部分：接口地址、请求协议、请求参数和预期结果。测试接口的步骤一般步骤是：发送请求->解析结果->验证结果。

简单来说，接口测试就是参照接口文档，调用接口，看结果的返回是否跟文档说明一致；另外，再测试一下接口对异常逻辑的处理比如非法参数或边界值。

深入来说，接口测试的关注重点在于：

一、接口的数据逻辑是否正确。 我们需要充分理解接口的功能，内部是什么样的数据逻辑，它与上下游交换了那些信息或资源，不单纯地停留在参数调用和程序返回的表象数据。通俗地说，就是要知道这个接口是干什么用的，用到哪里，每次调用会发生什么，然后去检验改发生的有没有发生。

二、接口对于异常参数的处理机制与上下游服务的容错。 如下图所示，被测接口 A 依赖上游服务 A，那么服务A异常的时候被测接口是否很好的容错就很重要，否则服务挂起或宕掉都是有可能的。另外，作为服务提供方接口 B，应当要充分兼容不同的使用场景、或不同版本的调用方的使用，不能为了服务 E 做的需求，除了E其它的服务使用者都用不了了。总的来说，原则就是 “上游不可靠，下游要兼容” 。

接口测试自动化介绍

为什么是接口测试自动化？

接口测试自动化，简单来讲就是功能测试用例脚本化，然后执行脚本，产生一份可视化测试报告。

为什么要做接口测试自动化？

不管什么样的测试方式，都是为了验证功能与发现 bug。那为什么要做接口测试自动化呢？一句话概括就是是为了节省人力成本。具体来说，包括以下几点：

减轻自己工作量，把测试从枯燥的重复劳动的人工测试中解放出来；
协助手工测试完成很难模拟或无法模拟的的工作；
提高工作效率，比如测试环境的自动化编译、打包、部署、持续集成甚至持续交付等。
协助定位问题，比如接口层发现问题了，可以通过添加的 traceID 定位到日志错误或错误代码行，
尽早发现 bug，自动通知测试人员。一旦发现问题，立即通知测试人员，快速高效。

接口测试自动化的规范

这里结合我平常在做接口测试时的一些经验，总结了一些接口测试自动化的规范，抛砖引玉，欢迎大家补充。

文档准备

磨刀不误砍柴工，准备好分详细的接口相关文档能够帮助后续接口自动化测试工作的高效展开。相关文档包括但不限于一下内容：

1. 《需求文档》 ，明确定义了：接口背后的业务场景，即该接口是干什么用的，用到哪里，每次调用会发生什么等；

2. 《接口文档》 ，明确定义了：接口名，各个入参值，各个返回值，和其他相关信息；

3. 《UI 交互图》 ，明确定义了：各单页面需展示的数据；页面之间的交互等；

4. 《数据表设计文档》 ，明确定义了：表字段规则、表 N 多 N 关系（一对一、一对多、多对多）等；

务必和相关需求方确认好文档中的信息是可靠且最新的，只有依赖可靠的文档才能设计出正确详尽的接口用例，才能得到最正确的结果。

明确接口测试自动化需要的功能

1. 校验（断言）

测试断言是自动化测试中的测试通过条件，用于判断测试用例是否符合预期。所以支持对返回值校验是一个必须的功能。

2. 数据隔离

数据隔离就是指具体的请求接口、参数、校验等数据做到与代码相隔离，便于维护，一旦需要调整接口用例、新增接口用例时可很快速的找到位置。隔离的另一个好处就是可复用，框架可以推广给其他团队，使用者可以使用相同的代码，只需要根据要求填写各自用例即可测试起来。

3. 数据传递

做到数据隔离可维护后，数据传递是另外一个更重要的需求。接口测试时，首先我们会实现单接口解耦，后续按照业务场景组合多个接口。而数据传递是则是组合多个接口的必要条件，它让接口用例之间可以做到向下传参。举个例子，我们通过设备信息查询接口查询到当前天猫精灵音箱的设备信息，该接口会返回一个 UUID，接下来我们要通过用户信息查询接口去查询当前设备绑定的用户信息，此时第二个接口的请求数据是需要从第一个接口用例中的返回中提取的。

4. 功能函数

实际的业务场景测试会需要各种辅助功能的支持，比如随机生成时间戳，请求 ID，随机的手机号码或位置信息等等，此时我们就需要代码可以支持做到识别对应关键字时可以执行对应的功能函数进行填充。

5. 可配置

目前测试环境包括但不限于日常、预发一、预发二、线上等等，因此用例不单单只能在一个环境上执行，需要同一份接口用例可以在日常、预发、线上等多个环境都可以执行。所以框架需要做到可配置，便于切换，调用不同的配置文件可以在不同的环境执行。

6. 日志

日志包含执行的具体执行接口、请求方式、请求参数、返回值、校验接口、请求时间、耗时等关键信息，日志的好处一来是可以便于在新增用例有问题时快速定位出哪里填写有问题，二来是发现 bug 时方便向开发反馈提供数据，开发可以从触发时间以及参数等信息快速定位到问题所在。

7. 可视化报告

用例执行后，就是到了向团队展示结果的时候了，一个可视化的报告可以便于团队成员了解到每次自动化接口用例执行的成功数、失败数等数据。

8. 可持续集成

对于已经有测试用例并测试完成的接口，我们希望能够形成回归用例，在下一个版本迭代或上线之前，通过已有用例进行一个回归测试，确保新上线的功能不影响已有功能。因此，这就需要接口自动化测试是可持续集成的而不是一次性的。