Keploy
免费
Keploy 是面向 AI编程 团队的 API 与集成测试平台，核心做法是用 eBPF 记录真实流量，将其转成可在 CI 中回放的回归测试、Mock 和隔离沙箱。
Keploy - 深度工具分析
Keploy 的核心参数与统计
| 参数 | 当前公开信息 |
|---|---|
| 工具类型判定 | 生产力 / 业务端应用 |
| 核心交付形态 | 开源 CLI + 云端控制台 + 企业版能力 |
| 核心技术路线 | eBPF 网络层流量捕获、record/replay、Mock Registry、AI 辅助覆盖率扩展 |
| 支持平台 | Web、CLI、API |
| 公开许可 | OSS 核心为 Apache 2.0 |
| 公开生态信号 | GitHub 17.6k stars、2.2k forks、127 位贡献者、597 个 Releases |
| 官网公开指标 | 1.2M+ downloads、200M+ mocks created、15.6k stars |
| 最新可核验 OSS 版本 | v3.5.66，2026-06-16 |
一句话简评：Keploy 不是“再一个测试管理面板”，而是把生产流量直接转成回归测试和依赖沙箱的 API 测试平台，重点解决集成测试写得慢、Mock 不可信、CI 回归覆盖不稳这三个老问题。
工具类型判定：Keploy 更接近规则 D 的生产力 / 业务端应用，而不是基础模型、MCP 或单纯 RAG 基建。理由很直接：它的主交付是给研发团队拿来落地 record/replay、覆盖率分析、团队协作和企业治理的测试平台，用户采购时看的也是定价层级、CI 接入、权限、SLA 和沙箱能力，而不是底层模型接口本身。
宣传核验：官网把核心卖点写成“capture real API traffic with eBPF and replay it in CI as deterministic regression tests, auto-generated mocks, and production-like sandboxes”。这条宣传和官方 CLI、GitHub README、定价页是对得上的，不是单纯把 LLM 套在测试文案上。它切中的真实痛点是 API 与集成测试最费时间的部分并非断言本身，而是如何把真实依赖、边界值、顺序关系和外部系统行为稳定重建出来。
Keploy 的用户与市场认可
开源信号：GitHub 仓库公开 17.6k stars、2.2k forks、127 位贡献者和 597 个发布版本，说明它不是一次性发布后停更的演示项目，而是持续高频迭代的工程化产品。
站点公开指标：官网首页公开 1.2M+ downloads、200M+ mocks created，并给出 Gartner Peer Insights 4.6/5、G2 4.9/5、Capterra 4.9/5 的评分入口。这里更适合把它视为“市场采用线索”，而不是绝对结论，因为评分样本量与统计口径仍应以各平台实时页面为准。
商业化信号：定价页已经区分 Playground、Pro、Enterprise 三层，并把 SCIM、目录同步、99.99% SLA、优先响应、Kubernetes record-replay、staging/prod capture 放到企业层。这意味着 Keploy 的目标不只是开源社区使用，而是明确在做团队级和企业级交付。
隐性收益：对研发组织来说，Keploy 的真正价值不是“少写几个测试文件”，而是把原本只掌握在资深后端和测试同学手里的环境知识、依赖行为和回归样本沉淀成可重复运行的资产。团队换人后，回归能力不至于跟着人一起流失。
成本优势：把手写集成测试的人力账改成流量资产账
| 成本层级 | 当前公开信息 | 需要注意的边界 |
|---|---|---|
| C 端 / 个人 | OSS 核心可长期自托管；Playground 免费，含 30 test suites/月、100 test runs/月、5000 integrations/月、5 AI credits | 免费层足够试用，但不适合高频回归或多人协作长期跑生产级验证 |
| 开发者 / API | Pro 页面公开为 19 美元/用户/月 + additional usage，且含 19 美元 usage credit、合同测试、负载测试、协作和更快生成能力 | 超额使用、AI 额度和实际运行规模带来的附加费用，仍应以官方实时计费页和控制台为准 |
| 企业 / 私有化 | Enterprise 走商务咨询，强调访问控制、SCIM、SOC2/GDPR/HIPAA/ISO readiness、99.99% SLA、staging/prod capture | 没有公开标准价，采购前必须核验数据驻留、支持响应、合规边界、SLA 触发条款 |
免费的真相：Keploy 的免费层不是“无限开源 + 无限云端体验”。开源核心可以自托管，但云端 Playground 把每月 test suite、test run、integration run 和 AI credits 都做了明确封顶，适合验证 record/replay 机制是否匹配你的服务，而不适合把整个团队流水线都压上去。
降本增效量化推演：对已经有 API 服务、数据库依赖和第三方接口的团队，Keploy 最可能省下的是“写集成测试样板 + 搭 mock 环境 + 维护回放数据”的时间。以一个中型服务新增 8 到 12 个关键回归用例为例，传统做法常见是半天到一天才能把录制数据、依赖桩和断言对齐；用 record/replay 路线，试点成熟后通常可以压到 1 到 2 小时内完成首轮可运行资产。这是工程推演，不是官方承诺。
隐性成本：若服务调用里本身就夹杂强随机值、时间戳、顺序敏感数组、动态签名或高噪声字段，团队还得花时间配 noise filtering、normalize 和 templatize 规则。Keploy 不是零治理成本，只是把成本从“人工写样板”转移到了“治理录制质量和回放稳定性”。
Keploy 的主要功能
- 真实流量录制：通过
keploy record -c "<启动命令>"捕获 API 调用、数据库查询和部分流式事件，核心价值不是录下来，而是录制过程中不用为每种语言单独接 SDK。 - 确定性回放测试：通过
keploy test在 CI 或本地回放录制资产，让服务在隔离依赖条件下重跑请求，适合做回归验证和接口行为比对。 - 依赖 Mock 与基础设施虚拟化：Keploy 不只录 HTTP mocks，还把 MySQL、MongoDB、Postgres、Redis、DynamoDB、Kafka、gRPC、GraphQL 等依赖纳入支持矩阵，解决“单测能跑、集成测试环境搭不起来”的老问题。
- AI 覆盖率扩展：官方把 AI 能力放在基于已有录制和 OpenAPI/Swagger 发现 boundary values、缺失字段、错误类型和时序问题上，属于“扩展测试覆盖”而不是替代 record/replay 主链路。
- 报告与风险感知修正：CLI 公开
report、normalize、rerecord、sanitize、templatize等命令，其中normalize默认对高风险失败保守处理，避免团队把真实 breaking change 误当成该更新的测试基线。
专家视点：Keploy 的功能协同效应很强。真实流量录制只是起点，真正拉开差距的是“录制资产 -> 依赖 mocks -> 离线回放 -> 报告 diff -> normalize/rerecord 修正 -> 再进入 CI”的闭环。一旦这个闭环成立，研发团队就不必在 Postman 样例、手写集成测试、临时 stub 服务和 CI 报表之间来回切换。
不适配边界：如果你的系统主要是纯前端交互、桌面端本地逻辑，或者关键验证点是复杂视觉回归而不是 API/依赖链路，Keploy 的优势会明显下降。它更擅长服务端 API 与集成行为，不是通用质量平台。
Keploy 的模型与版本演进
版本主线：公开最清晰的版本脉络来自 GitHub Releases，而不是官网营销页。最近几次发布表明 Keploy 仍然在高频打磨 replay、mock diff、数据库协议解析和 CLI 稳定性。
近期 OSS 版本节点
| 版本 | 日期 | 公开变化 |
|---|---|---|
| v3.5.66 | 2026-06-16 | 增加 Aerospike kind、统一 mock mismatch side-by-side diff、修复 startup mocks 行为 |
| v3.5.65 | 2026-06-12 | 修复 MySQL replay、Docker daemon 启动竞态、agent 自终止逻辑 |
| v3.5.64 | 2026-06-09 | 把 flow body noise 纳入 mock matching 的 NoiseConfig |
| v3.5.62 | 2026-06-08 | 新增 --strict-failure，对 replay 响应偏差采取更严格失败判定 |
云端与商业化演进
从 OSS 到云端协作：官网 FAQ 和 Pricing 已公开 Playground、Pro、Enterprise 分层，说明产品已经从“单机录制工具”发展成带协作、Spend 管理、Mock Registry、Time Freezing、合同测试和合规控制的测试平台。
边界提醒：云端控制台自身的内部版本号、精确发布日期和功能逐项上线时间没有完整公开，因此这里不编造所谓 Cloud v1、v2 的命名，统一以官方公开定价与文档页为准。
Keploy 的技术优势
机制 -> 效果 -> 场景 1：eBPF 网络层拦截：Keploy 通过 eBPF 在网络层捕获调用，而不是要求业务代码全量埋点或每种语言都引 SDK。直接效果是多语言团队更容易统一接入；最适合微服务、API 网关后端、对外部依赖多的服务。
机制 -> 效果 -> 场景 2：record/replay + infra virtualization：它把真实请求、依赖返回和部分基础设施交互一起录下来，再在回放时复原 deterministic sandbox。效果是测试不必强依赖外部数据库、消息队列或第三方 API 在线可用；最适合 CI 环境不稳定、外部依赖昂贵或难复刻的团队。
机制 -> 效果 -> 场景 3：风险感知的测试资产维护：normalize、rerecord、report 和 strict-failure 这些命令说明 Keploy 并不假设录制后资产永远稳定，而是把“如何安全更新测试基线”也做成产品能力。效果是测试资产随服务演进时，不需要每次全靠人工肉眼 diff。
机制 -> 效果 -> 场景 4：AI 只负责补 coverage，不主导主流程：官方把 AI credits 用在 bug detection、self-healing、coverage gap 扩展，而不是完全替代 record/replay。这样做的好处是减少“全靠模型猜测试”的不稳定性，更适合追求回归可信度而不是单纯追求生成数量的工程团队。
合规与风险：Enterprise 页写了 SOC2 / GDPR / HIPAA / ISO readiness，但这类表述更接近“企业交付能力方向”，不等于默认所有场景自动满足合规要求。涉及生产流量录制时，仍要自行核验敏感字段脱敏、数据保留周期、地区隔离和审计日志策略。
如何使用 Keploy
3 分钟快速上手：官方安装文档和 CLI 文档都公开了最短路径，适合先在一个本地服务上验证 record/replay 是否能跑通。
curl --silent -O -L https://keploy.io/install.sh && source install.sh
keploy login
keploy record -c "go run main.go"
keploy test -c "go run main.go" --delay 10典型落地路径：
- 先在单个 API 服务上用
keploy record录一组真实调用，确认生成的 testcases 和 mocks 能落在本地目录。 - 再用
keploy test回放，观察报告里是否出现高噪声字段、顺序差异或依赖不稳定问题。 - 对有意变更的响应，用
normalize或rerecord更新测试资产，而不是直接忽略失败。 - 当本地稳定后，把录制和回放接入 GitHub、GitLab 或 Jenkins，再决定是否启用云端协作、Mock Registry 和更高阶 AI 能力。
人机协作边界：Keploy 可以把“录制、回放、报告生成、部分修正建议”自动化，但不能把“哪些变更应该接受、哪些变更其实是生产回归”完全自动化。涉及支付、权限、合规接口和高价值客户流程，仍要保留人工确认点。
Keploy 的产品定价
| 套餐 | 当前公开价格 | 公开能力摘要 |
|---|---|---|
| Open Source | 免费自托管 | 本地 record/replay、开源核心、CLI 能力 |
| Playground | 免费 | 30 suites/月、100 tests/月、5000 integrations/月、5 AI credits、自动化 CI/CD、schema coverage 仪表盘 |
| Pro | 19 美元/用户/月 + additional usage | 含 19 美元 usage credit、团队协作、free viewer seats、更快生成、合同测试、负载测试、邮件与聊天支持 |
| Enterprise | 未公开，需咨询 | SCIM、团队访问控制、SOC2/GDPR/HIPAA/ISO readiness、99.99% SLA、Kubernetes 与 staging/prod capture、专属工程支持 |
价格解读：Keploy 的收费核心不是“有没有 AI”，而是你是否需要更高频的云端生成、更细的协作治理和企业交付保障。对只想验证 record/replay 是否适配本团队的用户，OSS 或 Playground 足够；对要把测试资产变成跨团队平台能力的组织，真正的采购点在 Enterprise 条款，而不是 Pro 单价本身。
待官方页面为准：Pro 的额外 usage、Enterprise 合同价、AI credit 超额计费、viewer seat 细则和数据保留策略没有在当前公开抓取信息里完全展开，预算前应以官方实时页面或销售沟通为准。
Keploy 的应用场景
- 微服务 API 回归：适合频繁改动接口编排逻辑的后端团队，把生产或 staging 流量转成稳定回归样本，减少发布前靠人工点接口的低效验证。
- 依赖重、环境贵的集成测试：适合依赖数据库、消息队列、第三方支付、通知或内部服务的系统，通过 mocks 和 sandbox 降低环境搭建成本。
- CI 中的契约与覆盖率治理：适合想把 schema coverage、coverage gap detection 和 contract diff 纳入 PR 流程的团队，让“测试覆盖够不够”不再只靠经验判断。
- 新服务上线前的冒烟与回放验证：适合把一批真实请求快速录成第一批回归资产，用于上线前 smoke test 和变更后比对。
降维打击场景：当团队已经有真实流量、接口稳定在 HTTP/gRPC/GraphQL/数据库依赖这一类可捕获链路里，而且发布节奏快、手写集成测试跟不上时，Keploy 的爽点最明显。
Keploy 的适用人群
- 后端与平台工程师：需要把 API、数据库和外部依赖一并拉进回归流程的人，最容易直接看到效率收益。
- 测试开发与 QA 自动化团队：需要把集成测试资产化、把 flaky 原因收敛到可解释报告中的团队，适合用 Keploy 做统一入口。
- DevOps / CI 负责人：需要把 record/replay、报告和团队协作嵌进流水线的人，会更关注 viewer seats、SLA、SCIM 和运行规模。
- 企业研发管理者：已经从“会不会用”进入“怎么治理、怎么审计、怎么规模化”的组织，可以关注 Enterprise 的控制面能力。
劝退 / 不适用人群：纯前端视觉回归团队、单机场景脚本工具用户、没有稳定 API 边界的原型项目，以及不允许任何真实流量样本被录制或脱敏治理成本过高的组织，采用门槛会明显偏高。
总结与展望
Keploy 的核心竞争力在于它把真实流量、依赖行为和回归验证串成一条工程闭环，而不是只做“AI 生成几个测试案例”的表层功能。对 API 驱动型团队来说，它最值钱的部分是 record/replay 和基础设施虚拟化，让集成测试从高人力、低覆盖、环境脆弱的工作，变成可在 CI 中重复运行的资产。
当前限制也很明确：一是公开定价只完整披露了免费层和 Pro 基础入口，企业合同与超额使用细则仍需商务确认；二是生产流量录制天然带来数据脱敏、审计和保留策略要求；三是高噪声接口和复杂动态响应仍需要团队自己建立 normalize、templatize 和人工确认规则。采购/采用风险评估：如果团队没有稳定的 API 边界、没有脱敏治理能力，或者希望完全零人工地自动接受所有测试变更，Keploy 反而可能把错误基线快速放大。更稳妥的采用方式是先选一条依赖复杂但边界清晰的服务做试点，验证回放稳定性、噪声治理成本和 CI 集成效果，再决定是否扩到团队级采购。
版本信息
- v3.5.66 ：GitHub Releases 公布的最新 OSS CLI 版本，新增 Aerospike kind、统一 mock mismatch diff，并修复启动 mocks 在前 5 个测试用例内的行为。
- v3.5.65 ：修复 MySQL replay 状态读取、Windows 与 macOS Docker daemon 启动竞态，以及 agent 父进程退出后的自终止行为。
- v3.5.62 ：增加 --strict-failure 标志，用于在 replay 阶段把响应偏差直接判为失败，而不是降级为 obsolete。
- v3.4.1 ：官方安装文档示例中展示的 CLI 版本号，暂无公开精确发布日期，可视作 2026 年 5 月时的公开安装快照。
用户评价