共计 2827 个字符，预计需要花费 8 分钟才能阅读完成。
为什么要做接口自动化
绝对于 UI 自动化而言，接口自动化具备更大的价值。
为了优化转化门路或者晋升用户体验，APP/web 界面的按钮控件和布局简直每个版本都会产生一次变动，导致自动化的代码频繁变更，没有起到缩小工作量的成果。
而接口一旦研发实现，前期重构 / 大幅度批改的频率则比拟低. 因此做接口自动化性价比还是很高的，对于迭代版本旧有性能的回归，beta 测试，线上回归都能起到事倍功半的作用。
本文不具体谈单个接口的测试，咱们来次要来剖析一下基于业务场景的接口自动化怎么做。
问题在哪里
一个业务场景通常须要多个接口能力走完一个残缺的业务流程，其中每个接口实现一个特定的性能步骤。例如微信的增加好友流程：
每个操作步骤里都至多有一条接口申请。那么咱们把这个流程以接口申请的形式体现进去，如下：
咱们想要实现这条接口用例，须要的操作有哪些？
1)输出微信 id，收回查问申请
2)将获取到的用户信息传递给“增加好友接口”，发动增加好友申请
3）将申请好友的用户信息传给下发好友申请接口
4）将批准信息传给成为好友音讯接口
5）将回绝信息传给回绝音讯接口
概括起来有几个须要解决的问题：测试数据传入，接口依赖，接口间参数传递。
这也是接口测试自动化中会遇到的广泛问题，解决方案能够迁徙到各类业务中去。接下来笔者将针对上述问题提出一些具体的解决方案
工具介绍 本文所用接口测试工具：Apifox Windows 版
Postman 作为接口测试工具，在业界的位置毋庸置疑，但 Apifox 作为一款外乡的接口调试、接口测试 & 测试管理软件，劣势在于合乎国内互联网的测试模式和工作流程, 用起来更棘手些。
大部分性能均能由可视化界面 + 控件操作实现，对于不懂代码、不会写脚本的测试人员，根本也能够无痛顺利地实现接口自动化的工作。
因而本文解说自动化的时候会间接应用 Apifox，大家如果须要跟着文章解说学习的，能够先去官网（www.apifox.cn）下载注册一个，软件收费。
全靠参数化
手工测试的长处在于灵便可控，自动化则依赖咱们事后设置好的步骤实现性能
接口间参数传递
像上述微信好友申请的例子，波及到多个接口间的参数传递，下一个接口对依赖于上一个接口响应中的某个字段，须要将它能精确提取并传递过去。
解决方案 ：提取上一个接口响应数据 – 参数化 – 下一个接口调用该参数。
这样无论接口运行多少次，传递的参数怎么变动，下个接口都能动静提取并调用。
Apifox 上操作步骤如下：
1）在要提取参数的接口的后置步骤里，应用 json path 表达式提取指标响应字段并命名，设置变量类型
2）该字段会保留到我的项目设置中，同一环境，同一我的项目里的其余接口具备调用权限。
运行一下上图中的接口，能够看到该字段曾经被提取到变量设置中了。
3）在须要调用该变量作为参数的接口申请参数里，以参数模式填入到对应空格中
看一下后果：
发送该 post 申请，在接口 > 运行 > 理论申请 tab> 申请 URL 中能够看到，该参数已被胜利调用
测试数据参数化
应用变量
某些测试数据（如登陆账号密码，用户信息等）会在不同的接口被重复调用，这个时候能够将该测试数据参数化，与接口响应参数不同的是，响应参数是获取自上一个接口的，而测试参数是咱们间接写进变量设置里的。在 Apifox 里的操作步骤如下：
1)在全局变量中设置好测试数据变量名和值
2) 间接在接口申请参数中调用该测试数据- 应用测试数据集
当咱们须要上传不同的测试数据以校验响应返回数据是否存在异样时，一个接口参数须要多个测试数据。这个咱们放到前面 测试治理 的局部谈。
测试断言
既然是自动化测试，咱们无奈一一人工去校验返回的 response 是否合乎咱们的要求，因而须要用脚本 / 性能设置替人力实现这些工作。
咱们次要校验：
*1）接口申请是否胜利，即返回的 code 是否合乎预期
2）返回的接口数据里的关键字段、要害值是否合乎预期 *
在 Apifox 上，能够间接通过界面操作设置根本的断言操作：
1) 在接口治理 - 后置操作 里抉择断言
2) 申请收回之后，如果返回值合乎预期，则在返回处会提醒断言胜利，失败则给予谬误提醒。
如果须要灵便设置断言，能够应用 apifox 里的后置操作中的自定义脚本性能，它也提供了代码模板性能，测试人员只需批改期待值即可。
对于单个接口，自动化的预备工作行将输出数据和接口间的参数传递都参数化、不要写死, 方面前期数据批改和保护，以及应用测试断言来代替人工查看接口测试后果。
实现了这部分工作之后，咱们接下来就能够把不同的接口组织到一条接口自动化用例里，实现一个业务场景的测试。
接下来的工作咱们在 Apifox 的测试治理 tab实现。
测试治理
导入测试用例
接口用例须要在测试单个接口的时候生成，这是在导入测试用例之前须要实现的筹备工作。在单个接口测试的时候抉择 保留为用例 即可生成测试用例。
在 测试治理 tab， 新建测试用例 > 导入接口用例 > 抉择该测试场景所需用例 > 默认抉择绑定 > 确定导入
导入结束后的用例如下，一个接口申请就是一个操作步骤，若干个步骤共同完成一个场景的测试。
接口执行程序
在上述用例中，接口申请的步骤是从上而下的，如果想要调整接口的运行程序，间接拖动接口到指标地位即可。
如果须要减少其余接口申请，则抉择 增加步骤。
应用测试数据集
上文 测试数据参数化 那一节有提到过一个接口须要多条测试数据的事件，拿到这里讲次要是功能模块刚好在这边，不便些。
在测试治理 > 用例的右侧，能够看到 测试数据 这个性能
点击治理数据，能够进入 测试数据tab 治理增加内部测试数据。
接着在测试步骤 > 设置 页面，将测试数据批改为测试数据集的变量名称
点击下方的运行按钮时，会弹出界面让测试人员抉择要用的测试数据集，每个测试数据集都会当成一条测试用例来运行。
对应的会生成多个测试后果：
除了可能间接填外，也能够导入内部的 CSV 文件，更加适宜大数据量的测试场景。
测试参数配置
在用例的右侧，有运行环境和保留变量变动值等配置，能够依据我的项目的理论须要选用。
其中 [距离进展] 和[应用全局 cookie]在接口测试中利用频率较高。
运行后果 & 测试报告
点击 [运行] 按钮，运行胜利会跳转到运行后果页面。还能够导出测试报告。
测试套件
同一个模块的接口用例能够合并为一个 测试套件 来运行，在测试套件页面，把单个接口用例间接增加进来，其余操作步骤和上文统一。
点击运行能够顺次运行增加的用例。
总结
整体解说下来，感觉 Apifox 做接口自动化的劣势在于 流程高度整合 、 低代码 、 贴合国内测试团队的工作模式和思维模式。
因而咱们从单个接口测试，到业务流程的接口测试，到整个测试套件组装，以及将它们自动化，一路下来，下一步的工作都是能够复用上一步的工作成绩的，简直没有被节约的工作量。
另一个点是，咱们用 Apifox 实现了自动化，但过程中简直没有须要用到代码的中央，很多中央都被它间接做成了可视化界面，咱们抉择控件填数据就行了，这对代码基础薄弱的测试人员的确是一大福音。
本次的《Apifox 的接口自动化测试攻略》就解说到大家了，心愿能对大家有帮忙。
