【接口测试实战(八)】postman之Collections和数据驱动测试实战

前情：

《【接口测试实战(零)】接口测试简介》

《【接口测试实战(一)】搭建接口测试环境》

《【接口测试实战(二)】根据接口文档使用postman测试》

《【接口测试实战(三)】接口测试用例的编写》

《【接口测试实战(四)】根据接口测试用例进行测试》

《【接口测试实战(五)】接口测试之断言实战》

《【接口测试实战(六)】接口测试之sandbox(沙盒)》

《【接口测试实战(七)】postman之变量与沙盒实战》

---

---

1）Postman测试集（Collections）

官方介绍：
“The Collection Runner allows you to run sets of requests in a specified sequence. The Collection Runner will log your request test results, and your scripts can pass data between requests as well as altering the request workflow.”

• Collection Runner 允许您以指定的顺序运行一组请求。Collection Runner 将记录您的请求测试结果，您的脚本可以在请求之间传递数据以及更改请求工作流程。

为了更方便地管理接口请求的执行，可以通过postman测试集（Collections）来完成测试的管理和操作。

• 每一个测试请求可以看作一个测试用例（testcase），通过save可以将请求保存到Collections中使用。
• Collections可以一次管理多个测试用例来执行。

下面根据实战来了解Collections常用的功能和使用流程。

2）实战：学生管理系统的学院信息接口

学生管理系统的介绍和使用可参考《【接口测试实战(一)】搭建接口测试环境》

2.1 测试用例设计以及编写断言

先用简单的几个用例来做试验（按执行顺序）：

1. 查询所有学院的信息，无学院信息（假设一开始是空表）：

   断言：
   

2. 新增一个学院的信息，新增成功：

   新增成功的返回应该是：

   {
       "already_exist": {
           "count": 0,
           "results": []
       },
       "create_success": {
           "count": 1,
           "results": [
               {
                   "dep_id": "API001",
                   "dep_name": "学院API001",
                   "master_name": "教授API001",
                   "slogan": "S-API001"
               }
           ]
       }
   }
   

   所以断言写为：
   

3. 修改该新增学院的信息，修改成功：

   修改成功后，会返回修改以后的学院信息：

   {
       "dep_id": "API001",
       "dep_name": "学院API-M001",
       "master_name": "教授API-M001",
       "slogan": "S-API-M001"
   }
   

   断言与步骤2的类似。

4. 删除该学院的信息，删除成功：

   

2.2 Collections管理测试用例

1、创建Collections，将上述请求添加到该Collections中：

• Collection精细化（Folder）：在collection中就可以添加Folder了，将相同场景的请求放入同一个Folder中，于是就实现了模块化的管理了。

2、运行Collections

将工程模块化的用例管理起来后，可以将工程模块化的用例执行起来，即一次执行一整个collection里的用例，或者执行一个collection里的某一个Folder里的用例。

运行参数：

• 点击Run collections，可以选择测试哪些用例，并且调整执行顺序。
• Iterations：即重复运行次数，会将选择好的collection中folder重复运行。
• Delay：间隔时间，用例与用例间的间隔时间。
• Data：外部数据加载，即用例的参数化，可以与Iterations结合起来用，实现参数化，也就是数据驱动。
• 如果不勾选save responses，则在结果中是不会记录reponse。

查看结果：

• 勾选save responses：

  

• 不勾选save responses：
  

3）数据（data）驱动测试

• 什么是数据驱动测试？

  数据驱动测试是一种在软件测试过程中使用的方法，用于描述直接测试的输入、可验证输出的条件表，以及测试环境的设置还有控制编码的过程。

  • 数据驱动：测试流程固定或不变，输入不同的参数或值，输出不同的测试结果，进行校验。

• 为什么需要数据驱动测试？

  在我们测试过程中往往需要测试我们场景更加的充分，而创建数据测试。

  • 测试数据包括输入输出，对输出的自动化验证等。
  • 减少了冗余和不必要的测试脚本
  • 用较少的代码生成测试脚本
  • 所有信息，如输入、输出和预期结果，都以适当的文本记录形式进行存储
  • 如果功能发生了变化，只需要调整特定的函数脚本就足够了

3.1 Postman数据驱动

当需要进行数据驱动方式运行多次Postman脚本时，可以通过csv或json格式的文件对接口测试数据进行管理，以方便用例管理执行。

• 在Iterations重复运行时，如果某个用例希望每次运行时，使用不同的数据，那么应该满足如下2个条件：
  • 脚本中要用到数据的地方参数化：接口请求中参数使用变量名获取，每次运行时重新获取当前的运行数据。
  • 需要有一个数据池：创建数据文件时使用这些变量名编辑测试数据。
  • 在测试沙箱中，参数的获取用data.参数名来读取。

Postman的runner提供了Iterations的输入项，也提供了Data的文件选择项，也就是意味着数据池是一个外部文件。

• Data数据文件常用格式：json、csv、txt三种格式。

3.2 实战：七日天气接口的数据驱动测试

1、将用到数据的地方参数化

• 每次Iterations测试不同的city，因此将city的输入参数化。
• 其实environment选择可不管，因为如果在两个不同的作用域中声明了同名的变量，则将使用作用域最窄的变量中存储的值，即优先级是Local>Data>Environment>Collection>Global（参考自官方文档）。
• 断言中用data.cityname，其中data是个内置对象，即代表每一次运行的那个map数据。
  • 可以用data.cityname来获取每次运行的对应的值。
  • 当然，由于是个map，也可以用data[‘cityname’]来获取对应的值。

断言部分跟 Postman 隔离开的，在断言部分不能直接获取 Postman中的变量值，运行是会提示变量未定义，此时需要使用pm.environment.get(“变量”)、pm.globals.get(“变量”)、data[“变量”]来获取postman里面的变量值。

2、创建数据池

新建一个excel表格，另存为csv格式（因为Data数据只支持csv、json和txt）：

• 注意：postman支持的是UTF-8格式，而excel保存的文件编码可能为gbk等等，需要转换一下csv的编码格式：
  • 方法1：保存时，选csv格式，然后在工具>Web选项>编码中选择UTF-8。（但是实际操作发现好像格式还是不太对）
  • 方法2：将csv格式用notepad++打开，然后在编码中选择转为UTF-8编码，并保存即可。

如果编码格式不对，在preview导入的数据时会出现如下情况：

3、选择Data文件并执行测试

• 当选择了csv文件后，系统会自动根据数据数量来填写Iterations。
  • 做了个实验，当数字写小了，就是只测前面的用例，写大了是最后一个重复多次测试：
    

最后的结果：

---

【部分内容参考自】

• postman logoLearning Center：https://learning.postman.com/docs/
• 数据驱动测试概念？：https://www.cnblogs.com/testertechnology/p/10981228.html
• Postman接口测试之管理用例Collections：https://www.jianshu.com/p/1455c397389c