tech官小西

Webapp Testing 技能评测 — 让 AI Agent 真正可用的浏览器测试方案

Webapp testing 决策树和侦查-执行模式

从 AI agent 的角度测试 Web 应用是一个出人意料地困难的问题。Agent 没有眼睛，没有鼠标肌肉记忆。每个断言都必须显式编写，每个选择器都必须准确无误，而且测试开始时服务器可能还没启动。webapp-testing 技能就是为了弥合这个鸿沟——问题是我们的够不够好，还是外面有更好的？

当前生态

在 AI agent 生态中搜索 webapp 测试工具，会发现一个鲜明的模式：几乎不存在专门为此设计的工具。GitHub 上搜索 "webapp testing AI agent skill" 返回零个有意义的结果。已有的工具分为三类：

  1. 通用浏览器自动化（Playwright、Puppeteer、Selenium）— 强大但无预设策略。给你一个浏览器，不是给你一个测试方法论。
  2. 视觉测试平台（Percy、Chromatic）— 回归测试很棒，但为人工驱动的 CI 流水线设计，不是 AI agent 工作流。
  3. Agent 专用浏览器工具（browser-harness、agent-browser）— 交互能力强但并非为测试而生。

webapp-testing 技能填补了"给你一个浏览器"和"给你一个测试"之间的空白。它提供了决策树、服务器生命周期管理和匹配 AI agent 实际工作方式的侦查-执行模式。

我们技能做对了什么

决策树是核心亮点。它问了两个每个 AI agent 在测试前都应该问的问题：

  1. 是静态 HTML 吗？ 如果是，直接读取文件找选择器。别浪费浏览器时间。
  2. 服务器在运行吗？ 如果不在，用 with_server.py 启动。如果在，直接进入侦查阶段。

这些看起来显而易见，但大多数测试工具跳过了这些问题。它们假设服务器已经在运行，或者启动了但不等待就绪，或者为一个本可以 50ms 解析完的静态页面启动了一个完整浏览器。with_server.py 设计得尤其好——支持多个服务器（后端+前端），等待端口就绪，退出时清理一切。我们的测试中，它零故障处理了 Django + Vite、FastAPI + Next.js 和三服务 Docker Compose 场景。

侦查-执行模式是另一个杀手特性。与其试图提前预测选择器（在非平凡的 SPA 上必然失败），这个模式说：导航→截图→检查 DOM→识别选择器→执行操作。这匹配了开发者调试测试时的实际工作流。你没见过渲染页面之前，不可能知道按钮的选择器。

缺失了什么

这个技能是工具箱，不是框架。它提供了基础积木但没有测试结构：

  • 没有断言库。 你手动写 page.locator('h1').text_content() 再比较。一个薄层封装，提供 expect_text()、expect_visible()、expect_count() 能大幅减少样板代码。
  • 没有测试组织。 没有测试套件、fixture 或 setup/teardown 的概念。每个脚本都是独立的孤岛。
  • 没有失败报告。 wait_for_selector() 超时时，得到的是 Playwright traceback。没有聚合，没有汇总，没有"5 个测试中 3 个通过"。

这些不是致命缺陷——这个技能为 AI agent 编写一次性验证脚本而设计，不是为人类开发者构建回归测试套件。但随着我们的 agent 写出越来越多的测试脚本，缺少结构就变成了摩擦。

外部替代方案：没有值得切换的

我们搜索了 PyPI、npm 和 GitHub 寻找可比较的 AI agent 测试技能。找到的最接近的几个：

  • Midscene.js — 使用自然语言断言的 AI 驱动测试。概念有趣，但需要 AI 调用的 API key，每次断言增加 2-5 秒延迟。
  • Shortest — 另一个 AI 测试框架。类似自然语言方法。同样的 API key + 延迟问题。
  • Browser Use 的测试工具 — Playwright 的薄层封装。比我们的技能结构更松散。

这些都没有提供令人信服的切换理由。要么太重（依赖 API），要么太慢（每次断言跑 AI），要么太薄（只是换了名字的 Playwright）。

值得借鉴的

唯一值得采用的外部模式是自然语言断言作为可选层。不是替换显式选择器——那太慢且不稳定——而是作为选择器断言失败时的后备：

Try: page.locator('.submit-btn').is_visible()
If timeout: ai_assert("页面上可以看到提交按钮")

这结合了显式选择器的速度和基于视觉后备的鲁棒性。Midscene.js 做得不错；我们可以借鉴概念而不引入依赖。

改进路径

三个改动可以将这个技能从"有用的工具箱"升级为"基础设施级能力"：

  1. 添加测试运行器包装。 一个简单的 Python 类，接受测试函数列表，顺序执行，收集结果，打印摘要。30 行代码，体验质量巨大提升。

  2. 添加常用断言辅助函数。 expect_text(selector, text)、expect_visible(selector, timeout=5s)、expect_count(selector, n)。减少样板代码，让测试脚本更可读。

  3. 添加视觉差异支持。 当 expect_visible() 失败时，自动截图并保存到测试输出旁。Agent 后续可以分析截图来理解断言为什么失败。

最终判断

保留现有技能。它填补了生态中的真实空白，核心工作做得到位。加入以上三项改进，并考虑轻量级自然语言断言后备。技能本身没问题——只是还没长完。