地区化浏览器测试矩阵：怎么选组合而不是全排列

浏览器、语言、地区三样相乘就是几百个组合，全跑一遍的代价没人扛得住，而问题通常只集中在少数组合里。地区化浏览器测试矩阵要解决的就是把组合数压到能每周复跑的量级，靠的是选样依据，不是穷举。只有"应用地区"这一维需要外部条件时，才轮到出口出场，可优先评估静态住宅代理 IP；它只改变访问位置，浏览器版本、设备时区和账号状态都不由它决定。先把三个高风险组合跑通一轮，再决定要不要扩。

先按用户和支持范围确定浏览器版本

语言、浏览器和组件的抽样还可参考多地区可访问性回归。 浏览器集合不是越多越好，要与产品支持政策对齐。先列出官方支持的浏览器与系统组合，标出主流组合、最低支持版本和本季度新增版本三类。

版本集合先保留三类：官方最低支持版本、当前主要使用版本、本次变更触及的 API 或渲染边界。其余版本能否并成一档，要看功能兼容证据、支持政策与历史回归记录，并写明合并人；跨内核（Blink、WebKit、Gecko）不合并。同一内核的大版本之间也会出现 API 缺失与渲染差异，不能默认合并。

真实用户侧只取两个数：各浏览器与语言的访问占比、近三个月的报错分布。取不到时把选择依据标为待确认，不虚构市场占比。

把浏览器、语言、设备和出口分别控制

"地区"不是一个开关，至少拆成五项：

• 语言与区域格式。
• 应用读取的地区配置。
• 设备时区。
• 账号所在地。
• 网络出口。

每一项都可能单独影响页面结果。合并成一个"地区"字段之后，出问题就说不清是哪一层。

五项里只有"网络出口"需要代理 IP，其余四项靠配置和账号控制；把它们捆成一项，是常见误配。

应用按哪个维度决定地区，由它自己的优先级规则决定；常见顺序是显式选择、账号、Cookie、出口 IP，但这是示例，要以被测应用的实现为准。测试前先把这套顺序确认下来，再设计冲突用例。这解释了为什么"浏览器设成某地区"不代表站点按该地区运行。要让出口参与测试，就把它作为单独变量，并记录应用最终识别到的地区，而不是记录"我设了哪个出口"。

共享组件（导航、表单、支付前一步）要用同一套维度复测，因为组件级差异会在所有地区放大。

优先测试高风险组合，避免全排列

进入发布窗口后，可按国际站发布后地区冒烟测试把高风险组合排到前面。 分层依据是失败影响，不是组合数量。高风险组合（核心任务 × 主流内核 × 主要地区）必须全跑；中风险按共享组件变更挑选代表值；低风险静态页只做小样本抽检。

表里"是否进回归"这一列要能站得住脚：某个组合被降级，就写下降级理由和下次复核时间，否则半年后没人知道它为什么没测。

同一组合换出口后结果变化，说明出口在这个样本上确实参与了决策；结果不变只能说明本样本没观察到差异，还要继续排查更高优先级的来源、同组映射与缓存。

记录已测组合和未覆盖的风险

每个组合记录四项：选择依据、实际生效配置、覆盖到的路径、未覆盖风险。组合执行完不等于覆盖完成，路径没走到关键提交前的状态，等于没测。

矩阵要能按变更增量维护：共享组件改动时复用组件矩阵，浏览器升级时只扩相关内核的兼容检查，地区新增时先补该地区的核心任务组合。发现的问题挂到对应缺陷号，否则下次复跑会重复发现同一个问题。

若某个组合连续加载失败，先按代理 IP 出口可用率与延迟测试的口径排除出口因素，再判断是不是兼容问题。

未覆盖项要显式写进发布说明，尤其是"某地区没有任何组合覆盖"这种结构性缺口。

FAQ

浏览器、语言和国家要做全排列吗？

通常不需要。全排列会让成本线性膨胀，而有效覆盖增长很慢。按用户覆盖、代码差异和失败影响挑组合，并把未覆盖项写明。

浏览器设成某地区就代表网站按该地区运行吗？

不一定。应用可能读账号、Cookie、显式选择或出口 IP，且优先级不同。测试要记录应用实际采用的配置和页面结果，而不是只记录你改了什么。

同一内核不同大版本能合并吗？

有证据时可以。前提三条同时成立：公共 API 无差异、该版本近几个版本没有渲染回归记录、支持政策一致，并写明合并人与复核日期。缺任何一条就单列；一旦出现版本相关缺失，立刻拆开。

测试矩阵要长期复跑，出口该怎么选？

出口固定一类更容易比较结果：需要长期稳定复跑时用静态住宅代理 IP，需要大量地区快速轮换时用动态住宅代理 IP。机房出口同样有可验证的地理位置，做可达性与大批量筛查够用；只有要验证住宅属性、或目标站点对住宅与机房区别对待时，才必须换成住宅样本。固定地区会话的产品说明可参见静态住宅 FAQ。

矩阵的产出不是"测了多少组合"，而是"哪些组合必须测、哪些缺口被接受"。这份判断要署名，并写下一次复核时间。若测试环境的出口本身属于变量，可按目标地区、会话与协议要求评估静态住宅代理 IP方案，产品规则与数据隔离仍需在自有测试环境验证。