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

Posted 2023-03-28 石臻臻的杂货铺

作者：石臻臻, CSDN博客之星Top5、Kafka Contributor 、nacos Contributor、华为云 MVP ,腾讯云TVP, 滴滴Kafka技术专家 、 LogiKM PMC(改名KnowStream)。

---

LogiKM(改名KnowStreaming) 是滴滴开源的Kafka运维管控平台, 有兴趣一起参与参与开发的同学,但是怕自己能力不够的同学,可以联系我,当你导师带你参与开源！ 。

文章目录

• • 1. 为什么做接口自动化
  • • 1.1 什么是接口测试
    • 1.2 做接口自动化的原因
    • 1.3 测试分层模型
  • 2. 需要哪些准备工作
  • • 2.1 自动化工具选型
    • 2.2 测试环境准备
    • 2.3 获取接口文档
    • 2.4 实际项目展示
  • 3. 测试数据准备和设计测试用例
  • • 3.1 测试数据准备思路
    • 3.2 测试数据准备实战演示
    • • 死数据
      • 活数据

文末送5本《自动化测试实战》

1. 为什么做接口自动化

1.1 什么是接口测试

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

在这里呢，首先抛个问题：接口测试和接口自动化有什么不同？

在这里先不做解答，大家可以带着这个问题去阅读后面的内容，相信自然会得到这个问题的答案。

1.2 做接口自动化的原因

如果要一一列举原因会列举出很多，在这里我把认为比较重要的几点原因列举如下：

• 现在越来越多的系统采用前后端分离架构、微服务架构，各服务之间更多的通过各种接口实现信息的互通，对接口直接进行测试，可以更全面的覆盖各类测试场景
• 如果仅依赖通过前端进行测试，因为前端对入参数据有些逻辑控制，会造成有些测试场景无法测试到，特别一些安全测试方面的场景无法覆盖
• 敏捷测试对测试效率上的要求很高，测试自动化的占比应该要远大于手工测试占比，才能比较好的胜任敏捷的要求
• 一般实际工作中，实施接口自动化要优先于界面自动化，因为在实际实施中，接口自动化脚本的维护成本要低于界面自动化，稳定性也要好很多
• 如今业务系统复杂度越来越高，单纯依赖手工回归，成本会急剧增加且测试效率大幅下降，接口自动化测试是一种非常好的解决方案，另外加上有很多工具的支持，接口自动化成为很多项目测试中必须要做的一块。

1.3 测试分层模型

要做接口自动化，我们先熟悉测试分层模型，从图中可以知道接口测试处于金字塔的第2层

针对业务逻辑自动化测试层，主要分为接口自动化和界面自动化

从测试体量上来看，接口自动化要大于界面自动化，这是综合测试成本、测试成效等多方面考虑的结果。

实际项目中，更多的是一种纺锤形的测试分层模型，中间最大的一部分是接口自动化，因为单元测试往往落地效果不好，项目的质量提升更多的依靠接口自动化来实现。

2. 需要哪些准备工作

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

2.1 自动化工具选型

我们在进行接口自动化测试前，首先要选择适合的测试工具，磨刀不误砍柴工，工具选好了，后面的测试工作也易于开展。

关于工具的选型不是本文的重点，在此不过多展开。对于刚接触接口测试的同学，可以本着易于上手、适合自己、满足项目需求这三点来选择

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

建议：

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

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

2.2 测试环境准备

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

1） 被测系统环境准备

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

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

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

2） 测试客户端环境准备

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

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

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

2.3 获取接口文档

测试工具和测试环境准备就绪之后，那下一步是不是就可以开始测试了，当然还不行，按照正常思路，你得知道要测试什么，依据什么来测试，搞清楚这些才能开始下一步的测试工作。
在传统的瀑布软件流程中，测试人员在做某个系统的手工功能测试时，测试人员会首先从业务人员或开发人员那边获取需求文档、系统设计文档，通过这些文档了解学习被测系统，测试用例也会依据这些文档来进行编写。

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

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

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

2.4 实际项目展示

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

• 接口列表展示
  

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

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

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

测试数据准备和设计测试用例可以同步进行，说起测试数据准备，我们要准备哪些内容呢，这个就要看具体的项目了，举个例子：如果你这个项目是需要用户登录的，那至少你要准备你的测试用户。

