免费开源的 API 测试 CLI 工具

厌倦了臃肿的GUI?为你精选8款好用、开源的API测试命令行工具,涵盖Hurl、Step CI、k6等,支持契约校验、模糊测试与高并发负载测试,助你在终端和CI流程中轻松掌控API质量!

用 Apifox,节省研发团队的每一分钟

免费开源的 API 测试 CLI 工具

免费使用 Apifox

相关推荐

最新文章

API

一体化协作平台

API 设计

API 文档

API 调试

自动化测试

API Mock

API Hub

立即体验 Apifox
目录

大多数 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

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

获取专属报价与部署方案

icon 详细的私有化部署系统架构与安全白皮书
icon 针对您公司规模的专属报价单
icon 免费的 1v1 专属产品演示 (Demo) 机会
获取部署方案
* 提交后,我们的客户经理将在 1 个工作日内与您联系
林俊锋 企业微信
@Apifox 专属顾问
扫码备注: 私有化 + 公司名