为什么要做接口自动化相对于UI自动化而言，接口自动化具有更大的价值。 为了优化转化路径或者提升用户体验，APP/web界面的按钮控件和布局几乎每个版本都会发生一次变化，导致自动化的代码频繁变更，没有起到减少工作量的效果。 而接口一旦研发完成，后期重构/大幅度修改的频率则比较低.因而做接口自动化性价比还是很高的，对于迭代版本旧有功能的回归，beta测试，线上回归都能起到事半功倍的作用。 本文不详细谈单个接口的测试，我们来主要来分析一下基于业务场景的接口自动化怎么做。 问题在哪里一个业务场景通常需要多个接口才能走完一个完整的业务流程，其中每个接口完成一个特定的功能步骤。例如微信的添加好友流程：
每个操作步骤里都至少有一条接口请求。那么我们把这个流程以接口请求的方式表现出来，如下：
仅作示意，并非实际 我们想要完成这条接口用例，需要的操作有哪些？ 1)输入微信id，发出查询请求
全靠参数化手工测试的优点在于灵活可控，自动化则依赖我们预先设置好的步骤完成功能 接口间参数传递像上述微信好友请求的例子，涉及到多个接口间的参数传递，下一个接口对依赖于上一个接口响应中的某个字段，需要将它能准确提取并传递过来。 解决方案：提取上一个接口响应数据--参数化--下一个接口调用该参数。
2）该字段会保存到项目设置中，同一环境，同一项目里的其他接口具有调用权限。 运行一下上图中的接口，可以看到该字段已经被提取到变量设置中了。
3）在需要调用该变量作为参数的接口请求参数里，以参数形式填入到对应空格中
看一下结果： 发送该post请求，在接口>运行>实际请求tab>请求URL中可以看到，该参数已被成功调用
测试数据参数化
测试断言既然是自动化测试，我们无法一一人工去校验返回的response是否符合我们的要求，因此需要用脚本/功能设置替人力完成这些工作。 我们主要校验： 在Apifox上，可以直接通过界面操作设置基本的断言操作：
如果需要灵活设置断言，可以使用apifox里的后置操作中的自定义脚本功能，它也提供了代码模板功能，测试人员只需修改期待值即可。
对于单个接口，自动化的预备工作即将输入数据和接口间的参数传递都参数化、不要写死,方面后期数据修改和维护，以及使用测试断言来代替人工检查接口测试结果。 完成了这部分工作之后，我们接下来就可以把不同的接口组织到一条接口自动化用例里，完成一个业务场景的测试。 接下来的工作我们在Apifox的测试管理tab完成。 测试管理导入测试用例接口用例需要在测试单个接口的时候生成，这是在导入测试用例之前需要完成的准备工作。在单个接口测试的时候选择保存为用例即可生成测试用例。 在测试管理tab，新建测试用例>导入接口用例>选择该测试场景所需用例>默认选择绑定>确定导入
导入完毕后的用例如下，一个接口请求就是一个操作步骤，若干个步骤共同完成一个场景的测试。
接口执行顺序在上述用例中，接口请求的步骤是从上而下的，如果想要调整接口的运行顺序，直接拖动接口到目标位置即可。 如果需要增加其他接口请求，则选择添加步骤。
使用测试数据集上文测试数据参数化那一节有提到过一个接口需要多条测试数据的事情，拿到这里讲主要是功能模块刚好在这边，方便些。 在测试管理>用例的右侧，可以看到测试数据这个功能
点击管理数据，可以进入测试数据tab管理添加外部测试数据。
接着在测试步骤>设置 页面，将测试数据修改为测试数据集的变量名称
点击下方的运行按钮时，会弹出界面让测试人员选择要用的测试数据集，每个测试数据集都会当成一条测试用例来运行。
对应的会生成多个测试结果：
除了能够直接填外，也可以导入外部的CSV文件，更加适合大数据量的测试场景。
测试参数配置在用例的右侧，有运行环境和保存变量变化值等配置，可以根据项目的实际需要选用。 其中[间隔停顿]和[使用全局cookie]在接口测试中应用频率较高。
运行结果&测试报告点击[运行]按钮，运行成功会跳转到运行结果页面。还可以导出测试报告。
测试套件同一个模块的接口用例可以合并为一个测试套件来运行，在测试套件页面，把单个接口用例直接添加进来，其他操作步骤和上文一致。 点击运行可以依次运行添加的用例。
总结整体讲解下来，感觉Apifox做接口自动化的优势在于流程高度整合、低代码 、贴合国内测试团队的工作模式和思维模式。 因此我们从单个接口测试，到业务流程的接口测试，到整个测试套件组装，以及将它们自动化，一路下来，下一步的工作都是可以复用上一步的工作成果的，几乎没有被浪费的工作量。 另一个点是，我们用Apifox实现了自动化，但过程中几乎没有需要用到代码的地方，很多地方都被它直接做成了可视化界面，我们选择控件填数据就行了，这对代码基础薄弱的测试人员确实是一大福音。 本次的《Apifox的接口自动化测试攻略》就讲解到大家了，希望能对大家有帮助。 |
|
|