当然你要明确一点，并不是所有数据都是测试前要准备好的，很多测试数据可能是一边测试一边准备的，因为只有测试到某个接口，才知道需要准备哪些数据，对于数据准备这块，依据实际情况灵活处理即可。

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

3.1 测试数据准备思路

个人感觉做接口自动化最麻烦的地方是对测试数据的准备和规划，测试数据准备的好不好非常影响脚本的健壮性，经常会因为测试数据问题，造成用例跑不过，影响接口自动化的成效。
对于测试数据准备，我的一般把测试数据分为两类：
①死数据；
②活数据。

1） 死数据

死数据指在测试前准备好的测试数据，这些数据往往都是手工在被测系统中准备好的，直接作为脚本的初始化参数供脚本使用。

这部分的数据建议不要太多，不然会导致前期准备时间比较长。能够当做死数据来准备的数据，建议是一些比较固定的、后续测试中不太容易发生变化的数据，像类似用户名密码这样的数据，在后续测试中不易发生变化，对后续数据维护成本不会太大。

2） 活数据

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

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

3.2 测试数据准备实战演示

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

死数据

说明：

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

活数据

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

• 通过执行相关接口来提取准备
  
  
  说明：
  图中通过创建应用和查询应用列表接口来准备测试数据“拥有所有环境的应用id”，用于后面用例的测试。

• 编写脚本自动生成
  

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

以上是对接口自动化需要做哪些工作的整体思路阐述，进一步思考，细心的同学会发现，对前期的准备工作，包括接口文档，环境等，需要一个平台管理，这样可以起到极大提升效率的作用，包括后续的脚本编写

Jmeter工具虽然很简单易用，也能满足需求，但脚本结构上还是过于灵活，比较适合单兵作战，不太适合团队协作。这里呢，推荐大家一款好用的既能兼顾接口文档维护、环境管理，又能用来做接口自动化的测试平台：eolink，其官网：https://www.eolink.com/，最新版本的eolink有着丰富易用的功能，帮助项目团队更好的对API接口进行管理和测试，这里简单介绍一下该平台对于API接口设计维护、环境管理、测试数据维护、Mock的功能：

1）API接口设计维护

平台提供了多种API维护方式：手工表单维护、通过模板创建、自动生成API文档等，并对API有状态和历史版本的管理，想了解更多可以参见：https://help.eolink.com/#/tutorial/?groupID=c-655&productID=13

2）环境管理

在接口测试中往往需要在不同环境中进行测试，对于环境，eoLink也提供了项目环境的管理模块，方便统一对环境进行管理。想了解更多可以参见：https://help.eolink.com/#/tutorial/?groupID=c-703&productID=13

3）测试数据维护

对于一个测试平台，测试数据维护功能是必须的，eolink也提供了非常易用的测试数据管理功能，在这里可以添加维护多组测试数据，并支持动态赋值。想了解更多可以参见：https://help.eolink.com/#/tutorial/?groupID=c-722&productID=23

4）Mock功能
在开发联调中Mock功能是使用最多的，少量自动化测试场景也需要Mock，eolink平台提供了高级Mock功能，可以满足一些复杂场景的Mock需求。想了解更多可以参见：https://help.eolink.com/#/tutorial/?groupID=c-687&productID=13

因eolink平台功能非常丰富，更多的其他功能将会在后续文章中继续介绍，想详细了解的同学可以直接去官网的帮助中心，会有更详细的介绍。

---

文末送书5本

赠送书籍：《Python软件测试实战宝典》
赠送数量：5
赠送规则：本文三连并分享
进抽奖群：加臻哥福利小助手进群( szzdzhp002 ) 回复暗号：22
中奖概率会保持在25%以上

本书从Python基础入手，系统讲解了使用Python语言来做接口自动化测试、性能自动化测试、安全测试以及功能自动化回归测试。
全书由浅入深，系统化地将作者多年测试开发工作中遇到的问题、解决方案等进行了实例化的阐述，书中丰富的实例代码可以直接在软件的各个自动化测试场景中使用。
作者针对近年来企业对测试开发岗位的需求倾力打造了此书，希望借由此书的出版能够使更多的读者更好地掌握Python测试开发的技能，并找到更理想的软件测试工作。
本书附赠全部测试实例源代码文件及Python软件测试核心知识点精讲视频。本书适合从事软件测试工作的技术人员及希望从事软件测试的专业人员阅读，也适合计算机、软件工程、自动化等相关专业的学生与老师参考。

