大多数 API 测试教程都会引导你使用 GUI。

但如果你习惯于在终端中工作、在 CI 中运行测试，或者想要一个能阅读其源码的工具，那么命令行才是 API 测试真正有趣的地方。

开源 CLI 工具能提供托管产品无法给予的东西：可供审计的开源协议、可自托管的二进制文件，以及可以随代码一同提交的配置文件。

这与“哪个工具最快”或“哪个二进制文件最小”不是同一个问题。

这里的核心关注点是许可证与控制权。

你能在不需要注册账号的情况下在局域网内运行它吗？它的源码是否托管在 GitHub 上并使用真正通过 OSI 认证的开源协议？如果供应商在下个季度调整价格，它还能继续工作吗？这篇清单将为你解答这些问题。

以下是 8 款用于测试 REST、GraphQL 和 HTTP API 的免费、源码可用的 CLI 工具。

每款工具都附带了具体的开源协议、真实的安装命令以及一个演示其工作原理的命令。

如果你想看包含托管工具在内的更广泛的评测，请参阅“最佳免费 API 测试工具综述”。如果只想寻找完全基于终端的手动调用接口方案，可以阅读“用于 REST API 测试的 curl 替代方案”指南，其中涵盖了交互式操作部分。

什么是适用于 API 测试的“开源” CLI 工具

许多工具都可以免费下载，但这并不等同于开源。

对于本清单，符合以下三点的工具才算合格：

• 真实的开源协议。 源码公开并采用经 OSI 批准的开源协议（MIT、Apache-2.0、MPL-2.0、AGPL-3.0、BSD）。你可以阅读源码、派生（fork）项目，并清楚地知道自己被允许做什么。
• 可自托管，无需账号。 你可以在自己的本地机器或 CI 运行器上独立运行整个工具，无需注册任何账号。没有席位费用，也没有向外发送数据的“回传”要求。
• 持续维护且可审查。 仓库托管在 GitHub 上，拥有可见的提交历史和 Issue 记录，这样你就可以在基于它构建流水线之前，评估它是否仍然活跃。

下面列出的所有工具都符合前两点。

对于不再符合第三点的工具，我已经进行了标记。

协议的选择比看起来更重要：如果你围绕它构建服务，AGPL-3.0（如 k6）会带来传染性（copyleft）义务，而 MIT 和 Apache-2.0 则更为宽松。

在将工具嵌入到产品中之前，请务必仔细阅读其开源协议。

Hurl：纯文本 HTTP 测试，单个 Rust 二进制文件

Hurl 可以运行以纯文本格式编写的 HTTP 请求，并对响应进行断言。

它由 Orange-OpenSource 使用 Rust 构建，底层由 libcurl 驱动，并以单个二进制文件形式分发。

测试文件的可读性极强，几乎与请求本身无异，这使得它们在拉取请求（pull request）中非常容易被评审。

开源协议：Apache-2.0。源码：github.com/Orange-OpenSource/hurl。

brew install hurl # or: cargo install --locked hurl# login.hurlcat > login.hurl <<'EOF'POST https://api.example.com/login{ "user": "acme", "pass": "s3cret" }HTTP 200[Asserts]jsonpath "$.token" existsEOFhurl --test login.hurl

最适合：希望以可读文本形式保留在版本控制中的契约式校验和冒烟测试。

坦白的限制：它专注于 HTTP，因此不支持 gRPC，也无法生成负载。

对于除了简单断言链之外的任何复杂场景，你只能编写更多的 .hurl 文件，而无法使用脚本语言。

Step CI：专为 CI 构建的 YAML API 工作流

Step CI 是一款专为持续集成设计的、基于 YAML 配置的工作流运行器。

它可以在单个工作流文件中支持 REST、GraphQL、gRPC、tRPC 和 SOAP，并能针对 OpenAPI 数据模型进行负载测试和校验。

该运行器和 CLI 永久免费。

开源协议：MPL-2.0。源码：github.com/stepci/stepci。

npm install -g stepciworkflow.yml describes steps, checks, and capturesstepci run workflow.yml

这类工具尤其适合这样的团队：希望用一个声明式文件把多步骤 API 流程一次性描述清楚，而且无论是在本地环境还是 CI 环境里，都能用同一套方式稳定运行。

需要提前说明的一点是，MPL-2.0 属于弱传染性（weak copyleft）开源协议。

换句话说，如果修改的是 Step CI 自身的文件，那么这些改动需要公开；但如果只是用它来测试自己的应用程序，就不受这一条限制。

Schemathesis：基于数据模型的属性测试

