测试人员必备：推荐一款智能测试数据清理AI Skill，支持db、redis、mq等

导读：前两篇我们推荐了让测试"跑起来"的 api-test-executor、让失败脚本"自己修好"的 api-failure-diagnoser。但跑完、修完之后，环境里堆满了测试数据。 今天给大家分享一款一键清空测试数据的 skill——api-testdata-cleaner。

问题背景

先问大家一个问题：你的测试环境，有多久没"打扫"过了？

大概率是这样的——

1. 1. 商品列表里堆满了"test 商品 001"、"测试商品 abc"；
2. 2. 用户管理里一堆"newuser_001"、"测试账号 xxx"；
3. 3. 订单表里几千条测试订单，查询都变慢了；
4. 4. 想跑同一个用例第二次，因为账号重复直接失败；
5. 5. 多人协作时，并发执行相互污染数据；
6. 6. 手动清理，又怕误删核心配置数据；
7. 7. 不清吧，Flaky Test 越来越多，自动化可信度下降；
8. 8. 最后只能"删库重来"，但又影响其他人测试……

行业统计，数据污染占 Flaky Test 成因的 60% 以上——这是接口自动化"随机失败"的头号元凶。

如果以上场景你中了三条以上，那么今天这款 skill，你一定要了解——api-testdata-cleaner，一款能让测试数据"一键净空"的 Agent Skill。

一、它是什么？

api-testdata-cleaner 是接口自动化测试的数据清理专家，你可以把它理解成测试环境的"智能清洁工"。

它的核心定位非常克制——只做一件事：

安全、精准、全场景地清理测试产生的脏数据，实现"执行前数据准备、执行中数据隔离、执行后数据清理"的全流程自动化，让环境始终处于"干净、可控、可复用"的状态。

听起来简单？但它从源头解决了接口自动化"随机失败"的问题。

二、5 大核心卖点

① 三层清理覆盖：DB + Redis + 文件，一个不落

这是它最核心的能力。

测试产生的脏数据，不止数据库一种。api-testdata-cleaner 覆盖三层：

为什么三层都要清？

因为只清数据库，残留的 Redis Token 可能导致登录态错乱；只清缓存，堆积的日志文件可能拖慢环境——脏数据在哪，它就清到哪。

② 无损清理：白名单保护，核心数据不误删

这是它最让人放心的能力。

自动清理最怕的是什么？误删核心数据。api-testdata-cleaner 用"数据归属标记 + 白名单保护"双重机制，确保只清理测试产生的临时数据：

白名单保护范围：

• • 系统内置的 admin 管理员账号（常驻账号，永不清理）
• • 人工预先录入、具备明确业务规则的正式数据
• • 基础配置数据、常驻测试账号

测试数据识别特征：

• • 内容多存在重复
• • 名称、字段中普遍包含 "test"、"测试" 等标识字样
• • 有明确的"数据归属"标记（来自哪次执行）

存疑处理：判定测试数据时如果有不确定的，会主动找人工确认再执行删除，绝不莽撞行事。

③ 业务适配：不是"删库式"清理

这是它最专业的能力。

普通的清理工具，往往是"DELETE FROM 表"的一刀切——简单粗暴，但会破坏业务关联。api-testdata-cleaner 支持按业务模块定制清理规则：

为什么要做业务适配？

以电商场景为例：如果只删订单不清库存，库存数据会越来越乱；如果只删用户不清购物车，会留下大量孤儿数据——真正的清理，要顺着业务逻辑走，而不是简单的"删库"。

④ 生产环境强制拦截：数据安全的最后一道防线

这是它最硬核的能力。

数据清理最怕的是什么？在生产环境执行了 DELETE。

api-testdata-cleaner 内置强制拦截机制：

• • 严格区分环境：dev / test / prod 三套环境配置隔离
• • 生产环境强制终止：识别到 prod 环境，直接终止执行 + 抛出警告
• • 日志全留痕：每一步操作都保留记录，方便审计追溯

这是数据安全的最后一道防线——哪怕配置错了、参数传错了，也不会对生产环境造成任何破坏。

⑤ 独立通用：一份能力，全场景适配

这是它最被低估的设计哲学。

为什么把数据清理独立成 Skill，而不是嵌入到执行或修复 Skill 里？

因为数据清理是通用能力，使用场景非常多：

• • 执行完测试 → 自动清理
• • 手动排查 Flaky Test → 单独清理
• • CI 每日回归前 → 定时清理
• • 脚本修复重测前 → 重置环境
• • 新人入职熟悉环境 → 按需清理

如果逻辑写死在执行/修复 Skill 里，这些场景都无法单独调用，只能重复编写代码。

独立成 Skill 的好处是——一份能力、全场景适配，无论何时何地需要清理，一个命令搞定。

