跨浏览器测试要依据产品支持策略和用户证据，选择有风险依据的浏览器、引擎、操作系统、版本、设备与流程组合。好的覆盖矩阵会说明每一格为什么重要、需要什么证据，也不会把未运行的环境写成兼容。
为什么需要这个 Skill
只列出浏览器名称，无法说明覆盖是否符合产品承诺。多个 Chromium 浏览器可能使用相同引擎，而 WebKit 或 Gecko 路径仍未覆盖；模拟视口也不能证明真实设备或操作系统输入的行为。
Skill 用来做什么
跨浏览器测试 Skill 会将已提供的支持规则、用户分布、已知缺陷、环境信息和已有运行记录，整理成一组规模适当、可复核的兼容性候选。它会保留每个覆盖单元的浏览器与设备身份，并指出仍缺少的证据。
Awesome QA Skills 按语言和测试阶段组织 Skill。系列总览 介绍通用安装方式；本文专讲跨浏览器覆盖决策。
根据证据建立覆盖矩阵
选择覆盖单元时，综合产品支持的浏览器和设备策略、用户权重、高风险流程、已知引擎差异，以及 CI 或设备实验室能力。真实浏览器、真实设备、模拟器和自动化引擎要分别记录。
| 矩阵维度 | 要记录的证据 | 它要回答的问题 |
|---|---|---|
| 支持单元 | 引擎、浏览器、版本、操作系统、设备，以及真实或模拟环境 | 这个环境是否属于明确的支持范围？ |
| 用户和流程风险 | 用户分布、受影响流程、已知缺陷与影响 | 为什么要把它纳入样本？ |
| 待验证行为 | 渲染、输入、存储、权限或平台集成 | 这个环境中哪些行为可能不同？ |
| 现有证据 | 构建、环境身份、运行时间、产物和结果来源 | 现有记录是否确实匹配这个单元？ |
不能根据 Chromium 浏览器的品牌数量推定 WebKit 或 Gecko 已覆盖。模拟视口也不是触控、操作系统键盘、硬件或浏览器集成行为的证明。如果没有支持规则或用户分布，就将单元选择标为未评估，并提出最小补充资料请求。
选取覆盖单元前先审计输入
源 Prompt 要求记录六类输入状态。把它们用于跨浏览器覆盖分析，避免按熟悉的设备矩阵填补缺口。
| 状态 | 跨浏览器示例 | 有边界的处理方法 |
|---|---|---|
| known / 已知 | 带版本的支持策略明确列出桌面 Firefox 和移动 Safari | 引用策略及生效日期 |
| missing / 缺失 | 未提供浏览器版本、操作系统、设备类型或用户权重 | 将对应矩阵维度留为未评估 |
| conflicting / 冲突 | 支持策略排除某浏览器，发布说明却称其受支持 | 并列两份来源，请负责人确认范围 |
| stale / 过期 | 旧运行记录针对的版本已不在支持窗口内 | 保留为历史证据，不视作当前覆盖 |
| out_of_scope / 范围外 | 本次不含嵌入式 WebView 或实体设备测试 | 明确记录排除项 |
| assumptions / 假设 | 首轮样本暂用一个声明过的流量估算 | 说明由谁验证，以及判断依赖什么 |
对每条现有运行记录，都要核对具体引擎、版本、平台、构建、数据和环境。表格里相邻的一行并不等于证据匹配。
示例：已保存支付方式的结算流程
假设团队要评审一个已保存支付方式的结算流程，计划使用键盘和触控，在 Chromium、WebKit 和 Firefox 上比较。本例只是任务描述，不足以证明所有组合都受支持，也不能证明某个浏览器已有缺陷。
有边界的设计分析可以先把“桌面 Firefox＋键盘”和“真实触控设备上的 WebKit”列为候选单元，再查支持策略与用户分布后确定优先级。Chromium 单元可以用于比较，但如果 WebKit 或 Gecko 属于支持范围，它不能代替对应引擎。操作系统、版本、支持状态和环境身份未给出前，结论只能是候选，不能算覆盖证据。
CBT-01 候选发现：支付弹窗关闭后的焦点
这是发现记录设计示例，不代表已经观察到故障。
| 发现字段 | 示例记录 |
|---|---|
| 对象与前置条件 | 支付弹窗关闭后的焦点行为；仅当指定浏览器和设备属于支持策略，且能复现相同构建、账号状态与视口时才适用 |
| 关注点与触发条件 | 如果需求或现有证据涉及此行为，检查弹窗关闭后键盘用户是否仍能到达预期焦点位置 |
| 来源与证据状态 | 本例只给出流程目标，没有支持矩阵、需求或运行产物；标记 UNASSESSED |
| 影响与优先级 | 取决于支持状态、受影响用户和流程影响；等证据和负责人评审后再定 |
| 责任角色 | 浏览器兼容性或 UI 测试负责人 |
| 验证与关闭条件 | 获授权的执行者在匹配环境中比较同一操作，并保存引擎/版本/系统、焦点元素、DOM 或可访问性状态、截图和控制台证据。只有当观察差异关联到受支持单元，且预期行为有来源可查时，才能关闭。 |
Skill 可以提出这种验证建议，但不会运行结算流程，也不会把候选写成缺陷。交付时要分开事实、证据支持的推断、候选建议和 Human 决策。
按环境交接证据
交给下一位执行者的材料应包括：选中的单元及选择理由、流程和前置条件、预期行为的来源、已有证据，以及最小后续验证动作。把首次出现差异的步骤和环境元数据放在一起；只有截图、没有浏览器、版本、系统、构建和数据上下文，后续难以比较。
覆盖数量不是覆盖结论。未运行单元、过期记录、互相冲突的支持规则和无法提供的设备，都应保留为未解决项，直到负责人确认。
怎样准备更好的输入
提供支持矩阵及版本、用户或设备分布、目标流程、已知浏览器缺陷、CI 或设备实验室限制和原始运行记录。移除个人及支付数据。材料缺失时，Skill 应给出受限的选择理由和待确认问题，而不是替团队编造浏览器策略。
和其他 Skill 配合
- UI 测试策略定义跨浏览器检查应保护的流程与平台范围。
- UI 测试选择器评审检查不同引擎中的选择器行为。
- 可访问性测试提供键盘和辅助输入的专项判定依据。
常见错误
- 把浏览器品牌数量当成不同引擎的覆盖数量。
- 同时改变浏览器、数据和视口，导致差异原因无法定位。
- 把截图或模拟器运行当成真实设备行为证明。
- 将不受支持或尚未运行的单元写成兼容。
安装与调用
安装这个 Skill：
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/cross-browser-testing -g使用 cross-browser-testing Skill 时，附上项目支持规则、目标流程、环境身份和已有证据。
常见问题
每个浏览器版本都要覆盖吗？
根据支持策略中的版本窗口和用户证据选择样本，并记录未覆盖版本的原因；不要暗示它们已经测试。
云端浏览器能证明移动端兼容吗？
不能单凭云端浏览器得出结论。应记录提供商、系统镜像、引擎版本、设备模拟和输入能力。没有目标设备类别的证据时，真实设备行为仍未评估。
参考
调用 Skill 前先阅读跨浏览器测试 Prompt，其中定义 CBT-## 发现字段与证据边界。源目录包含入口文件与可能存在的配套资料。