Schemathesis 会读取你的 OpenAPI 或 GraphQL 数据模型，并基于 Python 的 Hypothesis 库，通过属性测试生成数千个测试用例。

你不需要手动编写每个测试用例，它会对输入进行模糊测试（fuzzing）以发现 500 错误、数据模型违规以及与接口文档承诺不符的响应。

开源协议：MIT。源码：github.com/schemathesis/schemathesis。

uv pip install schemathesis # or: pip install schemathesisschemathesis run https://api.example.com/openapi.json

最适合：捕获你根本想不到去编写测试的边缘案例 Bug，尤其是在发布前。

这也是保持准确数据模型的最强有力理由之一。

坦白的限制：它需要真实的数据模型才能工作，而且大型 API 可能会产生大量的噪音，你需要使用其钩子（hooks）和选项来进行过滤。

Dredd：针对 API 描述的契约测试

Dredd 用于校验你的实际 API 是否与它的描述文档相匹配。

将其指向 OpenAPI（或 API Blueprint）文件和正在运行的后端，它就会回放文档中记录的每个请求，并将实际响应与规范进行对比。

它与语言无关，并支持用于初始化（setup）和清理（teardown）的钩子（hooks）。

开源协议：MIT。源码：github.com/apiaryio/dredd。

npm install -g dredddredd apiary.apib http://127.0.0.1:3000

最适合：证明你的接口文档与实际实现没有发生偏差（未漂移）。

坦白的限制（而且这是个大问题）：Dredd 的代码仓库已于 2024 年 11 月归档，目前处于只读状态。

它仍然可以运行，但已不再维护，因此请将其视为一个没有未来修复的稳定工具。

如果你需要一个处于活跃维护状态的数据模型驱动校验器，Schemathesis 是更安全的选择。

k6：用 Ja vaScript 编写脚本的负载测试

k6 是 Grafana 的负载与性能测试工具。

你可以使用 Ja vaScript 或 TypeScript 编写测试脚本，并通过高效的 Go 引擎大规模驱动它们。

当你需要了解 API 在数百或数千个虚拟用户下的表现，而不仅是单个请求是否通过时，它是首选的开源方案。

许可证：AGPL-3.0。源码：github.com/grafana/k6。

brew install k6k6 new script.js # generates a starter test k6 run script.js

最适合：与功能测试放在同一个代码仓库中的性能测试和浸泡测试（soak testing）。

坦率的限制：AGPL-3.0 具有很强的传染性（strong copyleft）。

这对于运行测试没有影响，但如果你围绕 k6 的代码构建并分发服务，该许可证会带来实质性的义务；请务必先仔细阅读。

此外，k6 专注于负载，而非细粒度的契约断言。

Newman：无需 GUI 即可运行 Postman 集合

Newman 是 Postman 官方提供的命令行集合运行器。

如果你的团队已经将 API 请求和测试保存为 Postman 集合，Newman 可以直接在终端或 CI 中运行该集合，无需桌面版应用。

这是将 Postman 工作流集成到流水线（pipeline）中的标准方式。

许可证：Apache-2.0。源码：github.com/postmanlabs/newman。

npm install -g newmannewman run my-collection.json -e staging-environment.json

最适合：已有 Postman 集合并希望在 CI 中运行，且不想为额外的 Postman 席位付费的团队。

坦率的限制：它与 Postman 集合格式紧密绑定，因此你必须在 Postman 的 UI（或其 JSON 文件）中编写测试，而不是在纯文本配置文件中。

它只负责运行集合，无法用于 API 的设计或 mock。

Ta vern：作为 pytest 插件的 API 测试工具

Ta vern 是一个 Python 库、命令行工具（CLI）以及 pytest 插件，它使用 YAML 来描述 API 测试。

由于它无缝集成到了 pytest 中，你可以免费获得整个 pytest 生态系统的支持：包括 fixtures、报告生成、并行运行以及你可能已经在使用中的 CI 集成。

它支持 REST、MQTT 和 gRPC。

许可证：MIT。源码：github.com/ta verntesting/ta vern。

pip install ta verntest_login.ta vern.yaml sits next to your other testspytest test_login.ta vern.yaml

它尤其适合这样一类团队：已经在用 pytest，并且希望把 API 测试和单元测试统一放在同一套体系里管理的 Python 团队。

现实一点说，它也有门槛——默认你已经熟悉 Python 测试环境的配置方式。

要是技术栈本身并不是 Python，那么对 pytest 的依赖往往就不再是优势，反而更像一种额外负担。

Venom：来自 OVHcloud 的多执行器集成测试工具

