合成测试数据是让地址 QA 更安全的最快方式之一。团队可以生成姓名、电话、地区、邮编和格式化地址行，而不是把生产客户记录复制到 staging。
对地址流程来说，这个区别很重要。结账、注册、税费计算、发票导出、onboarding、CRM 同步和客服工具都会接触地址字段。如果测试数据太干净，产品会漏掉真实布局和校验问题；如果测试数据来自真实客户，QA 环境又会变得更难治理。
主要使用场景
当目标是测试软件行为，而不是投递邮件时，可以使用合成地址数据。
- 注册和结账表单的回归测试。
- 跨国家字段和标签的本地化 QA。
- 需要真实感截图的 staging 演示。
- 需要地址形态 payload 的 contract test。
- 税费和区域逻辑测试，例如美国免税地址流程。
- 不暴露客户记录的客服、CRM 和后台测试。
GeoMock 面向的就是这类场景：为 QA、演示和开发生成地址记录。可以从国家地址生成器目录开始，再保存需要重复使用的记录。
合成数据和生产数据的区别
| 维度 | 生产客户数据 | 合成测试数据 |
|---|---|---|
| 隐私风险 | 高，需要严格治理 | 低，适合测试环境 |
| 边界覆盖 | 取决于已有用户 | 可以刻意生成 |
| 可复现性 | 复制和脱敏成本高 | JSON 可直接保存 |
| 演示用途 | 容易泄露真实信息 | 更适合截图和文档 |
| 真实可配送 | 可能真实 | 不应假设真实 |
合成数据不是万能的。它不能证明地址可配送，也不能替代税务、合规或身份验证服务。
如何建立地址测试集
一个实用的测试集可以这样组织：
- 每个关键国家保存 1-2 条稳定地址。
- 为结账、注册、账单和导出分别保存 payload。
- 把触发 bug 的地址加入回归夹具。
- 在发布前轮换生成新地址，寻找未知边界。
- 给每条 fixture 标注用途，而不是只保存原始 JSON。
好的 fixture 名称应该表达场景，例如 uk-postcode-checkout, jp-prefecture-mobile-card, us-zip4-tax-summary。
写 bug report 时保存什么
地址相关问题单建议包含：
- 生成地址的 JSON。
- 国家和地区。
- 表单路径或页面 URL。
- 桌面端或移动端截图。
- 出错字段和错误信息。
- 下游影响，例如邮件、PDF、导出或后台展示。
这样团队可以把问题从“看起来错了”变成“这个 payload 在这个流程里触发了这个行为”。
安全边界
合成地址数据不应用于真实配送、身份验证、支付审批、反欺诈判断、逃避税费或平台规则规避。它的定位是软件测试数据，而不是现实世界实体。
