当你在笔记本电脑上点击“运行”并看到 API 测试通过时，这并不能说明什么。真正重要的是那些在每次合并请求（PR）、每次合并以及每次每日构建中自动触发的测试，无需人工干预。将测试纳入这一循环的任务由命令行运行器完成。它获取你已编写的测试，在流水线中以无头模式运行，返回 CI 可读的状态码，并生成显示在构建仪表盘上的报告。

在团队搭建此类流程时，有两个运行器被反复提及：Postman CLI 和 Apifox CLI。它们的目标一致，但出发点不同。Postman CLI 运行你在 Postman 中构建的集合。Apifox CLI 运行你在 Apifox 中构建的可视化测试场景。两者都支持一键安装，都能接入 GitHub Actions、GitLab CI 和 Jenkins，并且在测试失败时都会使构建变红（报错）。真正的差异在于运行命令的上游：你如何编写测试、如何在 CI 中进行鉴权，以及测试定义实际存储的位置。

这是两者在命令层面的对比。没有刻意贬低，Postman CLI 在某些方面表现出色，在你将其投入流水线之前，你会清楚地看到每个运行器的适用场景。如果你是 Apifox 的新用户，它是一个集设计、调试、测试、mock 和文档于一体的 API 平台，而 CLI 是将你的测试带入自动化的关键环节。

• Postman CLI（二进制文件 postman）运行存储在 Postman 工作区中的集合。它基于 Newman，由 Postman 签名并提供支持，使用 Postman API 密钥进行鉴权。登录后，它会自动将运行结果发回 Postman 云端。
• Apifox CLI（apifox-cli，二进制文件 apifox）运行你在 Apifox 中可视化的测试场景。你通过访问令牌和 ID 指向某个场景，它将以无头模式执行该场景，无需 GUI。
• 两者都支持输出 JUnit、JSON、HTML 和终端报告。测试失败时都会导致构建失败。在这两种情况下，JUnit XML 都是接入 CI 仪表盘的标准格式。
• 如果你的测试已经存在于 Postman 集合中，且团队倾向于使用 Postman 云端进行报告和历史记录管理，请选择 Postman CLI。
• 如果你希望通过单一事实来源进行可视化的测试场景编写、请求编排、环境管理和数据驱动运行，并能完全控制报告是保留在本地还是上传到云端，请选择 Apifox CLI。

核心问题：存在但从未运行的测试

手动运行的测试注定会失效。有人编写了它，它通过了一次，然后就一直搁置在那里，而 API 已经发生了偏移。三个月后，测试出错了却没人发现，因为没人去运行它。解决方法不是编写更多测试，而是让现有的测试在每次变更时自动运行，并提供流水线可以识别的通过或失败信号。

CLI runner 是弥补这一差距的工具。要进入 CI 流程，它必须做到三件事：首先，必须在没有 GUI 的情况下运行，因为你的 CI runner 没有屏幕；其次，当发生失败时必须以非零状态退出，这样构建就会变红，从而阻止有问题的合并；最后，它必须生成机器可读的报告，以便评审人员无需在本地重新运行任何内容就能看到哪里出了问题。Postman CLI 和 Apifox CLI 都轻松达到了这些标准。它们的分歧点在于 run 之前发生的一切：测试是如何编写的，以及当 CI 需要它时它存放在哪里。

如果你正从头开始搭建自动化测试，那么阅读关于 CI/CD 中自动化 API 测试的更广泛模式的文章是很有价值的。在这里，我们将重点放在这两个 runner 上。

Postman CLI 的优势

首先，需要澄清一个让很多人困惑的点：Postman CLI 不是 Newman。Newman 是社区使用了多年的、基于 npm 的旧版开源 runner。Postman CLI 是一个较新的工具，它建立在 Newman 的基础之上，但由 Postman 公司签名并提供官方支持。如果你一直在运行 Newman，这两者是不能互换的，而且这种差异在 CI 中非常重要。如果你正在这两个 Postman 选项之间做抉择，我们在 Postman CLI vs Newman 中详细说明了这一区别。

Postman CLI 最大的优势在于它始终处于你团队已经熟悉的领域内。如果你的集合、环境和共享变量已经存在于 Postman 工作区中，CLI 运行它们几乎不需要任何转换。你不需要重新构建任何东西。你只需进行身份验证，指定集合名称，它就会像应用端一样准确地运行请求和测试。

安装只需一条命令。在 macOS 和 Linux 上，运行官方安装脚本：

curl -o- "https://dl-cli.pstmn.io/install/unix.sh" | sh

在 Windows 上，使用经过签名的 PowerShell 安装程序，如果你想将其固定为开发依赖项，也可以使用 npm 包：

npm install -g postman-cli

二进制文件是 postman。在 CI 中，你使用 Postman API key 进行身份验证，这是 Postman 推荐的流水线方法：

postman login --with-api-key $POSTMAN_API_KEY

然后通过 ID 运行集合，或者如果已导出，则通过本地文件路径运行：

postman collection run $POSTMAN_COLLECTION_ID -e $POSTMAN_ENV_ID

