SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场frontend-testing-debugging

frontend-testing-debugging

测试与质量

查看项目

更新于 10-21 22:51

技能介绍

用途

该技能用于在已渲染的前端界面上进行测试、调试或针对性改进，通常配合 Frontend Design Skills 插件、web dev 插件或 frontend dev 插件使用。它面向普通用户提示工作，不要求用户明确写出浏览器路由、截图、报告格式或回退策略。

触发场景包括：要求使用 web dev 插件改进 Web 仪表盘交易搜索区域、使用 frontend dev 插件打磨仪表盘、使用 Frontend Design Skills 插件调试 UI、测试本地 localhost 应用并修复损坏的交互等。

主要能力

  • 从简短提示中推断目标界面：依据仓库、当前打开的应用/浏览器 URL、附近文件或正在运行的开发服务器。若目标 URL 不明确，先检查仓库脚本和运行中的本地端口，再询问用户。
  • 对任何已渲染前端界面的代码改动，默认执行验证循环：识别目标流程、选择浏览器路径、做最小有用编辑、验证渲染行为、回复 QA 最终响应报告。
  • 浏览器路径分类：
    • Available：会话中列出了 Browser 插件及其 browser 技能，先阅读并遵循该技能再执行任何浏览器操作。
    • Absent：未列出 Browser 插件或 browser 技能，使用常规 Playwright，并记录“Browser plugin not available”。
    • Invocation failed：Browser 看似可用，但技能/运行时、Node REPL JavaScript 设置、标签页获取或导航失败，视为 Browser 路径阻塞。
  • 当 Browser 可用时，不首先使用常规 Playwright、外部 Chrome 或 shell open。仅当用户已允许回退或任务明确允许非 Browser 验证时，才从失败的 Browser 调用切换到常规 Playwright，并报告确切的 Browser 失败和回退决定。

使用方式

目标流程定义

在浏览器验证前，用一句话定义目标流程：

The flow under test is: [entry route] -> [user action or state] -> [expected rendered result].

若用户要求通用冒烟测试，则使用：

The flow under test is: app loads -> first meaningful screen renders -> primary visible controls respond without runtime errors.

Browser 插件循环

通过 Browser 技能描述的 Node REPL JavaScript 工具运行 Browser 命令，不自行发明独立的浏览器设置路径。除非 Browser 技能另有说明，保持使用同一标签页绑定。

必需顺序：

  1. 严格按 Browser 技能指示加载 Browser 运行时。
  2. 使用 agent.browser.nameSession("...") 命名会话。
  3. 使用 agent.browser.tabs.selected() 或 agent.browser.tabs.new() 获取标签页。
  4. 使用 tab.goto(url) 导航。
  5. 运行下方必需检查。
  6. 使用作用域内的 tab.playwright 定位器或 Browser 技能交互 API 进行交互。
  7. 编辑后调用 await tab.reload()，然后重复检查及失败交互。

对每个改变 UI 的操作，收集最廉价的下一个状态正确性证明：新的 DOM 快照、可见文本/状态、URL 变化、聚焦控件、toast、模态框、截图或控制台日志。

必需 Browser 检查

在声称渲染应用可用前运行：

  • 页面身份：await tab.url() 和 await tab.title() 与预期页面匹配。
  • 非空白：await tab.playwright.domSnapshot() 包含有意义的应用内容，而非空壳。
  • 无框架覆盖层：快照或截图不显示 Next.js、Vite、Webpack 或框架错误覆盖层。
  • 控制台健康：await tab.dev.logs({ levels: ["error", "warn"], limit: 50 }) 无相关应用错误，或每个相关错误都有解释。
  • 截图证据：await display(await tab.playwright.screenshot({ fullPage: false })) 支持视觉声明。
  • 交互证明：至少执行一个目标流程交互，并随后进行状态检查。

对于视觉工作，在可行时增加桌面加一个移动尺寸视口。对于参考驱动的工作，保留简短的不匹配台账：参考证据、渲染证据、修复或有意偏差。

Playwright 循环

当 Browser 不可用，或用户在 Browser 调用失败后允许回退时使用此分支。

顺序：

  1. 在 package.json 中查找脚本。
  2. 使用仓库的包管理器启动应用，并保持请求的主机精确。
  3. 若存在仓库的 e2e 脚本，优先使用。
  4. 否则在配置了 Playwright 时运行 pnpm exec playwright test 或包管理器等价命令。
  5. 若无项目 Playwright 工作流，用 pnpm exec playwright --version 验证 Playwright，然后用 pnpm exec playwright screenshot <url> /tmp/frontend-check.png 捕获截图。
  6. 如需更深入调试，在提交源码之外创建小型临时 Playwright 脚本，打开 URL、捕获控制台错误、截图并运行目标交互。
  7. 编辑后重新运行相同命令或脚本。

