前言
在前两篇博文《Postman使用 - 基础篇》《玩转Postman：进阶篇》中，我们介绍了 Postman 作为一款专业接口测试工具>测试工具在接口测试中的主要用法以及它强大的变量、脚本功能，给测试工作人员完成接口的手工测试带来了极大的便利。其实在自动化测试上，Postman 也能进行良好的支持。本篇我们就一起来了解如何利用 Postman 进行接口自动化测试。
自动化测试概述
在继续本篇内容前，我们还是首先温习一下和自动化测试相关的一些基本概念。
百度百科中给出的定义：
人为驱动的测试行为，从广义上理解可以包含从测试需求分析到测试设计、测试执行以及测试总结的全过程，而狭义的理解一般就是将测试设计通过测试代码来体现并通过代码的执行来自动地完成测试的执行并输出执行结果。
现在我们谈到自动化测试，更多还是在狭义层面，通过自动化测试来提升测试执行效率，通过快速得到测试用例的执行结果来尽快得到被测产品状态，更多是起到质量指示器的作用。
在《Postman使用 - 基础篇》中我们介绍了经典的自动化测试金字塔：
这个模型体现在自动化测试中，表示越底层的自动化测试所占比重应该越大，这样才有更好的投入产出比。而中间这一层的 Service 测试它既不像 UI 层那样维护成本巨大，很难跟得上快速迭代的要求，同时它又比单元测试更能在业务逻辑上进行质量验证。所以现在一般认为 API 测试是自动化测试实施上的优先选择。
借助一些自动化测试工具>测试工具或者自动化测试框架的帮助，我们可以在测试执行的用例组织、执行策略、测试数据管理、结果报告等方面更加方便地进行自动化测试的实施。下面我们就来看看 Postman 在自动化测试上提供的支持。
Postman的批量执行工具 Runner
Runner 是 Postman 中用于批量执行接口用例的模块，我们可以通过 Runner 模块来完成已编写接口用例的自动化测试执行。
Runner 功能介绍
在 Postman 主界面左上角，点击 Runner 按钮，即可打开 Runner 模块界面。如下图
相关设置的作用如图上标注。选中待执行的 Collection 或 Folder 后，点击运行按钮，会开启如下运行页面，并显示执行结果。相关界面元素含义如图上标注
接口的测试数据驱动
Postman 通过 引入 data 变量来支持 Runner 运行时的测试数据加载和数据驱动。在上一篇 Chat《玩转Postman：进阶篇》中，我们简单介绍了 data 变量的使用方法。这里我们再结合一个 GitHub API 的例子回顾一下：
数据文件中给出一组 Repositories 的信息（测试数据），我们运行一个和这组数据相关的接口：获取 repo、获取 repo 的 contributor、获取 repo 的 tag、获取 repo 的 topic，并分别进行相关校验
Postman 支持两种外部数据类型，json 格式或者 txt/csv 格式。这里我们假设将 repositories 数据以 json 格式保存在数据文件中，给出如下一些主流的开源自动化测试框架
[{"owner": "junit-team","repo": "junit5"
}, {"owner": "robotframework","repo": "robotframework"
},{"owner": "appium","repo": "appium"
},{"owner": "SeleniumHQ","repo": "selenium"
}]
在 Test 脚本中编写校验，在上一讲中我们提到一个技巧，对于重复使用的脚本我们可以把它们保存到 global 变量中，需要时执行这个变量内容即可。本例中我们需要执行的几个接口，都会用到是否正确返回成功响应的校验。
所以可以设置一个 global 变量 checkOK。变量值即需要执行的校验脚本
不同的接口中均包含了相应 repo 信息作为路径参数，然后我们再添加对应的校验
- 获取 repo 接口
/repos/:owner/:repo
eval(pm.globals.get("checkOK"));
//判断是否存在 stargazers_count 字段
pm.test("存在 Star 数据",function(){pm.response.to.have.jsonBody("stargazers_count")//获取 star 数量let star = pm.response.json().stargazers_count// 将Star数显示到Test Result中，并判断是否 超过 1000 Starpm.test("当前repo【"+ pm.variables.get("repo") +"】star数【"+ star +"】超 1000",
