midscene AI智能体实战：自然语言驱动UI自动化测试

上周我被测试群里一张截图弄得有点沮丧。一条跑了三年的核心下单链路用例因为前端把登录按钮的id从login-btn改成submit-login一夜间红了 26 条。新同事说改选择器就能解决但没有人知道这个按钮在第三个版本里还会不会再改一次。这种时刻我意识到传统 UI 自动化最贵的成本不是写用例而是维护用例。于是我开始认真看 midscene 这个方向一个用自然语言驱动浏览器、让 AI 智能体自己看页面、做操作、验结果的框架。这篇文章我会把 midscene 智能体做 AI 自动化测试的环境搭建、Demo 演示完整展开也会把midscene 被 Playwright 调用的原理这一部分讲透。我不打算只给命令还会解释每一步为什么这么做、实测中会遇到哪些坑、怎么排错。适合正在评估 AI Agent 做 Web 自动化测试的团队也适合想亲手跑通第一个 AI 测试 Demo 的个人开发者。不管你之前用的是 Selenium、Playwright 还是 Appium这篇文章的思路都能接上。1. 传统UI自动化的脆弱性与midscene智能体的解题思路1.1 一次前端改版引发的用例雪崩先还原一下开头那个场景。老用例长这样// 用了三年突然红了 await page.click(#login-btn);前端把按钮id改成>mkdir midscene-demo cd midscene-demo npm init -y npm i -D midscene/web playwright typescript tsx npx playwright install chromium每一步我都解释一下为什么这么做npm init -y生成一个默认的package.json给项目一个包管理入口。npm i -D midscene/web playwright typescript tsx一次装齐四个依赖。midscene/web是智能体 SDKplaywright是浏览器自动化框架typescript用来写 TS 脚本tsx是一个可以直接运行 TypeScript 文件的工具省去单独的编译步骤。npx playwright install chromium下载 Chromium 浏览器内核。这一步特别容易被人跳过因为刚才明明按了 playwright怎么跑不起来原因很简单playwright 的 npm 包只是客户端浏览器内核需要单独下载。如果下载超时先检查本机网络能否正常访问外部网络和 DNS 解析不要跳过这步后面所有脚本都依赖这个浏览器内核。3.3 模型参数的环境变量配置先把模型的三个环境变量配好export AI_API_KEY你的模型服务密钥 export AI_BASE_URL你的模型服务商兼容接口地址 export AI_MODELgpt-4o 或 qwen-vl 等同类型支持视觉的模型ID这里有一个很关键的实践绝对不要把密钥写死在代码里。一方面测试脚本经常会提交到仓库里密钥一旦提交就等于泄露另一方面CI 环境里换模型只需要改环境变量不需要动代码。团队内部如果统一走模型网关也可以把AI_BASE_URL指向网关地址方便统一计费和审计。配完之后可以用下面的命令验证一下环境变量是否已经生效echo $AI_API_KEY如果输出为空说明当前终端会话没有拿到变量检查一下是否用了错误的变量名。3.4 用最小脚本验证智能体真的能操作页面环境装好之后写一个最小的验证脚本业务逻辑越简单越好避免把问题混在一起。新建first-run.tsimport { chromium } from playwright; import { PlaywrightAgent } from midscene/web; async function main() { const browser await chromium.launch({ headless: false }); const page await browser.newPage(); const agent new PlaywrightAgent(page); await page.goto(https://www.saucedemo.com/); await agent.runTask(在用户名输入框填入 standard_user在密码输入框填入 secret_sauce); await agent.runTask(点击 LOGIN 按钮并断言页面出现 Products 标题); await browser.close(); } main();运行npx tsx first-run.ts如果你装到的 midscene 版本入口路径不同比如midscene/web/playwright下导出以你装到的版本提示为准核心用法不变创建PlaywrightAgent传入 Playwright 的page对象然后runTask下指令。跑起来之后你会看到浏览器窗口自己打开自动填入账号密码点击登录然后进入商品列表页。这一步跑通说明你的环境基本没问题。4. 可复现的Demo自然语言驱动登录与自动验证4.1 目标场景选型为什么选一个公开练习站选场景是有讲究的。第一次跑 AI 智能体千万不要拿公司内部复杂的后台系统练手因为任何一个环境变量、权限、弹窗问题都会让你分不清是环境问题还是智能体问题。我推荐用 SauceDemo 这个公开练习站。它专门为自动化测试设计登录账号固定、商品列表稳定、购物车流程完整页面结构也不复杂非常适合验证AI 智能体到底能不能看懂页面并执行流程。场景设计如下打开 SauceDemo 首页。用 standard_user 登录。进入商品详情页把 Sauce Labs Backpack 加入购物车。进入购物车页面断言商品存在并取回价格。这个流程覆盖了输入、点击、跳转、断言、数据提取几个核心能力足够说明问题。4.2 完整Demo脚本登录、断言、再到加购新建demo-flow.tsimport { chromium } from playwright; import { PlaywrightAgent } from midscene/web; async function main() { const browser await chromium.launch({ headless: false }); const page await browser.newPage(); const agent new PlaywrightAgent(page); await page.goto(https://www.saucedemo.com/); await agent.runTask(完成登录使用 standard_user 登录密码 secret_sauce然后点击登录按钮); await agent.runTask(在商品列表中点击名称为 Sauce Labs Backpack 的商品图片进入详情页); await agent.runTask(点击 Add to cart 按钮然后点击购物车图标); await agent.runTask(断言购物车页面里商品名包含 Sauce Labs Backpack并输出商品价格); await browser.close(); } main();这里四个runTask分别对应四段意图。你会发现整个脚本里没有任何一个 XPath 或 CSS 选择器。所有定位工作全部交给智能体完成。4.3 运行链路解读规划日志、执行日志与截图痕迹跑这个脚本的时候控制台会输出类似下面的信息模型当前认为页面处于什么状态、计划执行哪些动作、动作用了什么参数、执行结果如何。建议你在跑的时候打开两个终端一个跑脚本一个观察运行目录。我实测中的输出节奏大致是模型收到任务完成登录先观察页面截图。模型产生规划第一步定位用户名输入框第二步定位密码框第三步定位登录按钮。Playwright 依次执行点击、填入、再点击。模型再次截图确认页面已经跳转到商品列表页任务完成。注意这个 Demo 跑通后项目目录里往往会生成报告或截图文件。这些痕迹文件是调试的关键如果某一步出了问题你可以打开当时的截图看模型眼中的页面和你眼中的页面是否一致。很多时候你以为页面长这样其实弹窗、蒙层、加载态把关键元素挡住了。4.4 断言失败时智能体的自主容错行为传统自动化里断言失败就是用例失败红色一片。midscene 的机制不太一样runTask里的断言更像一个目标校验步骤。如果第一次断言失败智能体不会直接放弃它会重新截图、重新思考尝试修正操作。举个实际例子如果登录按钮被一个弹窗遮住了传统脚本会直接超时报错。midscene 智能体则会先看到有个弹窗然后判断这个弹窗是否需要关闭再执行关闭动作最后继续登录。我把这个特性叫做智能体自愈。它非常像真人测试员的工作方式第一次没找到按钮先看看是不是被什么挡住了处理完障碍再试一次。这也是它解决UI 自动化脆弱性的核心价值——不是消除错误而是在出错时有能力自己纠偏。当然自愈不是万能的。如果一个元素压根不存在或者页面直接白屏模型重试几次仍然会失败。所以后面要讲重试策略和失败现场保护。5. 接进现有测试体系与pytest、Appium、接口自动化共存5.1 不推翻pytest让智能体管看得见的流程我见过不少团队聊 AI 自动化测试第一反应是是不是要把现有的 pytest 框架全换掉完全没必要也不应该。pytest 这类框架最擅长的东西测试编排、数据断言、fixture 管理、报告输出、CI 集成。这些能力 midscene 替代不了也不应该替代。midscene 最擅长的东西是看得见的 UI 流程。所以合理的架构是分层协作pytest 负责调度和断言整个测试报告、执行顺序、数据准备、接口校验仍然归 pytest 管理。midscene 负责走流程把需要真实浏览器操作的步骤封装成智能体脚本。最后的 UI 结果可以由 midscene 断言也可以由 pytest 再做一轮兜底校验。这样做的好处是团队不需要推翻现有的 CI 流水线和测试资产只是新增一种用 AI 智能体执行 UI 流程的能力。5.2 pytest侧封装轻量入口的示例先写一个可复用的 midscene 流程脚本比如scripts/midscene_flow.ts它能退出码表示成功或失败。然后 pytest 里用 subprocess 调用它import subprocess def test_saucedemo_login_flow(): result subprocess.run( [npx, tsx, scripts/midscene_flow.ts], capture_outputTrue, textTrue, ) assert result.returncode 0, result.stdout result.stderr这种方式最粗暴但也最稳pytest 把 midscene 脚本当黑盒只需要知道流程走没走通。如果团队要求更精细的控制可以把 midscene 的断言结果输出成 JSONpytest 读取 JSON 里返回的数据比如商品价格再做数值断言。这里有个很重要的思路UI 流程交给 AI数据断言回到传统框架。AI 负责找到那个按钮并点下去传统断言负责价格算得对不对。各干各最擅长的事整体稳定性才会高。5.3 移动端Appium场景先分清WebView与原生控件聊到 Appium这里要泼一点冷水midscene 这类视觉智能体在移动端 WebView 或 H5 页面可以用但原生控件的场景不算顺畅。原因很简单原生控件不在网页 DOM 里Playwright 管不到智能体的视觉截图与原生控件没有直接的映射通道。如果你当前团队以 Appium 做移动端自动化建议这样考虑纯原生页面继续用 Appium但可以把 AI 用在语义化断言上。比如 Appium 取到页面源码和控件树之后喂给大模型做意图判断这个页面是否是登录成功后的首页。WebView / H5 页面如果应用的业务页面对应的是 H5可以考虑让 midscene 接管浏览器上下文用视觉方案跑 WebView 内的流程。混合场景先用 Appium 切到正确的 WebView context再把页面交给 Playwright 控制最后 midscene 接管操作。移动端这块建议先做小范围验证不要一上来就把核心 Appium 资产迁移过来。等 WebView 场景跑稳了再逐步扩展。5.4 渐进式迁移路径与试点范围从一个真实案例说起。我自己的团队做了一次小的渐进式试点只用了两个星期效果就出来了选一条最痛的链路从现有的几百条用例里挑出一条每次发版必做、每次改版必红的链路比如创建订单-提交-付款-回显。用 midscene 重写这条链路把原来的 XPath 全删掉改成自然语言任务。并行跑一周旧的用例继续在 CI 里跑midscene 脚本也跑对比两者的稳定性、失败率、维护时间。稳定后替换新脚本连续一周稳定后把旧脚本下线CI 里只留智能体版本。这个过程不要心急。一次迁移太多链路你会获得一堆 AI 生成的失败报告和烧掉的 token。从一条链路开始拿到信心和排错经验后再扩展。6. 实测中的坑、排错清单与一条判断标准6.1 从运行日志出发的完整排查链路智能体脚本报错之后第一反应不要改代码先看日志出现在哪一层。我按实际经验整理了这样一个排查顺序环境变量层是否报401或missing api key 大概率是AI_API_KEY没设置或设置错误。模型调用层是否返回空结果、JSON 解析失败 大概率是模型不支持视觉输入或者请求内容过大被服务商拒绝。规划层模型有输出但规划的动作明显不对 比如点击登录按钮规划成了先点击购物车。这种情况通常是模型对页面理解有偏差换更强的多模态模型或把任务描述写得更具体。执行层规划正确但 Playwright 报超时、元素不存在 看看页面是否真的有弹窗、蒙层、懒加载把等待时间调大。验证层操作全部完成但智能体仍然认为失败 检查断言措辞是否太模糊比如检查首页正常就不如断言页面出现 Products 标题明确。下面这张排查表我建议贴到团队的 wiki 里现象可能原因最快解法401 / missing api key环境变量没配检查AI_API_KEY模型输出为空 JSON模型不支持视觉换多模态模型规划动作明显错误任务描述太笼统把目标拆成更明确的子任务Playwright 点击超时页面弹窗、懒加载调大超时 先处理遮挡元素断言反复失败期望文案写错对照页面实际文案修改任务描述6.2 实测中高频遇到的五个坑这一节是我跑断腿换来的经验逐条说坑一非多模态模型硬上一跑就挂。第一次我图省事接了一个只支持文本的模型结果runTask执行到第一步就报错了。看日志才发现智能体需要看图文本模型根本给不出有效规划。换支持视觉的模型之后一切正常。坑二Playwright 浏览器内核忘装。装完playwrightnpm 包直接跑脚本报错Executable doesnt exist。跑一下npx playwright install chromium就解决。这是新手最容易卡住的一关。坑三模型温度配置过高每次操作结果都不一样。大模型默认的温度参数可能偏高同一个任务每次规划出来的步骤会漂移。做测试自动化时一定要把温度调低理想情况设为 0让输出尽可能稳定。坑四任务描述太笼统。我试过直接说买一个背包模型在商品列表页反复横跳因为它不知道该点哪个商品。改成点击名称为 Sauce Labs Backpack 的商品图片进入详情页之后一次就准了。任务描述越具体智能体越稳定。坑五盲目追求一次跑大量用例。智能体每个任务都要多次截图和模型推理Token 消耗远高于普通接口调用。跑一百条 UI 用例的成本可能比跑一万条接口用例还高。务必要把智能体用在刀刃上。6.3 成本控制token、超时与重试策略成本控制是 AI 测试能不能落地的关键。说几个我摸索出来的硬指标一次简单操作的 Token 消耗一个登录任务大概会经历 3-5 次截图和模型调用每次调用消耗几百到上千 Token。一个复杂流程跑下来可能消耗上万 Token。这个量级在可控范围但如果你拿它跑全量回归账单会非常可观。控制重试次数默认情况下智能体失败后会自动重试。建议设置合理的最大重试次数比如 2-3 次。再多就是浪费而且大概率是环境问题而不是智能体问题。把大任务拆小不要让智能体从打开浏览器一路做到验证数据库。基础导航和等待用 Playwright 直接写代码完成只在关键决策点启用智能体。比如page.goto(url)用代码直接导航登录、选择商品、验证结果这几步交给智能体。这样既省 Token又降低模型规划出错的概率。失败现场一定要留证据无论报告还是截图都要落盘。因为 AI 智能体的失败往往是概率性的没有现场截图你很难判断是模型规划错了还是页面状态不对。6.4 引入AI测试智能体的判断标准与个人体会最后说说我的判断标准这套标准现在是我们团队决定要不要用 AI 智能体的参考如果团队用例维护成本占测试开发时间超过一半值得试点。如果某条链路每次改版必红优先试点。如果页面有大量动态元素、频繁改版的组件优先试点。如果几千条用例都是点几下、填个框、看结果的重复流程需要谨慎评估成本。我在实际项目中把一条支付链路交给了 midscene。刚开始的几天它每天都会红一两次多数原因是模型对某些弹窗的误判和页面时序问题。后来统一了模型、把温度降到 0、给任务描述加上了明确的边界条件稳定度明显上去。最明显的变化是前端改版之后以前我要花半天改选择器现在只需要看一遍智能体的报告确认它通过视觉找到了新的元素位置然后把旧用例下线。当然我也必须说实话AI 智能体不会解决所有测试问题。数据断言、精确计算、稳定性保障这些仍然要依靠传统的测试框架和断言手段。它解决的是定位元素、维护选择器、应对前端改版这一层最让人头疼的问题而不是整个测试体系。如果你正在考虑尝试我的建议是不要从全量回归开始选一条你最痛的核心链路花一个下午把环境搭起来跑通上面这个 Demo然后认真观察一周。AI 测试这件事只有亲手跑一轮你才能真切感受到把维护成本从写选择器转移到人类表达意图是什么体验。