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

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

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

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

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

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

测试分层模型

要做接口自动化，我们要先熟悉测试分层模型，从图中可以知道接口测试处于金字塔的第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)死数据

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

• 2)活数据

建议更多的测试数据以活数据的形式准备，这样可以提高脚本的自动化率，减少后续手工的干预，活数据的准备手段比较多，我主要使用如下几种方式：

• 编写SQL查库
• 通过执行相关接口来提取准备
• 编写脚本自动生成

测试数据准备实战演示
为帮助大家更好的理解，这里拿之前用 Jmeter 做的接口自动化中的数据准备案例给大家做一下演示：

死数据

上图是目前我这个项目设置的死数据，有用户方面数据，团队方面数据、应用方面数据，这些数据一般手工创建好后，后续一般不会有太多调整。

活数据

• 编写 SQL 查库

图中 SQL 脚本用来获取删除状态的用户名，用于后面用例（“错误值检查（传入已经删除的username），接口返回失败”）的测试数据。

• 通过执行相关接口来提取准备

图中通过创建应用和查询应用列表接口来准备测试数据“拥有所有环境的应用 id”，用于后面用例的测试。

• 编写脚本自动生成

图中为了生成 appName 这字段值，用了Jmeter 的自带函数“${__time(MMdd-HHmm-SSS,tt)}” 来生成不会重复的应用名称，保证后续测试该字段不会重复（后台程序不允许该字段重复），从而使脚本能够多次成功运行。

以上是对接口自动化需要做哪些工作的整体思路阐述，进一步思考，细心的同学会发现，对前期的准备工作，包括接口文档，环境等，需要一个平台管理，这样可以起到极大提升效率的作用，包括后续的脚本编写，Jmeter 工具虽然很简单易用，也能满足需求，但脚本结构上还是过于灵活，比较适合单兵作战，不太适合团队协作。

这里呢，推荐大家一款好用的既能兼顾接口文档维护、环境管理，又能用来做接口自动化的测试平台：eolink，官网：https://www.eolink.com/。 最新版本的 eolink 有着丰富易用的功能，帮助项目团队更好的对 API 接口进行管理和测试。

这里简单介绍一下该平台对于 API 接口设计维护、环境管理、测试数据维护、Mock 的功能：

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

这里简单介绍一下该平台对于 API 接口设计维护、环境管理、测试数据维护、Mock 的功能：

[外链图片转存中…(img-ns1mvRVf-1719266848953)]
[外链图片转存中…(img-RsHg7JbZ-1719266848954)]
[外链图片转存中…(img-2FTF21bm-1719266848954)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！