接口自动化的关键思路和解决方案，本文全讲清楚了

引言

与 UI 相比，接口一旦研发完成，通常变更或重构的频率和幅度相对较小。因此做接口自动化的性价比更高，通常运用于迭代版本上线前的回归测试中。

手工做接口测试，测试数据和参数都可以由测试人员手动填写和更新。

因此我们在考虑将接口用例实现自动化的时候，主要思路就是在单个接口请求的测试用例已经完成的前提下，我们如何解决以下问题：

1. 业务测试场景会调用不止一个接口，下一个接口的请求依赖于上一个接口的数据，需要解决接口依赖问题

2. token 等鉴权数据有过期时间，多个接口用到该参数，需要解决一次修改，多处生效的问题

3. 一个接口要用到多个测试数据做覆盖

4. 批量测试下，需要知道某个接口返回的参数/数据是否符合预期

本文使用的自动化接口测试工具为 Apifox,官网下载地址：http://www.apifox.cn/?utm_medium=WCSA&utm_source=liam

直接下载注册安装后即可使用。接下来依次讲解下上述问题如何使用 apifox 解决。

正文

一.接口传参

举一个常见的场景说明。查询接口请求获取数据的时候，需要带一个 access_token 的参数，而 access_token 参数需要另外的鉴权接口获取。因此需要鉴权接口将获取到的 token 参数传递给查询接口，查询接口才能发起请求。

另一个常见的场景是，用户需要先登陆，才能将选中的商品加入购物车。这个接口顺利发起请求依赖于上一个接口获取数据。手动测试的情况下，直接人工复制即可。

解决方案：需要将上一个接口返回的数据进行识别提取出目标参数，保存为全局变量，下一个接口直接调用参数。

步骤：1）在 apifox 的接口 tab-后置操作 tab，选择提取变量

2）填写变量名称，变量类型和提取的表达式。提取表达式符合 json path 语法。在本接口数据中由于返回数据只有一层，因此采用 $.目标参数的方式提取。如果有多层参数，可以点击提取表达式旁边的问号，查看详细的 json path 语法。

获取到的参数以变量的形式存储，点击接口 tab 右上角的设置图标，可以查看到获取到的环境变量的值。

接着就可以在下一个接口，以参数的方式调用：

二. 外部数据源

一些 post 数据给后台处理的接口，需要对上传不同的数据来测试接口的返回和异常兼容，一个接口参数需要多次使用不同的数据。手动情况下我们可以直接在参数里填数据，之后每次手动改。

但如果实现自动化的话，像上述的测试方式难以实现。常用的解决方案是先编辑好 csv 文件，将测试数据一一写好保存，最后传入到接口请求参数中。Apifox 在这个问题上提供的解决方案为：a.对于少量的测试数据，可在界面内填好测试数据集供接口每次调用；如果是大量的数据，才使用 csv 文件；更少量的数据则可以直接写在全局变量中。

以全局变量的方式导入和上节讲到的接口传参类似，区别只在于测试数据不是从上一个接口获取到而是的我们自己填进去的。若是使用外部测试数据集，在测试管理 tab>用例界面右侧，有一个测试数据的开关项，打开即可导入测试数据。当然首先需要先把用例导入到测试步骤中来。

如图所示，我已经将 OCRtest（文本识别接口，功能为识别图片上的文字）接口导入用例步骤中，启用了外部测试数据，

接着点击管理测试数据，跳转到测试数据 tab：

在这个界面开始 新建/导入测试数据。此处数据集名称是给测试人员识别的，不会传入到接口里，一个数据集（1 行）代表该次运行中所有需要传入的测试数据，列名作为接口参数，接口每次发起请求，会依次调用该列下的其中一个值。

运行时，每一条测试数据都会当成一条测试用例来运行。

在上面讲到的“接口参数传递”和“传入测试数据”两个的思路是一样的，依赖于 apifox 提供的参数化功能，上传的数据参数以外部数据集的形式与接口分隔开来，将关键字段，不断变化的数据抽取出来独立于单个接口；

配置完成之后，接口每次运行都能够自行生成，传递和导入关键数据，如果需要修改，只需要在一个地方，一个文件内批量修改就能够全局生效。这其中有软件工程中的抽象和封装思想，而接下来会讲到的断言是另一种思路。

三. 测试断言

手工运行测试人员可以自行看接口请求是否成功，数据是否正常，但在自动化实践中，我们则需要代码帮我们判断实际返回和期望返回是否匹配。