除非任务需要且用户允许依赖变更，否则不安装新的浏览器依赖。

验证清单

  • 保持请求的主机精确。
  • 验证控件更新真实 UI 状态。
  • 滚动前检查首个视口，并在可行时检查桌面和一个移动尺寸视口。
  • 查找裁剪、重叠、不可读文本、换行、布局偏移、缺失资源、z-index 问题、滚动陷阱、过期加载和损坏状态。
  • 对于参考驱动的工作，将渲染截图与参考对比，保留简短不匹配台账。
  • 当请求渲染验证时，仅构建通过是不够的。

QA 最终响应报告

对任何非平凡的渲染 UI 验证运行，像 QA 工程师验证代码改动一样撰写最终响应，便于用户或 PR 审查者理解改了什么、测了什么、证据是什么、还有什么未测。

格式：

  • Summary：一两条要点说明用户可见改动及 QA 是否通过。
  • Environment：URL、视口、Browser 可用性分类，以及若使用 Playwright 的回退原因。
  • Changes Verified：改动的文件或界面，以及预期的具体用户可见行为。
  • Checks：页面身份、空白页检查、框架覆盖层检查、控制台健康、截图证据、交互证明的通过/失败表。
  • Interaction Loop：测试的确切交互路径，包括执行的控件或工作流及观察到的状态变化。
  • Evidence：在 QA 部分描述截图证据，然后将实际截图作为连续图片放在响应末尾。包含尽可能多的有用截图以证明相关的前、后、交互、响应式、错误或修复状态。
  • Commands / Browser APIs：列出关键命令和 Browser API 序列，不倾倒嘈杂日志。
  • Remaining Risk：未测试的视口、流程、浏览器、数据状态或已知限制。

若发现问题，在摘要前先列 Findings。每个发现应包含用户看到什么、复现步骤、截图/DOM/控制台证据、已知时可能的负责人或文件，以及所做修复或剩余阻塞。

使用 Browser 截图并应展示给用户时，通过 Browser 运行时发出或显示截图，以便在聊天中引用。使用 Playwright 截图时，保存在仓库外并在聊天中引用。当有助于验证不同状态或流程时包含多张截图。

不要将截图穿插在书面报告中。在最后放置简短 Screenshots 部分，使其成为连续图片画廊，每行一张图片。仅在澄清状态时添加简短标签，例如 Before、After、Filtered results、Empty state 或 Mobile。

默认不创建单独的 HTML 报告。仅当用户明确要求时创建独立报告文件，且除非用户明确要求提交产物，否则写在仓库外。

除非用户明确要求提交产物，否则不将报告、截图、追踪或临时脚本写入仓库。

相关技能

  • 当任务是设计创建、重新设计或对已接受概念的保真度时，使用 openai-frontend-design。
  • 在重要的 React/Next.js 组件编辑后，使用 react-best-practices。
  • 普通调试不要调用 Image Gen。仅当任务需要创建或修改视觉资产，或 openai-frontend-design 已在驱动概念到实现的保真度循环时使用。

最终响应

使用上述 QA 最终响应报告格式。保持简洁，但包含足够具体证据，使 PR 审查者无需立即重跑即可信任验证。

若 Browser 缺失而使用了 Playwright，最后建议用户安装 Browser 插件，以获得更好的前端开发体验，包括应用内导航、截图、DOM 快照、控制台日志和交互验证。

适用场景

  • 通过 Frontend Design Skills 或 web dev 插件对已渲染前端应用进行测试、调试或针对性改进。
  • 需要从简短提示推断目标界面并执行完整验证循环的前端改动。
  • 需要 QA 风格最终报告、截图证据和交互证明的前端验证任务。

限制

  • 当 Browser 可用时，不应首先使用常规 Playwright、外部 Chrome 或 shell open。
  • 仅当用户已允许回退或任务明确允许非 Browser 验证时，才从失败的 Browser 调用切换到常规 Playwright。
  • 除非任务需要且用户允许依赖变更，否则不安装新的浏览器依赖。
  • 默认不创建单独的 HTML 报告，也不将报告、截图、追踪或临时脚本写入仓库，除非用户明确要求。
  • 普通调试不调用 Image Gen。
  • 资料未提供具体收费、价格、平台支持范围或效果保证等信息。