Postman CLI 赢得大量忠实用户的原因在于运行后的处理。当你登录后，它会将运行结果直接发送到 Postman 云端，并显示在你的工作区中，与集合并列。测试历史、运行对比以及团队可见的仪表盘都一应俱全，无需任何额外的衔接工作。对于已经在使用 Postman 的团队来说，这种闭环体验非常实用，也是留住用户的一个合理理由。

Apifox CLI 的优势

Apifox 在相同的流水线任务中采取了不同的路径。你可以在 Apifox 应用内可视化地构建测试：将多个请求串联成一个测试场景，在每个响应上添加断言，从一个响应中提取值并传递给下一个请求，并针对数据文件循环运行整个场景。CLI 是这些场景的无界面执行器。它没有自己的测试格式，而是直接访问你的 Apifox 项目，通过 ID 找到你指定的场景，并像应用端一样运行它，然后返回报告。

这样做的好处是无需维护同一份测试的两个副本。你在可视化编辑器中构建的场景就是 CI 中运行的测试。不需要将运行正常的测试重新编写为脚本并进行调试。快速编写循环和自动化循环共享同一个单一事实来源。对于“登录 -> 创建 -> 读取 -> 删除”这类多步骤流程，可视化串联节省了大量原本需要手动编写的胶水代码。构建这些流程的技术细节在 API 测试自动化的测试场景指南中有详细介绍。

安装只需一条 npm 命令：

npm install -g apifox-cli

二进制文件名为 apifox。典型的运行方式是通过 ID 指定场景、选择环境、设置迭代次数，并使用访问令牌进行身份验证：

apifox run --access-token $APIFOX_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r html,junit

你不需要手动输入这些 ID。在 Apifox 中打开测试场景，切换到其 CI/CD 标签页，点击生成访问令牌，Apifox 就会为你生成完整的命令，其中已经填好了场景 ID 和环境 ID。你只需复制一次，将令牌存入 CI 密钥中，并在工作流中以 $APIFOX_ACCESS_TOKEN 引用它。

“令牌加 ID”模式是与 Postman CLI 最明显的区别。Apifox 运行存储在项目中的测试，CLI 通过网络获取这些测试，并使用令牌进行验证。报告方面也没有单独的云端选项：你可以通过 --out-dir 选择本地产物，只有当你希望将概览推送到 Apifox 云端时才添加 --upload-report。报告会保存在你指定的位置。

横向对比

从上表中可以发现两个关键点。首先，两款 runner 在 CI 核心功能上几乎一致：环境选择、数据驱动迭代、四种主流报告格式，以及失败时返回非零退出码。如果你只需要一个能在合并失败时报错的 runner，两者都能胜任。其次，真正的区别在于测试的存放位置以及编写方式。Postman CLI 运行的是存储在 Postman 工作区中的集合。Apifox CLI 运行的是存储在 Apifox 项目中的可视化测试场景。

报告器和退出码：CI 实际读取的部分

一个 runner 在流水线中的价值体现在两个方面：生成的报告和返回的退出码。只要处理好这两点，剩下的只是配置问题。

Postman CLI 接受以逗号分隔的报告器列表，当你登录后，它还会将结果同步到 Postman 云端：

postman collection run $POSTMAN_COLLECTION_ID -e $POSTMAN_ENV_ID --reporters cli,junit --bail

junit 报告器会被你的 CI 仪表盘解析为通过或失败的树状结构。--bail 标志会在遇到第一个失败的请求、测试或断言时停止运行，这在冒烟测试中能实现快速反馈。去掉 --bail 则会运行所有内容，最后统一报告所有失败项。CLI 在任何失败时都会返回非零退出码，因此构建会自动变红。

Apifox CLI 使用相同的 -r 报告器概念，并将所有内容写入同一个输出目录：

apifox run --access-token $APIFOXACCESSTOKEN -t 605067 -r html,junit --out-dir ./apifox-reports

其 --on-error 标志决定了测试场景运行中的行为：end 是默认值，在第一次失败时停止；continue 会运行所有步骤，以便在单份报告中收集所有失败项；ignore 则会跳过已知的异常步骤，而不影响整体运行。无论哪种方式，只要有失败项，进程就会以非零状态结束，JUnit XML 文件会生成在 ./apifox-reports 目录中，方便你的仪表盘读取。

实际效果是：两者都会生成 JUnit XML，都能正确地导致构建失败，并且都会归档一个供以后查看的 HTML 报告。报告方面的区别在于云端往返。Postman 在经过身份验证后，默认会将结果推送到其云端。而 Apifox 除非你要求上传，否则会将报告保留在本地。从抽象角度看，两者并没有优劣之分；一个适合想要自动托管历史记录而无需多加思考的团队，另一个则适合想要精确决定哪些数据离开 runner 的团队。

将两者集成到 GitHub Actions 中

两者的 GitHub Actions 任务结构是相同的：检出仓库、设置 Node、安装 CLI、运行测试，失败的退出代码会阻止合并。请将 secret 存储在仓库设置中，绝不要直接放在工作流文件中。