http 响应文本是高度结构化的，因此我们的期望返回无非是 header 和 body 中的响应状态码，关键字段，和关键值应该为某个值。只需要判断这些字段是否我们想要的即可。

断言是专门用来验证输出与期望是否匹配的工具，在测试实践中，我们一般通过比较实际输出值和输入值来校验的，即我们要判断返回数据“是否存在”“是否包含”“数据是否等于”“文本是否等于”。

因此判断用例请求结果的实现方案可分为三个要素：判断对象，校验方法，校验值与期待值。

思路明确了，接下来看如何用脚本/功能实现。Apifox 的断言功能面板（路径：接口 tab>运行>后置操作>断言）的可断言对象包括了响应数据中的 JSON，html 和 xml，header，cookie，基本上可以满足我们的要求。

校验的方法为断言对象的值是否符合测试人员规定的值范围

被校验的值可通过 json path 表达式提取

那么像对状态码的判断，某个确定返回值的校验这个，可以直接使用 apifox 提供的功能面板进行操作就行了。如果测试人员想要更加灵活的断言方式需要在后置操作里选择自定义脚本。

对于不太熟悉脚本的测试人员，可以使用 Apifox 右侧提供的代码模板，点击就会添加到左侧的脚本编辑面板里，基本上只需要修改断言的期望值就行了，难度不大。

如果是对单个接口做测试，断言结果会直接在响应 tab 返回

如果是批量测试，在测试结果里会显示断言结果：

这样我们构建接口自动化用例中的“结果判断”的问题就解决了。

四. 环境切换

接口在测试服测试通过之后还需要一轮线上验证，测试任务才算完成。

通常测试服和正式服的的区别只在于前置 URL 不同。为了让线上验证环节不耗费太多重复活动，我们这里可以在自动化项目开始构建的时候就先利用 apifox 提供的功能进行配置。将项目里所有接口共用的 http 协议和域名配置到前置 URL 中，接口地址只填资源路径和参数。

进行线上验证时，将参数配置和数据配置同步更新/切换为线上数据配置之后，只需要在运行环境里切换环境，就可以进行线上验证。

五. 批量测试

1.用例组织形式 apifox 里，用例是以测试用例--用例组--测试套件的形式组织的。一个测试用例可容纳多个测试步骤，一个接口请求为一个步骤。接口用例可直接从接口用例导入。如果设置和接口同步，那么接口一旦变更，测试用例这边也会同步变更。

一个常规用例步骤如下，涉及多个接口，接口之间存在参数传递，多个接口完成一个业务场景的测试。

接口用例导入完毕之后，进行测试参数配置，点击运行即可自动运行。

2.用例执行顺序

在一条测试用例里，接口请求的顺序由上到下依次执行，如果需要变更接口请求的步骤，只需要拖动接口移动到新的位置上去即可。

3.测试套件运行一个接口用例完成一个业务场景/一个业务流程的测试，一个测试套件包含多条用例，可将相同模块的用例集中到一起执行。这种用例组织模式和测试人员常用的用例管理软件 testlink 的组织方式实质是一样的。这样只要点击运行，就可以一键完成一个业务模块的接口测试。

测试完毕后会显示用例测试结果，上方面板为整体执行情况，下方分条列出具体用例执行结果。 如果需要导出测试报告，点击按钮可一键生成 html 格式的文件。

总结

一.接口自动化的工具思维和测试思维

我们这个接口自动化项目的搭建和执行基本都是围绕 Apifox 提供的功能进行的。和 postman 相比，用起来的感觉是特别顺手，用例的组织和测试的思维模式基本上也是几个大中厂都在用的，也符合国内测试组的工作流程，程，是工具来适应人，而不是人去适应工具，在理解门槛和思维切换这点上成本大大降低。

项目一路构建下来，基本都是功能界面的操作，几乎没有需要脚本的地方，对于不熟悉脚本的测试人员来说，可以用它来短时间快速完成测试任务。

如果大家不怎么熟悉那些英文测试术语，用起这个本土接口测试软件，理解成本少点，可能效率会更加高一点。

二.贯穿整个接口自动化项目的三个基本思路：

a.单个接口的测试数据和变量参数化，接口测试结果进行断言

b.单个接口用例以业务测试场景为框架搭建，接口依赖通过参数传递 &接口执行顺序解决

c.用例组织以业务模块和业务流程、逻辑为框架组织成测试组和测试套件，方面后期迭代和更新维护

本文用 APifox 做接口自动化测试的具体流程和思路就介绍到这里，希望对大家有帮助。