postman接口自动化（二）用例管理与批量运行结果分析

一、用例管理
如何进行用例管理
Postman 中提供了一个集合collection的概念，通过集合以及集合中的文件夹Folder为我们提供了用例的管理方式。

我们可以粗略的将用例分为以下三个层级：

第一级：Collection，针对测试的一个项目；
第二级：Folder，针对模块；
第三级：Folder， 针对单个接口。
如果要进行流程测试，还可以建子文件夹，将流程中用到的请求集中在一起，方便运行和管理。

可以点击 Collection 后面的星号将 Collection 置顶。

如何新建 Collection

界面上的元素说明：
项目名称：用来描述一个 Collection，可以使用项目名或者产品名；
项目描述：用来为当前项目增加一些描述，相当于测试项目介绍文档；
认证模块：如果当前项目需要一个统一的认证方式（如 Bearer Token，Basic Auth，OAuth 等 ），可以在这里进行设置，对 Collection 中的每个请求有效；
前置脚本：类似普通测试框架中的 SetUp 模块，可以做一些请求的初始化，比如加密，生成签名 Sign 等。这里的代码会在当前 Collection 每个请求运行之前运行；
后置脚本：类似普通测试框架中的 TearDown 模块，可以做一些请求的清理动作，比如还原配置、清理测试数据等。这里的代码会在当前 Collection 每个请求运行之后运行；
预设参数：Collection 运行时的参数（变量），在 Collection 内部的请求中都可以调用该参数。关于参数将在后续章节中详细讲解。
基于以上的描述，你可以根据需要为 Collection 添加相应的内容。

二、批量运行用例
首先点击 Collection 后面的 > ，然后再弹出的窗口中点击 Run。


在上图的右侧会列出选择的所有请求列表，你可以根据需要调整位置或者决定哪些用例运行或者不运行。
同时还可以设置运行时的参数，比如选择环境、迭代次数、数据文件等。

运行参数如下：
**Environment：**选择运行的环境，环境主要决定环境变量的；
Iterations： 用例迭代的次数，也就是当前选中的这些请求需要运行几次；
**Delay：**延迟，用来设置每个请求之间的运行时间（以毫米为单位），如果设置了，则一个请求运行完后会等待相应的时间才运行下一个请求；
**save Responses：**记录响应日志，这是一种限制性的设置，默认是记录所有请求的日志，也可以限制为只记录错误日志或者完全不记录；
**Data：**选中数据文件，这是 Postman 提供的数据驱动的方式，数据针对当前 Collection 中请求中使用的变量。支持 Csv 和 Json 格式的文件；
**Keep variable values：**保持变量值。如果 Collection 中有脚本重新设置环境变量或者全局变量的值，默认情况下只对当次运行有效。如果勾选了此选项，那么在脚本中重设的变量值会保存下来，也就是会直接修改 Postman 中预设的变量值；
**Run collection without using stored cookies：**如果勾选此选项，运行 Collection 的时候则不会使用 Postman 的 cookie 管理器；
**Save cookies after collection run：**运行后，储存运行过程中的 cookies，此选项默认勾选。

Data 数据文件
这是 Postman 提供的数据驱动的功能，可以选择 Csv 或者 Json 文件中记录的数据。
以下面的请求为例，下图中的请求有2个参数path和value:

那么对应的文件格式如下：
1、Csv 文件的格式
csv 是一种以逗号为分隔符的文本文件，也可以通过 excel 编辑。Postman 支持的 csv 数据文件格式如下（顶部的 path 和 value 分别对应 Collection 请求中的变量）：

path, value
post, 1
post, 2
post, 3
post, 4

2、Json 文件格式
Json 文件大家应该都清楚，是一种类似 Js 中对象格式（熟悉 Python 的同学可以参考字典格式）。
Postman 支持的格式为一个数组，数组中的对象包含的键值对为所有的变量值：

[{
  "path": "post",
  "value": "1",
}, {
  "path": "post",
  "value": "2",
}, {
  "path": "post",
  "value": "3",
}, {
  "path": "post",
  "value": "4"
}]

注意，如果数据文件中的变量数量少于 Collection 中使用的变量数量，那么 Postman 运行时会尝试从**环境( Environment )**中取值。

文件上传后，会在 Data 选项下方出现 Data File Type 选项：

直接点击 Run 830TWS 按钮，运行整个 Collection 中所有的请求。

接下来就会依次用例，并将用例的运行情况和断言结果显示出来（我这里只运行了9个用例）：

你可以在结果中点击左边的红色方框或绿色方块，只看失败failed或者 passed 的断言。然后分析运行结果，分析时，你可以点击图中的请求名称或者运行前打开Postman Console来查看每个请求发送、接收以及断言的详细过程。
注意，这里顶部的统计数量 Failed 和 Passed 都是指断言的数量，一个请求用例可以包含多个断言，所以并不是请求用例的失败或通过数量。

三、运行结果分析
在运行过程中，总是有这样或那样的问题导致断言失败。比如网络导致请求发送不成功、变量值错误、接口本身的 Bug 等。
遇到失败的情况，我们肯定需要分析到底是不是 Bug 了。在 Collection Runner 运行后的测试结果中，可以查看运行的详细记录，以分析断言失败的原因。

通过结果日志分析
在运行的结果中，我们可以通过左侧的绿色和红色方块筛选器，筛选失败的断言。然后点击请求名称（用例名称），查看详细信息，如下图：

Request URL：请求发送的 URL，可以查看 Get / Delete 等类型的请求参数是否正确；
Request Headers：请求头部，可以查看请求中的 cookie / token 等认证信息或者 UserAgent 等头部字段的数据是否正确；
Request Body：请求数据，针对 Post / Put等类型的请求 Boby 中传递的数据是否正常，这是一个很重要的观察点；
Response Headers：响应头部，用于观察响应头部字段数据是否正确；
**Response Body：**响应数据，这是最重要的观察点，断言如果失败，大概率是因为响应数据的问题。这有可能是断言设置没有考虑到可能变化的数据，也可能是返回的数据不符合要求（Bug）。
当然这里主要记录的是响应中的数据，如果是在 Tests 或 Pre-requests 中的代码异常，这里就无法查看到了。

如果想要顺带查看代码问题，需要使用 Postman Console，也就是 Postman 的控制台，这里可以查看代码报错和使用 console.log() 函数打印的值。