全网最全的接口自动化测试教程
为什么要做接口自动化
相对于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上，可以直接通过界面操作设置基本的断言操作：
-
在接口管理-后置操作 里选择断言
-
-
请求发出之后，如果返回值符合预期，则在返回处会提示断言成功，失败则给予错误提示。
如果需要灵活设置断言，可以使用apifox里的后置操作中的自定义脚本功能，它也提供了代码模板功能，测试人员只需修改期待值即可。
对于单个接口，自动化的预备工作即将输入数据和接口间的参数传递都参数化、不要写死,方面后期数据修改和维护，以及使用测试断言来代替人工检查接口测试结果。
完成了这部分工作之后，我们接下来就可以把不同的接口组织到一条接口自动化用例里，完成一个业务场景的测试。
接下来的工作我们在Apifox的测试管理tab完成。
测试管理
导入测试用例
接口用例需要在测试单个接口的时候生成，这是在导入测试用例之前需要完成的准备工作。在单个接口测试的时候选择保存为用例即可生成测试用例。
在测试管理tab，新建测试用例>导入接口用例>选择该测试场景所需用例>默认选择绑定>确定导入
导入完毕后的用例如下，一个接口请求就是一个操作步骤，若干个步骤共同完成一个场景的测试。
接口执行顺序
在上述用例中，接口请求的步骤是从上而下的，如果想要调整接口的运行顺序，直接拖动接口到目标位置即可。 如果需要增加其他接口请求，则选择添加步骤。
使用测试数据集
上文测试数据参数化那一节有提到过一个接口需要多条测试数据的事情，拿到这里讲主要是功能模块刚好在这边，方便些。 在测试管理>用例的右侧，可以看到测试数据这个功能
点击管理数据，可以进入测试数据tab管理添加外部测试数据。
接着在测试步骤>设置 页面，将测试数据修改为测试数据集的变量名称
点击下方的运行按钮时，会弹出界面让测试人员选择要用的测试数据集，每个测试数据集都会当成一条测试用例来运行。
对应的会生成多个测试结果：
除了能够直接填外，也可以导入外部的CSV文件，更加适合大数据量的测试场景。
测试参数配置
在用例的右侧，有运行环境和保存变量变化值等配置，可以根据项目的实际需要选用。 其中[间隔停顿]和[使用全局cookie]在接口测试中应用频率较高。
运行结果&测试报告
点击[运行]按钮，运行成功会跳转到运行结果页面。还可以导出测试报告。
测试套件
同一个模块的接口用例可以合并为一个测试套件来运行，在测试套件页面，把单个接口用例直接添加进来，其他操作步骤和上文一致。 点击运行可以依次运行添加的用例。
总结
整体讲解下来，感觉Apifox做接口自动化的优势在于流程高度整合、低代码、贴合国内测试团队的工作模式和思维模式。
因此我们从单个接口测试，到业务流程的接口测试，到整个测试套件组装，以及将它们自动化，一路下来，下一步的工作都是可以复用上一步的工作成果的，几乎没有被浪费的工作量。
另一个点是，我们用Apifox实现了自动化，但过程中几乎没有需要用到代码的地方，很多地方都被它直接做成了可视化界面，我们选择控件填数据就行了，这对代码基础薄弱的测试人员确实是一大福音。
感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
