共计 3441 个字符，预计需要花费 9 分钟才能阅读完成。
引言
与 UI 相比，接口一旦研发实现，通常变更或重构的频率和幅度绝对较小。因而做接口自动化的性价比更高，通常使用于迭代版本上线前的回归测试中。
手工做接口测试，测试数据和参数都能够由测试人员手动填写和更新。
因而咱们在思考将接口用例实现自动化的时候，次要思路就是在单个接口申请的测试用例曾经实现的前提下，咱们如何解决以下问题：
- 业务测试场景会调用不止一个接口，下一个接口的申请依赖于上一个接口的数据，须要解决接口依赖问题
- token 等鉴权数据有过期工夫，多个接口用到该参数，须要解决一次批改，多处失效的问题
- 一个接口要用到多个测试数据做笼罩
- 批量测试下，须要晓得某个接口返回的参数 / 数据是否合乎预期
本文应用的自动化接口测试工具为 Apifox, 官网下载地址：www.apifox.cn
间接下载注册装置后即可应用。
接下来顺次解说下上述问题如何应用 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 做接口自动化测试的具体流程和思路就介绍到这里，心愿对大家有帮忙。
