UI 测试的日常，是不是这样？
周五下午，上线前最后一次回归。你打开测试平台，手动点过每一个页面——首页、列表页、详情页、创建表单、提交、删除……一个流程走完 20 分钟，10 个流程就是半个下午。中间弹了个弹窗没处理，整个流程白跑。
你想写自动化脚本？打开框架文档，写选择器、写断言、写等待逻辑、处理异步加载……一个用例写半小时，页面一改版，选择器很可能立刻失效。
更扎心的是：用例覆盖全凭经验，漏测的永远是没想到的那个路径。
如果只需要说一句"帮我测这个网站"，AI 就自动遍历页面、梳理用例、执行测试、输出报告呢？
这正是 ui-testing 想解决的问题。
ui-testing：一句话搞定 UI 自动化测试
ui-testing 是一个基于 Chrome DevTools MCP 的 UI 自动化测试 Skill。给它一个 URL，它就能自动完成从页面探索到报告输出的整条链路：
用 ui-testing 测试 https://your-site.com
接下来它会自动完成：
- 页面 遍历：基于 BFS 先广后深，自动发现站内可达页面
- 用例梳理：从页面结构中提炼端到端业务流程，并按优先级排序
- Playbook 沉淀：按站点保存测试经验，下次直接复用
- 测试执行：直连本地 Chrome，真实操作页面并截图留证
- 报告输出：生成标准化 Markdown 报告，包含通过率、报错统计和截图
零脚本，零配置，零维护。 你只负责说"测什么"，它负责补上"怎么测"。
它是怎么做到的？
直连你的 Chrome，不是模拟请求
ui-testing 通过 Chrome DevTools MCP 直连你本地已打开的 Chrome 浏览器。就是你日常使用的那个 Chrome：已登录的账号、已保存的 Cookie、当前真实的前端状态，全都在。
这意味着它不需要额外启动一个隔离的无头浏览器，也不需要你重新登录一遍系统。对后台系统、运营平台、数据控制台这类"必须登录后才能测"的场景尤其友好。
前端框架感知，不瞎操作
现代 Web 应用大量使用 Vue、React、Angular，表单状态往往由框架自己的响应式系统管理。直接改 DOM 值，很多时候并不等于"真正完成输入"：Vue 的 v-model 可能不会触发，React 的 state 也未必会更新。
ui-testing 内置框架探测，会自动识别页面所使用的框架，并选择对应的交互策略：
| 框架 | 操作方式 |
|---|---|
| Vue 2 | 通过 vue 实例直接操作组件数据 |
| Vue 3 | 通过 vue_app 获取应用实例 |
| React | 沿 Fiber Tree 定位组件状态 |
| 通用回退 | 使用原生 setter + dispatchEvent 强制触发响应 |
不是暴力填表，而是用框架的方式操作框架。
Playbook 驱动，越跑越快
第一次测试某个站点时， ui-testing 会遍历页面、梳理用例、生成 Playbook。第二次再测同一个站点，可以直接复用 Playbook，跳过大部分重复探索，速度会明显提升。
Playbook 不只是用例列表，还会沉淀站点的技术特征：框架类型、表单组件路径、下拉框值映射、SPA 路由特征……这些信息会让后续测试更精准，也减少重复试错。
想更新用例？加一句话就行：
用 ui-testing 测试 https://your-site.com，更新用例
经验自进化，越用越聪明
这是 ui-testing 最有意思的设计之一：三层经验 回写 机制。
| 层级 | 回写内容 | 效果 |
|---|---|---|
| Playbook 层 | 站点技术特征、表单映射 | 同站点复测更快更准 |
| 通用脚本层 | 新框架探测逻辑 | 支持的框架越来越多 |
| 策略层 | 新场景的处理方案 | Shadow DOM、iframe、富文本编辑器逐步覆盖 |
遇到新框架，就回写到探测脚本；遇到新场景，就回写到策略层。你测过的每一个站点，都在反过来增强这个工具。
更重要的是，这些经验不是黑盒参数，而是以 Markdown 形式沉淀下来：人可读、可版本控制、可迁移，也方便团队协作和持续维护。
它适合哪些场景？
如果你符合下面任意一种情况， ui-testing 都会很顺手：
- 上线前回归：想快速确认关键流程有没有被改坏
- 后台系统冒烟测试：系统依赖登录态，传统脚本启动成本高
- 新页面上线验收：先让 AI 帮你把可达路径和基础用例摸清楚
- 重复性巡检：同一个站点需要定期复测，希望越测越快
尤其是那种"人点起来很机械、写脚本又嫌重"的场景，它的价值会非常明显。
快速上手
安装 Skill
使用 Agent 自然语言自动安装（推荐）。你只需要把下面这段话发给 Agent，让它自己完成下载、放置和接入：
请帮我安装 ui-testing 这个 Skill：
1) 从 https://github.com/bodhiye/ui-testing 获取最新代码，将整个 ui-testing 目录放到你的 skills 目录下
2) 运行 node scripts/chrome-devtools-mcp.mjs 启动 Chrome DevTools 端口
3) 将脚本输出的 mcpServers.chrome-devtools 配置片段注册到你的 MCP 配置中，确保端口号与脚本输出一致；若需重载配置则自行重启
4) 调用 list_pages 验证 MCP 工具可用，确认能返回 Chrome 标签页列表
完成后告诉我：Skill 放置路径、MCP 配置位置、验证结果
对话即测试
用 ui-testing 测试 https://your-target-site.com
如果你已经跑过一次，还可以直接让它更新既有用例：
用 ui-testing 测试 https://your-target-site.com，更新用例
使用建议
为了让结果更稳定，也更安全，实际使用时建议注意这几点：
- 优先在真实可操作的登录态下执行：
ui-testing直连本地 Chrome，登录后再测通常更接近真实业务流程 - 先从只读或低风险流程开始：尤其是在生产控制台、运营后台这类环境里，先验证页面进入、搜索、筛选、表单打开等安全动作
- 把复测交给 Playbook：首次探索负责"摸清页面"，后续复测负责"快速验证变更"
- 把报告当成协作产物：测试截图、失败步骤、页面上下文可以直接拿给研发、测试、产品一起看
写在最后
UI 自动化测试的痛点，从来都不是"能不能测"，而是维护成本太高：脚本和页面强绑定，页面一变脚本就废；用例靠人写，覆盖率全凭经验；框架五花八门，适配成本居高不下。
ui-testing 换了一个思路：让 AI 去理解页面、理解框架、理解业务，再替你完成从用例设计到测试执行的整条链路。 用例自动生成、经验自动沉淀、框架自动适配，你只需要给出一个 URL。
它当然不是 UI 测试的终局，但很可能代表了一种新方向：测试不再从脚本开始，而是从一句自然语言开始。
