大多数 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.hurl
cat > login.hurl <<'EOF'
POST https://api.example.com/login
{ "user": "acme", "pass": "s3cret" }
HTTP 200
[Asserts]
jsonpath "$.token" exists
EOF
hurl --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 stepci
workflow.yml describes steps, checks, and captures
stepci 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 schemathesis
schemathesis 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 dredd
dredd apiary.apib http://127.0.0.1:3000最适合:证明你的接口文档与实际实现没有发生偏差(未漂移)。坦白的限制(而且这是个大问题):Dredd 的代码仓库已于 2024 年 11 月归档,目前处于只读状态。它仍然可以运行,但已不再维护,因此请将其视为一个没有未来修复的稳定工具。如果你需要一个处于活跃维护状态的数据模型驱动校验器,Schemathesis 是更安全的选择。
k6:用 JavaScript 编写脚本的负载测试
k6 是 Grafana 的负载与性能测试工具。你可以使用 JavaScript 或 TypeScript 编写测试脚本,并通过高效的 Go 引擎大规模驱动它们。当你需要了解 API 在数百或数千个虚拟用户下的表现,而不仅是单个请求是否通过时,它是首选的开源方案。
许可证:AGPL-3.0。源码:github.com/grafana/k6。
brew install k6
k6 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 newman
newman run my-collection.json -e staging-environment.json
最适合:已有 Postman 集合并希望在 CI 中运行,且不想为额外的 Postman 席位付费的团队。坦率的限制:它与 Postman 集合格式紧密绑定,因此你必须在 Postman 的 UI(或其 JSON 文件)中编写测试,而不是在纯文本配置文件中。它只负责运行集合,无法用于 API 的设计或 mock。
Tavern:作为 pytest 插件的 API 测试工具
Tavern 是一个 Python 库、命令行工具(CLI)以及 pytest 插件,它使用 YAML 来描述 API 测试。由于它无缝集成到了 pytest 中,你可以免费获得整个 pytest 生态系统的支持:包括 fixtures、报告生成、并行运行以及你可能已经在使用中的 CI 集成。它支持 REST、MQTT 和 gRPC。
许可证:MIT。源码:github.com/taverntesting/tavern。
pip install tavern
test_login.tavern.yaml sits next to your other tests
pytest test_login.tavern.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-available)工具之列。但它依然值得了解,原因在于:上述工具各自只做一件事,而要将 Hurl、Schemathesis、Newman 加上 mock 服务端缝合进一个连贯的工作流中,需要你自己去维护,这是一项实打实的工作。
Apifox 将设计、测试、mock 和文档融入到了同一个平台中,而 apifox-cli 则将测试端带到了终端。你只需编写一次测试场景,然后就可以通过单条命令在 CI 中运行它们:
npm install -g apifox-cli
apifox login --with-token <YOUR_TOKEN>
apifox run --access-token <TOKEN> # 全部通过时退出状态码为 0,失败时为非 0
输出是带有 agentHints.nextSteps 的结构化 JSON,这使得它很容易通过脚本进行处理或交给 AI 智能体(Agent)。完整的 apifox-cli 指南详细介绍了完整的命令集。所以:虽然不是开源的,但其免费额度加上 CLI 为你提供了一个集成化的替代方案,省去了将多个单一用途工具拼凑在一起的麻烦。如果你硬性要求必须使用可审计的许可证,请从上述八款工具中进行选择。如果集成化的工作流对你更重要,这就是折中之选。
如何选择
| 工具 | 最适合 | 安装 | 是否开源? | 许可证 |
|---|---|---|---|---|
| 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 |
| Tavern | pytest 中的 API 测试 | pip install tavern |
是 | MIT |
| Venom | 多执行器集成测试套件 | GitHub releases | 是 | BSD |
| apifox-cli | 一体化的“从设计到测试”工作流 | npm i -g apifox-cli |
否(有免费额度) | 商业授权 |
根据具体工作选择合适的工具。当你需要快速、可读性强的请求校验时,可以选择 Hurl 或 Newman;当你拥有数据模型并希望自动发现 Bug 时,可以选择 Schemathesis;当面临规模与并发挑战时,选择 k6;当测试需要融入更大的测试套件中时,选择 Tavern 或 Venom。如果你正在将这些工具与更庞大的流程进行权衡,API 测试策略指南介绍了每种类型适用的场景,而无头(headless)API 测试工具一文则探讨了在完全没有 UI 的情况下运行测试。
总结
开源 CLI 工具让您可以完全自主地阅读、fork 并运行 API 测试。Hurl 和 Newman 可以处理日常的请求校验,Schemathesis 和 Dredd 负责强制执行您的契约,k6 专注于性能,而 Tavern 和 Venom 则能将 API 测试融入更广泛的套件中。您可以根据许可证和您需要完成的具体工作来选择工具;同时运行其中两个也完全可行。
如果您希望在同一个地方进行设计、测试、mock 和撰写文档,而不是去维护一个工具链,Apifox 覆盖了全生命周期,并提供了用于 CI 的 apifox-cli。下载 Apifox 体验该 CLI 并与上述工具结合使用,看看哪种组合最适合您的流水线。
开发必备:API 全流程管理神器 Apifox
介绍完上文的内容,我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具,Apifox 是目前提升研发效率的首选。
如果你正在开发项目,不妨试试其极其友好的界面设计,它完全兼容 Postman 和 Swagger 数据格式,导入数据非常方便,,即使是新手也能很快上手,点击这里即可注册使用。

值得一提的是,除了个人和常规团队使用,针对有高安全合规要求、或需要在内网环境协作的企业,Apifox 还提供了深度定制的私有化部署方案。
获取专属报价与部署方案
详细的私有化部署系统架构与安全白皮书
针对您公司规模的专属报价单
免费的 1v1 专属产品演示 (Demo) 机会