搜索入口与读者问题
Shopify 测试订单与上线 QA：从付款到退款逐层验收
先冻结候选版本，再用测试订单分别回读付款、折扣、运费、税费、通知、库存、履约、取消和退款。官方页面只说明入口与规则，不能替代当前店铺的订单、邮件、库存、资金或回滚证据。
Shopify 测试订单应该先覆盖哪些成功、失败和边界场景？
Test payment gateway 和 Shopify Payments test mode 怎样按当前店铺选择？
测试付款通过，为什么仍不能证明真实收款和 payout？
测试订单怎样同时核对折扣、免邮门槛、税费和不支持地址？
订单存在但通知、库存或事件不对，先从哪一层排查？
Shopify Payments 测试订单能不能真实履约或购买运单面单？
取消和退款怎样证明库存回补，而不是只证明按钮点过？
什么时候可以解除密码上线，什么时候要暂停或回滚？
官方来源与复核边界
这些页面用于确认测试订单、密码、取消、退款、Payments test mode 和上线准备的官方入口；它们不能证明本店真实支付、payout、银行退款、仓库发货、库存回补、通知投递或上线安全。证据请脱敏，别公开客户地址、订单号、支付资料或邮件内容。
第五阶段 · 上线验收
测试订单与上线 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、订单号、地址类型、金额、支付状态、错误提示、截图和复测时间。
验收订单后链路
先检查确认通知、库存 Committed、Location、员工测试通知、模拟交易和事件。不要真实履约 Shopify Payments 测试订单，也不要购买会收费的运单面单。履约回执和追踪模板应使用与真实仓库、承运商隔离的演练或测试环境；实际发货属于另行批准的操作，不是这笔模拟支付单的必做步骤。
做完后应该看到或拿到：得到订单后各环节的观察记录，标明哪些已在隔离环境演练，哪些真实履约结果还未取得。
怎样算完成：通知、库存和事件对同一测试单有可解释记录；履约与追踪分别标注隔离演练或未验证。模拟订单存在不等于已真实出库，缺少物流证据不能填成通过。
如果结果不对或入口没出现：订单有了但没有通知时，检查通知触发、recipient、sender、spam、模板和订单状态，必要时手工联系客户并留 incident 记录。
留下证据：保存脱敏订单、模拟交易、Location、测试邮件和事件引用，记录下游隔离方式。物流测试另附演练环境和结果，不混入真实发货记录。
失败处理：不要用后台有订单证明下游完成；从客户邮件、订单时间线和实际库存分别回读。
测试取消、退款和回补
在支持的测试路径中取消或模拟退款，确认记录、测试邮件、库存 restock、税行和事件。检查是否实际发生库存回补，不把点按钮当成完成。Shopify Payments 模拟交易不验证真实手续费、payout 或银行退款；这些项目分别留给实际资金对账。
做完后应该看到或拿到：得到取消/退款后的付款、库存、通知、税费和事件变化。
怎样算完成：退款金额、退款状态、库存回补、税行、通知和分析变化都有证据，不能只看按钮已点击。
如果结果不对或入口没出现：结果不一致时保留原订单、退款 ID 和时间线，按付款、库存、税费、通知和事件来源逐项定位后重测。
留下证据：记录订单号、取消/退款类型、退款 ID、库存变化、税行、邮件、事件和手续费边界。
解除密码并开启上线监控
关闭阻塞项后，确认 payment test mode 已关闭，主域和 Markets 正确；按测试前记录恢复需要的自动化和自动履约，并再次确认不会把遗留测试单发给仓库。第二人核对后再解除店铺密码保护。首日监控 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/邮件/事件：________ | 恢复上一版本或停用异常来源 | 负责人/通过或阻塞：________ |
| Payment test-mode gate | paid plan；Shopify Payments test mode 或 Test payment gateway；生产流量窗口已隔离 | 支持模拟成功、拒绝/失败等 checkout 路径。 | test mode 期间 live credit-card orders 受影响；模拟交易不进入 payouts/reports。 | 通过 / BLOCK |
| Fulfillment isolation | 自动履约 / warehouse app 已停用或隔离；不购买真实 shipping label | 订单后链路可以在不真实发货的情况下检查。 | 测试订单被真实履约或买面单会产生真实操作/费用，不应作为默认验收。 | 通过 / STOP |
| 监控与回滚负责人 | 有人负责首日订单、支付、库存、通知和客服 | 负责人/观察窗口：________ | 触发条件达到时执行已写明动作 | 负责人/通过或阻塞：________ |
当前设置需要确认的决定
按行填写当前店铺的实际值，不要把示例或计划值当成完成。实际值符合条件并有保存或测试证据，才可以标记通过。
| 项目 | 推荐设置 | 为什么 |
|---|---|---|
| QA 环境 | 受密码保护的候选版本 | 避免测试影响真实客户 |
| 上线门槛 | 所有 blocker 关闭 | 关键问题不能留到上线后 |
| 证据 | 预期、实际、截图、订单号 | 让问题可复现和复核 |
| 回滚 | 恢复密码或上一主题 | 故障出现时快速止损 |
这些地方先不要乱动
- 不要只跑成功订单，也不要只在管理员预览中测试。
- 不要在 QA 期间无记录地安装 App、改主题或改支付。
- 不要把 blocker 留到上线后再看；先写明恢复密码、暂停市场或回到上一主题的动作。
常见问题
一笔成功订单可以代表上线通过吗？
不可以。还要覆盖失败、取消、退款、折扣、运费、税费、不支持地址、通知、履约、追踪和事件边界。
Test payment gateway 和 Shopify Payments test mode 有什么区别？
两者都能模拟 checkout，但 Shopify Payments test mode 依赖已完成的 Shopify Payments setup；Test payment gateway 是 Shopify 提供的测试 gateway。当前文档也说明 gateway testing 需要 paid plan。要按当前店铺真实 provider 选择，不混用真实卡信息。
为什么测试完一定要再确认 test mode 关闭？
因为 payment provider 处于 test mode 时，真实信用卡订单不能按正常 live 路径处理。上线签字必须把 test mode off 作为明确 gate，而不是假设有人之后会关。
可以在 QA 期间继续改主题吗？
不建议。先冻结候选版本；任何变更都要记录并标记受影响用例，否则旧结果不再证明当前版本。
测试模式关闭后就一定能收款吗？
不保证。还要确认 provider status、市场、币种、主域、结账、客户通知和真实监控，出现停止线要能回滚。
当前结论与继续条件
上线 QA 的完成标准不是“看起来没问题”，而是每个关键区域都有预期、实际证据、负责人、通过条件和失败动作。只有成功/失败/边界用例可对账、测试模式关闭、密码和监控经过复核，才进入下一步。
下一步按问题分流