结论先说
注册地址测试：保存、编辑与 CRM 映射
测试注册地址字段前，先确认注册阶段是否真的需要完整地址。若确有需要，应按国家建立结构化字段映射，并验证 Unicode、邮编前导零、可选字段、保存后编辑、API/数据库/CRM 往返和删除流程。测试环境应使用合成数据，不复制真实用户资料。
分步执行
安全且可复现的测试流程
把 Seed 和数据版本保存在测试用例中，先验证正常路径，再故意制造地区、邮编与字段状态不一致的情况。
- 01
先确认是否真的需要注册地址
如果产品只需要国家或时区，不要提前收集完整地址。减少字段能提高完成率，也能降低隐私与数据维护成本。
- 02
建立国家专属字段映射
把州省、城市、下级地区、邮编、街道和门牌映射到稳定的内部字段，不要把所有国家都强制塞进两个通用地址行。
- 03
测试保存后再编辑
完成注册后重新打开资料页，检查 Unicode 字符、前导零和空的可选字段是否原样保留。
- 04
检查跨系统同步
对比页面、API、数据库和 CRM 中的字段，确认没有把行政区显示名误写进代码字段，也没有在 CSV 中破坏非 ASCII 字符。
- 05
加入删除与最小化测试
用户删除地址后，下游副本也应遵循产品的数据保留策略。验证可选字段不会在下一次编辑时被旧数据重新填充。
发布前检查清单
- 国家变化会更新字段结构和标签
- 邮编按字符串保存并保留连字符与前导零
- Unicode 城市和地区名称能够往返保存
- 可选字段为空时不会写入占位垃圾值
- API、数据库和 CRM 字段映射一致
- 编辑与删除操作不会恢复旧地址
地址表单测试矩阵
地址表单测试矩阵
把这些测试项复制到验收用例中，并用固定 Seed 保存失败样例。
| 测试项 | 输入或操作 | 预期结果 |
|---|---|---|
| 最小字段路径 | 只选择业务真正需要的国家或地区 | 不强制收集无关街道与门牌 |
| 国家切换 | 从美国切换到日本 | 标签、字段顺序、邮编规则与行政区选项同时更新 |
| Unicode 往返 | 保存 東京都、İstanbul 或 München | 编辑、API、数据库与 CRM 中字符一致 |
| 空可选字段 | 不填写楼层、房间或下级地区 | 保存 null/空值，不写入 N/A 等垃圾占位符 |
| 删除地址 | 用户清除已保存地址并重新打开资料 | 下游系统按保留策略删除，旧值不再出现 |
演示测试案例
案例：CRM 把行政区显示名覆盖成代码
- 场景
- 日本注册地址在页面保存“東京都”，API 同时发送 regionCode=13。CRM 导入映射错误，把 13 写入用户可见地址，重新编辑时选择器无法匹配。
- 问题定位
- 系统没有区分稳定代码、当地显示名与格式化地址。首次注册成功并不能证明跨系统往返正确。
- 修复与验收
- 为 code、displayName 和 formattedAddress 定义独立字段，在 API、数据库、CRM 和编辑页面逐层断言，并加入删除与旧值恢复测试。
先做数据最小化，再做校验
注册流程往往不需要完整邮政地址。先说明业务为什么需要每个字段，再决定必填状态和保留周期。测试用例也应覆盖只填写国家、只填写账单地区或完全不保存地址的路径。
结构化存储与格式化展示分离
数据库应保存可验证的结构化字段，展示层再根据国家规则生成当地格式或国际格式。只保存一段格式化文本会让搜索、去重、迁移和 CRM 映射变得困难。
把 Seed 和数据版本写进测试证据
相同 Seed 只有在相同数据版本和国家规则下才保证重现。缺陷报告应同时记录两者，并附上结构化提交载荷；这样即使页面文案调整，也能定位真正的数据问题。
生成资料只用于开发与 QA，不代表真实人物、账户、政府证件或可投递地址。
参考资料
流程建议参考可访问性、输入验证与数据最小化的权威资料。
审核与维护 MockAddr Editorial Team