Postman Collection Runner 设置请求间隔与迭代节流方法

如果 Collection Runner 连续发送请求过快，可以直接在运行配置里的 Delay 设置每个请求前的等待毫秒数。比如把 Iterations 设为 2、Delay 设为 500 ms，Runner 会按 collection 中的请求顺序执行，并在每次请求前加入半秒间隔；新增等待时间还要加上接口响应和脚本耗时。

官方地址：https://www.postman.com/

Postman Collection Runner 的 Delay 控制什么

打开 Collection Runner 后，Run configuration 通常会看到 Iterations、Delay 和 Iteration data。这里的 Delay 单位是毫秒，含义是每个请求发送前的固定等待。它改变的是 Runner 的发送节奏，不会修改接口本身，也不会把一个 collection 变成并发执行器。

图中的界面是根据上述字段绘制的原创操作示意图，用来说明入口和字段关系，不是 Postman 实际截图。

从 Runner 入口设置请求前的间隔

1. 打开运行入口：进入 Collections，选中目标 collection，点击右侧 Run；也可以从底部工具区打开 Runner，把 collection 拖入运行区域。
2. 确认运行范围：在 Run type 中选择 Functional 和 Local，核对中间的请求列表。只保留本次需要的请求，必要时用拖动调整顺序。
3. 填写节流参数：在 Run configuration 中将 Iterations 填为 2，将 Delay 填为 500 ms。若没有数据文件驱动需求，Iteration data 保持空白即可。
4. 检查可见状态：点击 Start run 前，确认 Delay 字段仍显示 500 ms，迭代次数为 2，且请求列表没有误选其他文件夹。

这一步的关键是把 Delay 放在 Runner 的运行配置里，而不是把等待逻辑误写进环境变量。若只想控制顺序、不想增加等待，Delay 应保持 0；若希望每个请求都错开，才设置正数。

用请求数和迭代次数估算节流后的运行时间

假设 collection 有 3 个请求，运行 2 轮，Delay 为 500 ms，可以先用 3 × 2 × 500 ms = 3000 ms 估算固定等待。实际总时间还包括 6 次请求的网络响应、前置脚本和测试脚本，因此这个结果只是节流新增时间的估算，不是完整运行时长。

Runner 的 Delay 是请求级设置，所以不要只用“迭代次数减一”去计算。另一个边界也很重要：如果同时启动多个 collection run，单个 Runner 的等待不会替其他 Runner 排队；需要全局限流时，应在测试调度层统一控制并发。

运行后核对结果与常见坑

1. 点击 Start run，等待 Run results 出现。
2. 展开 Iteration 1 和 Iteration 2，按请求名称核对执行顺序与通过、失败状态。
3. 如果结果明显快于预期，先回到运行配置检查 Delay 是否被清空或改成 0，再确认是否启动了另一个没有节流的 Runner。

可见的完成状态只能说明这次运行结束，不能证明接口具备稳定吞吐能力。Delay 适合给功能回归、演示和轻量批处理留出间隔；不适合拿来替代并发压测、服务端限流或生产流量治理。

相关问题

Delay 是每轮之间等待一次吗？

不是。它按请求配置等待，估算时应把请求数和迭代次数都纳入；实际耗时还要加网络和脚本时间。

把 Delay 调大就能做接口限流吗？

只能控制单个 Runner 的发送节奏。多个运行实例、其他客户端和服务端并发仍需单独治理。

为什么结果运行时间没有精确等于估算值？

估算只计算固定等待，接口响应、重定向、前置脚本和测试脚本都会让总时间变长。