测试地址数据：固定装置里该怎么组织

测试地址数据看起来是最不需要动脑的一类测试数据：地址结构简单，随便造几条就能跑。真正上线之后才发现，地址恰恰是最容易让测试环境与生产环境行为分叉的字段——长度、字符集、国家间的字段差异、以及那条没有邮编的国家。这篇讲怎么把固定装置里的地址组织好，读完你能列出一份够用的边界样本清单，也能让下一个接手的人看懂每条样本为什么在那里。

为什么测试库里不能放真实客户地址

地址属于个人数据，把它放进测试环境等于把生产数据泄露到管控更弱的地方。测试环境的访问权限通常更松，备份和快照更容易被下载，日志里也常原样打印。真实地址一旦进了测试库，就同时失去了访问控制和可追溯性这两层保护。

还有一层纯技术的理由：真实数据会被反复使用，团队开始围绕它的具体取值写断言，例如断言某城市必然属于某行政区。等到这条数据被清理，测试就一起坏了，而它本来要验证的逻辑可能根本不需要那个具体城市。用合成的数据，断言可以写在结构上而不是取值上。

固定装置该怎么组织地址?

建议按国家与场景两个维度组织。国家决定格式与字段规则，场景决定这条数据要触发什么行为：正常投递、缺邮编、超长街道行、非拉丁字符、单元号缺失、行政区与邮编不匹配。

命名上把这两层写进可见的标识里，让人从名字就能读出用途，而不是打开数据才明白。数据集本身要能版本化，每次新增样本都在同一处集中登记，避免同一个边界样本在很多文件里各写一遍、后来只改了其中一处。

还有一处容易被忽略：固定装置里的地址常常同时被界面测试、接口测试和数据迁移测试读取，三处对字段完整度的要求并不一样。界面测试需要能填满每个输入框的数据，接口测试需要能触发校验分支的数据，迁移测试需要能覆盖历史格式的数据。与其让它们共享一份大而全的样本，不如按用途分成几组，每组只声明自己需要哪些字段。

关于可复现的意义，以及同一次随机种子应不应该复现同一批数据，可复现的测试数据里有专门的讨论。

假数据重复使用会有什么问题?

固定装置里的数据被反复使用本身没问题，问题出在它悄悄变成了事实标准。当一批假地址在很多项目里长期存在，团队会开始依赖它的具体形状，比如某个邮编必须配某个城市，而这条约束在真实的地址体系里可能根本不成立。

解决办法是让数据集可生成、可替换。把「需要一条缺邮编的地址」和「需要这条具体的地址」区分开：前者是需求，后者只是当前的实现。做到这一步，换一批样本就不会牵动测试代码。

边界样本要准备哪些?

下面这份清单覆盖了大多数会真正引发故障的情况：

清单一长，容易只准备第一条就收工。建议把它当成一张勾选表，每加一个国家就对照一次。

清单里的样本要区分两类用途。一类是验证系统不会误拦合法输入，例如没有邮编的国家、字母数字混合邮编、非拉丁文字地址，它们对应的失败表现是用户提交不了。另一类是验证系统确实会拦住错误输入，例如邮编与行政区不匹配、必填字段为空，它们对应的失败表现是错误的地址顺利入库。两类都要有，只测其中一类会让问题从一边滑到另一边。

生成数据和手写数据该怎么选

手写适合数量少、意图明确的样本，比如那条专门用来触发超长街道行的地址。数量一多，手写就会退化：复制上一条改几个字符，结果一整批样本其实只覆盖了一种格式。

生成适合需要覆盖多个国家、多个格式组合的情况，尤其是你希望字段之间保持一致关系的时候——城市属于哪个行政区、邮编属于哪个行政区，这些关系让人手工维护代价太高。生成之后仍然要落回固定装置，不能每次跑测试都随机产生新数据，否则失败用例无法复现。

给开发者：固定装置的结构与自查

第一，每条地址样本都带一个稳定标识，测试引用标识而不是引用具体取值。标识改名要有迁移路径，不要直接删。

第二，把国家、场景与预期行为写成同一条记录的三个部分。预期行为写清楚这条样本应该被接受还是被拒绝，以及拒绝时命中的是哪条规则。

第三，避免在样本里出现真实可投递的地址。合成的数据也要检查一次：街道名可以用公开地名，但门牌与楼层应当是随机的，避免恰好拼出一处真实门牌。

第四，定期清理不再对应任何规则的样本。固定装置最容易累积的就是这类数据，它们不会让测试失败，只会让维护者失去判断力。顺带说明一点：固定装置里的合成地址只用于测试，不能投递，也不指向任何真实住户。

第五，多国样本清单可以直接用随机地址生成器生成，用它保证字段一致，再把样本固化进你的数据集。表单层面还需要补哪些用例，见收货地址表单的测试用例；真实地址在测试环境里的处理边界，见地址数据与隐私。

下一步

打开你现在的测试数据文件，数一数里面有几个国家、几种场景。如果只有一种国家格式，先补上一条没有邮编的样本和一条字母数字混合邮编的样本——这两条能拦住最常见的误拦类问题。需要现成的多国样本时，用随机地址生成器按国家批量导出，再固化进仓库即可。