接口自动化测试实践指导（中）：接口测试场景有哪些

在第一篇文章 接口自动化测试实践指导（上）：接口自动化需要做哪些准备工作中详细给小伙伴们讲解了一下接口自动化需要做哪些准备工作，准备工作中最后一步接口测试用例设计是非常重要的一个环节，用例设计的好不好，直接关系到我们的测试质量，那如何进行测试用例设计呢，这里呢我结合自身经验，帮助大家梳理一下接口测试用例设计思路，希望对大家后续接口测试工作有所帮助和提升。

可以看看这个 ： https://www.eolink.com/

1 接口测试场景梳理

1.1 设计思路

在接口测试中，很大程度上，我们的测试质量依赖于接口测试场景的设计，而接口的测试场景和传统的功能测试场景又有所不同，不少测试同学一时无法很好的转换，一上来进行接口测试思路上会比较乱，这里呢给大家梳理一下接口的常用测试场景，并进行了分类，感兴趣的同学建议反复多看几遍，并多思考一下。

注：性能角度和安全角度的实际测试要比功能角度测试复杂的多，本篇重点讲解功能角度测试，后续再写专题文章来详细讲解接口的性能和安全测试如何进行。

1.2 功能角度讲解

接口测试的功能角度划分，依据侧重的角度不同，可以有多种划分方法，目前我实际测试工作中主要使用的测试场景可以划分为五类：基础检查、正常多角度、异常多角度、必录项检查、边界值检查。
大家注意这个顺序安排：基础检查->正常多角度->异常多角度->必录项检查->边界值检查；优先级是依次降低的。实际在进行接口测试时，建议按照这个优先级顺序进行测试用例设计，不一定所有接口的测试都要设计这么全面，需要综合考虑时间成本、接口的重要性等多重因素来决定。
下面分别解说一下功能角度下的每个场景分类，利于大家理解清楚：
1） 基础检查
该角度主要目的是对接口进行通过性验证，通过输入有效入参，检查接口返回正常，可通过返回状态码或关键字段来进行判断。但内容是不是返回正确，不在该角度检查范围内。
2） 正常多角度
该角度主要验证多种有效入参组合，检查接口均能返回符合预期的正确数据。类似于普通的功能测试，从黑盒角度考虑，利用等价类的思想，划分接口各个入参可能的正常场景组合值，并检查接口返回结果的正确性，是否符合我们入参设置的预期结果。
3） 异常多角度
该角度主要验证多种无效入参组合，检查接口均返回符合预期的报错信息。需要注意的是，该角度更多的是考虑业务角度的异常场景，而非针对某个入参的异常数据测试。针对每个入参的异常数据测试将更多的放到边界值检查场景中。
4） 必录项检查
该角度检查比较明确，就是依据接口文档，检查各个必录的入参是否真的被设为了必录项，在场景设计上，需要测试当只录入必录项入参时，接口应该能够返回处理成功的信息，否则要么是文档写的有问题，要么是接口代码逻辑有问题。
5） 边界值检查
该角度主要从入参要素级角度进行检查，针对接口的每个入参进行特殊字符检查、长度边界值检查等。这个角度的检查优先级最低，原因是一般系统前端都会有控制，这种非法的数据一般是无法正常传递给后端，但如果为了接口更好的健壮性，前端虽然进行了控制，但后端接口也加一下校验控制，安全性和健壮性上会更高。当然实际项目中，后端开发人员往往因为这块处理比较费时，往往没有做到太全面的控制，针对这种情况，我们测试可以依据具体系统使用场景，综合评估一下风险，如果有比较大的风险，还是要具体要求开发人员完善一下后台校验。

2 用例设计实战演示

对于接口用例的维护，这里呢推荐两款工具，一款是单兵神器Jmeter，一款是可以免费且非常好用的API接口协作平台Eolink，该平台不仅支持API接口的协作开发，更有丰富的接口测试功能，支持对接口的测试。Eolink对接口的测试用例维护样例如下：

下图为用Jmeter维护的一组对创建应用接口的接口测试用例，后续会以此为例子给大家解说一下上面章节所说的接口测试场景。

