1. 测试数据生成这件事为什么值得单独拎出来聊做开发、做测试的人都有一个共识功能代码写完了只是开始真正折磨人的是“拿什么数据来跑”。一个订单系统你写完了下单逻辑想验证并发扣库存有没有问题结果手头只有三条手工录入的假数据连分页都翻不满一页更别提压测了。一个用户画像模块你想验证标签命中率结果数据库里只有“张三、李四、王五”三个名字性别全是男年龄全是 18 岁这种数据跑出来的结果没有任何参考价值。所以测试数据生成从来不是“随便造几条”的小事它直接决定了你的测试覆盖率、缺陷发现率以及上线之后会不会被真实数据打脸。我见过太多团队在项目后期才想起来补数据临时写脚本、临时改字段最后数据之间外键对不上跑一半报错排查半天发现是造数据的人把用户 ID 和订单 ID 搞混了。这个内容要聊的就是测试数据生成这件事到底有多少种做法六款常用工具各自适合什么场景以及现在用 AI 来生成测试数据到底靠不靠谱、怎么落地。不管你是刚入行的测试新人还是带了几年团队的老手只要你还在一线跟数据打交道这篇内容都能让你少走一些弯路。我会把每款工具的适用边界、参数配置、踩坑点都摊开讲最后重点说说 AI 生成这条路子怎么用才不翻车。2. 六款主流测试数据生成工具横向拆解2.1 工具选型之前先搞清楚你的数据需求属于哪一类在推荐工具之前我必须先泼一盆冷水没有一款工具能通吃所有场景。你在选工具之前先问自己三个问题。第一个问题你要的是结构化数据还是非结构化数据结构化就是数据库表里的行和列字段类型明确有主外键约束非结构化就是文本、图片、日志、JSON 嵌套文档这类格式松散但内容有语义要求。第二个问题你的数据量级是百条级、万条级还是百万级百条级手工写都行万条级需要脚本或工具百万级就得考虑生成效率和存储开销了。第三个问题数据之间有没有关联约束比如订单表里的 user_id 必须能在用户表里找到商品价格必须大于 0创建时间不能晚于支付时间。有约束的数据生成难度直接上一个台阶。把这三个问题想清楚你基本就能锁定工具范围了。下面这六款是我在实际项目里反复用过的各有各的脾气。2.2 六款工具的能力对比与适用场景先上一张对比表把核心差异摆出来后面再逐个展开。工具类型代表方案数据关联性学习成本适合量级典型场景在线数据生成器某在线 Mock 平台弱极低百条级前端联调、接口 Mock命令行生成工具某 Faker 类库中低万条级单元测试、数据库填充数据库内置函数SQL 随机函数弱低万条级快速造简单表数据专用数据工厂某数据构造框架强中高百万级集成测试、压测录制回放工具流量录制方案强中取决于流量回归测试、真实场景复现脚本自研Python/Java 脚本完全可控中任意复杂业务约束场景这张表不是让你背下来的是让你在选型时有个参照。我逐个说一下实际使用中的感受。在线数据生成器最大的优势是快打开网页选字段类型点生成复制粘贴就能用。但它的问题也很明显数据之间没有关联生成的 100 个用户和 100 个订单user_id 对不上。所以它只适合前端联调阶段后端逻辑测试千万别用它。命令行生成工具是我用得最多的。以 Python 的 Faker 类库为例一行代码就能生成姓名、地址、邮箱、手机号而且支持多语言。它的关联性可以通过代码控制比如先生成用户列表再从用户列表里随机取 ID 生成订单。缺点是数据量大了之后内存占用高百万级需要分批写入。数据库内置函数适合应急。比如 MySQL 的 RAND() 配合 INSERT INTO SELECT几行 SQL 就能造出几万条数据。但它生成的数据太“假”了姓名全是“user_12345”地址全是“address_1”只能用来测分页和基本查询业务逻辑测试指望不上。专用数据工厂是给专业测试团队用的支持定义数据模型、字段规则、关联关系还能控制生成速率和分布。学习曲线陡但一旦配好复用性极强。我之前在一个金融项目里用它造了 50 万条交易流水关联了用户、账户、商户三张表跑批测试一次通过。录制回放工具的思路不一样它不是“造”数据而是“抄”数据。把生产环境的流量录下来脱敏之后在测试环境回放。优点是数据绝对真实缺点是依赖生产流量而且脱敏不彻底会有合规风险。脚本自研是最灵活的也是最累的。业务约束越复杂自研脚本的价值越大。比如“VIP 用户的订单金额必须是普通用户的 1.5 倍以上且订单创建时间必须在工作日 9 点到 18 点之间”这种规则用现成工具很难配但写个 Python 脚本就是几行判断的事。提示选工具的时候不要追求“一步到位”先用最简单的方案把流程跑通遇到瓶颈再换。我见过太多人一上来就搭数据工厂结果配了两天规则业务需求变了全白干。3. 用 AI 生成测试数据到底怎么落地3.1 AI 生成数据的核心逻辑从“规则驱动”到“语义驱动”传统工具生成数据的逻辑是规则驱动你告诉它字段类型是字符串长度 10它就随机拼 10 个字符。至于这 10 个字符是“张三”还是“asdfghjkl”它不关心。AI 生成数据的逻辑是语义驱动你告诉它“生成一条用户投诉记录投诉内容是物流太慢情绪偏负面”它会生成一段像人写的投诉文本而不是随机字符串。这是本质区别。这个区别带来的价值在于当你的测试需要“像真实业务数据”而不是“像数据库字段”时AI 的优势就出来了。比如测试一个情感分析模块你用 Faker 生成的“用户评论”全是乱码模型根本跑不出结果但用 AI 生成的评论有褒有贬有长有短测试才有意义。AI 生成测试数据目前主要有三种落地方式。第一种是直接调用大模型 API把字段说明和约束写成提示词让模型返回 JSON 格式的数据。这种方式最灵活但要注意控制返回格式否则模型可能给你返回一段散文。第二种是用 AI 辅助写生成脚本。你把业务规则描述给 AI让它帮你写 Python 脚本你审核后运行。这种方式适合规则复杂但数据格式固定的场景AI 帮你省的是写代码的时间不是生成数据的时间。第三种是用 AI 做数据增强。你已经有了一批真实数据比如 1000 条脱敏后的用户反馈让 AI 基于这些数据生成更多相似的变体扩充测试集。这种方式在算法测试里特别常见。3.2 提示词怎么写才能让 AI 吐出可用的数据这是实操中最关键的一步。我见过很多人写提示词就一句话“生成 100 条用户数据”结果 AI 返回一堆格式不统一的文本根本没法解析。正确的做法是把 AI 当成一个刚入职的实习生你要把字段名、类型、取值范围、格式要求、关联关系全部说清楚。下面是我常用的提示词模板你可以直接抄。你是一个测试数据生成器。请生成 50 条用户表数据以 JSON 数组格式返回不要有任何额外说明文字。 字段要求 - user_id整数从 10001 开始递增 - user_name中文姓名2-3 个字 - age整数18-65 之间 - gender枚举值只能是 男 或 女 - city中国一线城市名称 - register_time日期时间格式 YYYY-MM-DD HH:mm:ss范围在 2023-01-01 到 2024-12-31 之间 - vip_level整数0-3 之间0 表示非会员 约束 - 年龄大于 60 的用户vip_level 不能为 3 - register_time 必须按时间先后顺序排列这个提示词的关键点在于明确输出格式JSON 数组、明确字段类型和范围、明确约束条件、明确不要额外文字。实测下来这样写提示词AI 返回的数据 90% 以上可以直接用剩下 10% 可能需要微调。还有一个技巧分批生成。不要一次性让 AI 生成 1000 条它可能会偷懒或者格式错乱。每次生成 50 到 100 条多跑几次然后合并。这样既保证了质量也方便排查问题。注意AI 生成的数据一定要做格式校验。我踩过的坑是AI 有时候会把数字写成字符串比如 age: 25 而不是 age: 25如果你的代码直接入库类型不匹配就会报错。所以生成之后跑一遍校验脚本把不符合类型的数据过滤掉或者修正。3.3 AI 生成数据的边界哪些场景千万别用AI 不是万能的有些场景用它就是给自己找麻烦。第一涉及精确计算的场景。比如你要生成一批订单数据要求“订单总金额 商品单价 × 数量 运费 - 优惠券”这种精确的数学关系AI 经常算错。它可能会给你一个总金额 100但单价 30、数量 3、运费 10、优惠券 5算下来对不上。这种场景还是用脚本生成AI 只负责生成商品名称、用户备注这类文本字段。第二数据量极大的场景。百万级数据用 AI 生成成本高、速度慢而且没必要。这种场景用 Faker 类库或者数据工厂AI 只用来生成其中需要语义的字段比如商品描述、用户评论。第三有严格合规要求的场景。AI 生成的数据可能包含训练数据里的真实信息片段虽然概率很低但一旦出现就是事故。所以涉及个人隐私、商业机密的测试数据要么用脱敏后的真实数据要么用规则工具生成不要用 AI。第四需要精确控制数据分布的场景。比如你要测试一个推荐算法要求用户年龄符合正态分布性别比例 6:4地域分布按真实城市人口比例。这种精确的分布控制AI 做不到必须用脚本按概率生成。我个人的经验是AI 负责“像”脚本负责“准”。两者结合才是最高效的方案。4. 从零搭建一套可复用的测试数据生成流程4.1 第一步定义数据模型和约束规则不管你用什么工具第一步永远是把数据模型写清楚。我习惯用一个 YAML 文件来描述因为 YAML 比 JSON 好写注释比 Excel 好做版本管理。table: user fields: - name: user_id type: integer start: 10001 step: 1 - name: user_name type: string generator: ai prompt: 中文姓名2-3个字 - name: age type: integer min: 18 max: 65 - name: gender type: enum values: [男, 女] weights: [0.55, 0.45] - name: city type: string generator: faker faker_type: city - name: register_time type: datetime start: 2023-01-01 00:00:00 end: 2024-12-31 23:59:59 order: ascending constraints: - age 60 vip_level ! 3这个文件的好处是人和机器都能读。人看了一目了然机器可以直接解析成生成逻辑。字段的 generator 标记了用哪种方式生成ai 走 AI 接口faker 走本地类库integer 走随机数。约束条件单独列出来方便校验。4.2 第二步分层生成先主表后从表数据关联是造数据最容易翻车的地方。我的做法是分层生成先做主表用户表再做从表订单表从表的外键从主表的主键里随机取。具体操作上先生成用户列表存到一个临时文件或者内存里。然后生成订单的时候每生成一条订单就从用户列表里随机选一个 user_id 填进去。这样保证订单的 user_id 一定能在用户表里找到。如果关联层级更深比如用户 → 订单 → 订单详情 → 商品那就一层一层往下生成。每一层都依赖上一层的输出。这种方式的缺点是内存占用高但数据量在百万级以内都可以接受。超过百万级就要考虑用数据库临时表来存中间结果。提示生成关联数据的时候记得控制关联比例。比如不是每个用户都有订单你可以设定 70% 的用户有 1-5 条订单30% 的用户没有订单。这样更接近真实业务场景也能测试到“无订单用户”的分支逻辑。4.3 第三步数据校验与清洗生成完数据不要直接入库先跑一遍校验。校验分三层。第一层是格式校验字段类型对不对日期格式对不对枚举值在不在范围内。这一层用 JSON Schema 或者自定义校验脚本都能做。第二层是业务校验约束条件有没有被违反。比如“年龄大于 60 的用户 vip_level 不能为 3”这种规则要单独写校验逻辑。第三层是关联校验外键能不能找到对应的主键关联数量对不对。比如订单表里的 user_id 是不是都在用户表里存在。校验不通过的数据要么丢弃要么修正。我一般选择丢弃并记录日志因为修正的成本可能比重新生成还高。但如果丢弃率超过 10%说明生成规则有问题需要调整提示词或者参数。4.4 第四步入库与性能优化数据校验通过之后就是入库。入库的性能优化有几个关键点。批量插入比单条插入快得多。MySQL 的 INSERT INTO ... VALUES (...), (...), ... 一次插 1000 条比循环插 1000 次快几十倍。但要注意 max_allowed_packet 参数一次插太多可能会超限。关闭索引和约束再插入插完再重建。对于百万级数据这个优化能把入库时间从几小时缩短到几分钟。但要注意关闭约束期间不能有脏数据写入否则重建索引会失败。分批提交每 1000 条或 5000 条提交一次事务。事务太大容易锁表太小又频繁 IO。我一般用 2000 条一批实测下来比较均衡。# 批量入库示例 import pymysql conn pymysql.connect(hostlocalhost, usertest, passwordtest, databasetest_db) cursor conn.cursor() batch_size 2000 for i in range(0, len(data), batch_size): batch data[i:ibatch_size] sql INSERT INTO user (user_id, user_name, age, gender, city) VALUES (%s, %s, %s, %s, %s) cursor.executemany(sql, batch) conn.commit() print(f已插入 {min(ibatch_size, len(data))} 条) cursor.close() conn.close()这段代码是我常用的模板改一下 SQL 和字段就能复用。注意 executemany 的参数格式是列表套元组每个元组对应一条记录。5. 实操中踩过的坑与排查技巧5.1 数据生成常见问题速查表问题现象可能原因排查方法解决方案AI 返回格式不是 JSON提示词没强调格式检查提示词是否明确要求 JSON在提示词开头加“只返回 JSON不要任何说明文字”生成的数据外键对不上关联逻辑没做或做错了抽样检查从表外键是否在主表中分层生成从表外键从主表主键池中取入库速度极慢单条插入或索引过多查看 SQL 执行计划批量插入临时关闭索引数据分布不均匀随机函数有偏或权重没配统计各枚举值的数量用加权随机代替均匀随机AI 生成的数据有重复提示词没要求唯一性去重统计提示词加“所有 user_name 不重复”日期顺序错乱生成时没排序检查日期字段是否按序生成后按日期排序再入库内存溢出一次性加载太多数据监控内存使用分批生成、分批入库这张表里的问题我几乎每一个都遇到过。重点说几个印象深刻的。AI 返回格式问题是最常见的。有一次我让 AI 生成 100 条商品数据提示词里写了“返回 JSON”结果它返回了一个 Markdown 代码块里面才是 JSON。我的解析脚本直接报错。后来我在提示词里加了一句“不要用 Markdown 代码块包裹直接返回纯 JSON 文本”问题就解决了。外键对不上这个问题根源在于生成顺序。如果你先生成订单再生成用户订单里的 user_id 就是瞎编的用户表里根本没有。所以一定要先主后从这个顺序不能乱。数据分布不均匀是个隐蔽的坑。比如你用随机数生成性别理论上男女各 50%但实际跑出来可能 70% 是男。这是因为随机函数的分布特性数据量小的时候偏差更明显。解决办法是用加权随机或者生成后做一次平衡调整。5.2 几个让我省下大量时间的实操技巧技巧一用固定随机种子。生成数据的时候如果每次结果都不一样排查问题就很麻烦。设置一个固定的随机种子每次生成的数据序列完全一致方便复现和对比。Python 的 random.seed(42) 或者 numpy 的 np.random.seed(42) 都能做到。技巧二生成数据的同时生成校验报告。不要等入库之后才发现问题生成完立刻跑校验输出一份报告总条数、各字段空值率、枚举值分布、约束违反数量。这份报告就是你判断数据质量的依据。技巧三把生成配置和生成脚本分开。配置字段规则、约束条件放在 YAML 或 JSON 文件里脚本只负责读取配置并执行。这样业务规则变了改配置文件就行不用动代码。团队协作的时候测试人员可以自己改配置不需要开发介入。技巧四AI 生成的数据一定要人工抽检。不要因为 AI 说“已生成 100 条”就信了。随机抽 10 条出来看看姓名是不是像人名地址是不是像地址评论是不是像人话。我抽检的时候发现过 AI 生成的“中文姓名”里混进了英文名还有一次生成的“城市”里出现了“纽约”。抽检花不了几分钟但能避免大问题。提示如果你用 AI 生成的数据做自动化测试的输入建议把生成结果缓存起来。同一个测试用例每次跑都用同一批数据避免因为数据变化导致测试结果不稳定。缓存文件用版本号管理需要新数据的时候再重新生成。6. 关于测试数据生成我个人的几点体会做了这么多年测试和数据相关工作我最大的体会是测试数据生成不是技术问题是意识问题。很多团队不是不会造数据是根本没把造数据当回事。等到测试跑不起来、缺陷漏到线上才回头补课。六款工具也好AI 也好都只是手段。核心是你得清楚你的测试需要什么样的数据。是只需要字段格式对还是需要业务语义对是只需要单表数据还是需要多表关联是只需要百条级还是需要百万级想清楚这些工具选型就是水到渠成的事。AI 生成测试数据这条路我的建议是先用起来再优化。不要一上来就追求完美提示词先跑通一个简单场景比如生成用户评论看看效果。效果好了再扩展到其他字段效果不好就调整提示词或者换回规则工具。AI 不是替代传统工具是补充传统工具覆盖不到的场景。最后分享一个小技巧把你常用的提示词和生成脚本存成一个模板库。下次遇到类似场景直接改字段名和范围就能用不用从头写。我自己的模板库里存了二十多个提示词模板覆盖用户、订单、商品、日志、评论等常见场景新项目直接复用效率提升非常明显。这个方向后续还可以往数据血缘追踪上扩展就是记录每一条测试数据是怎么生成的、经过了哪些处理、被哪些测试用例使用了。这样当测试结果异常时可以快速定位是数据问题还是代码问题。我现在正在尝试用元数据管理的方式来做这件事等跑通了再单独写一篇分享。
1. 测试数据生成这件事为什么值得单独拎出来聊做开发、做测试的人都有一个共识功能代码写完了只是开始真正折磨人的是“拿什么数据来跑”。一个订单系统你写完了下单逻辑想验证并发扣库存有没有问题结果手头只有三条手工录入的假数据连分页都翻不满一页更别提压测了。一个用户画像模块你想验证标签命中率结果数据库里只有“张三、李四、王五”三个名字性别全是男年龄全是 18 岁这种数据跑出来的结果没有任何参考价值。所以测试数据生成从来不是“随便造几条”的小事它直接决定了你的测试覆盖率、缺陷发现率以及上线之后会不会被真实数据打脸。我见过太多团队在项目后期才想起来补数据临时写脚本、临时改字段最后数据之间外键对不上跑一半报错排查半天发现是造数据的人把用户 ID 和订单 ID 搞混了。这个内容要聊的就是测试数据生成这件事到底有多少种做法六款常用工具各自适合什么场景以及现在用 AI 来生成测试数据到底靠不靠谱、怎么落地。不管你是刚入行的测试新人还是带了几年团队的老手只要你还在一线跟数据打交道这篇内容都能让你少走一些弯路。我会把每款工具的适用边界、参数配置、踩坑点都摊开讲最后重点说说 AI 生成这条路子怎么用才不翻车。2. 六款主流测试数据生成工具横向拆解2.1 工具选型之前先搞清楚你的数据需求属于哪一类在推荐工具之前我必须先泼一盆冷水没有一款工具能通吃所有场景。你在选工具之前先问自己三个问题。第一个问题你要的是结构化数据还是非结构化数据结构化就是数据库表里的行和列字段类型明确有主外键约束非结构化就是文本、图片、日志、JSON 嵌套文档这类格式松散但内容有语义要求。第二个问题你的数据量级是百条级、万条级还是百万级百条级手工写都行万条级需要脚本或工具百万级就得考虑生成效率和存储开销了。第三个问题数据之间有没有关联约束比如订单表里的 user_id 必须能在用户表里找到商品价格必须大于 0创建时间不能晚于支付时间。有约束的数据生成难度直接上一个台阶。把这三个问题想清楚你基本就能锁定工具范围了。下面这六款是我在实际项目里反复用过的各有各的脾气。2.2 六款工具的能力对比与适用场景先上一张对比表把核心差异摆出来后面再逐个展开。工具类型代表方案数据关联性学习成本适合量级典型场景在线数据生成器某在线 Mock 平台弱极低百条级前端联调、接口 Mock命令行生成工具某 Faker 类库中低万条级单元测试、数据库填充数据库内置函数SQL 随机函数弱低万条级快速造简单表数据专用数据工厂某数据构造框架强中高百万级集成测试、压测录制回放工具流量录制方案强中取决于流量回归测试、真实场景复现脚本自研Python/Java 脚本完全可控中任意复杂业务约束场景这张表不是让你背下来的是让你在选型时有个参照。我逐个说一下实际使用中的感受。在线数据生成器最大的优势是快打开网页选字段类型点生成复制粘贴就能用。但它的问题也很明显数据之间没有关联生成的 100 个用户和 100 个订单user_id 对不上。所以它只适合前端联调阶段后端逻辑测试千万别用它。命令行生成工具是我用得最多的。以 Python 的 Faker 类库为例一行代码就能生成姓名、地址、邮箱、手机号而且支持多语言。它的关联性可以通过代码控制比如先生成用户列表再从用户列表里随机取 ID 生成订单。缺点是数据量大了之后内存占用高百万级需要分批写入。数据库内置函数适合应急。比如 MySQL 的 RAND() 配合 INSERT INTO SELECT几行 SQL 就能造出几万条数据。但它生成的数据太“假”了姓名全是“user_12345”地址全是“address_1”只能用来测分页和基本查询业务逻辑测试指望不上。专用数据工厂是给专业测试团队用的支持定义数据模型、字段规则、关联关系还能控制生成速率和分布。学习曲线陡但一旦配好复用性极强。我之前在一个金融项目里用它造了 50 万条交易流水关联了用户、账户、商户三张表跑批测试一次通过。录制回放工具的思路不一样它不是“造”数据而是“抄”数据。把生产环境的流量录下来脱敏之后在测试环境回放。优点是数据绝对真实缺点是依赖生产流量而且脱敏不彻底会有合规风险。脚本自研是最灵活的也是最累的。业务约束越复杂自研脚本的价值越大。比如“VIP 用户的订单金额必须是普通用户的 1.5 倍以上且订单创建时间必须在工作日 9 点到 18 点之间”这种规则用现成工具很难配但写个 Python 脚本就是几行判断的事。提示选工具的时候不要追求“一步到位”先用最简单的方案把流程跑通遇到瓶颈再换。我见过太多人一上来就搭数据工厂结果配了两天规则业务需求变了全白干。3. 用 AI 生成测试数据到底怎么落地3.1 AI 生成数据的核心逻辑从“规则驱动”到“语义驱动”传统工具生成数据的逻辑是规则驱动你告诉它字段类型是字符串长度 10它就随机拼 10 个字符。至于这 10 个字符是“张三”还是“asdfghjkl”它不关心。AI 生成数据的逻辑是语义驱动你告诉它“生成一条用户投诉记录投诉内容是物流太慢情绪偏负面”它会生成一段像人写的投诉文本而不是随机字符串。这是本质区别。这个区别带来的价值在于当你的测试需要“像真实业务数据”而不是“像数据库字段”时AI 的优势就出来了。比如测试一个情感分析模块你用 Faker 生成的“用户评论”全是乱码模型根本跑不出结果但用 AI 生成的评论有褒有贬有长有短测试才有意义。AI 生成测试数据目前主要有三种落地方式。第一种是直接调用大模型 API把字段说明和约束写成提示词让模型返回 JSON 格式的数据。这种方式最灵活但要注意控制返回格式否则模型可能给你返回一段散文。第二种是用 AI 辅助写生成脚本。你把业务规则描述给 AI让它帮你写 Python 脚本你审核后运行。这种方式适合规则复杂但数据格式固定的场景AI 帮你省的是写代码的时间不是生成数据的时间。第三种是用 AI 做数据增强。你已经有了一批真实数据比如 1000 条脱敏后的用户反馈让 AI 基于这些数据生成更多相似的变体扩充测试集。这种方式在算法测试里特别常见。3.2 提示词怎么写才能让 AI 吐出可用的数据这是实操中最关键的一步。我见过很多人写提示词就一句话“生成 100 条用户数据”结果 AI 返回一堆格式不统一的文本根本没法解析。正确的做法是把 AI 当成一个刚入职的实习生你要把字段名、类型、取值范围、格式要求、关联关系全部说清楚。下面是我常用的提示词模板你可以直接抄。你是一个测试数据生成器。请生成 50 条用户表数据以 JSON 数组格式返回不要有任何额外说明文字。 字段要求 - user_id整数从 10001 开始递增 - user_name中文姓名2-3 个字 - age整数18-65 之间 - gender枚举值只能是 男 或 女 - city中国一线城市名称 - register_time日期时间格式 YYYY-MM-DD HH:mm:ss范围在 2023-01-01 到 2024-12-31 之间 - vip_level整数0-3 之间0 表示非会员 约束 - 年龄大于 60 的用户vip_level 不能为 3 - register_time 必须按时间先后顺序排列这个提示词的关键点在于明确输出格式JSON 数组、明确字段类型和范围、明确约束条件、明确不要额外文字。实测下来这样写提示词AI 返回的数据 90% 以上可以直接用剩下 10% 可能需要微调。还有一个技巧分批生成。不要一次性让 AI 生成 1000 条它可能会偷懒或者格式错乱。每次生成 50 到 100 条多跑几次然后合并。这样既保证了质量也方便排查问题。注意AI 生成的数据一定要做格式校验。我踩过的坑是AI 有时候会把数字写成字符串比如 age: 25 而不是 age: 25如果你的代码直接入库类型不匹配就会报错。所以生成之后跑一遍校验脚本把不符合类型的数据过滤掉或者修正。3.3 AI 生成数据的边界哪些场景千万别用AI 不是万能的有些场景用它就是给自己找麻烦。第一涉及精确计算的场景。比如你要生成一批订单数据要求“订单总金额 商品单价 × 数量 运费 - 优惠券”这种精确的数学关系AI 经常算错。它可能会给你一个总金额 100但单价 30、数量 3、运费 10、优惠券 5算下来对不上。这种场景还是用脚本生成AI 只负责生成商品名称、用户备注这类文本字段。第二数据量极大的场景。百万级数据用 AI 生成成本高、速度慢而且没必要。这种场景用 Faker 类库或者数据工厂AI 只用来生成其中需要语义的字段比如商品描述、用户评论。第三有严格合规要求的场景。AI 生成的数据可能包含训练数据里的真实信息片段虽然概率很低但一旦出现就是事故。所以涉及个人隐私、商业机密的测试数据要么用脱敏后的真实数据要么用规则工具生成不要用 AI。第四需要精确控制数据分布的场景。比如你要测试一个推荐算法要求用户年龄符合正态分布性别比例 6:4地域分布按真实城市人口比例。这种精确的分布控制AI 做不到必须用脚本按概率生成。我个人的经验是AI 负责“像”脚本负责“准”。两者结合才是最高效的方案。4. 从零搭建一套可复用的测试数据生成流程4.1 第一步定义数据模型和约束规则不管你用什么工具第一步永远是把数据模型写清楚。我习惯用一个 YAML 文件来描述因为 YAML 比 JSON 好写注释比 Excel 好做版本管理。table: user fields: - name: user_id type: integer start: 10001 step: 1 - name: user_name type: string generator: ai prompt: 中文姓名2-3个字 - name: age type: integer min: 18 max: 65 - name: gender type: enum values: [男, 女] weights: [0.55, 0.45] - name: city type: string generator: faker faker_type: city - name: register_time type: datetime start: 2023-01-01 00:00:00 end: 2024-12-31 23:59:59 order: ascending constraints: - age 60 vip_level ! 3这个文件的好处是人和机器都能读。人看了一目了然机器可以直接解析成生成逻辑。字段的 generator 标记了用哪种方式生成ai 走 AI 接口faker 走本地类库integer 走随机数。约束条件单独列出来方便校验。4.2 第二步分层生成先主表后从表数据关联是造数据最容易翻车的地方。我的做法是分层生成先做主表用户表再做从表订单表从表的外键从主表的主键里随机取。具体操作上先生成用户列表存到一个临时文件或者内存里。然后生成订单的时候每生成一条订单就从用户列表里随机选一个 user_id 填进去。这样保证订单的 user_id 一定能在用户表里找到。如果关联层级更深比如用户 → 订单 → 订单详情 → 商品那就一层一层往下生成。每一层都依赖上一层的输出。这种方式的缺点是内存占用高但数据量在百万级以内都可以接受。超过百万级就要考虑用数据库临时表来存中间结果。提示生成关联数据的时候记得控制关联比例。比如不是每个用户都有订单你可以设定 70% 的用户有 1-5 条订单30% 的用户没有订单。这样更接近真实业务场景也能测试到“无订单用户”的分支逻辑。4.3 第三步数据校验与清洗生成完数据不要直接入库先跑一遍校验。校验分三层。第一层是格式校验字段类型对不对日期格式对不对枚举值在不在范围内。这一层用 JSON Schema 或者自定义校验脚本都能做。第二层是业务校验约束条件有没有被违反。比如“年龄大于 60 的用户 vip_level 不能为 3”这种规则要单独写校验逻辑。第三层是关联校验外键能不能找到对应的主键关联数量对不对。比如订单表里的 user_id 是不是都在用户表里存在。校验不通过的数据要么丢弃要么修正。我一般选择丢弃并记录日志因为修正的成本可能比重新生成还高。但如果丢弃率超过 10%说明生成规则有问题需要调整提示词或者参数。4.4 第四步入库与性能优化数据校验通过之后就是入库。入库的性能优化有几个关键点。批量插入比单条插入快得多。MySQL 的 INSERT INTO ... VALUES (...), (...), ... 一次插 1000 条比循环插 1000 次快几十倍。但要注意 max_allowed_packet 参数一次插太多可能会超限。关闭索引和约束再插入插完再重建。对于百万级数据这个优化能把入库时间从几小时缩短到几分钟。但要注意关闭约束期间不能有脏数据写入否则重建索引会失败。分批提交每 1000 条或 5000 条提交一次事务。事务太大容易锁表太小又频繁 IO。我一般用 2000 条一批实测下来比较均衡。# 批量入库示例 import pymysql conn pymysql.connect(hostlocalhost, usertest, passwordtest, databasetest_db) cursor conn.cursor() batch_size 2000 for i in range(0, len(data), batch_size): batch data[i:ibatch_size] sql INSERT INTO user (user_id, user_name, age, gender, city) VALUES (%s, %s, %s, %s, %s) cursor.executemany(sql, batch) conn.commit() print(f已插入 {min(ibatch_size, len(data))} 条) cursor.close() conn.close()这段代码是我常用的模板改一下 SQL 和字段就能复用。注意 executemany 的参数格式是列表套元组每个元组对应一条记录。5. 实操中踩过的坑与排查技巧5.1 数据生成常见问题速查表问题现象可能原因排查方法解决方案AI 返回格式不是 JSON提示词没强调格式检查提示词是否明确要求 JSON在提示词开头加“只返回 JSON不要任何说明文字”生成的数据外键对不上关联逻辑没做或做错了抽样检查从表外键是否在主表中分层生成从表外键从主表主键池中取入库速度极慢单条插入或索引过多查看 SQL 执行计划批量插入临时关闭索引数据分布不均匀随机函数有偏或权重没配统计各枚举值的数量用加权随机代替均匀随机AI 生成的数据有重复提示词没要求唯一性去重统计提示词加“所有 user_name 不重复”日期顺序错乱生成时没排序检查日期字段是否按序生成后按日期排序再入库内存溢出一次性加载太多数据监控内存使用分批生成、分批入库这张表里的问题我几乎每一个都遇到过。重点说几个印象深刻的。AI 返回格式问题是最常见的。有一次我让 AI 生成 100 条商品数据提示词里写了“返回 JSON”结果它返回了一个 Markdown 代码块里面才是 JSON。我的解析脚本直接报错。后来我在提示词里加了一句“不要用 Markdown 代码块包裹直接返回纯 JSON 文本”问题就解决了。外键对不上这个问题根源在于生成顺序。如果你先生成订单再生成用户订单里的 user_id 就是瞎编的用户表里根本没有。所以一定要先主后从这个顺序不能乱。数据分布不均匀是个隐蔽的坑。比如你用随机数生成性别理论上男女各 50%但实际跑出来可能 70% 是男。这是因为随机函数的分布特性数据量小的时候偏差更明显。解决办法是用加权随机或者生成后做一次平衡调整。5.2 几个让我省下大量时间的实操技巧技巧一用固定随机种子。生成数据的时候如果每次结果都不一样排查问题就很麻烦。设置一个固定的随机种子每次生成的数据序列完全一致方便复现和对比。Python 的 random.seed(42) 或者 numpy 的 np.random.seed(42) 都能做到。技巧二生成数据的同时生成校验报告。不要等入库之后才发现问题生成完立刻跑校验输出一份报告总条数、各字段空值率、枚举值分布、约束违反数量。这份报告就是你判断数据质量的依据。技巧三把生成配置和生成脚本分开。配置字段规则、约束条件放在 YAML 或 JSON 文件里脚本只负责读取配置并执行。这样业务规则变了改配置文件就行不用动代码。团队协作的时候测试人员可以自己改配置不需要开发介入。技巧四AI 生成的数据一定要人工抽检。不要因为 AI 说“已生成 100 条”就信了。随机抽 10 条出来看看姓名是不是像人名地址是不是像地址评论是不是像人话。我抽检的时候发现过 AI 生成的“中文姓名”里混进了英文名还有一次生成的“城市”里出现了“纽约”。抽检花不了几分钟但能避免大问题。提示如果你用 AI 生成的数据做自动化测试的输入建议把生成结果缓存起来。同一个测试用例每次跑都用同一批数据避免因为数据变化导致测试结果不稳定。缓存文件用版本号管理需要新数据的时候再重新生成。6. 关于测试数据生成我个人的几点体会做了这么多年测试和数据相关工作我最大的体会是测试数据生成不是技术问题是意识问题。很多团队不是不会造数据是根本没把造数据当回事。等到测试跑不起来、缺陷漏到线上才回头补课。六款工具也好AI 也好都只是手段。核心是你得清楚你的测试需要什么样的数据。是只需要字段格式对还是需要业务语义对是只需要单表数据还是需要多表关联是只需要百条级还是需要百万级想清楚这些工具选型就是水到渠成的事。AI 生成测试数据这条路我的建议是先用起来再优化。不要一上来就追求完美提示词先跑通一个简单场景比如生成用户评论看看效果。效果好了再扩展到其他字段效果不好就调整提示词或者换回规则工具。AI 不是替代传统工具是补充传统工具覆盖不到的场景。最后分享一个小技巧把你常用的提示词和生成脚本存成一个模板库。下次遇到类似场景直接改字段名和范围就能用不用从头写。我自己的模板库里存了二十多个提示词模板覆盖用户、订单、商品、日志、评论等常见场景新项目直接复用效率提升非常明显。这个方向后续还可以往数据血缘追踪上扩展就是记录每一条测试数据是怎么生成的、经过了哪些处理、被哪些测试用例使用了。这样当测试结果异常时可以快速定位是数据问题还是代码问题。我现在正在尝试用元数据管理的方式来做这件事等跑通了再单独写一篇分享。
