
这次我们来看一个字节跳动开源的 AI 自动化测试项目Midscene.js。它的核心思路不是传统“根据选择器找元素”而是让大语言模型直接理解页面结构再用自然语言描述“我要做什么”自动完成点击、输入、断言、数据提取等一系列操作。如果你之前写过 Playwright、Selenium又觉得脚本维护成本高、页面元素一改就要重跑定位逻辑那 Midscene.js 值得认真看一看。它最值得关注的几个点第一上手成本比传统自动化测试低得多不需要写复杂 XPath 或 CSS 选择器第二它支持自然语言指令能直接说“点击登录按钮”“提取列表里的所有标题”第三它把 Playwright 做成了底座说明可以复用成熟浏览器自动化体系第四AI 自动化测试不是演示 Demo它可以跑批量任务、接 CI/CD也能封装成接口服务对外提供能力。这篇文章直接从实战角度带你走一遍环境准备、依赖安装、模型接入、功能测试、批量任务、接口封装、常见问题排查。不会只停留在“什么是 AI 自动化测试”的概念层面。看完之后你至少能搭出一个可以跑自然语言 Web 自动化用例的最小项目并判断它适不适合落到你当前的测试体系里。如果你已经比较熟悉 Playwright那么这半个小时就能完成大部分搭建工作如果你是刚接触自动化测试也没关系我会把每一步命令和代码都拆开写复制后按自己的页面调整即可。1. 核心能力速览能力项说明项目类型浏览器端 UI 自动化测试框架 / AI 测试工具开源方字节跳动核心原理LLM 理解页面截图与 DOM 信息根据自然语言指令完成操作主要功能自然语言操作、AI 断言、数据提取、页面问答、浏览器自动化运行环境Node.js 环境依赖浏览器自动化能力浏览器支持Chromium 系浏览器为主可通过 Playwright 或对应浏览器扩展接入本地 GPU 要求通常不依赖本地 GPU主要调用视觉大模型接口如需本地模型可另做适配启动方式npm 包方式、脚本方式、浏览器插件方式接口能力可封装为 HTTP 服务也可在 Node.js 脚本中直接调用批量任务支持通过脚本循环或任务队列批量执行页面场景适合场景Web 回归测试、表单流程测试、数据抓取、页面内容校验、AI 交互验证这里必须补充一个前提Midscene.js 依赖大模型对页面的理解能力。也就是说它并不是纯本地规则引擎而是“视觉理解 自然语言 浏览器自动化”的组合。因此你需要准备一个支持视觉理解的大模型 API或者接入本地兼容服务。关于模型选择后面会专门讲。2. 适用场景与使用边界2.1 适合谁用测试工程师日常回归用例写烦了想减少元素选择器维护。前端开发写完页面想快速验证关键路径是否能跑通。RPA 方向开发者需要把重复网页操作变成自动化任务。测试平台建设者想在现有平台里增加“自然语言测试”能力。产品 / 运营如果用浏览器插件版也能快速录制并回放一些简单流程。2.2 能解决什么问题传统 UI 自动化的最大痛点是页面 DOM 一改动XPath、CSS 选择器就可能失效。Midscene.js 的做法是让模型理解“页面上有什么”例如你告诉它“点击‘下一步’按钮”模型结合截图和 DOM 信息找到对应位置并执行。页面 class 变化通常不影响自然语言描述这是很大的维护成本优势。它还能做几类事情确定性的交互操作比如登录、填表、翻页页面状态断言比如“当前页面是否出现错误提示”结构化数据提取比如“把这个表格第一列所有文本提取出来”甚至可以进行页面问答比如“这个页面改版后用户引导文案写的是什么”。2.3 不适合什么场景AI 输出有不确定性。如果你要处理的是要求毫秒级响应、严格幂等、每次结果必须完全一致的场景传统自动化脚本仍然更合适。另一个边界是如果被测页面有严格的访问控制、数据脱敏要求或者不允许自动化访问那么无论是传统工具还是 Midscene.js都要先确认授权和边界。未经授权抓取第三方页面、攻击性测试、绕过登录验证等行为不属于“实战教程”的合理范围。涉及版权、隐私、肖像、敏感数据时也要先确认是否有权使用。尤其是要接入电商、支付、社交平台页面做自动化验证时必须遵守平台规则和所在地区法律。3. 环境准备与前置条件Midscene.js 虽然是 AI 驱动但基础环境并不复杂。它是一个 Node.js 生态下的工具所以先准备 Node.js 环境。3.1 基础环境清单项目建议操作系统Windows 10/11、macOS、Linux 均可Node.js建议使用 LTS 版本例如 Node.js 18 或更高版本包管理器npm、pnpm、yarn 任选浏览器Chromium 或 Chrome 系浏览器模型 API需要支持视觉理解的大模型 API 或本地兼容服务网络环境能访问模型 API 服务及被测页面磁盘空间主要是浏览器和 npm 依赖通常几 GB 内3.2 验证本地环境打开终端执行node -v npm -v如果能看到版本号说明 Node.js 环境基本没问题。接下来创建项目。4. 安装部署与启动方式4.1 创建项目并安装依赖mkdir midscene-demo cd midscene-demo npm init -y接着安装 Midscene.js 与 Playwrightnpm i -D midscene/web playwright typescript tsx这里使用 TypeScript 是为了写自动化脚本时更友好如果你更习惯 JavaScript可以省略typescript和tsx。安装完 Playwright 后需要安装浏览器内核npx playwright install chromium如果是内网环境下载浏览器可能会失败。可以设置 Playwright 的镜像源或者手动指定浏览器路径。具体方法要根据你的网络环境和版本去查对应文档。4.2 配置模型服务Midscene.js 需要模型来理解页面。最稳妥的方式是把模型配置放到环境变量里不写死在代码中。在项目根目录创建.env文件OPENAI_API_KEY你的APIKey OPENAI_BASE_URLhttps://你的模型服务地址/v1 MIDSCENE_MODELgpt-4o如果你使用的是 OpenAI 兼容接口的模型比如某些国产模型、本地部署模型通常也能通过baseURL切换。这里的变量名是通用示例实际使用时以当前版本官方文档为准。4.3 编写第一个最小脚本创建一个first.ts文件import { Agent } from midscene/web; import { chromium } from playwright; (async () { const browser await chromium.launch({ headless: false }); const page await browser.newPage(); const agent new Agent({ page }); await agent.ai(打开 https://example.com); await agent.ai(等待页面加载完成然后告诉我页面标题); await agent.ai(断言页面标题包含 Example Domain); await browser.close(); })();启动npx tsx first.ts如果模型配置和页面访问都没问题你应该能看到浏览器自动打开、执行操作并在控制台输出结果。这里先解释一下agent.ai并不是传统意义上的“点击指定元素”而是把自然语言指令交给模型模型结合页面状态决定下一步动作。所以同一行指令在不同页面下的表现可能不同这是正常现象。5. 功能测试与效果验证接下来按照四个维度做功能验证自然语言操作、AI 断言、数据提取、页面问答。建议用一个稳定的测试页面来跑比如你自己本地启动的静态页面或者一个内部练习系统。5.1 自然语言操作先写一个最简单的表单流程测试比如登录、搜索、提交表单import { Agent } from midscene/web; import { chromium } from playwright; (async () { const browser await chromium.launch({ headless: false }); const page await browser.newPage(); await page.setViewportSize({ width: 1280, height: 800 }); const agent new Agent({ page }); await agent.ai(打开 https://example.com/login); await agent.ai(在用户名输入框输入 test_user); await agent.ai(在密码输入框输入 test_password); await agent.ai(点击登录按钮); await agent.ai(等待 2 秒告诉我当前页面是否出现了用户中心入口); await browser.close(); })();这个用例看起来像“人话”但执行背后经历的过程是截图、解析 DOM、模型推理、定位元素、执行操作。如果页面有弹窗、懒加载、异步渲染模型不一定能准确找到目标元素。这时候需要把指令写得更具体比如“点击页面右上角红色登录按钮”。判断成功的标准浏览器按预期完成输入和点击。页面上出现了对应结果。控制台没有报错。5.2 AI 断言Midscene.js 里可以专门做断言判断页面状态是否符合预期。例如const result await agent.aiAssert(当前页面没有出现 500 错误); console.log(断言结果:, result);如果页面出现“500 Internal Server Error”模型会返回断言失败反之返回成功。相比传统断言“等待某个元素出现”AI 断言更接近人的观察方式看整体页面状态而不是某个 DOM 节点。5.3 数据提取自动化测试经常会验证“页面数据是否正确展示”。用自然语言提取数据非常直观const data await agent.aiQuery(提取当前页面所有商品名称和价格用 JSON 数组返回); console.log(提取结果:, data);模型会把页面中看到的商品名、价格整理成结构化 JSON。这一步很适合用来做页面内容校验或者做舆情监控、数据采集场景。不过要注意如果页面数据量很大模型上下文有限应该先控制范围比如“只提取第一屏的商品卡片”。5.4 页面问答除了操作和提取你还能直接向页面提问const answer await agent.aiQuery(这个页面的导航栏有哪些功能入口); console.log(answer);这种“页面问答”能力适合用来做 UI 改版后的内容巡检比如对比不同页面的文案、模块功能是否一致。但它依赖模型视觉能力页面截图模糊时结果会不稳定。5.5 失败排查思路如果模型找不到按钮可以先排查页面是否加载完成如果模型误解了指令可以把指令改得更具体比如补充位置、颜色、文本内容如果模型返回格式不正确可以显式说明输出格式例如“只返回 JSON不要额外说明”。6. 接口 API 与批量任务Midscene.js 本身不是 HTTP 服务但它可以很方便地被包成接口也可以直接写循环跑批量任务。下面分别给方案。6.1 用脚本批量跑多个 URL假设你需要对一批页面执行相同操作比如“打开每个页面检查标题是否正常”import { Agent } from midscene/web; import { chromium } from playwright; const urls [ https://example.com/page/1, https://example.com/page/2, https://example.com/page/3, ]; (async () { const browser await chromium.launch({ headless: true }); const results: Array{ url: string; title?: string; ok: boolean } []; for (const url of urls) { const page await browser.newPage(); const agent new Agent({ page }); // 这里做简单的重试防止单次 AI 调用失败导致任务中断 for (let retry 0; retry 2; retry) { try { const title await agent.aiQuery(告诉我当前页面的标题); results.push({ url, title, ok: true }); break; } catch (error) { console.error(第 ${retry 1} 次失败:, url, error); } } await page.close(); } console.table(results); await browser.close(); })();这个模式已经具备“批量任务”的雏形。生产环境里可以把urls换成任务队列把results写进日志或数据库。6.2 封装成 HTTP 接口如果测试团队希望把 AI 自动化测试能力集成进平台可以写一个简单的 Node.js HTTP 服务import express from express; import { Agent } from midscene/web; import { chromium } from playwright; const app express(); app.use(express.json()); app.post(/run-task, async (req, res) { const { url, instruction } req.body; if (!url || !instruction) { res.status(400).json({ error: missing url or instruction }); return; } const browser await chromium.launch({ headless: true }); try { const page await browser.newPage(); const agent new Agent({ page }); await agent.ai(打开 ${url}); const result await agent.aiQuery(instruction); res.json({ ok: true, result }); } catch (error) { res.status(500).json({ ok: false, error: String(error) }); } finally { await browser.close(); } }); app.listen(3000, () { console.log(service on http://127.0.0.1:3000); });然后启动npm i express npx tsx server.ts调用接口curl -X POST http://127.0.0.1:3000/run-task \ -H Content-Type: application/json \ -d {url:https://example.com,instruction:提取当前页面所有导航文字}这会返回模型提取到的数据。注意接口服务必须放到可信网络环境中限制访问来源避免被滥用。被测页面也必须是你有权操作的页面。6.3 批量任务的工程建议每个任务增加“任务 ID”方便日志追踪。AI 调用可能偶发失败重试次数建议 2 到 3 次。控制并发。一次性开太多 Playwright 页面容易吃满内存也会触发模型服务限流。保存截图。AI 操作失败时截图是排查最关键的证据。把 prompt、模型响应、页面 URL 统一记录到结构化日志里。7. 资源占用与性能观察Midscene.js 的消耗和传统 UI 自动化不同传统自动化消耗 CPU、内存和网络带宽Midscene.js 额外消耗“模型 Token 和接口时延”。7.1 观察指标指标观察方式说明浏览器进程内存任务管理器 / 进程监控多个并发页面会显著增加内存模型接口时延控制台输出或日志单次 AI 调用通常需要 1 到 5 秒具体取决于模型服务Token 消耗模型服务后台统计截图 DOM 信息会消耗较多 Token任务总耗时脚本计时页面加载 AI 推理 操作等待7.2 降低消耗的方法优先使用headless: false做调试稳定后再切到headless: true跑回归。控制页面数量避免一次开太多浏览器标签页。指令尽量精简不要让模型去处理整页所有内容。提取数据时缩小范围例如“只输出第一行”。对大型页面先滚动到目标区域再让模型操作或提取。模型调用加超时时间防止一直等待。7.3 显存问题如果你接的是云端模型 API通常不需要本地 GPU也不存在显存占用。如果你选择在本地部署一个视觉模型来对接 Midscene.js那就要看具体模型和推理框架的显存需求。文章写的所有“资源占用”都以你实际运行环境为准尤其是本地模型方案必须单独测量。8. 常见问题与排查方法问题现象可能原因排查方式解决方案请求模型时报 401API Key 错误或未配置检查环境变量确认接口是否能直接调用重新配置有效的 API Key检查权限模型返回内容为空模型不支持视觉 / 图片未上传检查模型类型查看日志中是否包含截图信息换成支持视觉理解的多模态模型找不到页面元素页面未加载完成、模型理解错误打开页面截图看模型视角下页面状态增加等待时间指令描述得更具体断言结果不稳定页面状态变化、模型回答不一致重复运行多次看失败模式减少模糊指令明确断言条件浏览器无法启动Playwright 浏览器未安装或版本不匹配执行npx playwright install chromium安装浏览器内核或指定浏览器可执行路径并行任务失败浏览器并发过多、模型触发限流检查内存占用和接口返回状态码降低并发数增加重试服务端口被占用本地端口被其他程序占用netstat -ano看端口占用更换端口或关闭占用进程打开 https 站点失败证书问题 / 网络拦截查看浏览器控制台日志检查网络环境和证书配置除了上述表格有一个高频问题需要单独提Midscene.js 不是“万能魔法”。模型能理解页面但也会出现误判。遇到第一次跑不通的用例不要立刻怀疑工具坏了先看截图确认模型是否真的“看到”了页面内容。这一步能省下大量排查时间。9. 最佳实践与使用建议9.1 用例设计要像人话但也要有边界直接说“点那个按钮”太模糊。更稳的指令是“点击页面右上角蓝色的‘登录’按钮”。自然语言不等于随心所欲为了让模型少猜你要把位置、颜色、文本、顺序说清楚。9.2 先小规模试点不建议第一天就把所有历史用例迁移到 Midscene.js。先挑 5 到 10 条高频、低风险的用例跑通比如登录流程、搜索流程、表单提交。验证稳定性后再逐步扩大范围。9.3 目录结构建议midscene-demo/ ├─ tests/ # 测试脚本 ├─ screenshots/ # 失败截图 ├─ logs/ # 运行日志 ├─ results/ # 结构化输出 ├─ .env # 模型配置 └─ package.json模型输出、输入素材、结果数据分开存放排查问题时能更快定位。9.4 为批量任务加日志和重试AI 接口有不确定性批量任务必须设计重试机制。推荐在每个任务里记录任务 ID目标 URL自然语言指令模型响应或错误信息执行时间截图路径这样即使某条用例失败也能从日志里还原现场。9.5 合规与授权提醒Midscene.js 是测试工具不是“绕过限制”的工具。使用它时请确保你有权对目标页面执行自动化操作。涉及用户数据、敏感信息、版权内容时更需要提前确认合规边界。未授权抓取数据、做恶意注册、绕过风控等行为不应出现在任何自动化测试实践中。9.6 模型选择策略优先选择视觉理解能力强的多模态模型。不同模型对页面布局、中文文本、复杂表单的理解能力差异很大。如果你的模型识别不了复杂页面试试换一个模型供应商或本地部署方案。实际选型时需要做一个小批量测试而不是只看模型榜单。10. 总结与下一步Midscene.js 最值得尝试的不是“自动化”而是它把自动化测试的门槛从“写选择器”降到了“写自然语言”。这对功能测试、前端开发、RPA 场景都有直接价值。你不需要背 XPath 语法不用在每次前端组件重构后重新维护元素定位只要页面视觉上还能被人类理解AI 自动化测试就具备执行基础。第一次尝试时建议先验证这三件事一是本地环境能不能跑通一个最小脚本二是你的模型服务对目标页面理解是否足够准确三是批量执行时稳定性是否达标。最容易踩的坑不是安装失败而是模型“看到了但理解错了”所以一定要把截图和日志留好。后面可以继续扩展的方向很多把 Midscene.js 接入 GitLab CI / GitHub Actions实现提交代码后自动回归关键路径封装成内部测试平台的服务让非技术人员也能用自然语言发起测试结合定时任务做页面内容巡检和数据监控。甚至可以把一批页面操作封装成“AI 浏览器助手”配合现有自动化体系形成“传统断言 AI 兜底”的双层测试方案。如果你正在对比 Playwright 与 AI 自动化测试更务实的做法是先保留原有 Playwright 用例资产把 Midscene.js 作为补充层用于那些“用传统选择器很难稳定描述”的场景。跑通之后再评估是否值得把核心流程逐步迁移过去。这个项目本身就建立在 Playwright 之上两者不是二选一而是可以合在一起用的。建议收藏备用。整个上手路径并不复杂准备 Node.js、装依赖、配置模型、写脚本、跑起来剩下的就是反复调指令。等你的自然语言用例积累到一定数量会发现 AI 自动化测试真正解决的不是“点击快”而是“用例维护成本高”这个问题。