注册表单假地址生成器可以帮助团队创建测试账号，而不收集、不复用真实用户地址。最好的使用方式不是“伪装成一个真实的人”，而是“让产品正确处理地址形态的数据”。
用户经常会搜索 “fake address for signup”、“sample address for test account”、“random address for registration form” 或 “test user address without personal data”。GeoMock 针对的正是这种更安全的 QA 模式。
为什么注册表单需要地址变化
注册表单经常被复用到 onboarding、账单、配送和资料设置。一个字段在创建账号时能通过，不代表同一份数据出现在表格、卡片、发票或客服侧栏时也能正常显示。
可以用 GeoMock 为这些场景生成合成数据：
- 新账号注册。
- 资料补全。
- 组织账单设置。
- 配送偏好设置。
- Marketplace 卖家 onboarding。
- 内部管理后台用户创建。
- 销售或客服使用的演示账号。
注册测试矩阵
每一条生成地址都应该走完整生命周期，而不只是提交第一个表单。
| 步骤 | 测试问题 | 检查重点 |
|---|---|---|
| 创建账号 | 用户能否提交有效字段？ | 必填标签和校验信息 |
| 邮件确认 | 地址会不会出现在邮件里？ | 模板中是否泄露类似 PII 的内容 |
| 编辑资料 | 用户能否更新地址字段？ | 国家和邮编之间的依赖 |
| 已保存卡片 | 地址是否干净换行？ | 移动端和桌面端卡片布局 |
| 管理后台 | 客服是否能快速读懂？ | 表格列、截断和可读性 |
| 导出 | payload 是否被保留？ | CSV、webhook、CRM 和 JSON 字段名 |
如果产品支持多个国家，至少加入一条美国记录和一条非美国记录，可以从国家地址生成器目录生成。国家切换是很多注册表单保留旧状态或旧邮编校验的地方。
隐私优先的测试数据规则
合成地址可以降低风险，但前提是团队明确把它当作合成数据处理。
- 不要把生成地址和真实姓名、真实邮箱或真实支付方式混用。
- 不要把生成数据用于身份验证或真实配送。
- 长期存在的演示账号应标记为 demo 或 test。
- 尽量让测试账号不进入生产分析报表。
- 删除已经没有价值的测试记录。
如果团队正在替换从生产库复制出来的数据，可以继续阅读地址 QA 的合成测试数据。合成数据最好根据场景刻意生成，而不是从真实客户表里抓取。
更好的 bug report 写法
注册流程出现缺陷时，把生成的 payload 放进问题单。一个好的问题单应该包含：
- 使用的国家和地址字段。
- 触发失败的具体步骤。
- 预期结果和实际结果。
- 桌面端或移动端截图。
- 复制出来的 JSON。
- 是否能用另一条同国家地址复现。
这样开发可以专注修复状态、校验或布局问题，而不用猜测试人员当时输入了什么。
什么时候不要使用
假地址生成器不适合真实用户注册、平台规则规避、风控绕过、真实配送或支付审批。它的价值在于帮助团队更安全地测试软件，而不是创造可以用于真实交易的身份或地址。
