接口自动化测试实践指导（上）：接口自动化需要做哪些准备工作

为什么做接口自动化

什么是接口测试？

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

做接口自动化的原因

我把认为比较重要的原因有以下几点：

越来越多的系统采用前后端分离架构、微服务架构，各服务之间更多的通过各种接口实现信息的互通，对接口直接进行测试，可以更全面的覆盖各类测试场景；

如果仅依赖通过前端进行测试，由于前端对入参数据的一些逻辑控制，会造成有些测试场景无法测试到，特别是安全测试方面的场景无法覆盖；

敏捷测试对测试效率上的要求很高，测试自动化的占比应该要远大于手工测试占比，才能比较好的胜任敏捷的要求；

一般实际工作中，实施接口自动化要优先于界面自动化，因为在实际实施中，接口自动化脚本的维护成本要低于界面自动化，稳定性也要好很多；

如今业务系统复杂度越来越高，单纯依赖手工回归，成本会急剧增加且测试效率大幅下降，接口自动化测试是一种非常好的解决方案，另外加上有很多工具的支持，接口自动化成为很多项目测试中必须要做的一块。

测试分层模型

要做接口自动化，我们要先熟悉测试分层模型，从图中可以知道接口测试处于金字塔的第2层。针对业务逻辑自动化测试层，主要分为接口自动化和界面自动化。从测试体量上来看，接口自动化要大于界面自动化，这是综合测试成本、测试成效等多方面考虑的结果。实际项目中，更多的是一种纺锤形的测试分层模型，中间最大的一部分是接口自动化，因为单元测试往往落地效果不好，项目的质量提升更多的依靠接口自动化来实现。

需要哪些准备工作

接口自动测试的准备工作基本包括以下：

自动化工具选型

我们在进行接口自动化测试前，首先要选择适合的测试工具，磨刀不误砍柴工，工具选好了，后面的测试工作也易于开展。关于工具的选型不是本文的重点，在此不过多展开。对于刚接触接口测试的同学，可以本着易于上手、适合自己、满足项目需求这三点来选择。

目前常用的测试工具如下：

建议：

如果你第一次接触接口自动化，可以先选择 Postman 开展接口自动化，该工具使用简单易于入门，当然更深入使用该工具，还是需要费些时间研究学习一下，该工具的支持的功能还是很强大。

本文的实战样例会采用 Jmeter 进行展示，因为笔者演示的项目使用的测试工具就是 Jmeter。大家阅读本篇文章时，重点要放在测试思路如何组织上，具体接口用例的实现形式上可以忽略，不同工具的实现形式是不一样的。

测试环境准备

测试环境准备可分为两部分：被测系统环境准备和测试客户端环境准备

1)被测系统环境准备

该环境就是被测系统的运行环境准备，进行测试前，我们肯定需要知道要测试哪个系统，这个系统的访问地址是多少，这样我们才能进行后续的测试工作。

测试环境最好由测试人员自己维护起来，这样避免依赖开发人员，也能加强测试人员对测试环境管控，避免环境被人随意改动，影响测试工作。

最开始的测试环境部署，最好要请教开发人员，尽量保证测试环境各项配置与生产基本一致，避免因为配置不同，遗漏某些bug。当然像数据库这样的配置肯定要使用测试环境专用的配置，连接测试数据库，决不能直接连接生产数据库进行测试。

2)测试客户端环境准备

该环境的准备比较简单，就是部署有测试工具的客户端环境，最简单的方式就是本机部署安装测试工具，当然也有比较复杂的客户端环境准备，如你要做持续集成测试，可能要集成 Jenkins，环境部署上就会复杂好多，初学者可以先不关注。

因采用不同的测试工具，客户端环境准备上会有所不同，具体的依据自己采用的测试工具来准备。

注：目前我采用的测试工具是 Jmeter，客户端环境准备比较简单，只需安装好 java 运行环境，从官网下载 Jmeter 安装包解压即可使用。

获取接口文档

测试工具和测试环境准备就绪之后，那下一步是不是就可以开始测试了，当然还不行，按照正常思路，你得知道要测试什么，依据什么来测试，搞清楚这些才能开始下一步的测试工作。

在传统的瀑布软件流程中，测试人员在做某个系统的手工功能测试时，测试人员会首先从业务人员或开发人员那边获取需求文档、系统设计文档，通过这些文档了解学习被测系统，测试用例也会依据这些文档来进行编写。

如果你的项目采用敏捷开发模式，文档虽然不多，但依然可以从产品经理那里获取产品设计原型、PRD 文档等，据此来了解被测系统，进行用例分析和编写工作。

说了上面这么些，只是给大家一个对照，对于接口测试，同样也需要首先获取一些文档，依据这些文档来了解被测接口，并进行用例分析和编写。不过需要注意，接口文档形式比较多样，有的项目组可能采用 word 文档，更多可能采用一个系统维护接口文档（如：RAP、eolink 等），也有的组采用 Swagger 工具生成。

目前测试最多的是 http 类的接口（一般以 RESTful API 居多），也有 WebService 类接口，本篇演示内容会以 RESTful API 风格的 http 类接口来进行展示。

实际项目展示

目前这个项目采用 eolink 这款工具来维护接口文档，使用这块工具来维护接口文档还是非常方便（该项目使用的是老版本的 eolink，新版本 eolink 丰富了很多更易用的功能，更多功能介绍可参见文末），具体展示如下：

接口列表展示

删除应用”接口维护内容展示

测试数据准备和设计测试用例

上面内容准备就绪后，就可以开始接口测试用例的设计，用例设计完毕后只需要再准备一些初始测试数据，就可以开始进行接口的调试与测试工作了。

测试数据准备和设计测试用例可以同步进行，说起测试数据准备，我们要准备哪些内容呢?这个就要看具体的项目了，举个例子：如果你这个项目是需要用户登录的，那至少你要准备你的测试用户。当然你要明确一点，并不是所有数据都是测试前要准备好的，很多测试数据可能是一边测试一边准备的，因为只有测试到某个接口，才知道需要准备哪些数据，对于数据准备这块，依据实际情况灵活处理即可。

对于测试数据按照我自己总结的思路可以从如下三个角度考虑：

测试数据准备思路

个人感觉做接口自动化最麻烦的地方是对测试数据的准备和规划，测试数据准备的好不好非常影响脚本的健壮性，经常会因为测试数据问题，造成用例跑不过，影响接口自动化的成效。

对于测试数据准备，我的一般把测试数据分为两类：①死数据；②活数据。

1)死数据

死数据指在测试前准备好的测试数据，这些数据往往都是手工在被测系统中准备好的，直接作为脚本的初始化参数供脚本使用。这部分的数据建议不要太多，不然会导致前期准备时间比较长。能够当做死数据来准备的数据，建议是一些比较固定的、后续测试中不太容易发生变化的数据，像类似用户名密码这样的数据，在后续测试中不易发生变化，对后续数据维护成本不会太大。