一、它是什么api-testdata-cleaner 是接口自动化测试的数据清理专家你可以把它理解成测试环境的智能清洁工。它的核心定位非常克制——只做一件事安全、精准、全场景地清理测试产生的脏数据实现执行前数据准备、执行中数据隔离、执行后数据清理的全流程自动化让环境始终处于干净、可控、可复用的状态。听起来简单但它从源头解决了接口自动化随机失败的问题。二、5 大核心卖点① 三层清理覆盖DB Redis 文件一个不落这是它最核心的能力。测试产生的脏数据不止数据库一种。api-testdata-cleaner 覆盖三层清理层 清理内容 清理方式数据库MySQL 测试账号、商品、分类、订单等 按主键批量删除、按条件软删除缓存Redis 登录 Token、验证码、临时会话 按 Key 前缀批量删除本地文件 测试日志、报文、临时数据文件 按目录扫描清理为什么三层都要清因为只清数据库残留的 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_typetest, clean_scopeall, clean_targetall”–permission-mode bypassPermissions–output-format json清理完成后再触发 api-test-executor 跑全量回归——保证每次回归的数据基线一致。场景四脚本修复重测前的数据隔离修完一个因为账号重复失败的脚本想立刻重测/api-testdata-cleaner 清理用户模块测试数据保留调试日志通过 keep_debug_datatrue清理脏数据但保留调试日志——既隔离数据又方便复盘。场景五按模块精细化清理只想清某个模块不动其他数据/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场景 3CI 流水线每日回归前 → 先执行清理再跑用例场景 4脚本修复完成重测前 → 先重置环境数据。配置灵活支持精细化管控可在 Skill 入参中定义规则按需清理支持全局清理 / 按业务模块清理用户 / 订单 / 购物车分离清理支持 “执行后自动清理” / “手动触发清理” 两种模式支持 “调试模式保留数据” / “正式回归强制清理” 开关。可独立迭代扩展后续新增数据表、缓存、第三方临时数据只需要更新 api-data-cleaner 这一个技能不用改动整条链路的核心代码迭代成本极低。测试验证效果用口语化的方式直接输入要清理的内容和范围/api-testdata-cleaner 清理数据库中重复的测试数据接收到提示词后会先连接当前测试环境被测项目的环境配置校验环境信息是否连接成功然后开始执行数据库测试数据清理操作。最终效果我还是挺满意的该删除的测试数据全部都删除了之前由我人工创建的数据也全部保留下来了没有被误删而且整个操作几乎是在几秒钟内完成期间没有任何人工介入的动作。除了控制台显示清理结果外还会单独生成一份markdown格式的数据清理报告方便后续留存数据清理完成后我们打开被测项目前端页面在前端页面上比之前干净多了页面上所有的测试数据全部被清理掉了)执行过程自动连接测试环境数据库校验环境信息识别测试数据特征含 test、测试等标识应用白名单保护规则分模块执行清理生成清理报告最终效果✅ 该删除的测试数据全部删除✅ 人工创建的数据全部保留没有被误删✅ 整个操作几秒钟完成✅ 全程无人工介入✅ 单独生成 markdown 格式的数据清理报告方便留存温馨提醒如果在新开会话中调用需要提供被测项目的路径这样它才能读取到项目配置文件。在连续会话中它会自动继承上下文的项目路径。五、适合谁用强烈推荐接口自动化测试工程师日常清理脏数据、解决 Flaky Test测试开发工程师搭建团队环境管理能力、CI 流水线全栈测试工程师希望降低环境维护门槛测试团队负责人希望提升环境稳定性、降低 Flaky Test 困扰特别适合Flaky Test 频发、数据污染严重的团队立竿见影多人协作、共享测试环境的团队避免数据互相污染CI/CD 流水线需要定时重置环境的团队测试数据量大、手动清理成本高的团队不太适合还没有自动化测试的团队没数据可清测试环境与生产环境共用的团队建议先做好环境隔离六、如何获取和安装api-testdata-cleaner GitHub 仓库地址git clone gitgithub.com:xxx/skills.git安装到 WorkBuddycp -r skills/api-testdata-cleaner ~/.workbuddy/skills/安装到 Claude Codecp -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 解决的就是这个源头——让测试环境始终干净、可控、可复用。
