Apifox CLI对比Postman CLI：更优CI测试运行器

在本地环境点击“运行”并看到API测试通过，实际上并不能说明问题。真正关键的是——每次提交合并请求、每次合并代码、每次日常构建，测试都能自动触发，无需任何人手动点击。而将测试嵌入这个自动化流程的核心工具，正是命令行运行器。它负责获取你编写的测试，在流水线中以无头模式执行，返回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 指向某个场景，它就能以无头模式执行，无需图形界面。
• 两者都支持输出 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 是社区使用多年的旧版开源 runner，基于 npm。Postman CLI 是一个较新的工具，构建在 Newman 的基础之上，但由 Postman 公司签名并提供官方支持。如果你一直在使用 Newman，这两者不能互换，而且在 CI 中这个差异很重要。如果你正好在这两个 Postman 选项之间做抉择，我们在另一篇文章中详细说明了 Postman CLI 与 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 $APIFOX_ACCESS_TOKEN -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" | sh
  postman 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-cli
  apifox run --access-token ${{ secrets.APIFOX_ACCESS_TOKEN }} -t 605067 -e 1629989 -r cli,junit

两者都很简洁、易读，并且在流水线关注的层面上表现一致：运行通过则以零退出并允许合并，运行失败则以非零退出并阻止合并。如果你想深入了解如何在 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 之外的对标情况。