用 AI 生成测试数据：效率提升与脱敏红线

测试数据不够，是测试覆盖不足最常见的原因。AI 能把"造数据"的时间压下来，但前提是永远不要把真实数据喂进去。

一、测试数据的三类需求

• 正常数据：符合业务规则的典型值，用来跑通主流程
• 边界数据：最大长度、最小金额、刚好到期、跨年跨月
• 异常数据：类型错误、空值、超长、特殊字符、重复键

人工造数据往往只覆盖第一类，因为后两类要一条条想，最费时间。AI 的价值恰好在这里：按规则批量枚举，比人想得全。

二、怎么提需求才有效

别说"帮我造 100 条用户数据"，要给规则和目的：

把表结构直接贴给它，比描述字段更准。生成后一定要在测试库执行一遍，看约束是否真的被满足。

三、脱敏红线：真实数据不出内网

1. 任何情况下不把生产数据（姓名、手机号、身份证、地址、病历、合同金额）直接贴给外部模型
2. 需要用真实分布做参考时，先统计后使用：只给"年龄 20–60，集中在 30–40"这类聚合描述
3. 必须用真实结构时，走本地部署模型或已完成脱敏的数据集
4. 生成数据里若出现与真实人物高度吻合的信息，视为脱敏失败，重新生成

法律上，个人信息即使"看起来是假的"，只要可还原到具体个人就仍受约束。这条红线不能靠"应该没事"来判断。

四、生成结果必须校验

• 格式：手机号、邮箱、身份证校验位是否合法
• 业务：状态与时间是否自洽（先下单后支付，不能倒序）
• 唯一性：主键、业务唯一键不重复
• 分布：不能全是极端值，否则测不出正常路径的性能

五、固化到流程里

1. 把常用数据集的生成提示词与校验脚本一起放进测试仓库
2. 按业务模块维护"数据种子"，接口变更时同步更新规则
3. 性能测试数据单独一套，量级按生产比例缩放，不要直接用功能测试数据
4. 定期回看：哪些缺陷是因为数据没覆盖到，反推补充哪类数据

做到这一步，造数据从"每次临时想"变成"随时可复现"，测试才真正稳定下来。