Postman—构建工作流

前言

在使用“Collection Runner”的时候，集合中的请求执行顺序就是请求在Collection中的显示排列顺序。但是，有的时候我们不希望请求按照这样的方式去执行，可能是执行完第一个请求，再去执行第五个请求，然后再去执行第二个请求这样的方式；那么在“Collection Runner”中如何去构建不同的执行顺序呢？这篇文章将总结如何在Postman中构建不同的工作流。为了配合完成这篇文章的讲解，需要下面的集合文件，并在Postman中完成导入。点击下载进行下载示例文件。

基础用法

当我们开始运行“Collection Runner”时，所有请求都会按照我们在主应用中看到的顺序进行运行。这意味着内部的所有请求都会首先按它们所在文件夹的顺序执行，然后执行集合根目录中的所有请求。但是，我们可以使用名为setNextRequest()的内置函数来覆盖此行为。

顾名思义，setNextRequest()将允许我们指定接下来要运行的请求。

结合上面提供的测试集合数据，导入以后，我们会发现测试集合中有四个请求。在第一个请求的“Tests”标签页中包含以下代码：

// Some code here

postman.setNextRequest('Request 4')

// Some code here

postman.setNextRequest()是一个带有一个参数的函数，它是接下来要运行的请求的名称或ID。在这个例子中，我们正在请求1的测试脚本中将请求4设置为下一个请求。这意味着请求1完成后，执行将跳转到请求4。如果我们现在运行相同的集合，将会看到只有两个请求现在运行。如下图所示：

请注意，setNextRequest()仅适用于“Collection Runner”和Newman，其目的是运行集合，而不是发送单个请求。

高级用法

现在我们对setNextRequest()的工作原理有了一定的理解，我们可以用它做一些更加高级的工作。由于不再受限于定义请求的顺序，因此我们可以在集合内部来回跳转请求，建立条件逻辑或跳过不必要的请求。但是，有一些需要我们注意的问题：

• setNextRequest()总是在当前脚本所有语句执行完成后才执行。这意味着如果在其他代码块之前放置setNextRequest()请求，这些代码仍然会被执行；
• setNextRequest()有一个作用域，它是集合运行的源。这意味着如果我们运行一个集合，我们可以跳转到集合中的任何请求（即使是使用相同语法的文件夹内的请求）。但是，如果运行文件夹，则setNextRequest()的作用域限于该文件夹；也就是说我们可以跳转到该文件夹内的任何请求，但不能跳转到文件夹外的任何请求。这包括其他文件夹内的请求以及集合中的根级别请求。

参考：https://www.jellythink.com/archives/189