mcpField
W
web-testing

web-testing

github.com/onsager-ai测试与质量761 次安装2 周前更新
代码仓库

关于 web-testing

web-testing 是一项探索式测试技能，用真实浏览器验证仪表盘 UI 变更，不替代回归测试。它指导 Agent 按代码差异检查相关路由的桌面和移动视口，并以截图和结构化结论记录结果。

主要功能

  1. 01将代码变更映射到相关路由
  2. 02测试桌面和移动视口
  3. 03操作界面并验证结果
  4. 04截取截图作为证据
  5. 05将发现转化为确定性测试
  6. 06分类端到端测试失败

适用场景

  1. 01验证拉取请求中的仪表盘改动
  2. 02检查响应式布局回归
  3. 03调查端到端测试失败
  4. 04为发现的问题添加持久测试

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/onsager-ai/dev-skills --skill web-testing

安装后在 Claude Code 中输入/web-testing确认已加载。

详细介绍

Web Testing Protocol（L2）

对仪表板 UI 变更进行探索式、AI 驱动的验证——不是回归测试。回归覆盖由 L1 负责（仪表板测试目录下的冒烟测试和端到端测试套件）。L2 用于捕捉 L1 遗漏的问题：布局错误、移动端回归，以及只会在真实浏览器中失败的交互流程。

**在其他仓库中采用：**此流程（读取差异 → 映射到路由 → 在两个视口下运行 agent-browser → 截图 → 给出结论）与仓库无关。下方的路由表、测试路径和结论架构是来自 onsager-ai/onsager 的示例。Fork 此技能，并将这些具体内容替换为你自己的仪表板对应内容。

何时调用

  • PR 涉及 apps/dashboard/**
  • L1 端到端测试失败，需要判断这是真正的回归、偶发问题还是环境问题
  • 有人要求“验证 UI”或“试用这项变更”

被测应用

CI 流水线会构建 crates/stiglab/deploy/Dockerfile——一个整合 Rust 后端（stiglab + synodic）和预构建仪表板 SPA 的单一映像。它监听 http://localhost:3000。

主要路由：

路由页面标题
/工厂概览Factory
/sessions会话列表Sessions
/sessions/:id会话详情—（动态）
/nodes节点列表Nodes
/artifacts构件列表Artifacts
/spine事件主干查看器—（动态）
/governance治理Governance
/settings设置和凭据Settings

视口（始终测试这两种）

  • 桌面端：agent-browser set viewport 1280 720
  • 移动端：agent-browser set viewport 375 812

移动端很重要——仪表板采用响应式布局（参见各处的 md: 断点）。横向溢出和导航隐藏是最常见的两类回归问题。

流程

  1. 读取差异（git diff $DIFF_RANGE）——CI 会通过环境变量提供 DIFF_RANGE。
  2. 将变更映射到路由。 修改 src/pages/SessionsPage.tsx ⇒ /sessions。修改 src/components/layout/** ⇒ 所有路由。
  3. 针对每个受影响的路由，在每个视口下：
    • agent-browser open http://localhost:3000<route>
    • 对页面进行快照；验证标题和关键元素是否正常显示。
    • 主动操作交互元素——不要只检查标记：
      • 点击按钮、提交表单、打开对话框。
      • 验证操作结果——UI 状态是否变化、对话框是否关闭、是否出现了新数据？标记存在并不能证明功能正常。
    • 检查布局错误。尤其是在移动端：出现横向滚动即为失败；导航遮挡内容也为失败。
    • 运行 agent-browser screenshot --screenshot-dir /tmp/l2-screenshots，然后将输出文件重命名为 {route-slug}-{desktop|mobile}.png。
  4. 将发现固化为测试。 验证新行为或发现能够描述修复方案的错误时，在 apps/dashboard/tests/smoke/（组件级）或 apps/dashboard/tests/e2e/（浏览器级）下编写确定性的 L1 测试。这是将 L2 发现转化为永久 L1 覆盖的方式。
  5. 输出结论。 返回符合 tests/l2-verdict-schema.json 的 JSON：
    • 如果每条受影响的路由在两个视口下都通过，则为 PASS。
    • 如果任一路由失败，则为 FAIL；在 viewports[].issues[] 中列出具体失败情况。

分类模式

在 L1 端到端测试失败后调用时，你的任务有所不同：

  1. 阅读 apps/dashboard/tests/e2e/ 下失败的测试文件。
  2. 使用 agent-browser 在 http://localhost:3000 上复现问题。
  3. 对每个失败进行分类：回归（实际错误）、偶发问题（间歇性问题／时序问题）或环境问题（测试框架或 CI 问题）。
  4. 返回符合 tests/l2-triage-schema.json 的 JSON，其中包含根本原因和建议的修复方案。

防护措施

  • 范围限于差异内容。一行改动无需重新测试整个应用。
  • 截图是必需的证据——没有截图，就说明视口没有运行。
  • 不要凭空编造路由。如果差异中新增了路由，就使用该路由；否则沿用上表。
  • 控制成本。每个视口使用一个浏览器会话就足够了。

评论

支持 Markdown