实战分享：测试数据准备太慢？我用脚本+AI建了个“数据工厂”

做功能测试，最耗时的往往不是“点页面”，而是“把数据准备齐”。合同、订单、成本、审批、权限……你只要少一个前置条件，后续流程就全卡住了；你只要用手在页面上点20次，半天时间可能就没了。

我在处理CRM这类流程长、角色多、数据重的项目时，后来干脆把“数据准备”这件事，做成了一个可复用的工具：输入几个参数，就能自动生成一套能跑通主流程的数据。我习惯叫它“数据工厂”。

这篇讲的不只是概念，都是我真正在项目里用过、能落地的做法，涵盖为什么要做、怎么做、如何避免翻车，以及怎么和测试用例、自动化测试配合。

1. 为什么数据准备会拖慢测试效率？

最典型的三种情况，你肯定遇到过：

• 手工创建慢：手动创建一条合同数据可能需要2分钟，200条就是400分钟，一整天基本就耗进去了。
• 容易出错：字段填错、状态选错、审批链路配错，测试跑到一半才发现数据不对，一切又得重来。
• 环境不一致：你测试用的是A套数据，开发复现问题时用的是B套数据，来回拉扯，定位问题困难。

所以我后来给自己定了个要求：测试数据必须可重复、可批量、可追溯。否则，测试工作只会越做越慢，越做越乱。

2. “数据工厂”的目标其实很简单

我不追求一开始就“覆盖所有场景”，而是先把最刚需的路径打通：

• 能快速生成主流程数据：例如“合同创建 → 提交审批 → 审批通过/驳回”这条核心链路。
• 能批量生成：无论是几十条还是几百条测试数据，脚本都能稳定处理。
• 能回放追溯：出了问题，能立刻知道这条数据是谁、在何时、用什么参数生成的。
• 能和自动化衔接：UI回归或接口测试脚本运行时，无需再手动点击造数据。

一句话总结：就是把数据准备从依赖个人经验的“手艺活”，变成可随时调用的“标准件”。

3. 实现拆解：先定义“最小可跑通数据集”

先别急着动手写脚本，第一步是把“最小数据集”的定义弄清楚，否则你会在编码过程中不断返工。

以CRM类项目为例，我会先梳理一份“最小可跑通数据集”清单：

• 主体数据：合同或订单的基础字段（名称、关联客户、金额、日期等）。
• 关联数据：成本预占记录、关联工单、广告位或资源占用等（根据具体系统而定）。
• 角色与权限：至少包含创建人、审批人、财务等两到三个关键角色账号。
• 流程状态：覆盖草稿、已提交、审批中、已通过、已驳回等关键状态节点。
• 可验证点：确保生成的数据在列表可查询、详情页能打开、状态可按预期变化。

先把这份清单写出来，后续的脚本开发就会目标明确：所有逻辑都围绕这份数据集进行参数化扩展。

4. 实现方式的选择：优先接口，其次UI

在实际项目中，最省心高效的组合是：

• 接口调用造数据（主力）：速度快、稳定性高、非常适合批量操作。
• UI操作验证流程（辅助）：仅用于验证关键链路的页面表现，不承担大量的数据创建工作。

很多人一开始就试图用UI自动化来造数据，结果往往是：执行缓慢、脚本脆弱，还极易受前端页面改动的波及。

如果项目有开放的API、内部接口，或者可以通过抓包复现请求，那就优先采用接口方式。即使暂时没有现成接口也没关系，可以先通过UI操作造出一套“基准数据”，再逐步分析、封装出独立的接口调用函数。

5. 常用的参数化设计（实战够用版）

我通常把输入参数控制在5个以内，越少越容易使用和维护：

• count：需要生成的数据条数。
• bu：业务单元（对于那些有多个业务线的老系统特别有用）。
• role_set：角色组合，例如“创建人+审批人+财务”。
• template：数据模板，用于区分不同产品线或场景的字段差异。
• mode：生成模式，如“单条”或“批量”。

对于输出数据，我也固定格式，以确保可追溯性：

• contract_id / contract_no
• creator / approver
• created_at
• status
• trace_id （最关键，用于唯一标识和追踪本次生成任务）

6. 避坑指南：数据工厂最容易翻车的4个点

• 唯一性约束不足：合同名称、编号等字段写死固定值，脚本跑第二轮就会因重复而失败。解决办法是强制加入唯一性标识，如“时间戳+随机数”。
• 状态未最终落库：调用创建接口成功了，但关联的审批流可能还未走完，此时立刻去列表查询断言会失败。解决办法是加入等待机制，轮询查询直到状态落库。
• 权限串号或缓存问题：多角色在同一浏览器上下文切换时，可能导致数据可见性异常。解决办法是做好测试账号的隔离，例如使用独立的浏览器会话。
• 环境差异导致失败：测试环境的字段校验规则、默认值等与预发/生产环境不一致。解决办法是将字段值模板化，并与环境配置关联。

踩过这些坑后你就会明白：构建数据工厂不仅仅是“写个脚本”，本质上是“将数据准备规则工程化”。

7. AI如何靠谱地助力数据工厂？

我不用AI来“直接生成最终可用的脚本”，而是用它来完成三件事，这样效果更稳定可控：

• 梳理手工步骤为Checklist：让AI帮你理清创建路径、所有必填字段以及复杂的依赖关系。
• 辅助设计参数表：分析哪些字段可作为变量、哪些必须固定、哪些会直接影响业务流程。
• 生成代码骨架：提供函数结构、参数校验逻辑、标准输出格式的初步代码框架。

我最常使用的提示词句式如下（你可以直接复用）：

“我需要构建一个测试数据工厂，目标是批量创建【合同/订单】数据，并完成【提交审批/审批通过】的流程。请输出：最小可跑通数据集清单、字段间的依赖关系、参数化设计的建议、数据生成后的回收或清理策略，以及脚本项目的目录结构建议。”

AI输出的内容我只当作高质量的初稿，最终一定要结合自己项目的实际业务逻辑进行确认和调整。

8. 数据工厂带来的测试节奏变化

变化最明显的体现在三个方面：

• 用例评审更快：测试用例中可以直接写明“使用模板A数据集”，无需再花费时间讨论和描述如何准备数据。
• 回归测试更快：在开始回归测试前，只需5分钟批量生成所需数据，自动化脚本便可直接运行验证。
• 问题复现更快：提交缺陷单时直接附上生成数据时的 trace_id，开发人员可以一键复现完全相同的测试场景。

尤其在项目排期紧张的时候，一个可靠的数据工厂能把你从“数据准备焦虑”中彻底解放出来。

9. 给你的起步建议

不要一开始就试图做一个“大而全”的数据工厂。选择一个当前最痛点的主流程链路入手，例如：

• 合同创建 + 审批流
• 商品下单 + 库存成本预占
• 礼品卡批量入库 + 用户领取 + 余额消耗

只要把这一条链路做成“输入参数 → 生成数据 → 完成验证”的闭环，你在测试效率上的提升就已经超过了大多数团队。

希望这篇来自真实项目的经验总结对你有启发。如果你在构建自己的数据工厂过程中有其他心得或疑问，欢迎到云栈社区的测试与运维板块交流讨论。