Venom 来自 OVHcloud，可在多种执行器类型中运行集成测试：例如 HTTP 请求、Shell 脚本、IMAP、Web、数据库等。

它使用 Go 语言编写，采用 YAML 测试套件，并能生成 CI 系统可以直接读取的 xUnit 结果文件。

当单个测试不仅需要调用 HTTP 接口，还需要与多种其他服务进行交互时，它会非常实用。

许可证：BSD（修改版）。源码：github.com/ovh/venom。

从 GitHub releases 下载二进制文件，然后运行：

venom run testsuite.yml

最适合：在一个测试套件中混合了 API 调用、数据库检查或脚本步骤的端到端流程。

坦诚的局限：由于执行器（executors）太多，YAML 会变得很冗长，而且文档假定你会自己拼凑仓库中的示例。

Apifox 的定位（以及一个坦诚的说明）

坦诚地讲，Apifox 不是开源的。

它是一款提供免费额度的商业产品，因此并不属于源码可用（source-a vailable）工具之列。

但它依然值得了解，原因在于：上述工具各自只做一件事，而要将 Hurl、Schemathesis、Newman 加上 mock 服务端缝合进一个连贯的工作流中，需要你自己去维护，这是一项实打实的工作。

Apifox 将设计、测试、mock 和文档融入到了同一个平台中，而 apifox-cli 则将测试端带到了终端。

你只需编写一次测试场景，然后就可以通过单条命令在 CI 中运行它们：

npm install -g apifox-cliapifox login --with-token apifox run --access-token # 全部通过时退出状态码为 0，失败时为非 0

输出是带有 agentHints.nextSteps 的结构化 JSON，这使得它很容易通过脚本进行处理或交给 AI 智能体（Agent）。

完整的 apifox-cli 指南详细介绍了完整的命令集。

所以：虽然不是开源的，但其免费额度加上 CLI 为你提供了一个集成化的替代方案，省去了将多个单一用途工具拼凑在一起的麻烦。

如果你硬性要求必须使用可审计的许可证，请从上述八款工具中进行选择。如果集成化的工作流对你更重要，这就是折中之选。

如何选择

可以按具体工作来选工具：

• 需要快速、可读性强的请求校验：Hurl 或 Newman
• 拥有数据模型并希望自动发现 Bug：Schemathesis
• 面临规模与并发挑战：k6
• 测试需要融入更大的测试套件：Ta vern 或 Venom

工具	最适合	安装	是否开源？	许可证
Hurl	Git 中的纯文本 HTTP 断言	brew install hurl	是	Apache-2.0
Step CI	声明式 CI 工作流	npm i -g stepci	是	MPL-2.0
Schemathesis	基于数据模型的属性模糊测试（Fuzzing）	pip install schemathesis	是	MIT
Dredd	文档与实现对比的契约测试	npm i -g dredd	是（已归档）	MIT
k6	负载与性能测试	brew install k6	是	AGPL-3.0
Newman	在 CI 中运行 Postman 集合	npm i -g newman	是	Apache-2.0
Ta vern	pytest 中的 API 测试	pip install ta vern	是	MIT
Venom	多执行器集成测试套件	GitHub releases	是	BSD
apifox-cli	一体化的“从设计到测试”工作流	npm i -g apifox-cli	否（有免费额度）	商业授权

如果你正在将这些工具与更庞大的流程进行权衡，API 测试策略指南介绍了每种类型适用的场景，而无头（headless）API 测试工具一文则探讨了在完全没有 UI 的情况下运行测试。

总结

开源 CLI 工具让您可以完全自主地阅读、fork 并运行 API 测试。

Hurl 和 Newman 可以处理日常的请求校验，Schemathesis 和 Dredd 负责强制执行您的契约，k6 专注于性能，而 Ta vern 和 Venom 则能将 API 测试融入更广泛的套件中。

您可以根据许可证和您需要完成的具体工作来选择工具；同时运行其中两个也完全可行。

如果您希望在同一个地方进行设计、测试、mock 和撰写文档，而不是去维护一个工具链，Apifox 覆盖了全生命周期，并提供了用于 CI 的 apifox-cli。

下载 Apifox 体验该 CLI 并与上述工具结合使用，看看哪种组合最适合您的流水线。

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

介绍完上文的内容，我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。

作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具，Apifox 是目前提升研发效率的首选。

如果你正在开发项目，不妨试试其极其友好的界面设计。

它完全兼容 Postman 和 Swagger 数据格式，导入数据非常方便，，即使是新手也能很快上手，点击这里即可注册使用。

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