多地区发布冒烟测试：先跑哪些地区与停止条件

发布后的冒烟只回答一个问题：这次发布有没有把核心链路打坏。它不承担覆盖率证明，也不替代回归——把冒烟当回归用，通常意味着每个版本都在赌没测到的那条路径。多地区发布冒烟测试的价值在顺序和停止条件，而不在跑了多少地区。要在限定时间里拿到多个地区的真实出口，可优先评估动态住宅代理 IP；它改变的是访问位置，构建版本、开关状态、测试数据和账号权限仍在发布系统与测试环境一侧，出口换不来。按下面五个检查点跑一轮，任何一条触发停止条件就先停。

根据用户分布和改动范围选测试地区

组合地区与浏览器风险的取法，可参考国际化浏览器与地区测试矩阵。 地区不是先到先得，而是按"这次改了什么"来选。三类必须进：默认地区（多数链路以它为基准）、本次变更直接影响的地区（配置、文案、路由改动落点）、已知高风险的回退地区（历史上出现过落错语言或路由缺失）。

一个地区是否单独进清单，看它有没有独立的路由、权限、开关、数据或支付通道。共享构建不等于共享行为：同一份产物在不同地区可能走不同路由与配置。没有地区差异证据的，可以并组抽样，但并组理由要写进发布说明。

发布说明里要能写清"哪些地区这次不跑、为什么"，这一行比多列五个地区更有信息量。本次发布包含首次上线地区时，它单独成行并保留可追踪记录，不要并入同组地区的结论——合并之后就查不到它到底跑没跑。

地区清单定完，再决定这些地区用哪类出口进入；顺序反了，往往会为不需要出口的地区多买一份资源。

按入口、登录和核心流程依次检查

入口及地区语言映射的复核步骤见多语言网站链接回归测试。顺序不是偏好，而是责任划分：前一步不通，后一步的“通过”就没有参考价值。

按入口到核心任务的顺序逐项检查

固定顺序是：首页可打开 → 地区识别是否正确 → 登录或注册入口可达 → 一个核心任务能走到提交前 → 关键返回状态可读。每一步失败即停止后续，不要“先跑完再汇总”。登录检查只用测试账号，不触碰真实用户数据与生产权限。重试次数与时限由团队 SLO 或值班规则决定，本文不给具体数字。走到提交前只证明前置环节可达。若这条任务的价值在提交之后，另在隔离环境用测试数据补一次安全提交，并核对结果是否落库。

逐个地区执行并先排除出口故障

每个地区只跑这一条主干，不分支测试。分支（多语言切换、多种登录方式、异常态）留给回归。冒烟阶段引入分支，最常见的结果是时间耗尽而主干还没跑完。并行不是禁忌，前提是每个地区用独立账号、独立上下文、独立数据与独立资源预算；共享账号、共享配额或共享测试数据时才必须串行，否则地区差异和资源竞争会混在一起，复现成本反而更高。开跑前先确认出口本身是通的：记录响应码、握手耗时与重试次数，出口不稳时先换出口重跑，不要直接登记页面缺陷。

出现这些情况时停止并升级处理

哪些结果需要立即停止

停止条件要事先写死，三条就够：核心入口打不开、地区识别结果与预期不一致、核心任务在提交前报错。

命中任意一条，当前用例立即停止并登记缺陷，由值班负责人评估发布影响。是否扩大抽测由负责人授权：可以在隔离数据与独立账号下抽一两个代表地区，判断影响范围与是否共享组件，不必等凑够两个地区才升级。

表里"停止条件"一列记录的是页面现象，不是出口状态；出口不通时先换出口重跑，不登记为页面缺陷。

修复后如何确认恢复

升级按影响判断，不按地区数量：共享组件、公共接口或构建产物出问题，直接按发布级处理；只有单地区的配置或内容异常，才先按地区排查，不必立刻回滚全局。同一现象出现在两个地区只是加重证据，不是升级门槛。

恢复验证重跑受影响地区与被改动链路，并补跑一次基准地区，确认改动没带出新的地区差异；不做全量重跑。全量重跑既不必要，也会把已经排除的因素重新引入。

冒烟通过后继续做完整回归

冒烟通过不说明发布安全。接下来要做的是把本次变更点转成针对性回归清单：改动过的组件、模板、配置项各列一条用例，跑在受影响地区上。

通过结论里要写清覆盖了哪些地区、哪些链路、哪些没覆盖。没有未覆盖项的冒烟报告通常不可信——发布后的第一次冒烟几乎不可能覆盖所有地区。

如果冒烟发现问题，恢复后仍需重跑同一顺序，并把失败地区的出口、构建号、时间窗记进发布记录。否则下一轮无法判断是偶发还是回归。

FAQ

冒烟应该覆盖所有地区吗？

不需要。冒烟是风险抽样，覆盖默认地区、变更影响地区和高风险回退地区即可，其余地区在回归阶段补。

一个地区跑失败了，要不要继续跑下一个？

默认不要。命中停止条件先结束本轮，把失败复现清楚；是否在隔离数据与独立账号下抽测一两个代表地区，由负责人按发布影响决定，不要自行继续。

冒烟通过就能继续扩大发布吗？

不能。冒烟通过只代表主干链路可用，且这是发布后的验证，不是发布前的放行。变更点回归与未覆盖地区仍需按计划补齐，扩大发布的决定要同时看这两份结论。

冒烟必须用代理 IP 吗？

只有要验证真实 IP 的地理识别、CDN 分发或按 IP 生效的限制时，才必须用对应地区出口；地区配置、语言与账号分支可以在测试环境用参数或替身构造。需要真实出口时，短时多地区抽查用动态住宅代理 IP，长期固定同一地区观察用静态住宅代理 IP。需要在多个地区切换时，产品使用规则可参见动态住宅 FAQ。

"跑了几个地区"不是结论，"哪些地区必须跑、哪些缺口被接受"才是。发布窗口前的 30 分钟（团队预算示例，按实际并发与地区数调整）只跑这一条主干，其余检查留给回归。若访问地区需要按会话灵活切换，可按目标地区与并发要求评估动态住宅代理 IP方案，产品规则仍需在自有测试环境验证。