SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场playwright-triage

playwright-triage

测试与质量

查看项目

更新于 10-15 14:34

技能介绍

用途

playwright-triage 用于对 Playwright 的 GitHub issue 进行分诊（triage）。其目标不是修复问题，而是得出一个清晰、经过验证的状态结论。

主要能力

1. 先对 issue 分类

按内容而非标签判断 issue 的真实类型：

  • Bug：需要复现，这是该技能的主体部分。
  • 功能请求（Feature request）：无需复现。检查该功能是否已存在（搜索文档/API，可能以其他名称存在），阅读并核实报告者引用的来源，并指出真正的设计问题。如果请求小而明确（例如“失败时大声报错而不是静默失败”），理想产出是一个验收测试：一个自包含的 spec，断言当前行为（今天通过），并把期望行为作为 fixme/注释断言并列其中。
  • 上游/环境问题：属于真正的外部责任方（Node 项目、浏览器引擎、网站自身的服务器/证书配置），而非 Playwright。需要找到真正的责任方，不要强行复现，核实所引用的上游 issue 并指出真正的修复路径。注意：Playwright 家族——@playwright/mcp（源码位于本仓库 packages/playwright-core/src/tools/mcp/）、playwright-vscode、-python、-java、-dotnet——不属于“上游”，它们就是本项目自身。绝不要告诉报告者去项目内其他仓库重新提交。
  • 问题/使用咨询：直接回答或指向文档。

2. 复现 bug

  • 如果用户提供了最小复现，先尝试它。如果无法复现，尝试他们可能遗漏的因素：三种浏览器、有头/无头模式、若干近期版本，以及代码片段或触发方式的各种变体。只有在真正充分探索之后才报告“无法复现”，并说明尝试过什么。
  • 跨浏览器运行，留意差异——只在 webkit 复现、或除 firefox 外都复现的 bug 是值得优先指出的强信号。许多 bug 与浏览器无关，同样真实：在所有浏览器上复现是好结果，而非“未发现”。
  • 阅读整个讨论串，包括评论——缺失的复现或收窄的触发条件往往就在那里。
  • 提取输入：版本、浏览器、操作系统、复现仓库/片段、期望与实际（作为判断依据）。若有缺失，先猜测并尝试，在报告中注明假设。
  • 优先在 tip-of-tree 上复现，目录为 ~/tmp/issue-<number>/：克隆链接的仓库，或用 npm install @playwright/test@next 搭建单项目配置（参见 bisect-published-versions.md）。使用 PLAYWRIGHT_HTML_OPEN=never。若在 ToT 上复现，则是活跃 bug——记录测试的确切版本/sha，若疑似回归则进行二分（参见指南）。
  • 若 ToT 不复现，尝试用户报告的版本。若该版本复现而 ToT 不复现，说明已修复——找出修复的版本/PR（cherry-pick 可能仍值得）。若两者都不复现，则是不完整或环境特定——说明无法匹配的部分。（以 -next 结尾的版本，如 1.62.0-next，不是 npm 版本——它表示 tip-of-tree，即你已尝试的 @next 构建。）
  • 若 ToT 复现，搜索相关报告。先检查 issue 时间线中的交叉引用。使用 GitHub MCP 的 issue 和 pull request 搜索工具，而非 CI 中的 gh，并限制为少量搜索。用诸如 repo:microsoft/playwright "exact error string" 和 repo:microsoft/playwright <API name> <trigger> 的查询搜索开放和已关闭的 issue 与 PR。也搜索相关家族仓库：microsoft/playwright-python、microsoft/playwright-java、microsoft/playwright-dotnet、microsoft/playwright-vscode。阅读有用的匹配项和关联变更，包括维护者决定和后续报告。比较 API 用法、触发条件、版本和行为，而不仅是标题。检查现有 API 或选项是否实际满足报告者的目标，而非回避失败操作。若现有证据已确立重复或已发布修复符合报告者条件，直接报告该状态，无需重复复现。
  • 要交互式单步调试测试，使用 playwright-cli 技能。
  • 报告有时针对 Playwright 项目的其他部分——@playwright/mcp（源码在本仓库）、playwright-vscode、playwright-python、playwright-java、playwright-dotnet。这些都是本项目自身，照常分诊：检出该仓库并在其自身语言/工具链中复现。绝不要告诉报告者该 issue 属于另一个 Playwright 仓库或应重新提交——那是内部分流细节，不是报告者的问题。

3. 将复现精简为自包含测试

将庞大或应用特定的复现提炼为单个自包含 spec，按项目测试风格编写：一个 test(...)，使用 page 和 server fixture，并标注 issue 链接。关键要求：

  • 不使用 test.beforeAll / afterAll，不使用 http.createServer，不手动 setup/teardown。fixture 已提供 page 和 web server。使用 server.setRoute(...)、server.setRedirect(...)、server.PREFIX、server.EMPTY_PAGE，而非自建服务器。
  • 用 page.setContent(...) 或 page.goto(server.PREFIX + '/...') 驱动页面。
  • 只保留触发 bug 所需内容，并以失败的断言结尾。
  • 放入仓库（tests/page/）并用 npm run ctest 运行。

可参考的真实自包含测试示例：

  • tests/page/page-network-request.spec.ts — should return event source：server.setRoute SSE 端点，无生命周期钩子
  • tests/page/selectors-css.spec.ts — should use light DOM structure for child combinator with slotted content：page.setContent 配合内联 shadow DOM（#37768）
  • tests/page/workers.spec.ts — should report worker script as network request after redirect：server fixture 配合路由/重定向 + 浏览器缺口 fixme（#35678）

4. 验证相关修复

对于相关 PR，检查其是开放、关闭未合并还是已合并，修复是否已发布及在哪个版本。在可用时对 PR 分支运行精简复现，记录确切 commit 和结果。若修复已发布，也在该发布版上验证复现。报告任何无法验证的内容，而不是把开放或已合并的 PR 当作修复的证明。

5. 报告

给出符合 issue 类型的状态——对于 bug：reproduced / fixed-on-latest / cannot-reproduce / not-a-bug / duplicate of #N；对于功能请求或上游/环境问题：简短结论（already-possible、valid request、upstream — owned by X）——并附证据。对于 bug，包含精简复现，并详尽说明运行过的内容——完整的浏览器、版本和变体矩阵，而不仅是成功的那一个——以便读者信任结论并跳过重复检查。指出任何浏览器特定差异。用 Playwright bot 语气撰写（.github/workflows/bot-voice.md，相对于仓库根目录）——维护者语气，而非 AI 腔。

注意事项

  • 只运行你信任的代码——先浏览链接的仓库/片段；若有 postinstall 脚本、混淆代码或随机小库，停止并在 issue 评论中报告。
  • 分诊止于复现和状态；不要跳到修复。

适用场景

当被要求分诊、复现或验证一个 GitHub issue（新 bug 报告等）时使用。

限制

该技能聚焦于分诊与复现，不负责实际修复。具体支持的版本、平台等细节以资料所述为准，其余暂未提供。