Keploy：让真实流量自动变成测试用例

一峰收录于公众号文章

2026-06-15 约 1523 字预计阅读 4 分钟

在微服务越来越普遍的今天，接口测试面临一个很现实的问题：

测试环境难搭、依赖服务太多、Mock 成本越来越高。

一个简单的接口调用，背后可能依赖数据库、Redis、消息队列以及多个下游服务。为了编写自动化测试，我们往往需要花费大量时间构造 Mock 数据，维护测试环境。

而 Keploy 提供了一种不同的思路：

直接录制真实流量，再自动生成测试用例和 Mock。

什么是 Keploy

Keploy 是一个开源的 API 测试生成工具。

它能够在应用运行过程中自动捕获请求和依赖调用，并生成：

API 测试用例
数据库 Mock
Redis Mock
gRPC Mock
HTTP 下游服务 Mock

随后可以在没有真实依赖的情况下进行回放测试。

简单来说：

你正常运行一次服务，Keploy 帮你把这次请求自动变成可重复执行的测试。

Keploy 的核心原理

Keploy 的底层依赖 Linux 的 eBPF 技术。

它并不需要侵入业务代码，而是在系统调用层面捕获网络和数据库交互。

例如：

HTTP 请求
MySQL 查询
PostgreSQL 查询
Redis 命令
gRPC 调用

当请求经过应用时，Keploy 会记录：

用户请求内容
服务返回结果
服务访问过的外部依赖
依赖返回的数据

最终生成一组 YAML 文件。

整个过程如下：

真实请求
    ↓
Keploy 捕获流量
    ↓
生成 Test YAML
生成 Mock YAML
    ↓
保存到本地
    ↓
后续自动回放

一个简单例子

假设有这样一个接口：

GET /api/user/1

接口内部会：

HTTP
 ↓
Redis
 ↓
MySQL

首先启动录制：

keploy record -c "go run main.go"

然后访问接口：

curl http://localhost:8080/api/user/1

Keploy 会自动生成：

keploy/
├── tests/
│   └── test-1.yaml
└── mocks/
    ├── mysql.yaml
    └── redis.yaml

其中：

test.yaml 保存请求与响应
mock.yaml 保存依赖返回结果

回放测试

录制完成后，可以直接执行：

keploy test -c "go run main.go"

测试时：

不再访问真实数据库
不再访问真实 Redis
不再访问真实下游服务

而是使用录制时保存的 Mock 数据。

这样测试环境就变成：

HTTP 请求
    ↓
业务代码
    ↓
Keploy Mock

整个过程不依赖外部系统。

因此非常适合：

本地开发
CI/CD
回归测试
老系统改造

Keploy 的优势

1. 无需手工编写 Mock

传统自动化测试经常需要：

when(userService.query(1))
    .thenReturn(user);

或者维护大量 JSON 文件。

而 Keploy 直接来自真实流量。

因此：

更接近生产环境
不容易遗漏字段
不需要手工维护

2. 自动生成测试用例

很多项目的测试覆盖率低，并不是因为不重视质量，而是因为：

写测试太费时间。

Keploy 将一次真实请求直接转换为测试用例。

对于已有系统来说：

几分钟即可获得第一批回归测试
无需修改业务代码
无需额外学习测试框架

3. 适合微服务架构

微服务最大的难点之一是依赖链路复杂。

例如：

A
↓
B
↓
C
↓
D

当 D 服务不可用时：

测试失败
环境搭建困难

Keploy 可以把这些依赖全部录制下来。

后续执行测试时：

A
↓
Mock(B)
Mock(C)
Mock(D)

从而摆脱环境依赖。

4. 非侵入式

很多测试框架需要：

修改代码
注入 SDK
增加测试埋点

Keploy 的特点是：

从系统层捕获流量，而不是业务层。

因此对现有项目改造成本较低。

适合哪些场景

老系统补测试

历史项目往往：

没有自动化测试
文档不完整
依赖关系复杂

Keploy 可以快速建立第一层回归保护。

重构验证

重构过程中最担心：

功能是否被改坏。

利用生产流量录制的测试集，可以快速验证重构前后行为是否一致。

CI 回归测试

将录制好的测试集接入流水线：

代码提交
 ↓
构建
 ↓
Keploy 回放
 ↓
验证结果

可以有效降低线上回归风险。

使用限制

Keploy 并不是万能的。

需要注意几个限制：

依赖 Linux

Keploy 基于 eBPF。

因此：

Linux 原生支持
Docker 环境支持
macOS 无法直接运行

通常需要在 Linux 容器或 Linux 服务器中使用。

流量质量决定测试质量

Keploy录制的是：

你实际访问过的请求。

如果录制期间没有覆盖某个业务场景，那么测试集中也不会包含对应用例。

因此它更适合作为：

回归测试生成器
流量驱动测试工具

而不是完全替代测试设计。

总结

Keploy 最有价值的地方在于：

将“真实流量”直接转化为“自动化测试资产”。

它利用 eBPF 捕获请求与依赖调用，自动生成测试用例和 Mock 数据，使得复杂微服务环境下的回归测试成本大幅降低。

对于已经上线多年、缺少自动化测试的系统来说，Keploy 提供了一条相对低成本的补测试路径：

先录制真实流量，再逐步建立自动化回归体系。

如果你的项目正面临测试覆盖率不足、依赖环境复杂、Mock 成本高的问题，那么 Keploy 值得深入研究。

目录