电商 Checkout 地址测试清单：从自动填充到运费重算

本文要点

至少覆盖纯键盘手工输入、浏览器 autocomplete、粘贴多行地址、地址建议列表和已登录用户的地址簿。每条路径最终应生成同一 API 契约，但必须保留用户所选国家和单元信息。

建议服务没有结果或超时时，不能阻止合法的手工输入。界面应说明用户可继续完成地址，而不是陷入空结果下拉框。

如果服务返回建议地址，对话框应并排展示原始输入和建议值，标出具体变化，并允许用户保留原值。不要静默替换公寓号、楼宇名或用户确认的当地拼写。

测试接受建议、保留原值、关闭后重新打开、服务超时和建议值缺失 Address Line 2 等分支。

地址的国家、州、省或邮编改变后，旧的配送方式可能不再可用，运费、税费、免邮门槛和预计日期都需要重算。在新报价返回前，应防止用户以旧总价提交。

连续快速修改 postcode 会产生多个并发报价。只能应用最新地址版本的结果，并取消或忽略过期请求。

勾选“账单地址同收货地址”时，系统可以创建当前副本，但不要让两个对象持续共享可变引用。用户取消勾选并编辑账单地址后，收货地址不应跟着改变。

不要用随机地址测试支付服务的真实地址校验。支付提供商的 sandbox 通常有自己的测试卡和触发值，应按其文档使用。

shippingAddress = structuredClone(selectedAddress);
billingAddress = sameAsShipping
  ? structuredClone(shippingAddress)
  : enteredBillingAddress;

双击按钮、网络超时后重试和移动端返回页面都可能重复提交。客户端需要显示进度并禁用重复操作，服务端则要使用 idempotency key 保证一次业务结果。

订单保存的是最终确认的地址快照，而不是只引用会被用户后续修改的地址簿记录。提交测试要读取订单 API，确认地址、运费报价版本和幂等键一致。

移动端还要覆盖软键盘挡住主按钮、系统将页面放到后台后回来、以及支付授权页返回的情况。页面恢复时先查询已有订单或幂等请求状态，不要立即重发订单。

最后用一条在结账中修改过两次的地址审计订单：订单快照应是最后确认版本，报价必须来自该版本，且地址簿后续变更不会改写历史订单。

地址建议服务失败时是否应该阻止下单？

不应必然阻止。根据业务风险，可允许手工确认，并将地址标记为未验证。

修改 postcode 后要重算哪些内容？

至少重算可用配送方式、运费、预计时效和相关税费，并丢弃过期并发结果。

禁用下单按钮能防止重复订单吗？

不能完全防止。服务端还需要 idempotency key 或等价机制处理重试和并发请求。