[!info] related notes

• 所属 MOC: postman-moc, CI/CD MOC, Testing MOC
• 前置概念: postman-scripts-tests-and-runner
• 相关概念: 发布与运行期验证
• 相关资源: postman

Postman CLI 与 Monitors

范围

这篇笔记聚焦 Postman 的执行自动化层：如何从 collection runner 走向 CLI 和持续监控。

为什么要放在一起理解

如果只在本地手动跑 collection，Postman 仍然只是个人工具。

它真正进入团队工程链路，是通过：

• Postman CLI 接入 terminal 和 CI/CD
• Monitors 在云端定时跑关键流程

依赖路径 / 调用链 / 演进链

1. 本地批量执行

起点是 collection runner，用于手动批跑。

2. CLI 接 CI/CD

当 collection 需要进入发布流程时，CLI 的作用是：

• 在命令行运行 collection
• 给 CI/CD 返回明确 exit code
• 在测试失败时阻止合并或发布

3. Monitors 做持续观测

Monitors 的作用不是“发布前验证”，而是“发布后持续检查”。

它更适合：

• uptime 检查
• latency 观察
• 核心业务流程定时回放
• 多地区 synthetic checks

对比与易混淆点

Runner vs CLI

• Runner：本地批量执行
• CLI：自动化流水线执行

CLI vs Monitor

• CLI：常用于发布前 / 合并前
• Monitor：常用于发布后 / 线上持续观测

Monitors 不等于全量可观测平台

它更接近 API synthetic monitoring，而不是完整的日志、metrics、trace 平台。