测试身份数据指的是按真实字段结构合成出来的姓名、证件号码、出生日期、住址与联系方式：它看起来像一份身份档案，却不指向任何真人。开发与测试里凡是需要一个「人」的地方，从注册表单到批量导入，用它都够。本文讲清它和真实数据的区别、哪些场合必须换掉真实数据，以及一条记录内部要满足哪些一致性。
测试身份数据到底是什么
一组测试身份数据由若干字段拼成：姓名、性别、出生日期、证件号码、电话、住址、邮箱。它追求的是让下游程序认得出这些字段，而不是让某个具体的人真实存在。所以判断它合格与否的标准，和判断真假无关，只和形状有关。
形状具体指三件事。第一，取值必须合法：出生日期是真实存在的一天，不是二月三十日；号码长度与字符集符合发行国的习惯。第二，字段之间要自洽：电话的国家码要与所在国家一致，证件号的形态要属于同一个国家，出生日期算出来的年龄要和记录声称的成年状态对得上。第三，整批数据要能复现：同一条记录在两次生成里应当是同一个值，否则一个只在第二次出现的失败就无法复盘。
这三条里最容易被忽略的是第三条。随机生成很容易，可复现却需要设计，而不可复现的测试数据会把排查方向直接带偏。
什么时候需要一批测试身份数据
需求差别很大，从十几条到上万条都有。下表按常见场景对照需要关注的重点：
| 场景 | 规模 | 最需要关注 |
|---|---|---|
| 表单与字段校验 | 十几条 | 边界值与必填组合 |
| 注册和登录流程的自动化 | 一次几十条 | 可复现、可断言 |
| 演示与文档截图 | 三到五条 | 看起来自然、不冒犯任何人 |
| 批量导入与性能压测 | 上千到上万条 | 生成速度、唯一性、字段一致性 |
表单校验关心的是边界：姓名只有一个字、没有姓氏、生日是闰日、证件号比常见长度短一位。流程自动化关心的是稳定性：同一条数据跑两遍必须走到同一个分支。演示关心的是观感：不能出现明显荒诞的姓名与地址。压测关心的是吞吐与内存，数据本身反而可以简单。
同一批数据一般无法同时满足这四种需求，所以更常见的做法是按场景各准备一份，而不是找一份万能数据。
为什么不能拿真实的身份数据做测试?
真实身份数据属于个人数据，而测试环境通常是权限最松的地方：开发者本地就有副本，日志会打印字段内容，报错截图会流进聊天记录。数据一旦复制进去，再想彻底清除就非常困难，因为没有人能列全它到底散布在哪些数据库、缓存、备份和日志里。
还有一层风险来自人员与时间的跨度。测试环境里的人换来换去，几年后没人能说清某个字段是从哪来的；当初那份导出文件也早已不知去向。相比事后追查，从一开始就不把真实数据放进测试环境是成本最低的选择。
这里有一条所有测试数据都适用的底线：合成出来的身份数据只用于测试与演示，不能用来冒充真人，也不能用来通过实名验证、开户、签合同或注册需要真实身份的账号。真实数据与测试数据之间应当有一条明确的隔离线，而不是靠自觉。
合成数据和把真名删掉有什么区别?
「把姓名删掉就安全了」是流传最广的误解。个人数据能否指向某个人，取决于所有字段的组合，而不取决于是否留下姓名字段。出生日期加上邮编加上性别这样的组合，在多数地区就足以把一个人缩小到极小的范围，年份越精确越明显。下表把几条常见做法放在一起对照：
| 做法 | 数据来源 | 能否还原 | 适合测试吗 |
|---|---|---|---|
| 合成 | 凭空生成，不来自任何真人 | 无法还原 | 适合，首选 |
| 匿名化 | 来自真实记录，去掉标识字段 | 理论上不可还原，实际有风险 | 有条件使用 |
| 假名化 | 来自真实记录，标识字段换成编号 | 持有对照表就能还原 | 谨慎，等同真实数据管理 |
| 掩码 | 真实记录的展示层，只显示局部 | 原始记录仍在 | 只用于展示，不用于测试库 |
区分它们的关键是数据来源与可还原性：合成数据根本没有对应的人，假名化的数据只要有对照表就能还原，掩码只是显示方式变了。拿掩码后的数据当测试数据，等于把真实数据换了个样子继续用。
在本站的身份生成器里怎么一次生成多条
要在本地准备一批记录，最省事的方式是直接用身份信息生成器：选好国家，一次生成多条，姓名、生日、证件号、电话与住址都来自同一套字段规则，字段之间的一致性由工具保证，不需要自己拼。生成结果可以导出成表格或文本，随用随取，用完丢掉也不心疼。
工具的价值主要在于省掉拼数据的时间。手工造数据时最容易出现的问题不是写错一个字段，而是几条记录之间互相矛盾：同一批里所有人的生日都落在同一天，或者所有电话号码的前缀完全相同。用它生成时这类问题会轻得多，你只需要决定要哪些国家、要多少条。
至于每条记录要不要带证件号，取决于你的测试目标。只测注册表单的话，姓名、生日和联系方式就够了；流程里出现了证件核验环节时再补上证件字段，能少则少。
给开发者：一条身份记录要包含哪些字段
字段清单建议按依赖关系分层，而不是平铺成一长串。最底层是国家，它决定证件号的形态、电话的国家码、住址的结构；第二层是出生日期与性别；第三层是姓名与联系方式。后一层可以依赖前一层，反过来不行。
按这个分层写生成逻辑，能顺手解决几个常见的坑。证件号的长度与字符集随国家变化，写死一种格式会在换国家时全军覆没；电话的国家码必须跟着国家走，否则字段一致性检查会报警；出生日期只存日期本身，不要存成带时区的时刻，否则计算年龄时会因为它落在哪一天而抖出一天误差。
另一件值得提前做的事是给生成器留一个种子参数。固定种子意味着同样的输入永远得到同样的记录，失败可以原样重放；不确定的种子适合压测，但不适合排查问题。这两种模式最好同时存在，由调用方选。
固定装置本身也会随时间腐化：有人改了一个字段，用例的期望值没跟着改，测试就红了。把记录与用例一一对应地命名，并在改数据时顺手改断言，比事后去猜为什么失败要省事得多。真实个人数据为什么不能进测试环境，见测试数据与隐私规则。
下一步
如果你正要给测试环境准备一批身份记录，直接打开身份信息生成器，按国家批量生成，导出后放进你的固定装置。生成的数据只用于测试，不要拿它去通过任何需要真实身份的流程。
想接着了解这套数据在设计上的取舍，可以读合成数据与匿名化的区别，以及测试固定装置里的身份数据该怎么组织。姓名在不同语言里的结构差异，见不同地区的姓名数据；如果你更关心的是这批数据为什么必须可复现，可复现的测试数据那篇讲得更细。