测试数据生成方法对比：六种造数方案的适用边界

造测试数据的难点从来不是「能不能造出来」，而是造出来的东西在该像真的地方别露馅、在不该像真的地方别越界。下面六种做法都有人长期在用，也都被它们咬过。按「它在什么时候是错的」来写，比罗列优点有用。

用程序库在代码里造数会出什么问题?

这类库是程序库：你在测试代码里调用它，它返回结构化的假数据。它的强项是字段各自独立，姓名、邮箱、公司名互不相关，单看每个字段都像模像样。

弱项恰好是同一件事：生成地址时，城市、行政区、邮编往往来自不同的数据池，拼在一起经常互相矛盾。库本身不会拦你，因为它不知道你的业务要求这些字段彼此对应。

还有一个容易被忽略的性质：默认情况下它多半是随机的。测试跑两次拿到两个不同的邮箱，一次通过一次失败，而你改的其实是别的代码。

什么时候它是错的：当被测代码会跨字段校验，或者下游报表要按地区聚合时。这时候拼出来的记录会在断言里炸掉，修数据的时间比自己写还长。如果只是要一批格式正确的占位文本，它仍然是最省事的选择。

托管式造数服务的代价在哪里?

在网页上定义字段和规则，服务端按数据结构返回表格、文本或数据库语句。优点是规则可视化、导出格式多、团队里不写代码的同事也能改。

缺点首先是数据要出网：请求经过第三方，字段定义和生成结果都留在对方那一侧，涉及内网结构或真实用户字段的场景就不该这么造。其次是它同样不理解你业务字段之间的耦合，你可以在界面上写条件规则去逼近，但规则一多，维护成本会超过直接写脚本。

什么时候它是错的：数据不允许出网、持续集成需要离线跑，或者要一次生成几十万条时。

浏览器里的在线生成器

点一下出一批数据，适合的场景很窄：临时填一张表单截图、给设计稿配占位内容。它的价值是零配置、零依赖。

风险是你看不到生成逻辑，字段之间的约束是黑盒；不少工具没有稳定种子，同一个按钮点两次结果不同，进不了自动化流程。

挑这类工具时，值得看的不是界面漂亮程度，而是三件事：数据来源是否写清楚、是否支持固定种子、是否能导出成文件而不是只能复制粘贴。如果生成的是地址和证件一类的结构化数据，还要多问一句：行政区、城市、邮编是不是来自同一条记录。拼凑式的实现很容易做出「城市在广东、省份在四川」这种组合，拿去跑需要地区校验的接口必然失败。本站的地址生成工具与身份信息生成器把行政区、城市与邮编绑在同一条数据记录上，就是为了让这类组合不可能出现。

手写固定装置的边界

把种子数据写在迁移脚本或固定装置文件里。最土，也最可控。它天然可复现，文件内容就是结果；天然可评审，改动里能看到每一行改了什么；不依赖任何第三方。

代价是写得慢、覆盖面窄，而且容易腐化：字段格式规则变了，没人会想起回去改那份固定装置。

什么时候它是错的：当你需要几百条带分布特征的数据，或者要覆盖几十个国家和地区时。手写只适合关键路径上的少量样本，别拿它当主力。

生产数据脱敏的风险在哪里?

把生产库导出来，替换掉敏感字段再用。好处是分布、边界值、脏数据全都是真的，真实数据里的奇怪字符、超长字段、空值，你自己想不出来。

风险有三层：脱敏不彻底等于泄露；脱敏过度会破坏字段之间的关联，比如改了邮编却没改城市，数据看起来能跑，实际已经在骗自己；样本本身带偏见，某个地区只有三条记录，测试就永远覆盖不到。

什么时候它是错的：合规上明确不允许，或者你没有能力验证脱敏规则是否覆盖了全部敏感字段时。不要以「先导出来用着」开头。这类做法的边界在合成数据与匿名化里有更细的对照。

一份样本到处复用的问题

最常见的做法：一个测试用户对象被所有用例引用。

坏处是它只覆盖一条路径，所有测试都在验证「这个特定用户能走通」。一旦某条分支要求空值、超长值或非 ASCII 字符，就没人测过，而代码覆盖率报表不会告诉你这件事。

什么时候它是错的：当你的测试套件声称覆盖了校验分支时。至少给每个关键字段准备一组边界样本，而不是一份永远不变的固定记录。固定装置该怎么组织，测试固定装置里的身份数据给了具体做法。

下表把六种方案按最关键的取舍放在一起：

实际项目里怎么组合

一个够用的组合是：关键路径用手写固定装置配固定种子；字段彼此独立的大批量数据用程序库或在线工具生成；地址、证件、邮编这类有内部约束的字段，选能保证一致性的生成方式，而不是从几个池子里随机抽。

最后一件事是验证：拿到一批数据之后，用同一套规则把它过一遍，看有没有字段组合被拒。这种反向校验的用法常被忽略，但它能在测试跑起来之前就暴露造数错误。用校验工具把同一批数据过一遍是最省事的入口。

常见问题

为什么不干脆全部用生产数据?

因为脱敏的正确性本身就需要测试，而你没有独立的参照物去验证它。更现实的原因是权限与合规：生产数据的访问范围通常比测试环境小得多，把数据搬过去这件事在很多团队里根本走不完流程。生产数据适合用来发现边界情况，然后把这些边界情况补进合成数据里，而不是长期作为测试数据源。

程序库和在线工具能混用吗?

能，而且很常见：用程序库生成一批结构化记录，再手工补上几条特定边界值。需要注意的是别让两边的规则漂移，库升级、在线工具的默认格式改了，混用的结果就会在不同时间产生不同数据。固定版本、固定种子、把生成结果落盘成固定装置再引用，是把漂移挡在持续集成外面的办法。

生成好的测试数据要不要提交到仓库?

关键路径上的小样本建议提交，理由是它可评审、可回溯，而且不依赖生成时用的工具版本。大批量数据不建议提交：仓库会膨胀，改动记录会变得没法看。折中做法是把种子和生成脚本提交，数据本身在流水线里现生成，同时把一份期望输出作为快照存下来做比对。

怎么快速判断一批数据自洽不自洽?

先看有没有跨字段约束：城市与行政区、邮编与城市、证件号与出生日期、手机号与所属地区。再把这些字段两两组合，检查是否存在互相矛盾的行，比如行政区不在该国列表里、邮编长度与该国规则不符。这种检查不需要业务知识，纯格式层面就能筛掉大部分问题，剩下的再人工看。这类矛盾为什么会出现，见测试数据的字段自洽。

以上六种方案都只是工程手段，彼此之间没有绝对优劣；本文不构成对任何第三方服务条款、许可协议或数据处理法规的说明，选型前请按你所在组织的合规要求自行确认，示例数据一律不得用于真实业务。