三、5 个典型使用场景

场景一：日常测试后的数据清理

一轮测试跑完，环境里堆满了测试数据：

/api-testdata-cleaner 清理数据库中重复的测试数据

它会自动连接测试环境数据库，几秒钟完成清理，并生成清理报告——全程无人工介入。

场景二：Flaky Test 排查前的环境重置

某个用例"有时过、有时不过"，怀疑是数据污染：

/api-testdata-cleaner 清理用户模块和订单模块的测试数据

精准清理指定模块，回到"干净状态"再跑一遍——快速定位是否是数据问题。

场景三：CI 每日回归前的环境初始化

每天凌晨定时回归，需要先重置环境：

claude -p "调用 api-testdata-cleaner 技能，参数: env_type=test, clean_scope=all, clean_target=all" \
  --permission-mode bypassPermissions \
  --output-format json

清理完成后，再触发 api-test-executor 跑全量回归——保证每次回归的数据基线一致。

场景四：脚本修复重测前的数据隔离

修完一个因为账号重复失败的脚本，想立刻重测：

/api-testdata-cleaner 清理用户模块测试数据，保留调试日志

通过 keep_debug_data=true，清理脏数据但保留调试日志——既隔离数据，又方便复盘。

场景五：按模块精细化清理

只想清某个模块，不动其他数据：

/api-testdata-cleaner 只清理购物车模块的测试数据

支持按模块精细化控制（user / cart / order / address / all）——灵活适配各种场景。

四、实战效果：几秒钟干完半天的活

这是AI 进化社中一个非常典型的实战场景。

起因：调用 api-test-executor 执行测试、使用 api-failure-diagnoser 处理脚本故障后，环境中留存了大量测试数据——商品管理里有冗余的测试商品、商品分类里有大量测试分类、用户管理里出现大量测试用户。

比如商品管理中，存在大量冗余的测试商品数据：

商品分类中，存在大量的测试分类数据：

用户管理中出现大量的测试用户数据：

为避免数据堆积、防止数据污染，我希望在每轮接口测试执行和校验完毕后，能自动清理这些测试数据。

但如此同时，会面临一个方案实现决择，针对这个需求，我们应该是选择在现有技能上做改造，还是新建一个专门负责数据清理的独立Skill技能？

先说结论：优先考虑新增一个独立的技能，比如 api-testdata-cleaner（测试数据自动清理技能），如果有需要，还可以通过调用链联动，在接口执行、故障修复完成后自动触发清理；

为什么？原因其实很简单，我们可以先对比一下这两个方案的优劣区别。

方案一：在现有 Skill 中嵌入清理逻辑

如果在现有 Skill 中嵌入清理逻辑，也就是把数据库、缓存、临时账号 / 订单 / 购物车等数据清理代码，直接写到 api-test-executor 或 api-failure-diagnoser 内部。虽然实现简单，短期开发成本低，单次执行也不需要额外调用其它技能，但：

• • 违反了单一职责原则，我们前面所有的skill技能设计，都遵循一个原则：一个 Skill 只做一件事：
  • • api-test-executor：只负责用例调度、接口执行、结果收集；
  • • api-failure-diagnoser：只负责故障诊断、脚本修复；如果强行嵌入数据清理，会让单个技能职责臃肿，代码耦合严重，后续维护、修改逻辑时容易牵一发而动全身。
• • 复用性极差，测试数据清理是通用能力：
  • • 单条用例调试需要清数据；
  • • 全量回归前需要初始化环境；
  • • 定时任务执行前需要重置；
  • • 问题排查前也需要清理脏数据。如果逻辑写死在执行 / 修复技能里，其他场景无法单独调用清理能力，只能重复编写代码，产生冗余。
• • 灵活性不足，无法按需控制，实际测试中存在差异化需求：
  • • 部分场景：执行完必须立刻清数据（常规回归）；
  • • 部分场景：执行完保留数据用于问题排查（故障复盘、BUG 定位）；
  • • 部分场景：只清理某一个模块数据（如仅清空购物车，保留用户账号）。内嵌逻辑只能 “一刀切”，无法灵活配置

方案二：新增独立 api-testdata-cleaner 数据清理 Skill

开发一个独立通用的数据清理技能，可以让其专门负责数据库、Redis、临时文件、测试账号、业务临时单据（订单 / 购物车 / 优惠券） 等全量 / 指定范围测试数据清理、环境重置工作。

虽然需要额外开发一个新 Skill，短期多一点开发工作量，但长期收益远大于成本，具体表现在几方面：

• • 循单一职责，架构更标准：
  • • 延续前期拆分 Skill 的设计思路，各司其职：执行 → 诊断修复 → 数据清理，链路清晰，每个模块功能纯粹，更符合企业级自动化工程规范。
