跳到主要内容
开发工具2026-07-166 分钟阅读

Mock 数据生成器完全指南:快速生成测试数据

为什么需要 Mock 数据生成器

日常开发里,联调、界面调试、演示和轻量压测都要大量测试数据。手写不仅慢,而且容易千篇一律,或字段格式对不上真实业务。

Mock 数据生成器 按你勾选的字段类型组合多行假数据,可改列名、选地区样本、设随机种子,并导出 JSON / CSV / TSV / YAML / SQL。全程在浏览器本地完成,不上传。

常见痛点

  • 后端接口还没就绪,前端无法联调——先用生成器造一批同结构假数据把界面跑起来
  • 测试需要多类型字段,手写太慢;造好的 JSON 可用 JSON 格式化核对结构
  • 演示数据一眼假,客户或评审观感差
  • 需要几百上千行做列表滚动或导入演练,手写不现实

工具里有什么

字段类型一览

当前提供 32 种字段,分七类:

类别示例典型用途
基本信息中/英文名、性别、年龄、布尔值、用户名、手机、邮箱、身份证、地址、公司用户列表、个人中心
网络IPv4/IPv6、URL、域名、User-Agent日志、网关联调
日期时间随机/过去/未来日期、时间戳排序、筛选、订单时间
数字整数、浮点、百分比图表、报表占位
文本随机串、Lorem、随机中文列表标题、正文占位
标识符UUID/GUID、订单号、银行卡号主键、支付演示
颜色HEX、RGBUI 色板占位

只要结构占位、不关心字段语义时,可用更轻的 JSON 生成器;要邮箱、手机、姓名这类「像真的」字段,用本工具。

地区样本(locale)

地区设置会影响手机号、地址、公司与性别文案:

  • 中文 / 国内:11 位手机号前缀、省市街道地址、中文性别标签与公司后缀
  • English / US:+1 (area) xxx-xxxx 手机号、美国城市街道邮编、英文公司与 gender 标签

中文名 / 英文名作为独立字段类型,可与地区组合:例如地区选 English,仍可勾选中文名做双语界面测试。

随机种子:可复现的 fixture

留空种子时每次结果不同,适合随手演示。填写任意字符串(如 fixture-users-v1)后,在字段、行数、地区、格式不变的前提下,再次生成会得到相同输出。适合:

  • 前端 golden test / snapshot 对照
  • PR 里贴固定样例,避免「我这边跑出来不一样」
  • 文档与教程中的可复制样例

同一种子换列名或行数,结果会变——种子绑定的是整次生成参数,不是单一字段。

导出格式

格式适合
JSONmock server、前端 fixture、再交给 JSON 转 TypeScript
CSV / TSVExcel、数据管道;CSV 可用 CSV↔JSON 互转
YAML配置型 mock、部分 CI fixture
SQLINSERT INTO mock_data (...) VALUES ...,本地库灌数前按需改表名

单次行数范围是 1–1000。先用十几行验列类型与下游解析,再放大行数。

使用场景

场景一:前后端并行

  1. 按接口文档勾选字段并改成真实列名(如 userId、createdAt)
  2. 需要可复现时设种子,导出 JSON
  3. 前端挂本地 mock;后端就绪后只换数据源

场景二:列表与边界观感

勾选超长倾向的文本类型(Lorem、随机中文)与布尔/年龄等短字段混排,观察表格折行、空态与排序。布局压测还可搭配 Lorem 生成器。

场景三:本地库灌数

导出 SQL,在开发库执行前检查表名与列类型是否匹配;布尔字段会写成 TRUE/FALSE。生产环境不要灌入任何 PII 形态的随机值。

实用建议

  1. 先定列,再生成:列名对齐真实 API,减少前后端对字段名的二次改写。
  2. 小批量验通再放大:10–20 行够 UI;列表滚动可到数百行;本工具上限 1000,更大压测请用服务端脚本。
  3. 演示选地区样本:国内客户看中文地址与手机;国际 demo 切 English/US,避免「英文名 + 中国手机号」的违和感。
  4. 需要稳定样例就写种子:文档、CI、评审材料统一用同一 seed。
  5. 假数据也要合规:格式像真不等于可以冒充真人;勿写入生产库。

与「中国测试数据」工具怎么分工

本工具是通用多字段表格造数器。若要批量、覆盖更全的国内证照号码,用专用的中国测试数据生成器与校验器(身份证、统一社会信用代码、车牌等)。重叠是有意的:

需求更合适
混合用户行(姓名 + 邮箱 + UUID + 日期)做 UI mock本 Mock 生成器
语法合法的身份证 / 银行卡 / 统一社会信用代码批量中国测试数据工具
核对粘贴号码是否过校验位同簇格式校验器

本页身份证现已按 GB 11643 MOD 11-2 生成校验位;银行卡对公开测试 BIN 做 Luhn。它们仍不对应真人/真账户——校验位通过 ≠ 真实签发。

种子卫生与 fixture 碰撞

种子只冻结同一次请求的随机性:字段类型、列名、行数、地区、格式,以及(对时间类字段)生成时注入的墙钟。团队常踩三类坑:

  1. 只改列名、种子不变——输出会变,因为字段规格参与生成输入
  2. 跨环境共用一个种子但默认地区不同——即使种子字符串相同,CN/US 手机号也会分叉
  3. 导出 SQL 后手改表名——灌库没问题,但列变更后请回工具重生成,避免引号/转义漂移

种子按 fixture 命名(fixture-users-v2),不要用人名电脑名(alice-laptop)。在 PR 里贴样例 JSON 时把种子一并写上。

能力边界(如实说明)

  • 输出是扁平行对象(每行一组字段),不是任意深度的嵌套 JSON 树。需要嵌套时,可先生成扁平 JSON,再在代码里组装,或手写一层结构。
  • 字段之间无业务关联(例如订单时间不必晚于注册时间);复杂关联请在测试代码里二次加工。
  • 带校验位的身份证/银行卡仍是合成数据——勿写入生产库,也勿当成「真实证件存在」的证明。

结语

把「造数」从手写里拆出来,联调与演示会快很多。ToolVault 的 Mock 数据生成器 支持数十种字段类型、地区样本、随机种子与多种导出格式,纯前端运行。需要结构化契约时,生成后再用 JSON Schema 相关工具校验即可。

排查注记

「种子卫生」单独成节并列出三类坑,是因为种子只冻结同一次请求的随机性——字段、行数、地区、格式都参与生成输入,只改列名、种子不变,输出照样会变;所以团队约定按 fixture 命名种子、PR 里贴样例时把种子一并写上,防的就是「我这边跑出来不一样」。「能力边界」如实说明的三条(扁平行对象、字段间无业务关联、校验位通过不等于真实签发)划定了工具替你负责的范围,复杂关联要回测试代码二次加工。实用建议第一条「先定列、再生成」也是同一逻辑:列名对齐真实 API,省掉前后端对字段名的二次改写。