最近我在 GitHub 上翻到一个项目：keploy，把 API 测试里最磨人的两个环节直接干掉了，分享给大家。
这个项目在 2022 年 就建仓了，到我写稿这天，项目已经获得 18.7k star。10 月 20 号刚发了 v3.6.153，patch 版本一天能出好几个，维护更新相当频繁。
这个项目，先记住几个关键信息即可：
- 项目：
keploy，Keploy 公司开源的 API 测试工具，把真实流量录成测试用例和数据 mock - 技术栈：Go，Apache-2.0 协议，装完是一个单二进制 CLI
- 热度：18665 star，写稿这天实测
- 迭代：四年多，v3.6.153，10 月 20 号刚发
- 商业：开源核心免费，云端企业版另算。官网口径 300M+ mock、客户栏挂着 Amazon、Apple、Flipkart，这类数字没法核验，听听就行
- 地址：github.com/keploy/keploy
它干的事很简单，一句话概括：
Keploy 是开源、基于 eBPF 的无侵入式 API / 集成回归测试工具，录制真实流量（接口、数据库、消息队列调用）自动生成测试用例与依赖 Mock，在 CI 里回放做回归校验，不用改业务代码、不用接入 SDK、不限语言
几个核心功能特性
1、无侵入流量录制（eBPF）
在 Linux 内核层抓流量，业务代码零修改、不用代理、不用埋码；语言无关，Python/Java/Go/NodeJS 等任意后端都支持。捕获范围不止 HTTP 接口：Postgres、MySQL、MongoDB、Redis、Kafka、RabbitMQ、内部微服务调用全部抓包记录请求 + 返回结果。
2、自动生成测试用例 + 自动 Mock 依赖
录制完成自动产出 yaml 格式测试用例，同时把下游依赖的返回保存为 Mock。回放测试的时候不会去连真实 DB / 第三方接口，测试稳定、环境成本极低，解决集成测试环境不稳定的痛点。测试 yaml 可以直接提交 Git，团队共享。
3、Record-Replay 录制回放模式
- Record：跑一遍业务、调用接口，流量被录下来变成用例
- Test：重新启动应用，回放请求，对比响应差异，捕获回归 bug
4、原生 CI/CD 集成
支持 GitHub Actions、GitLab CI、Jenkins，PR / 合并时自动跑 Keploy 回归用例，快速发现接口变更导致的兼容性问题
5、可人工维护用例
yaml 文件可读，可以手动编辑断言、过滤动态噪声（时间戳、随机 id）；业务逻辑变更后，重新录制一键更新用例，不用重写脚本 Keploy Blo...
6、其他补充
AI 辅助生成边界用例、测试覆盖率统计、Schema 校验、契约测试能力；企业版支持 K8s 集群录制、生产流量脱敏录制等能力，开源版本 Apache2.0 协议可免费使用。
keploy 到底能解决哪些核心痛点
第一个痛点在测试用例：接口文档经常滞后、不全，用例基本靠人工逐条编写。很多人在 Postman 里攒了几百条请求，但能稳定放进 CI、自动回归的寥寥无几。项目工期一紧张，接口自动化测试往往是最先被砍掉、被搁置的部分。
第二个痛点在依赖与 Mock：想要跑通一条完整的业务链路，比如下单流程，前置依赖一大堆：用户服务、库存服务、支付渠道等。要么维护一整套完整的联调测试环境，要么手动逐个编写 Stub。可测试环境十分脆弱，别人改个配置、脏数据堆积，整套环境就容易挂掉；手写 Stub 更是无底洞，写完一层下游，才发现还有更深的依赖链路要处理。很多时候，搭建环境、维护依赖所消耗的时间，甚至远超写测试本身。
行业里其实已有不少方案，但各有短板：Python 的 vcr.py、Java 各类流量录放库，都需要侵入业务代码，耦合强、语言绑定，换一个技术栈就要重新适配；WireMock、mountebank 这类代理型 Mock 工具，需要把服务流量定向到代理，HTTPS 场景还要额外处理证书，而且大多只能捕获 HTTP 流量，数据库、消息队列、内部 RPC 调用覆盖不到，繁重的环境依赖问题依然没能根治。
这两个痛点本质上指向同一个缺口：
真实的业务请求本就日复一日流过服务，只是这些流量没有被自动沉淀成可回归的测试用例与依赖快照。
Keploy 就是瞄准这个缺口，基于 eBPF 做无侵入录制，不需要改代码、不需要代理劫持，自动捕获 HTTP、数据库、Redis、消息队列等全链路流量，一键生成带内置 Mock 的回归用例。录制下来的依赖快照会直接替代真实下游，不再需要维护一整套复杂联调环境；产出的 YAML 用例可以提交 Git、接入 CI，持续做回归校验，把接口回归测试的成本压到最低。
keploy 又是如何工作的？
eBPF 这个词最近两年快被讲烂了，但在这个场景里它是真的对症。
传统方案要么嵌库要么走代理，根子上都是「让流量路过我安排的地方」，嵌库侵入代码，代理侵入部署。eBPF 在内核里把包看了，应用层面什么都不用动，这是「不用改代码」四个字能成立的底层原因。
回放是反过来的。测试模式下应用照常启动，它去找数据库、找 Redis、找支付接口的调用，在半路被 keploy 截住，直接返回录制时的响应。数据库不用起，Stripe、Twilio 这类第三方也不用真调，官方文档里提了一句，连幂等性都不用保证，因为依赖根本没被真的执行过。
这就是它比「HTTP mock 工具」多走的那一步。Postgres、MySQL、MongoDB、Kafka、RabbitMQ 这些环境依赖被一起虚拟化了，跑一套回归，一台笔记本就够，不用等联调环境排期。
自动生成的测试工具多数死在一个地方，用例没人看得懂，没法 review，放两个月就成了僵尸文件，删了可惜，留着误报。keploy 的解法是把用例落成项目里的实体文件，测试用例和 mock 以 YAML 落在项目的 keploy/ 目录，直接进 git、走 PR。新接口上线前录一遍，diff 里就能看到这次改动影响了哪些请求的响应，测试资产跟着代码一起被人审。
覆盖率这块它给了个双视角口径。开发熟悉的语句覆盖、分支覆盖它算，QA 关心的 API schema 覆盖、业务场景覆盖它也算，两边合到一份报告里。开发和测试对「覆盖了多少」各说各话的老问题，至少在工具层面有了一个统一算法。
安装方式
安装方法很简单，只要一条脚本即可。
# 一键安装脚本（官方推荐）
curl --silent -O -L https://keploy.io/install.sh && source install.sh
# 验证安装
keploy --version
也可以手动下载二进制（AMD64）
curl --silent --location "https://github.com/keploy/keploy/releases/latest/download/keploy_linux_amd64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/keploy /usr/local/bin
macOS 也可以 brew install keploy/tap/keploy。装完要 keploy login 一次，浏览器授权或者配 KEPLOY_API_KEY 环境变量都行。
⚠️ 注意：底层依赖 eBPF，原生只支持 Linux；Mac、Windows 需要 WSL2 或者 Linux 虚拟机运行 Keploy CLI
使用流程
录制还是用你平时启动服务的命令。
keploy record -c "python main.py"
服务起来以后正常发请求，用 Postman 打、点页面、跑一段真实流量都行，用例和 mock 自动落进 keploy/ 目录。
比如，你当前搭建了一个 Python FastAPI 后端
步骤 1：录制流量，生成测试用例
-c 参数就是启动你的后端服务命令，keploy 会托管启动进程并抓流量
# 录制模式
keploy record -c "uvicorn backend.main:app --reload"
启动后，你自己调用接口（curl/postman/ 前端请求），正常跑业务流程； 录制完成，终端按 Ctrl+C 停止，自动在当前目录生成 keploy/tests/，里面是 yaml 测试用例 + mock 文件，直接可以 git 提交。
示例 curl 调用你的接口（录制时触发）
curl http://127.0.0.1:8000/health
curl -X POST http://127.0.0.1:8000/user -H "Content-Type:application/json" -d '{"name":"test"}'
步骤 2：回放执行回归测试
回放一条命令。
# 回放测试模式，delay是服务启动等待时间
keploy test -c "uvicorn backend.main:app --reload" --delay 5
Keploy 会自动读取 tests 目录里的用例，回放所有请求，拦截数据库 / 第三方调用、使用之前录制的 mock 返回；对比接口响应，输出测试报告，不一致就标记失败，发现回归问题。
步骤 3：接入 CI
- name: Run Keploy Tests
run: keploy test -c "uvicorn backend.main:app" --delay 5
环境上有几个门槛要记。
Linux 要内核 5.10 以上。Mac 用户注意，Apple Silicon 有原生模式，不用 Docker，但原生模式只支持 Go、Node、Python、Java 四种语言，抓的协议只有 HTTP/HTTPS、MySQL、MongoDB，要用 Postgres、Redis、Kafka、gRPC 就得走 Docker。
还有一个容易踩的坑，-c 参数直接给二进制命令，套 npm start、mvn 这类启动器会出问题。
日常使用记住 record 和 test 两个子命令就够，录完看一眼 keploy/ 目录，把噪声字段配好，提交进 git。文档里提醒过，高流量环境先别直接录，用例去重还是实验性功能，从低流量环境起步。
AI 在里面干的是补边角的活
这个项目也接了 AI，但只是用来做辅助。
录制的用例来自真实流量，真实流量有个天然短板，用户没走过的路径就没有用例。keploy 拿已有的录制加 Swagger/OpenAPI 文档，让 AI 生成边界值、缺字段、错类型、乱序调用、超时重试这些边角用例，补上录制覆盖不到的地方。
它官网现在的定位也整个压到了 AI 上，讲的是用真实流量的数字孪生验证 AI 写的代码，还挂了 Claude Code 的接入入口，让 AI Agent 改完代码自己跑一遍 keploy test 看回归。方向是那个方向，落到本地开源核心，AI 目前就是补边角的角色，主干还是流量录制。这个主次我反而觉得是对的，真实流量比模型生成的用例可信，AI 用来填缝，不用来当主角的。
先泼几盆冷水
好用是好用，但有几个现实问题得摆出来。
Mac 原生模式的支持范围前面说了，协议和语言都有限制，重度依赖 Postgres、Kafka 这类，老老实实走 Docker，别指望原生模式全包。
装完强制 keploy login，哪怕只用本地的录制回放。个人觉得这步对开源工具来说有点重，国内网络环境下浏览器授权偶尔还得折腾两回。
还有商业边界要认清。本地录制回放、用例生成都是 Apache-2.0 的开源部分，但生产环境录制、mock 仓库、时间冻结这些挂在云端企业版里。公司靠企业版养着开源，这个模式没毛病，只是选型时要想清楚自己要的功能在不在开源那一层。
写在最后
我的看法，工具可用可不用，看具体业务需求，但思路可以借鉴。
一条是「流量即用例」。你的测试环境每天都在产生真实请求，这些请求就是现成的测试资产，与其手写几百条用例，不如想办法把流量接住、存成可回放的文件。就算不用 keploy，录制回放加噪声过滤这套思路，自己拿任何语言实现一版，接口回归的覆盖率和新鲜度都会上一个台阶。
另一条是「mock 要做到全依赖」。只 mock HTTP 接口的测试，永远被数据库和环境拴着。数据库、消息队列、第三方一起虚拟化，测试才和环境解绑，这也是它敢说「跑测试不用起依赖」的底气。
不合适不必硬上，把流量录制、依赖虚拟化这两个设计搬进自己的工具和流程，比装一个新工具更值。
项目地址放这，感兴趣的自己翻。
GitHub: github.com/keploy/keploy
官网: keploy.io
我是狂师，公众号长期分享 AI 提效实战与测试开发技术干货。