如果你还在用XPath和CSS Selector维护UI自动化用例我强烈建议你留出十分钟认真了解一下midscene——一个基于大模型智能体的开源测试框架它正在改变我和很多同行做自动化测试的方式。midscene的核心思路特别简单你不再需要写一长串元素定位表达式而是用一句自然语言告诉AI你想做什么智能体通过视觉理解、语义分析、DOM结构三重信息自动完成元素定位和操作执行。这篇文章的目标很明确从零开始把midscene的环境搭起来再通过一个真实的搜索测试demo让你看到AI自动化测试到底怎么跑通。我还会把这段时间在真实项目里踩过的坑、验证过有效的技巧全部摊开来讲。无论你是被自动化脚本维护成本折磨的测试开发还是想看看AI Agent能替测试团队干多少活的负责人这篇文章应该都能给你一些实际参考。1. midscene是什么从写选择器到说人话的自动化测试1.1 传统UI自动化的三重痛苦先聊聊为什么整个测试行业都在关注AI。我做了很多年UI自动化传统框架Selenium、Playwright、Appium用下来有三个绕不开的痛点。第一个痛点是元素定位。你写一个用例可能一半时间花在找选择器上。CSS要写.btn-primary span.icon-arrowXPath更要命还有那些动态生成的class每次发版都可能变。第二个痛点是页面改版。前端一调整DOM结构测试脚本就跟着报废一套几千条用例的回归体系维护成本高得吓人。第三个痛点是动态内容。登录态、异步渲染、弹窗广告都让脚本变得脆弱今天能跑通明天就莫名失败。这三个痛点本质上指向同一个问题传统框架让测试人员翻译页面结构而页面结构恰恰是最不稳定的部分。所以当AI智能体出现后测试圈里很快形成了一个共识——UI自动化的下一个突破口可能就是让电脑听懂人话。2026年被不少同行看作是智能体从概念演示走向工程化落地的分水岭AI测试工具正是这个趋势里落地最快的场景之一。1.2 midscene的解题思路给智能体一双眼睛midscene的解法一句话总结就是用多模态大模型充当测试的眼睛和脑子。它的工作过程大致是这样智能体拿到你的自然语言指令后会同时做三件事——读取当前页面的DOM树结构、截取页面视觉快照、结合语义理解来判断目标元素在哪里。在搜索框里搜一下关键词这句话对人类来说毫无歧义但传统框架必须知道那个输入框的id到底是search还是kw。midscene不依赖这些它理解搜索框这个概念本身再从页面结构里找到最匹配的那个元素。这个设计带来的好处是实打实的。第一页面class和id随便改只要UI上的功能和布局没变用例就不需要动。第二对于Canvas、WebGL这类难以用DOM定位的复杂页面视觉理解通道能兜住。我试过在一个纯Canvas绘制的图表页面上跑midscene传统框架全部抓瞎它反而能通过视觉找到图表的图例区域。1.3 midscene的四个核心动作用过midscene的人应该能感受到它把自动化能力收敛成四个核心动作非常清晰run任务执行用一句话描述目标比如在搜索框输入关键词并点击搜索智能体负责拆解成一步步操作。assert断言验证验证页面状态是否符合预期比如断言页面上出现包含midscene的搜索结果。它不靠精确文本匹配而是语义级判断。extract数据抽取从页面里抽取结构化数据比如提取这张表格里所有产品的名称和价格按JSON格式返回。这对回归测试里的数据校验特别有用。score质量评分对页面视觉质量打分比如布局是否合理、是否有遮挡等。这块主要面向前端质量评估在测试里做辅助判断也用得上。这四个动作覆盖了UI自动化用例里绝大部分场景。更重要的是它们都是自然语言驱动的不用写一行选择器。你在用例文件里写测试步骤就像在写一份给测试员看的手工用例AI照着执行并验证结果。2. 半小时环境搭建从Chrome插件到Playwright工程化2.1 零代码体验路线Chrome插件很多人第一次接触midscene都是从Chrome插件开始的。midscene官方提供了浏览器插件安装之后打开任意页面按快捷键唤起AI面板直接输入一句话比如点击页面上登录按钮然后输入用户名admin插件就会自动操作给你看。这条路线适合两种人一种是只想验证midscene效果、还没下定决心引入到正规测试流程的人另一种是测试团队的leader想五分钟之内让组员看到AI测试到底长什么样。插件的执行过程是可视化的每一步操作都会留下记录你能看到AI怎么决策、点了哪里、结果如何。插件体验版一般走的是midscene官方提供的内置模型额度主要目的就是让你快速上手不建议依赖它跑大批量测试任务。真要纳入测试体系得走SDK路线。2.2 工程化路线Node.js Playwright midscene SDK正规玩法是走工程化路线用Node.js或TypeScript编写测试脚本通过midscene SDK和Playwright控制浏览器再结合测试运行器和CI/CD把AI测试用例沉淀成正式回归资产。为什么是Node.js而不是Python或Java主要因为midscene原生深度绑定Playwright而Playwright是Node生态出生的。Python当然也有Playwright但midscene的SDK和社区示例基本都以JS/TS为主。跟着主生态走遇到问题你能搜到更多现成答案这个在踩坑阶段特别重要。我的建议是Node版本用20。装之前先确认本机Node和npm可用然后初始化一个npm项目mkdir midscene-demo cd midscene-demo npm init -y npm i -D midscene/web playwright npx playwright install chromium第4行是下载Chromium浏览器内核网络下载速度不理想时这里容易卡住后面的常见问题里我会讲怎么处理。2.3 模型配置内置体验与外部APImidscene本身不生产模型它依赖一个多模态大模型来做理解和决策。模型选型直接决定测试效果和成本。第一次体验时你可以用内置模型额度不配任何API Key就能跑缺点是有调用次数限制并发能力弱不适合正式环境。正式接入时通常走OpenAI兼容接口可选范围很大GPT-4o和Claude的视觉理解能力强、准确率高但API成本偏高通义千问的Qwen-VL-Max在国内团队里用得挺多中文理解好、价格适中DeepSeek最近在多模态上进步很快成本控制得很激进也值得关注。配置上建议通过环境变量注入避免把Key写进代码仓库。我习惯在项目根目录放一个.env.example里头列出MIDSCENE_MODEL、MIDSCENE_API_KEY、MIDSCENE_BASE_URL三个变量真正的内容写进本地.env由启动脚本加载。2.4 初始化项目并跑通第一个脚本依赖装好、模型配好之后写第一个脚本验证整体链路。脚本逻辑非常简单打开必应首页自然语言驱动搜索然后退出。// demo-bing.mjs // 基于midscene 0.9.x playwright import { chromium } from playwright; import { createAgent } from midscene/web; const browser await chromium.launch({ headless: false }); const page await browser.newPage(); const agent createAgent({ model: process.env.MIDSCENE_MODEL || gpt-4o, apiKey: process.env.MIDSCENE_API_KEY, llmOptions: { baseUrl: process.env.MIDSCENE_BASE_URL }, }); await page.goto(https://www.bing.com); await agent.run(在搜索输入框输入 midscene AI 并敲击回车); await agent.assert(页面上出现了 midscene 相关的搜索结果); await browser.close();这里我用的是page.goto直接进入页面再用agent.run做操作。跑通的标志是浏览器自动打开必应、输入关键词、回车然后日志里显示断言通过。第一次跑建议开有头模式headless: false亲眼看到AI在操作心里才有底。3. Demo演示一个搜索测试用例的完整落地3.1 场景需求与用例设计为了避免能跑但说不清楚干了啥我设计一个稍微完整的demo。场景测试在必应中搜索 midscene验证搜索结果能正常展示。这个场景覆盖了UI自动化的标准路径——页面打开、输入操作、异步结果加载、结果断言。我把用例拆成四个步骤打开必应首页在搜索框输入关键词midscene AI 自动化测试并回车等待搜索结果加载完成断言页面出现与关键词相关的搜索结果这几个步骤里最关键的是第4步。传统做法是写expect(page.locator(#b_results)).toContainText(midscene)一旦id变化就会失败。midscene用语义断言AI判断页面上有没有指向midscene的搜索结果页面结构变了也不影响结论。3.2 完整代码实现带注释代码直接用上一章的框架加上显式等待和错误信息输出。我用必应做演示是因为它页面结构稳定、不需要登录也不容易触发反爬机制适合当AI测试的练手页面。// midscene-search-demo.mjs // 环境Node 20 / midscene 0.9.x / playwright import { chromium } from playwright; import { createAgent } from midscene/web; const delay (ms) new Promise(resolve setTimeout(resolve, ms)); (async () { const browser await chromium.launch({ headless: false }); const page await browser.newPage(); page.setDefaultTimeout(30000); const agent createAgent({ model: process.env.MIDSCENE_MODEL || gpt-4o, apiKey: process.env.MIDSCENE_API_KEY, }); console.log([1/4] 打开必应); await page.goto(https://www.bing.com, { waitUntil: domcontentloaded }); console.log([2/4] 执行搜索); await agent.run(在搜索输入框中输入 midscene AI 自动化测试 并按下回车); console.log([3/4] 等待结果加载); await delay(2000); console.log([4/4] 断言结果); await agent.assert(搜索页上出现了与 midscene 相关的结果标题); console.log(PASS: 断言通过); await browser.close(); })();这里有个细节值得说为什么在AI操作之后加一个delay因为搜索结果加载是异步的AI的视觉判断在页面还没渲染完成时可能会误判——它看到页面还停留在加载状态就以为搜索没生效。加一个适度的等待准确率会高很多。3.3 运行与结果解读运行命令很简单export MIDSCENE_MODELgpt-4o export MIDSCENE_API_KEY你的Key node midscene-search-demo.mjs你要关注两个输出。第一个是agent.run执行过程里AI的操作轨迹它会展示AI看到了什么、点击了哪里每条操作都会有时间戳。第二个是agent.assert的断言结果通过就是PASS不通过则会返回AI认为的页面状态文本。如果断言没通过先看是不是页面真的没加载出来再看是不是AI理解有偏差。比如AI可能认为midscene相关的结果标题必须包含完全一致的英文单词而实际页面展示的是中文描述。这时候把断言描述改得更明确、更贴近业务语言就能解决。这个demo虽然简单但它完整走通了AI自动化测试的最小闭环往里填充更多业务逻辑就能变成一个正式的UI测试用例。4. 进阶玩法从demo到可交付的测试工程4.1 用YAML编排复杂测试场景一个真实的测试项目不可能只有一个操作。midscene支持把测试脚本用结构化形式管理起来。比如一段回归用例可以这样组织打开首页、登录、点击创建、验证创建结果、退出。你可以把每个步骤写成自然语言配置项放在YAML文件里统一管理name: 用户创建流程回归 steps: - action: 打开 https://your-app.com - action: 在用户名输入框填入 test_user密码填入 test_pass点击登录 - action: 点击左侧菜单的创建项目 - action: 在项目名称输入框填入 自动化测试项目点击保存 - assert: 页面出现 创建成功 的提示并且列表里出现了 自动化测试项目测试运行时逐条执行任何一个步骤断言失败就停下来并输出对应的页面快照和操作日志。这样做的好处很直接测试用例的维护从改代码变成改描述。业务同学可以把需求变更直接翻译成用例描述测试团队不用再面对一堆晦涩的XPath和class名。4.2 接入CI/CD流水线让AI测试自动跑起来AI测试要真正落地必须进CI/CD。项目结构建议是测试脚本放在独立目录每次提交代码后自动安装依赖、启动测试服务、跑AI测试、生成报告。GitHub Actions的配置大概长这样name: UI Test on: [push] jobs: ai-test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 - run: npm ci - run: npx playwright install chromium - run: npm test env: MIDSCENE_MODEL: ${{ secrets.MIDSCENE_MODEL }} MIDSCENE_API_KEY: ${{ secrets.MIDSCENE_API_KEY }}关键点有两个。第一模型API Key用secrets方式注入不要在配置里明文出现这个习惯能避免很多安全事故。第二建议在测试命令外面套一层失败重试因为AI判断带有一定概率性单次失败不代表功能有bug重跑一次往往是PASS。我见过不少团队因为第一次跑红就直接判负结果误报率高得吓人最后AI测试方案被整个否掉其实只是策略没设计好。4.3 用数据抽取做结构化验证除了常规的UI操作和断言extract功能在测试里的价值经常被低估。比如你要验证一个表格页的分页功能是否正常传统做法是逐项比对页面文本写一堆解析逻辑。用midscene你可以一句话让AI把当前页的表格内容全部抽出来以JSON格式返回然后在代码里做结构比对。数据量一大这种方式的效率优势非常明显。我实际用下来extract对页面结构变化的容忍度很高。表格某个列的样式变了、字段顺序调整了只要语义没变抽取结果就是稳定的。这比原来写一堆选择器加解析逻辑省心太多。而且AI抽取出来的数据是天然结构化的可以直接喂给后续的断言逻辑或数据比对工具链路上省掉不少手工转换。5. 实战避坑环境搭建与稳定性问题实录5.1 装环境就翻车的三个坑第一个坑是Playwright浏览器下载慢甚至失败。这几乎是每个新手都会遇到的问题。我的处理办法是设置下载镜像环境变量让浏览器内核走镜像源下载或者在CI里提前把浏览器缓存打进镜像。核心思路就是别直接连官方源具体镜像地址和配置方式网上有大量现成方案这里不展开。第二个坑是Node版本过旧导致SDK安装失败。如果你还在用Node 14甚至更老的版本midscene/web安装时大概率会报错。建议直接上Node 20 LTS很多莫名其妙的报错就消失了。第三个坑是Headless模式无头模式下断言失败率高。AI的视觉理解依赖页面渲染截图无头模式下截图渲染容易不完整导致AI漏判元素。调试阶段一定先跑有头模式等脚本稳定之后再切无头。我见过有人在无头模式下反复调整提示词调了一天都没找到原因切回有头模式一眼就看出是渲染问题。5.2 模型选型的成本与效果平衡模型选得不对midscene的体验会两极分化。便宜的模型经常识别不准确页面元素没找到就随便点贵的模型效果好但跑几百条用例的成本也不低。我的经验是分场景选模型日常调试用便宜的轻量模型正式回归阶段切到准确率更高的旗舰模型。还可以给每条用例设置合理的超时和重试次数防止单次模型调用卡死整个测试流程。另外一个成本技巧是合并操作。比如登录这个过程完全可以拆成输入用户名、输入密码、点击登录三个独立操作但这样就是三次模型调用。更好的做法是写成一句在登录页填入用户名和密码并登录让AI一次性完成既省API调用次数也减少中间环节的失败概率。5.3 稳定性优化与兜底策略AI测试最大的争议是不稳定性。我自己实测的体感是单个AI操作的成功率大概在90%上下但在关键步骤上叠加一层稳定性策略之后用例整体成功率能到95%以上。具体做法有几个步骤执行前先等待页面完全加载操作失败后自动重试对于关键断言把语义断言和文本断言做双重校验针对弹窗、登录态等特殊情况在脚本里预设处理路径。还有一个很实用的经验不要让AI一口气执行10个步骤的长链路把它拆成2-3个短动作组合成功率会明显上升。AI的容错能力再强也架不住链路过长导致的误差累积。打个比方让AI一步步从A走到J成功率高还是从A走到J中间还要处理两个弹窗成功率高答案显而易见。我自己在真实项目里跑midscene跑了大概一个季度最深的体感是它不会完全取代传统自动化测试但它把测试脚本维护成本这个老大难问题压下去了一大截。以前最怕的页面改版现在基本只需要在用例描述层做微调不用再一行行改选择器。最后给想尝试的读者一个建议别一上来就追求把核心回归全部迁到AI测试先挑一条经常因为页面改版而挂掉的用例用midscene把它重写跑两周对比一下维护成本你会有很明确的判断。工具轮子还在快速迭代但用自然语言描述测试意图这个方向我是比较笃定的。