本地化 QA 不只是翻译界面文字。地址数据会出现在注册表单、结账、发票、已保存资料、CSV 导出、邮件、PDF、管理后台和客服工具中。如果这些地方只用一条国内样例测试，全球化缺陷会一直被隐藏。
合成地址数据为本地化团队提供了一种更安全的测试方式，不需要把真实客户记录复制进 QA 环境。
本地化团队应该测试什么
地址相关本地化应覆盖这些维度：
| 测试区域 | 检查重点 | 常见问题 |
|---|---|---|
| 字段标签 | state、province、prefecture、suburb、postal code | 统一叫 state，导致非美国用户困惑 |
| 必填规则 | 不同国家哪些字段必填或可选 | 新加坡被要求填写省份 |
| 邮编规则 | 数字、字母数字、空格、大小写 | 英国 postcode 被数字正则拒绝 |
| 地址顺序 | 街道、城市、地区、邮编的展示顺序 | 日本地址在收据上顺序不自然 |
| 移动端布局 | 长街道、长城市名、双行摘要 | 地址遮挡按钮或价格 |
| 导出 | CSV、webhook、CRM、发票字段 | 国家代码或地区名丢失 |
这些问题跨越内容、本地化、前端、后端和运营工具，最好在发布前通过专门样例覆盖。
推荐 QA 流程
- 从国家地址生成器目录选择一组目标国家。
- 每个国家生成 1-3 条地址。
- 把地址填入注册、结账、账单、资料页和后台流程。
- 截图桌面端和移动端展示。
- 复制 JSON，保存发现问题的 payload。
- 把稳定样例沉淀到自动化或回归清单中。
第一轮不需要覆盖所有国家。先覆盖能打破不同假设的国家：美国、英国、加拿大、日本、澳大利亚、新加坡和新西兰。
移动端检查
本地化问题在移动端更容易暴露。检查这些界面：
- 结账页地址表单。
- 订单确认页。
- 已保存地址卡片。
- 发票预览。
- 邮件模板。
- 后台列表或客服侧栏。
重点看长字段是否换行、按钮是否仍可点击、价格和税费是否被挤出视口、错误信息是否能读懂。
合成数据的好处
使用合成地址，而不是生产数据，有几个优势：
- 减少真实个人信息进入 staging 的风险。
- 可以刻意生成边界场景，而不是等待真实用户数据出现。
- 更容易把 payload 贴进 bug report。
- 适合截图、文档和演示。
- 可以轮换样例，发现新的布局和校验问题。
不过合成数据不能证明地址真实可配送，也不能替代国家政策、税务或合规判断。
何时保存固定样例
当某条生成地址暴露了问题，就应该保存下来：
- 触发过移动端溢出。
- 触发过错误邮编校验。
- 触发过国家切换状态残留。
- 触发过导出字段丢失。
- 触发过邮件或 PDF 排版异常。
固定样例适合回归测试；随机生成适合探索。两者结合，测试覆盖会更稳。
