webapp-testing 用于检查本地网页的交互行为。它采用 Python Playwright，先观察实际渲染页面，再选择元素并执行操作，也提供帮助管理一个或多个开发服务的脚本。适合确认搜索、表单、筛选和导航流程，不应该只把“浏览器能打开首页”当作测试完成。
安装与调用
在 Claude Code 的聊天输入框依次发送下面两条命令。这是插件命令，不是在系统终端运行的 Shell 命令；第二条安装的是包含 webapp-testing 的官方技能包。
/plugin marketplace add anthropics/skills
/plugin install example-skills@anthropic-agent-skills
安装后，在同一项目的会话里明确说“使用 webapp-testing”，再提供文件或任务。下面的提示词是可修改的首次输入示例。安装会加入技能说明与资源；它不会替你准备输入资料，也不代表所有依赖已经在本机安装。若找不到技能，先检查插件是否安装并启用，以及会话是否已加载最新插件，再继续任务。
给它一个有预期结果的操作
使用 webapp-testing 检查本地商品目录的搜索流程。
启动命令是 npm run dev，端口 5173。
输入已知商品名应显示对应结果，输入不存在的词应显示空状态，清除后恢复列表。
先观察页面再选定位器；保存失败截图和浏览器错误，不修改应用代码。
提供启动方式、端口、允许使用的账号或数据，以及每一步应该发生什么。如果服务已经在运行，直接给 URL，不要再启动第二个实例占用同一端口。涉及提交表单的测试，应说明它连接测试环境还是会产生真实记录，避免测试范围和业务操作混在一起。
对于静态 HTML，可以先读文件了解结构；动态应用则要先等待页面到达可操作状态，再查看截图和 DOM。技能示例使用 networkidle 等待，但持续联网的应用可能无法进入完全安静的状态；这时应围绕真正需要的元素和页面状态设置等待，而不是不断增加固定延迟。
用辅助脚本管理服务生命周期
随包 scripts/with_server.py 支持启动服务后执行测试，并在结束时清理服务。先查看它的 --help，确认自己的启动命令与端口，再交给 Agent 组合。文档也展示前后端两个服务的形式，测试脚本本身只需要关注浏览器操作。相对脚本路径以安装后的技能目录为准。
定位元素时优先使用真实可见名称、角色或稳定标识，观察页面后再写选择器。测试搜索时，不只检查输入框里出现了文字，还要检查结果数量或具体条目、空状态和清除后的行为。这样一条流程才有可以判断对错的完成条件。
失败后同时看断言、截图、控制台错误和服务状态：可能是按钮行为错误，也可能是服务未就绪、依赖缺失或测试数据与预期不一致。把这几类问题区分开，再决定要修应用还是修测试。结束时关闭浏览器，保留可重复运行的脚本、输入数据和结果说明。若下一步要自动修复代码，可以另行明确授权范围；本例首先得到的是可复现的问题证据。
把一次点击扩展为可复现的旅程
例如检查商品搜索，不妨准备一个确实存在的商品和一个不存在的关键词。依次执行搜索、检查结果、进入详情、返回、清除筛选，并记录每步应出现的元素。这样既测试搜索也测试状态是否在导航后保留。直接写“页面正常”无法指出哪个交互坏了。
失败时保存当前 URL、截图、控制台报错和相关网络请求状态，先确认是应用错误、启动失败还是测试数据已变化。选择器应依据实际渲染后的标签和角色，不要因为源码里有某个类名就假设用户能看到它。测试脚本最后清理浏览器和本次启动的服务，方便下次在相同前置条件下重跑。
测试环境也要成为步骤的一部分
写测试前记录基准 URL、数据库或种子数据、浏览器尺寸，以及是否允许提交真实表单。一个结账测试若不说明使用沙箱支付，就不能安全地按生产流程跑。需要登录时使用获准的测试账号，避免把个人会话或私有 Cookie 写进脚本。让 Agent 把启动服务、等待就绪、执行断言和清理进程放进同一可重跑流程；这样别人拿到失败记录时能复现，而不必猜本机当时运行了什么。
测试的是用户旅程，不是能否打开网页
可从登录开始：写明测试账号、入口、登录后应到的页面，以及登出或返回时的预期，再让 Agent 用 Playwright 验证。一个公开示例通过这类脚本发现登录流程依赖浏览器历史，认证状态也没有及时更新。若 Skill 被拿来抓远程价格页，那已偏离本地 Web 应用测试的用途；把请求写成“启动本地服务，执行动作并断言结果”，更容易得到可复现的失败记录。