说明：上图展示的是对“创建应用接口”编写的测试用例，该接口的用例是完全按照5个场景分类来设计测试用例，并且在设计用例时，按照每个场景分类优先级依次进行用例设计，这样做的好处是整个设计思路比较清晰明了，最大限度避免遗漏某些场景用例编写。

2.1 基础检查类用例展示

说明：该用例入参随机设置一套可使接口返回正常的一套参数即可。

说明：断言的设置也比较简单，检查接口返回某个关键字段即认为成功

2.2 正常多角度用例展示

说明：该用例主要设置检查各种不同构建类型的应用能否创建成功。

2.3 异常多角度用例展示

说明：该用例是来检查当language字段设置了不存在的值，检查接口返回失败（这类错误数据，接口会返回非200错误码）

2.4 必输检查用例展示

说明：该用例是来检查当language字段设置为null后，检查接口返回预期失败信息，失败信息为：“必须为你的应用选择他的开发语言”

https://www.eolink.com/

2.5 边界值检查用例展示

说明：该用例是来检查tag字段多种不合法入参，检查接口返回预期失败信息，失败信息为：“项目名称只能包含字母、数字、中划线，且不能以中划线为开头和结尾。长度2-50个字符”

最后，再给小伙伴们介绍一下Eolink在测试用例方面的神奇特性：支持自动生成测试用例的能力。该能力可以智能生成多种场景的测试用例，并实现快速生成各种正常类型，异常类型，边界值，必填值的用例。有兴趣的小伙伴建议去官网详细了解一下：https://www.eolink.com/

另外该平台还有着丰富易用的测试功能，帮助项目团队更好的对API接口进行管理和测试，这里简单介绍一下几个好用的功能：
1）支持在线、本地、客户端进行测试
eolink除了常规支持服务器端发起测试，还支持客户端（本地）、插件（本地）发起测试，满足多种不同场景的测试需求，想了解更多，可以参见：https://help.eolink.com/#/tutorial/?groupID=c-628&productID=13
客户端（本地）：

服务器测试（在线）：

插件（本地）：

2）一键进行回归/冒烟测试
在以往的协作方式中，测试人员工作总是排在最后进行，无法参与项目讨论，无法进行快速大范围回归测试，甚至无法按时完成测试任务，导致项目延期或带着忐忑上线。在 API研发管理平台 中，由于协作是基于 API 文档进行的，当后端开发人员将 API 文档写好之后，测试人员就可以马上介入，在 API 文档的基础上编写测试用例，让测试工作前移。当 API 开发完成之后，测试人员可以一键将 API 的测试用例全部测完，并且得到详细的测试报告。后端开发只需要看到测试结果就能够知道自己的 API 是否满足测试需求，如果有异常则可针对性改进。想了解更多，可以参见：https://help.eolink.com/#/tutorial/?groupID=c-469&productID=13

3）丰富详细的测试报告
该平台也提供了丰富详细的测试报告，方便查看和分析测试结果，想了解更多，可以参见：https://help.eolink.com/#/tutorial/?groupID=c-469&productID=13

预告一下，下篇文章将给大家介绍一下接口自动化测试断言设置思路，感兴趣的小伙伴，建议持续关注一下。
https://www.eolink.com/

---

文末送书5本

赠送书籍：《Python软件测试实战宝典》
赠送数量：5
赠送规则：本文三连并分享
进抽奖群：加臻哥福利小助手进群( szzdzhp002 ) 回复暗号：25
中奖概率会保持在25%以上

本书从Python基础入手，系统讲解了使用Python语言来做接口自动化测试、性能自动化测试、安全测试以及功能自动化回归测试。
全书由浅入深，系统化地将作者多年测试开发工作中遇到的问题、解决方案等进行了实例化的阐述，书中丰富的实例代码可以直接在软件的各个自动化测试场景中使用。
作者针对近年来企业对测试开发岗位的需求倾力打造了此书，希望借由此书的出版能够使更多的读者更好地掌握Python测试开发的技能，并找到更理想的软件测试工作。
本书附赠全部测试实例源代码文件及Python软件测试核心知识点精讲视频。本书适合从事软件测试工作的技术人员及希望从事软件测试的专业人员阅读，也适合计算机、软件工程、自动化等相关专业的学生与老师参考。