按平台与版本设计浏览器测试矩阵
为受支持的用户流程、平台和浏览器版本建立可维护的风险型兼容性矩阵，平衡覆盖、证据与发布决策。
BotBrowser Team
浏览器测试矩阵是覆盖决策，不是所有浏览器的清单。它把受支持的平台与版本连接到重要用户流程，并在失败代价高的地方加深测试。矩阵应可复现、可解释且便于维护。
选择受支持环境
从支持契约开始：操作系统、浏览器家族、版本范围、视口、输入方式和网络。每个单元都要有理由和负责人。Web Platform Tests 提供一致性 fixture，MDN Browser Compatibility Data 提供兼容性元数据，但都不能替代应用测试。
const cell = {
platform: 'linux',
browser: 'chromium',
release: '154',
viewport: 'desktop',
input: 'keyboard-and-pointer',
network: 'stable',
};
const journeys = ['sign-in', 'checkout', 'download'];
for (const journey of journeys)
await runJourney({ cell, journey, evidenceId: `${cell.browser}-${cell.release}-${journey}` });
标签描述测试条件，不推断用户机器。将 profile、路径、语言、数据状态和权限与单元一起保存。不同配置应建立明确的新单元。
| 单元决策 | 证据 | 动作 |
|---|---|---|
| 关键单元 | 支持契约与用户影响 | 每个候选版本运行 |
| 代表单元 | 流量或功能覆盖 | 按计划运行 |
| 探索单元 | 新平台或计划支持 | 限时且不阻塞 |
| 退役单元 | 无受支持用户 | 经负责人批准移除 |
| 未知单元 | 无负责人或证据 | 不称为受支持 |
排列用户流程
按影响、变化率、复杂度和恢复成本排序。登录、结账、上传、导出和键盘操作可能是关键流程；信息页可以只做 smoke check。把优先级原因写在矩阵旁边。
流程卡应包含前置条件、动作、可见结果、清理和证据。分开功能、视觉、可访问性和性能结果。导航成功不代表焦点、错误提示或窄视口布局正确。
平衡平台与版本覆盖
平台覆盖操作系统、输入、图形和字体；版本覆盖浏览器引擎变化。选择 baseline、当前、候选和一个仍受支持的旧版本，不要无理由乘上每个 patch。
把高风险流程配给能暴露其失败模式的单元，并分开记录浏览器、profile 和产品 build 标签。
BotBrowser 受控上下文支持在声明 profile、平台、版本、视口和网络的情况下重复授权流程。这是其能力。它不会选择支持政策、替代 WPT、保证每个版本，也不授权针对第三方服务的测试。这些是其限制。
审查矩阵漂移
支持范围、版本、路径或风险变化都会造成漂移。发布、路由或政策变化后审查矩阵，并保留负责人、日期、证据和退役原因。
单元失败时先分类为应用缺陷、浏览器回归、环境配置、测试数据或已批准回退。重跑最小 fixture 并比较已知正常单元。只有当证据改变支持或发布决策时才扩展覆盖。
做发布决策
在候选版本测试前定义阻塞规则。关键流程失败可阻塞发布；探索单元可以创建 follow-up。记录矩阵版本、平台标签、build、流程结果、限制、负责人和回滚条件。矩阵通过不证明服务器、授权或业务完成。
审查应写明下一步动作和负责人。
在选择单元前先写清支持问题。
比较过程中保持基线不变。
每个流程保留前置条件和清理步骤。
功能与视觉结果分开记录。
可访问性属于流程结果的一部分。
profile 与版本变化应分别比较。
失败单元要与已知正常单元对照。
矩阵成本应和覆盖一起评估。
例外必须有负责人和到期日期。
负面证据要留给下一次审查。
下载流程需要可验证的清理。
视觉路径需要声明状态和视口。
WPT 与兼容性数据是上下文，不是保证。
支持政策定义版本何时退役。
单元结果可以是 pass、block、follow-up 或 retire。
标签描述测试条件，不描述个人。
下一次 fixture 只改变一个重要变量。