使用 Web Platform Tests 建立浏览器功能信心

Web Platform Tests 在声明条件下提供规范证据，但不保证每个应用流程都能成功。应分开记录规范、共享测试、页面能力检查和用户可见的应用结果。能力存在不代表用户身份或设备类别。BotBrowser 可以提供受控的配置来运行能力检查，但不能改变标准如何定义某项能力，也不能改变其他浏览器如何实现它。

TL;DR

• 通过的 WPT 测试只证明某个算法在声明的来源、harness 和时机下成立，不证明应用流程一定走完。
• 先读元数据：tentative、flaky 或标记为预期失败的条目是覆盖问题，因非安全上下文或缺少用户手势而被跳过的测试，不能当成绿色通过。
• 把 missing、available、denied、failed、completed 五个状态分开记录，因为方法存在既不代表权限已授予，也不代表服务器已写入。
• 应用侧单独验证：响应带 201 和 Location 头，提示放在带 role="status" 与 aria-live="polite" 的元素里，备用控件可以用键盘触达。
• 在同一份记录里保存 WPT 路径、规范章节、浏览器构建、harness 版本、fixture 修订和结果日期，任一项变化就重跑这组子集。

目录

• 选择 WPT 证据
• 运行时能力检查
• 决策表
• 失败 fixture
• 应用验证
• BotBrowser：范围
• 实践结论

选择 WPT 证据

查看 WPT 仓库 和 testharness API。记录测试路径、规范章节、浏览器版本、来源、权限和日期。跳过、试验性或预期失败的测试需要保留备用路径。试验性功能的背景见源站试验与实验性 Web 平台功能。

结合元数据阅读结果。安全上下文、用户手势或权限策略可能让本地运行不同。复用 fixture 前检查许可证、依赖和清理行为。

可复现的 harness 观察

WPT 的公开实现可以直接检查 harness 边界。在固定提交的副本中运行 git grep -n "promise_test" -- resources | head -5，再打开 WPT 仓库 中的 resources/testharness.js。匹配结果显示，返回的 Promise 会在 harness 内完成，test.done() 或完成回调负责收口测试，这与产品服务器响应是两回事。这一公开实现观察把 WPT 通过与应用保存记录分开：前者只能证明浏览器到达断言，后者还需要应用自己的信号。把提交号和测试路径与浏览器结果一起保存，其他复核者就能重复检查。把服务器确认记录为独立的应用断言。

运行时能力检查

在调用前检查实际需要的方法，区分缺失、可用、拒绝、失败和完成。属性存在不能证明权限、服务可达或服务器写入成功。

保留用户输入并提供键盘可用的备用操作。记录来源、安全上下文、版本、状态、备用路径和可见结果，不采集无关属性。

决策表

观察	决定	可见结果	边界
声明矩阵中的 WPT 通过	纳入候选	能力检查后尝试	规定条件下的符合性
WPT 跳过或试验性	检查元数据	保留备用路径	测试覆盖
方法缺失或上下文受限	使用备用操作	保留任务	页面能力
调用被拒绝	分类一次	显示恢复操作	浏览器行为
调用完成	验证应用	确认可见信号	浏览器与应用

失败 fixture

fixture 创建自己的控件，只模拟自有 API，检查可见文字，并在所有分支删除节点。不要修改指纹或发送凭据。

async function run() {
  const host = document.createElement('div');
  host.innerHTML = '<p id="status"></p><button id="fallback" hidden>使用备用操作</button>';
  document.body.append(host);
  const status = host.querySelector('#status');
  const fallback = host.querySelector('#fallback');
  try {
    const ok = typeof navigator.share === 'function';
    const result = ok
      ? await navigator
          .share({ title: '合成项目', url: '/fixture' })
          .then(() => 'done')
          .catch(() => 'failed')
      : 'missing';
    status.textContent = result === 'done' ? '已完成' : '请使用备用操作';
    if (result !== 'done') fallback.hidden = false;
    console.assert(status.textContent && (result === 'done' || !fallback.hidden));
    return result;
  } finally {
    host.remove();
  }
}

应用验证

调用后验证应用所属的状态消息、控件或记录。promise 成功不代表服务器已保存记录。分开验证浏览器与应用结果，并测试焦点、键盘、标签和恢复路径。

浏览器版本、规范、安全上下文、权限或 harness 变化后，重新运行矩阵。保存 WPT 路径、状态、备用路径和复核日期，不保留个人内容。按平台与版本组织这些结果，可参阅按平台与版本设计浏览器测试矩阵。

BotBrowser：范围

BotBrowser 可为授权的 WPT 参考流程和重复能力检查提供受控上下文。隔离上下文分开可变状态并比较可见结果。

它不认证 WPT、不授予权限、不把来源变为安全上下文、不替代规范基础设施，也不证明服务器事务。BotBrowser 隔离文档说明可重复性，不是普遍兼容保证。

另请阅读浏览器 API 兼容与回退指南和 WebDriver BiDi 指南。

BotBrowser 可提供授权的 WPT 参考流程和可重复的受控上下文检查，但不保证规范符合性、不授予权限，也不替代业务事务证明。请同时记录能力和限制。

当规范、WPT、浏览器矩阵、应用和 fixture 各有负责人时，信心更可靠。记录路径、版本、来源、状态、备用操作和可见结果。

诚实使用负面证据。跳过、拒绝或超时都应分类，不能隐藏为通过；在应用证据充分前保留备用路径。

保存包含 WPT 路径、版本、上下文、状态、可见断言和备用操作的简短记录。

用同一 fixture 比较候选版本和上一版本，并保留第一个有意义的失败。

为每个例外记录负责人和复核日期。

注明可见备用操作，便于支持人员复现结果。

让未运行浏览器的人也能读懂记录，并说明边界、结果和下一步。

这样有限证据不会变成普遍承诺。

同时记录日期和下一次复核负责人。

这样浏览器信心可以持续更新。

结果应保留规范符合性与应用行为之间的边界。

不要把受控上下文描述为普遍保证。

来源

• Web Platform Tests 仓库
• WPT testharness API
• BotBrowser：多账号隔离

实践结论

每一层只问一个问题并写下答案：这份 WPT 文件覆盖哪个算法、页面实际调用到哪个方法、能力检查返回哪个状态、应用最后确认了哪个可见结果。决策表的一行如果在每一层都有答案，发布记录就站得住；缺一层时，诚实的写法是未测试，而不是通过。

先在合成页面上跑 fixture，用模拟的 navigator.share 和默认隐藏的 #fallback 按钮，并保留同时检查可见文字与备用控件的 console.assert。然后把这套流程放进受控上下文里重跑，并配合 wpt run --channel dev --log-wptreport wptreport.json，让浏览器构建和 pass、skip、fail 计数待在一起，而不是手抄一张表。

下一个浏览器版本发布前，重跑声明的子集，逐条对比两份记录。改动某个浏览器的条目之前，先让受影响客户路径的负责人看过差异，并在应用证据表明可选路径无需备用控件也能工作之前保留回退。