第五阶段 · 上线验收
测试订单与上线 QA：从成功付款到取消退款完整走一遍
在受控访问下冻结候选版本，覆盖成功、失败、折扣、免邮、税费、通知、库存、履约、追踪、取消、退款和事件，再解除密码并建立首日监控与回滚。
本课怎么做才算完成
沿着 Online Store > Preferences, Settings, Products, Orders, Analytics 找到正确页面，再完成设置、保存、验证和记录。完成不是看过页面，而是能指出保存状态、验证结果和继续条件。
- 后台路径
- Online Store > Preferences, Settings, Products, Orders, Analytics
- 本课产出
- 一份签字上线报告，包含测试用例、证据链接、阻塞问题、修复/复测、test mode 关闭、密码解除、监控负责人和回滚条件。
- 可以继续
- 成功、失败和边界用例都有结果，订单后链路可对账，测试模式关闭，密码解除和监控由第二人复核。
- 必须暂停
- 如果关键用例失败、测试模式状态不明、退款或库存无法回补，或没有回滚负责人，不要上线。
证据边界：一笔成功测试和签字表不证明未来所有流量、设备、市场、支付故障或第三方中断都不会出问题。
这一课为什么要先做
店铺能打开、商品能加购，都不代表能上线。上线证据是一笔订单从市场、商品、库存、运费、税费、支付、通知、履约、追踪、事件到退款都能对应；发现问题后要回到责任设置修复，再重新跑受影响链路。
开始前准备
- 前 19 课完成标准已复核，店铺仍处于 password protection 或受控访问。
- 准备桌面、iPhone/Android 尺寸、Gmail、Outlook 和至少两个测试地址。
- 冻结主题、商品、政策、支付、运费、税务、通知和 pixels 的候选版本。
跟着英文后台一步一步做
每做完一步就刷新页面或从前台验证一次。后台显示已保存，不代表客户看到的结果一定正确。
冻结上线候选版本
给主题、商品、政策、支付、运费、税务和 pixels 记录版本与时间。QA 期间不再并行改设计和安装 App；任何变更都写入问题单并标记需要重测的用例。
做完后应该看到或拿到：得到不再漂移的上线候选配置和变更记录。
怎样算完成：第二人能按版本、时间和问题单复述当前候选状态，测试不被未记录的改动污染。
如果结果不对或入口没出现：发现 QA 期间发生未记录改动时，确认当前主题/配置版本，标记受影响用例并重新冻结，不要继续沿用旧结果。
留下证据：保存版本号、变更时间、问题单、受影响用例、负责人和签字状态。
先做前台浏览与加购
用桌面和手机检查首页、菜单、搜索、集合、商品、变体、库存、购物车、折扣和政策。测试慢网和无痕浏览，确认没有登录缓存或管理员预览掩盖问题。
做完后应该看到或拿到：得到真实客户入口、商品选择、购物车和政策路径的前台结果。
怎样算完成：关键页面能在桌面和移动端打开，变体、价格、库存、折扣和政策显示与候选版本一致。
如果结果不对或入口没出现：上线后客户无法付款时，检查 test mode、provider status、Markets、currency 和 checkout，达到停止线先恢复密码并回滚。
留下证据：记录设备、网络、前台 URL、商品/变体、折扣、库存、政策和加购结果。
失败处理：不要只在管理员预览里判断可用；必须用无痕和移动端重走客户路径。
跑成功、失败和边界订单
完成成功支付、失败支付、取消支付、免邮门槛上下边界、折扣、另一个地区的税费和不支持地址测试。每个用例记录预期、实际、订单号和截图。
做完后应该看到或拿到：得到成功、失败、取消、折扣、运费、税费和不支持地址的订单用例结果。
怎样算完成：每个用例都能把预期、实际、订单状态、库存、通知和问题单对应起来。
如果结果不对或入口没出现：用例失败时保留订单和日志，定位是支付、运费、税务、市场、库存还是通知阶段，再修复对应设置并重跑。
留下证据：记录用例 ID、订单号、地址类型、金额、支付状态、错误提示、截图和复测时间。
验收订单后链路
检查 Order confirmation、库存 Committed、Location 分配、员工通知、支付 transaction 和事件。创建 fulfillment、加入 tracking、发送通知，再从客户邮件打开追踪链接。
做完后应该看到或拿到：得到一笔订单从付款到通知、履约、追踪和事件的完整对应。
怎样算完成：订单时间线、库存地点、支付交易、客户/员工通知、履约和追踪链接互相解释。
如果结果不对或入口没出现：订单有了但没有通知时，检查通知触发、recipient、sender、spam、模板和订单状态，必要时手工联系客户并留 incident 记录。
留下证据：保存订单号、transaction、Location、fulfillment、tracking、邮件 Message ID、事件 ID 和负责人。
失败处理：不要用后台有订单证明下游完成；从客户邮件、订单时间线和实际库存分别回读。
测试取消、退款和回补
对测试订单执行取消或退款，确认支付记录、邮件、库存 restock、税费和分析事件。记录手续费或 payout 的边界，不用测试店数据推断真实资金一定相同。
做完后应该看到或拿到：得到取消/退款后的付款、库存、通知、税费和事件变化。
怎样算完成：退款金额、退款状态、库存回补、税行、通知和分析变化都有证据，不能只看按钮已点击。
如果结果不对或入口没出现：结果不一致时保留原订单、退款 ID 和时间线，按付款、库存、税费、通知和事件来源逐项定位后重测。
留下证据：记录订单号、取消/退款类型、退款 ID、库存变化、税行、邮件、事件和手续费边界。
解除密码并开启上线监控
所有 blocker 关闭后，确认 payment test mode 已关闭、主域和 Markets 正确，再从 Online Store > Preferences 或当前密码设置解除保护。上线后前 24 小时监控 checkout、支付、通知、库存、events 和客服，达到回滚条件就恢复密码或上一主题。
做完后应该看到或拿到：得到第二人确认的密码状态、测试模式、首发域名、监控负责人和回滚动作。
怎样算完成：签字表所有关键区域通过，测试模式关闭，密码解除和监控窗口有记录，回滚可由指定负责人执行。
如果结果不对或入口没出现：库存或事件重复扣减时，暂停相关 App 或自动化，按订单时间线检查 Location adjustments、webhooks 和 duplicate pixels，修复后重跑同用例。
留下证据：保存密码解除时间、test mode 状态、主域/Markets、监控负责人、观察窗口、签字和回滚记录。
失败处理：任何关键用例失败、测试模式状态不明、退款或库存无法对账，或没有回滚负责人，都不要上线。
现在把判断用到你的店铺
在密码保护下先冻结版本，再用桌面、移动端和无痕环境完成浏览/加购。随后用成功、失败、边界和不支持地址订单验证后链路，最后由第二人确认 test mode、密码、主域、Markets、监控和回滚动作。
这一步先给出后台位置，再用一个实际情境检查你是否能做出决定。
把这一步用到你的店铺
完成后应得到：一份签字上线报告，包含所有测试用例、证据链接、阻塞问题、修复、复测、test mode 关闭证明、密码解除时间、监控负责人和回滚条件。
相关后台路径：Online Store > Preferences, Settings, Products, Orders, Analytics
先做判断，再对照原因
这不是记忆题。先选出能解决问题的动作，再看解释。
在店铺里逐项确认
按当前店铺的实际值逐项确认；这份清单不会替你保存设置或执行测试。
这一步还不能说明：一笔成功测试和签字表不证明未来所有流量、设备、市场、支付故障或第三方中断都不会出问题
继续条件：成功、失败和边界用例均有结果，订单后链路可对账，测试模式关闭，密码解除和监控由第二人复核
暂停条件：如果任何关键用例失败、测试模式状态不明、退款或库存无法回补，或没有回滚负责人，不要上线
下一步：上线后保留这份用例与结果，按真实事件更新它，并进入运营、数据和增长教程，而不是把 QA 当成一次性任务。
先补齐判断或核对项。没有足够信息时，保持暂停比猜一个通过更安全。
上线签字必须同时写清回滚动作
发布确认不能只写“看起来没问题”。每一行要有通过条件、实际证据、负责人和失败动作；任何 blocker 都要在上线前关闭或明确阻塞。
| 检查区域 | 通过条件 | 实际证据 | 失败时回滚 | 负责人/结论 |
|---|---|---|---|---|
| 店铺访问与密码 | 桌面/移动端按计划访问，密码状态明确 | 访问结果/时间：________ | 恢复密码或关闭发布入口 | 负责人/通过或阻塞：________ |
| 商品与库存 | 商品、变体、价格、Location 和缺货行为通过 | 商品/SKU：________ | 下架受影响商品 | 负责人/通过或阻塞：________ |
| 支付、税费与运费 | 目标市场成功、失败和边界用例通过 | 测试订单：________ | 暂停对应市场或支付方式 | 负责人/通过或阻塞：________ |
| 政策、通知与事件 | 政策可用、关键邮件到达、事件不重复 | URL/邮件/事件：________ | 恢复上一版本或停用异常来源 | 负责人/通过或阻塞：________ |
| 监控与回滚负责人 | 有人负责首日订单、支付、库存、通知和客服 | 负责人/观察窗口：________ | 触发条件达到时执行已写明动作 | 负责人/通过或阻塞：________ |
这一课需要做出的决定
按行填写当前店铺的实际值，不要把示例或计划值当成完成。实际值符合条件并有保存或测试证据，才可以标记通过。
| 项目 | 推荐设置 | 为什么 |
|---|---|---|
| QA 环境 | 受密码保护的候选版本 | 避免测试影响真实客户 |
| 上线门槛 | 所有 blocker 关闭 | 关键问题不能留到上线后 |
| 证据 | 预期、实际、截图、订单号 | 让问题可复现和复核 |
| 回滚 | 恢复密码或上一主题 | 故障出现时快速止损 |
这些地方先不要乱动
- 不要只跑成功订单，也不要只在管理员预览中测试。
- 不要在 QA 期间无记录地安装 App、改主题或改支付。
- 不要把 blocker 留到上线后再看；先写明恢复密码、暂停市场或回到上一主题的动作。
常见问题
一笔成功订单可以代表上线通过吗？
不可以。还要覆盖失败、取消、退款、折扣、运费、税费、不支持地址、通知、履约、追踪和事件边界。
可以在 QA 期间继续改主题吗？
不建议。先冻结候选版本；任何变更都要记录并标记受影响用例，否则旧结果不再证明当前版本。
测试模式关闭后就一定能收款吗？
不保证。还要确认 provider status、市场、币种、主域、结账、客户通知和真实监控，出现停止线要能回滚。
本课结论与继续条件
上线 QA 的完成标准不是“看起来没问题”，而是每个关键区域都有预期、实际证据、负责人、通过条件和失败动作。只有成功/失败/边界用例可对账、测试模式关闭、密码和监控经过复核，才进入下一步。