以下是 Postman CLI 版本：

- name: Run API tests (Postman CLI)run: |curl -o- "https://dl-cli.pstmn.io/install/unix.sh" | shpostman login --with-api-key ${{ secrets.POSTMAN_API_KEY }}postman collection run $POSTMAN_COLLECTION_ID -e $POSTMAN_ENV_ID --reporters cli,junit --bail

以及 Apifox CLI 版本：

- name: Run API tests (Apifox CLI)run: |npm install -g apifox-cliapifox run --access-token ${{ secrets.APIFOX_ACCESS_TOKEN }} -t 605067 -e 1629989 -r cli,junit

两者都很简洁、易读，并且在流水线关注的层面上表现一致：运行通过则以零（zero）退出并允许合并，运行失败则以非零（non-zero）退出并阻止合并。如果你想深入了解如何在 GitHub 工作流中运行 API 测试，使用 GitHub Actions 实现 API 测试自动化 提供了分步指导。对于 Jenkins 用户，将 Apifox 自动化测试集成到 Jenkins 中阐述了相同的思路。

那么，谁才是 CI 中的赢家？

没有唯一的赢家，因为正确的答案取决于你的测试目前存放在哪里，以及你的团队希望如何编写和存储它们。

如果你看重可视化编写和单一事实来源，而非云端托管历史记录，那么 Apifox CLI 胜出。你在可视化编辑器中构建一次测试场景，请求链和断言都会为你处理好，然后 CI 通过引用运行同一个场景。你可以决定报告是保留在本地还是上传。由于 Apifox 在同一个工作空间内涵盖了设计、mock 和文档，测试场景紧贴其校验的 API 契约，这防止了测试与规范脱节。想要更全面权衡这两个平台的团队可以阅读完整的 Apifox vs Postman 对比。

如果你的团队已经在使用 Postman，那么 Postman CLI 胜出。你的集合在那里，你的环境也在那里，并且你希望在无需任何设置的情况下在 Postman 云端查看运行历史。每次运行时的云端往返对于这种配置来说非常方便，而且该工具经过官方签名并提供支持。如果这符合你团队的情况，更换 runner 几乎带不来什么收益。

如果你已经对 Postman 的云端模型感到束缚，或者只是想编写一次测试并在任何地方运行，那么选择已经很明确了。下载 Apifox，创建一个测试场景，打开其 CI/CD 标签页，然后将生成的 apifox run 命令复制到你的流水线中。这就是全部设置。

FAQ

Postman CLI 与 Newman 是一回事吗？ 不是。Newman 是较早的开源 npm runner。Postman CLI 是基于 Newman 基础构建的新工具，由 Postman 签名并支持，内置了向 Postman 云端发送报告的功能。如果你在 Postman 侧这两者之间做选择，“Postman CLI vs Newman” 详细说明了它们的区别。

在 CI 中使用这两个 CLI 是否需要账号或 Token？ 是的，两者都需要，但形式不同。Postman CLI 通过 postman login --with-api-key 使用 Postman API key 进行身份验证。Apifox CLI 则使用通过 --access-token 传递的访问令牌进行身份验证。请将这两者都存储为 CI 密钥，切勿直接放在工作流文件中。

当测试失败时，这两个 runner 都会导致构建失败吗？ 是的。如果任何测试或断言失败，两者都会以非零状态码退出，这会告知你的 CI 系统将构建标红并阻断合并。Postman CLI 使用 --bail 在第一次失败时停止；Apifox CLI 使用 --on-error end，这是其默认设置。

我可以将报告保留在本地而不是发送到云端吗？ Apifox CLI 默认将报告保留在本地并写入 --out-dir；只有使用 --upload-report 时才会上传。Postman CLI 也会写入本地报告，但当你登录后，它会自动将运行结果发送到 Postman 云端。

如何获取我测试场景的确切 Apifox 运行命令？ 在 Apifox 中打开测试场景，切换到其 CI/CD 标签页，生成访问令牌，Apifox 就会构建完整的 apifox run 命令，其中已经填好了测试场景 ID 和环境 ID。复制它，将 Token 移入 CI 密钥，大功告成。如需查看所有可用参数，请运行 apifox run --help。

正在从 Postman 云端迁移的团队应该选择哪一个？ 如果你离开的原因是以云端为中心的模型或定价问题，那么 Apifox CLI 非常适合，因为它运行项目中的单个可视化测试场景，并允许你决定哪些数据离开 runner。可以先从 Apifox vs Postman 的对比开始，了解这两个平台在 runner 之外的对标情况。

开发必备：API 全流程管理神器 Apifox

介绍完上文的内容，我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具，Apifox 是目前提升研发效率的首选。

如果你正在开发项目，不妨试试其极其友好的界面设计，它完全兼容 Postman 和 Swagger 数据格式，导入数据非常方便，，即使是新手也能很快上手，点击这里即可注册使用。

值得一提的是，除了个人和常规团队使用，针对有高安全合规要求、或需要在内网环境协作的企业，Apifox 还提供了深度定制的私有化部署方案。