• • 高复用，全场景适配，该技能可独立调用，也可被其他技能联动调用：
  • • 场景 1：接口执行完成后 → 自动调用清理；
  • • 场景 2：手动排查数据污染问题 → 单独执行清理 Skill；
  • • 场景 3：CI 流水线每日回归前 → 先执行清理，再跑用例；
  • • 场景 4：脚本修复完成重测前 → 先重置环境数据。
• • 配置灵活，支持精细化管控，可在 Skill 入参中定义规则，按需清理：
  • • 支持全局清理 / 按业务模块清理（用户 / 订单 / 购物车分离清理）；
  • • 支持 “执行后自动清理” / “手动触发清理” 两种模式；
  • • 支持 “调试模式保留数据” / “正式回归强制清理” 开关。
• • 可独立迭代扩展后续新增数据表、缓存、第三方临时数据，只需要更新 api-data-cleaner 这一个技能，不用改动整条链路的核心代码，迭代成本极低。

测试验证效果

用口语化的方式，直接输入要清理的内容和范围

/api-testdata-cleaner  清理数据库中重复的测试数据

接收到提示词后，会先连接当前测试环境（被测项目的环境配置），校验环境信息是否连接成功，然后开始执行数据库测试数据清理操作。

最终效果，我还是挺满意的，该删除的测试数据全部都删除了，之前由我人工创建的数据也全部保留下来了（没有被误删），而且整个操作几乎是在几秒钟内完成，期间没有任何人工介入的动作。

除了控制台显示清理结果外，还会单独生成一份markdown格式的数据清理报告，方便后续留存：

数据清理完成后，我们打开被测项目前端页面，在前端页面上，比之前干净多了（页面上所有的测试数据全部被清理掉了)

执行过程：

1. 1. 自动连接测试环境数据库，校验环境信息
2. 2. 识别测试数据特征（含 test、测试等标识）
3. 3. 应用白名单保护规则
4. 4. 分模块执行清理
5. 5. 生成清理报告

最终效果：

• • ✅ 该删除的测试数据全部删除
• • ✅ 人工创建的数据全部保留（没有被误删）
• • ✅ 整个操作几秒钟完成
• • ✅ 全程无人工介入
• • ✅ 单独生成 markdown 格式的数据清理报告，方便留存

温馨提醒：如果在新开会话中调用，需要提供被测项目的路径，这样它才能读取到项目配置文件。在连续会话中，它会自动继承上下文的项目路径。

五、适合谁用？

强烈推荐：

• • 接口自动化测试工程师：日常清理脏数据、解决 Flaky Test
• • 测试开发工程师：搭建团队环境管理能力、CI 流水线
• • 全栈测试工程师：希望降低环境维护门槛
• • 测试团队负责人：希望提升环境稳定性、降低 Flaky Test 困扰

特别适合：

• • Flaky Test 频发、数据污染严重的团队（立竿见影）
• • 多人协作、共享测试环境的团队（避免数据互相污染）
• • CI/CD 流水线需要定时重置环境的团队
• • 测试数据量大、手动清理成本高的团队

不太适合：

• • 还没有自动化测试的团队（没数据可清）
• • 测试环境与生产环境共用的团队（建议先做好环境隔离）

六、如何获取和安装？

api-testdata-cleaner GitHub 仓库地址：

git clone git@github.com:xxx/skills.git

安装到 WorkBuddy：

cp -r skills/api-testdata-cleaner ~/.workbuddy/skills/

安装到 Claude Code：

cp -r skills/api-testdata-cleaner ~/.claude/skills/

安装完成后，在你的 AI 工具里直接说：

"/api-testdata-cleaner 清理数据库中重复的测试数据"

就可以开始用了。

小贴士：建议把它和 api-test-executor、api-report-generator 串起来用——通过 api-pipeline-scheduler 一键编排「执行 → 清理 → 报告」全流程。

写在最后

测试行业有个共识："Flaky Test 是自动化最大的敌人。"

而 Flaky Test 最大的源头，就是数据污染（占比 60% 以上）。

api-testdata-cleaner 解决的就是这个源头——让测试环境始终干净、可控、可复用。

它不会替代你的环境管理规范，不会替代你的数据隔离策略，更不会替代你对生产环境的敬畏。它只是把你从手动 DELETE、担心误删、反复重置环境的焦虑中解放出来，让你把精力聚焦在更有价值的事情上——测试策略优化、Flaky 根因深度分析、自动化体系持续改进。

需要强调的是：数据清理涉及生产安全，任何自动化能力都必须建立严格的保护机制。白名单、环境拦截、日志留痕——这三道防线，缺一不可。

而这，正是 AI 赋能测试的真正意义——不是替代人，而是让人更安心。

如果你也厌倦了每天手动清理测试数据，强烈推荐试试这款 skill。