1. 项目概述当AI遇上UI自动化测试最近在搞AI自动化测试发现一个挺有意思的领域让大模型直接操作浏览器完成UI测试任务。这听起来像是科幻片里的场景但现在已经有不少工具在尝试了。我花了不少时间折腾了两个基于Playwright和MCPModel Context Protocol的方案browser-use和midscene。这两个都不是简单的录制回放工具而是让AI像真人一样“看”网页、“想”操作、“执行”步骤的智能体。简单来说传统的UI自动化测试比如用Selenium或Playwright写脚本需要测试工程师把每一步操作点击、输入、断言都精确地编码出来。而AI自动化测试你只需要用自然语言告诉AI一个任务比如“去电商网站首页搜索‘无线耳机’把价格低于500元的前三个商品加入购物车”AI就能自己分析页面规划步骤并调用Playwright执行。这背后的核心就是MCP协议它像一座桥连接了大模型的“大脑”和Playwright的“手脚”。我之所以深入研究这个对比是因为在实际项目中我们经常面临测试用例维护成本高、对前端变化敏感的问题。一个按钮的class名改了可能一堆脚本就报错了。AI驱动的测试理论上对这类变化的鲁棒性更强因为它可以理解语义比如“搜索按钮”而不完全依赖脆弱的CSS选择器。但理想很丰满现实如何browser-use和midscene这两个具体的实现方案在易用性、稳定性、成本上到底有多大差别这就是我这篇文章想跟你唠明白的。2. 核心方案对比browser-use vs. midscene在开始搭建之前我们得先搞清楚手头的两把“武器”到底有何不同。browser-use和midscene都是基于“大模型Playwright”的AI测试智能体框架但设计哲学和实现路径差异不小。2.1 browser-use简洁直接的操作执行器browser-use更像是一个“翻译官”。它的工作流程非常直观你用自然语言下达指令“登录邮箱”。大模型分析指令将其分解成一系列原子操作“找到用户名输入框”、“输入文本‘xxx’”、“找到密码输入框”、“输入密码”、“找到登录按钮并点击”。browser-use将这些原子操作翻译成Playwright能理解的API调用page.locator(input[nameusername]).fill(xxx)。Playwright执行这些API操作浏览器。它的特点很鲜明架构轻量核心就是围绕Playwright API做了一层封装和调度概念简单容易理解。依赖明确的页面描述为了让AI准确找到元素browser-use通常需要你提供页面的语义化描述比如告诉AI“这是一个登录表单包含用户名、密码字段和一个提交按钮”。这可以通过辅助工具生成也可以手动编写。动作空间有限AI能执行的操作被限定在browser-use定义好的几个动作类型里比如click,fill,scroll等。这降低了复杂度但也限制了灵活性。注意browser-use对提示词Prompt工程和页面描述的准确性要求比较高。如果描述不清AI很可能找不到元素或者执行错误的操作。2.2 midscene具备“记忆”和“反思”能力的智能体midscene则更进一步它把自己定位为一个具备记忆和反思能力的自主智能体。它的目标不仅是执行任务还要能处理任务执行过程中的意外情况。它的核心循环可以概括为观察通过Playwright获取当前页面的HTML、截图、可访问性树等信息作为“眼睛看到的东西”。规划大模型基于任务目标和当前观察决定下一步做什么。这里的规划可能更宏观比如“我需要先导航到登录页面”。执行调用Playwright执行规划出的动作。反思/验证执行后再次“观察”页面变化。检查任务是否完成或者是否出现了错误比如弹窗、页面跳转失败。如果未完成或出错则重新规划。midscene的亮点在于上下文记忆它能记住之前执行过的步骤和观察到的页面状态这在多步骤复杂任务中至关重要避免AI“失忆”。自我纠错能力当操作未达到预期效果时比如点击后没反应它能尝试分析原因并采取替代方案比如换个选择器点击或者滚动页面再找。更少的预设依赖理论上它不需要非常精确的页面描述因为它可以自己“看”页面并理解。但实际上为了提升准确性提供关键区域的提示信息仍然有帮助。2.3 选型决策矩阵如何选择我根据自己的实践整理了一个对比表格你可以根据项目需求对号入座特性维度browser-usemidscene选型建议上手难度较低。概念简单与传统自动化脚本思维接近。较高。需要理解智能体的观察-规划-执行-反思循环。新手或追求快速验证选browser-use。灵活性较低。操作受限于预定义动作集。较高。智能体可以规划更复杂的操作序列和应对策略。任务多变、需要处理异常选midscene。稳定性中等。高度依赖初始页面描述的准确性描述不准则容易失败。潜在更高。具备反思和重试机制容错性更好。对测试稳定性要求高且页面有一定动态性可尝试midscene。执行成本较低。每次交互传递的信息相对精简主要是动作指令。较高。每次“观察”都需要将大量页面信息HTML片段、截图发送给大模型Token消耗大。关注API调用成本选browser-use。适用场景流程相对固定、页面结构稳定的表单提交、数据查询等任务。复杂的多页面流程、探索性测试、需要处理弹窗/验证码等动态交互的场景。简单任务用browser-use复杂探索用midscene。维护成本页面描述需要随UI变化更新。对UI变化的适应性相对更强但提示词和反思逻辑可能需要调优。页面频繁改动midscene的长期维护成本可能更低。我个人的体会是browser-use像是一个“听话的实习生”你指令清晰它就能干好而midscene则像一个“有经验的测试员”能自己动脑子解决一些简单问题但“工资”Token消耗也更高。对于大多数从零开始尝试AI测试的团队我建议先用browser-use跑通一个核心流程感受AI测试的威力与局限再根据需求评估是否需要midscene的更高级能力。3. 环境搭建与核心配置详解理论说再多不如动手跑一遍。下面我以browser-use为例带你走一遍完整的搭建流程并穿插讲解midscene的关键配置差异。为什么选browser-use开头因为它依赖更少更容易快速看到效果建立信心。3.1 基础环境准备无论选哪个方案以下都是必需品Node.js环境Playwright是Node.js生态的利器。建议安装最新的LTS版本如18.x或20.x。你可以去官网下载或者用nvm管理多个版本。Playwright这是我们的“手脚”。在项目目录下初始化并安装npm init -y npm install playwright安装完成后通常还需要安装浏览器内核。Playwright很贴心地提供了命令一键安装npx playwright install chromium这里我选择Chromium因为它够用且开源。如果你需要测试Chrome或Firefox的特定行为也可以安装对应的版本。大模型API密钥这是AI的“大脑”。目前browser-use和midscene主要支持OpenAI的GPT系列模型如gpt-4o-mini, gpt-4-turbo或Anthropic的Claude。你需要准备相应的API Key。OpenAI去platform.openai.com创建API Key。Anthropic去console.anthropic.com创建。重要安全提示永远不要将API Key硬编码在代码中或提交到Git仓库务必使用环境变量。在项目根目录创建.env文件并写入OPENAI_API_KEYsk-your-actual-key-here # 或 ANTHROPIC_API_KEYyour-claude-key-here然后在代码中通过process.env.OPENAI_API_KEY读取。3.2 browser-use项目初始化与配置browser-use本身是一个Node.js库。我们新建一个项目来集成它。# 创建项目目录并进入 mkdir ai-ui-test-with-browser-use cd ai-ui-test-with-browser-use # 初始化package.json npm init -y # 安装核心依赖 npm install browser-use playwright # 安装dotenv用于读取环境变量 npm install dotenv接下来创建我们的第一个AI测试脚本比如test-login.jsrequire(dotenv).config(); // 加载.env文件中的环境变量 const { Agent } require(browser-use); const playwright require(playwright); (async () { // 1. 启动浏览器 const browser await playwright.chromium.launch({ headless: false // 设为true可无头运行调试时建议false }); const context await browser.newContext(); const page await context.newPage(); // 2. 创建AI智能体并绑定到page const agent new Agent({ model: gpt-4o-mini, // 指定模型成本较低 apiKey: process.env.OPENAI_API_KEY, }); await agent.attach(page); // 3. 导航到目标网站 await page.goto(https://example.com/login); // 4. 给AI提供页面上下文描述关键步骤 await agent.context(这是一个示例网站的登录页面。 页面顶部有一个标题“Welcome Back”。 中间是一个登录表单。 表单包含两个输入框第一个是“Username”第二个是“Password”。 表单下方有一个蓝色的按钮上面写着“Sign In”。 最下面有一行小字“Forgot password?”。); // 5. 下达自然语言指令 try { const result await agent.run(请使用用户名“testuser”和密码“pass123”登录); console.log(任务执行结果, result); } catch (error) { console.error(任务执行失败, error); } // 6. 等待一会儿以便观察然后清理 await page.waitForTimeout(3000); await browser.close(); })();配置要点解析headless: false调试时务必打开浏览器界面你能亲眼看到AI在操作什么这对于排查问题至关重要。页面上下文描述这是browser-use能否成功的关键。描述要简洁、客观、突出关键交互元素。不要写“左边有个框”要写“有一个标签为‘Email Address’的文本输入框”。你可以结合Playwright的DevTools插件快速获取元素的语义化描述。agent.run这里就是下发指令的地方。指令要清晰、无歧义。避免“登录一下”这种模糊指令而是“用管理员账号登录”。3.3 midscene项目初始化与关键差异midscene的搭建思路类似但配置更侧重智能体的“认知”能力。# 同样新建项目 mkdir ai-ui-test-with-midscene cd ai-ui-test-with-midscene npm init -y npm install midscene/core playwright npm install dotenv创建一个midscene-test.jsrequire(dotenv).config(); const { Midscene } require(midscene/core); const playwright require(playwright); (async () { const browser await playwright.chromium.launch({ headless: false }); const page await browser.newPage(); // 创建Midscene智能体实例 const agent new Midscene({ apiKey: process.env.OPENAI_API_KEY, model: gpt-4-turbo, // midscene通常需要能力更强的模型 // 关键配置定义智能体的“能力”和“目标” capabilities: [web_navigation, dom_interaction, screenshot_analysis], maxIterations: 10, // 最大执行步数防止死循环 }); // 绑定页面 await agent.bind(page); // 下达任务 - midscene的任务描述可以更宏观 const task 请访问 https://example.com 找到登录入口并使用凭据用户名: demo, 密码: demo123登录系统。登录成功后请检查页面顶部是否显示“Dashboard”字样。; console.log(开始执行任务: ${task}); const result await agent.run(task); console.log(任务完成报告, result.report); console.log(最终状态, result.success ? 成功 : 失败); await page.waitForTimeout(5000); await browser.close(); })();与browser-use的核心差异能力声明(capabilities)你需要告诉midscene智能体它有哪些“技能”比如网页导航、DOM交互、截图分析。这决定了它能“看到”什么和“做”什么。迭代限制(maxIterations)必须设置因为智能体可能会陷入“尝试-失败-再尝试”的循环这个参数是安全阀。任务描述可以更偏向目标而非具体操作步骤。midscene会自己分解。结果对象返回的result包含更丰富的信息如执行报告、是否成功、每一步的观察和行动日志。这对于分析和调试非常有帮助。实操心得在配置midscene时初期最容易遇到的问题是Token消耗爆炸。因为它每次观察都可能发送大量HTML。一个有效的优化技巧是在capabilities配置中可以指定只关注页面的特定区域如viewport区域或者通过filter排除掉script、style等无用标签大幅减少上下文长度。4. 实战构建一个完整的电商购物流程测试光说不练假把式。我们用一个更贴近实际的例子来感受两者的不同。假设我们要测试一个电商网站以 demo.ecommerce.com 为例的核心流程搜索商品、查看详情、加入购物车。4.1 使用browser-use实现对于browser-use我们需要为每个关键页面提供清晰的描述。// test-ecommerce-browser-use.js require(dotenv).config(); const { Agent } require(browser-use); const playwright require(playwright); (async () { const browser await playwright.chromium.launch({ headless: false }); const page await browser.newPage(); const agent new Agent({ model: gpt-4o-mini, apiKey: process.env.OPENAI_API_KEY, }); await agent.attach(page); // 任务1: 导航到首页并搜索 await page.goto(https://demo.ecommerce.com); await agent.context(这是电商网站首页。顶部有一个大大的网站Logo。Logo右边有一个搜索框占位符文字是“Search for products...”。搜索框右边有一个放大镜图标按钮。); await agent.run(在搜索框里输入“wireless headphones”并点击搜索按钮); // 任务2: 在搜索结果页选择商品 // 注意页面跳转了需要更新上下文描述 await page.waitForURL(**/search**); // 等待跳转完成 await agent.context(这是搜索结果页面。顶部有面包屑导航。页面主体是商品列表。每个商品卡片包含商品图片、商品标题、价格和一个“Add to Cart”按钮。列表按相关性排序。); // 指令需要更精确因为AI可能不理解“第一个” await agent.run(找到商品标题中包含“Bluetooth”和“Noise Cancelling”的第一个商品点击它的标题或图片进入详情页); // 任务3: 在商品详情页加入购物车 await page.waitForURL(**/product/**); await agent.context(这是商品详情页。顶部有商品主图。主图右边有商品标题、价格、商品描述。有一个数量选择器默认是1。有一个显眼的、绿色的“Add to Cart”按钮。按钮下方是库存状态。); await agent.run(点击绿色的“Add to Cart”按钮); // 验证 await page.waitForTimeout(2000); // 检查购物车图标上是否有数量徽章 const cartBadge await page.locator(.cart-icon .badge).textContent(); console.log(购物车商品数量: ${cartBadge}); await page.waitForTimeout(3000); await browser.close(); })();browser-use实战难点页面上下文切换每次页面发生重大变化跳转、弹窗都需要调用agent.context()更新描述否则AI会基于旧的描述进行操作必然失败。指令的精确性“第一个商品”这种指令对AI不友好。更好的做法是结合商品的特征如“标题包含XX关键词的商品”。这要求测试设计者更了解页面内容。等待与同步在agent.run前后经常需要手动waitForURL或waitForSelector确保页面状态稳定。AI不会自动等待网络请求。4.2 使用midscene实现同样的流程用midscene来实现代码会更简洁但智能体内部更复杂。// test-ecommerce-midscene.js require(dotenv).config(); const { Midscene } require(midscene/core); const playwright require(playwright); (async () { const browser await playwright.chromium.launch({ headless: false }); const page await browser.newPage(); const agent new Midscene({ apiKey: process.env.OPENAI_API_KEY, model: gpt-4-turbo, capabilities: [web_navigation, dom_interaction, screenshot_analysis], maxIterations: 15, // 可以配置反思逻辑当操作后页面关键元素未出现则重试或报告 reflectionRules: { cart_added: { selector: .cart-notification, .cart-badge-updated, description: 检测商品是否成功加入购物车的提示或徽章变化 } } }); await agent.bind(page); // 一个复合任务直接下达 const task 请执行以下电商网站测试流程 1. 访问 https://demo.ecommerce.com。 2. 在首页搜索“wireless headphones”。 3. 从搜索结果中选择一个带有“Noise Cancelling”标签的蓝牙耳机商品点击进入其详情页。 4. 在该商品详情页将其加入购物车。 5. 最后请验证购物车图标上的数字是否增加表示添加成功。 ; console.log(开始执行复合任务...); const result await agent.run(task); if (result.success) { console.log( 所有任务步骤已完成); console.log(执行日志, result.steps.map(s ${s.action} - ${s.observation}).join(\n)); } else { console.error(❌ 任务执行失败或未完成。); console.error(最后一步的观察, result.lastObservation); console.error(可能遇到的问题, result.error); } await page.waitForTimeout(5000); await browser.close(); })();midscene实战优势任务级描述你可以用一个段落描述整个测试场景智能体自己分解步骤。这更接近人类测试人员的思维方式。内置等待与重试midscene在每次行动后会主动观察页面变化并根据配置的reflectionRules或默认逻辑判断是否成功。如果点击“加入购物车”后没有出现成功提示它可能会尝试再次点击或者滚动页面寻找确认按钮。更强的容错性如果“第一个商品”点进去发现是缺货midscene可能会根据“选择...商品”这个目标自动尝试点击列表中的下一个符合条件的商品。我的踩坑记录在第一次用midscene跑这个流程时我设的maxIterations是5结果任务卡在了“选择商品”这一步。AI在搜索结果页来回滚动就是不确定点哪个。查看日志发现它在反复“观察-规划”因为页面商品较多它一次“看”不全。我把maxIterations增加到15并优化了任务描述为“选择一个带有‘Noise Cancelling’标签的...”给了更明确的筛选条件问题就解决了。这说明给AI更精确的约束能极大提升效率。5. 成本控制、稳定性优化与常见问题排查将AI测试引入生产我们不能只关心“能不能跑通”更要关心“贵不贵”和“稳不稳”。5.1 Token消耗分析与成本控制这是AI测试与传统测试最大的成本差异。Token就是钱。browser-use的消耗点初始化上下文每次agent.context()调用会将你的页面描述文本发送给大模型。每次agent.run()将你的指令和内部的动作规划历史发送给模型。优化策略页面描述务必精简只描述与任务相关的交互元素。避免大段复制整个页面的HTML或无关文本。midscene的消耗点每次观察这是大头它可能将页面HTML的结构化片段、可访问性树甚至截图经编码后的文本发送给模型。一个中等复杂度的页面一次观察消耗5000-10000 Token很常见。规划与反思每次决策也需要消耗Token。优化策略至关重要限制观察范围在配置中设置observationLimit只发送首屏或关键区域的HTML。过滤无用节点配置domFilter过滤掉script,style,svg等对理解页面交互无帮助的标签。使用更便宜的模型进行观察有些框架支持用小型、快速的模型如gpt-3.5-turbo来处理观察信息用大型模型如gpt-4来做核心规划。这需要框架支持混合模型调用。减少不必要的迭代通过提供更清晰的任务描述和规则帮助AI一次做对减少“观察-规划”的循环次数。一个简单的成本估算假设一次完整的midscene测试任务平均进行10次“观察-规划”循环每次观察消耗8000 Token规划消耗500 Token。使用gpt-4-turbo模型输入$1/1M tokens输出$3/1M tokens。那么单次测试的Token成本约为(8000 * 10 500 * 10) / 1,000,000 * $1 ≈ $0.085。这还不算输出Token。跑100次就是8.5美元。对于大规模回归测试这个成本需要仔细评估。5.2 提升测试稳定性的技巧AI测试的“脆弱性”主要来自页面变化和AI的“误解”。元素定位策略互补不要完全放弃传统选择器对于极其关键且稳定的元素如导航栏、登录按钮可以在AI指令中结合使用。例如给AI的上下文描述里可以写“登录按钮的CSS选择器是#login-btn它是一个蓝色的矩形按钮”。这样AI在规划时可能会优先使用这个明确的选择器。使用语义化、稳定的属性鼓励开发同学为关键交互元素添加>问题现象可能原因排查步骤与解决方案AI不执行任何操作或报告“找不到元素”1. 页面上下文描述不准确或缺失。2. 页面尚未加载完成AI已开始执行。3. 元素在iframe或Shadow DOM内。1.检查描述在headless: false模式下对照浏览器实际页面核对你的上下文描述是否匹配关键元素。2.添加等待在page.goto()和agent.run()之间加入page.waitForLoadState(networkidle)。3.处理特殊容器对于iframe需要先page.frameLocator()定位在描述中明确告知AI“元素在某个iframe里”。AI执行了错误操作如点错按钮1. 页面存在多个相似元素AI理解歧义。2. 指令模糊。1.细化描述增加元素的区分特征如“红色的取消按钮”、“表格第一行的编辑图标”。2.细化指令将“点击保存”改为“点击表单底部的蓝色‘保存’按钮”。任务陷入死循环不断重复相同操作1. (midscene)maxIterations设置过高且AI无法识别任务完成状态。2. 成功条件未达成但AI没有检测到失败。1.检查日志查看AI每一步的“观察”和“规划”输出看它卡在了哪里。2.定义明确终点在任务描述中强化最终状态如“直到页面跳转到/dashboard为止”。对于midscene配置清晰的reflectionRules。Token消耗异常高1. (midscene) 页面过于复杂每次观察发送的HTML太大。2. 任务步骤过多迭代次数多。1.启用DOM过滤确保过滤了script,style等标签。2.拆分任务将一个长任务拆分成多个子任务分别执行并管理上下文。运行速度非常慢1. 大模型API响应慢。2. 网络延迟。3. (midscene) 每次观察都在编码/发送大量数据。1.换用更快模型如从gpt-4换到gpt-4o或gpt-4o-mini。2.本地缓存对于不变的页面结构可以考虑将AI分析后的操作路径缓存下来下次直接执行但这会损失适应性。最重要的调试工具把headless设为false亲眼看着AI操作同时开启框架的详细日志。在browser-use和midscene中通常可以通过设置环境变量DEBUG*或verbose: true选项来打印AI与模型的交互细节这对于理解AI的“思考过程”和定位问题根源必不可少。6. 融合架构AI测试与传统测试的共生之道经过一番折腾我的结论是AI自动化测试目前还不是短期内也不太可能成为传统自动化测试的完全替代品。它更像是一个强大的“增强”工具。一个理想的现代UI测试体系应该是两者的结合。我设想中的融合架构是这样的核心业务流程Happy Path使用browser-use这类轻量级AI测试来覆盖。因为核心流程的页面通常稳定需求明确。用自然语言编写和维护这些测试用例对产品和业务测试人员非常友好能极大提升用例编写效率。探索性测试与复杂场景在每次重大发布前使用midscene这样的智能体进行“探索”。给它一个目标比如“测试新上线的结账流程”让它自己去跑可能会发现一些我们预设用例中没想到的交互问题或边缘情况。稳定性与断言所有关键的断言Assertions尤其是涉及具体数据验证的如订单总金额、库存数量仍然应该由传统的、精确的Playwright脚本来完成。AI测试执行完操作后可以调用一段硬编码的Playwright脚本进行结果验证。这样结合了AI的灵活性和传统脚本的精确性。测试资产生成器AI测试可以作为一个“录制”工具。当你手动操作一遍流程AI可以在一旁“观察”并生成对应的Playwright脚本骨架。你可以在这个骨架基础上进行精细化修改和断言加强这比从零写脚本要快得多。技术实现上可以搭建一个测试运行器它能够解析用自然语言编写的“测试任务卡”然后决定是调用AI测试模块还是传统脚本模块或是两者的组合。测试报告也需要统一整合。这条路还很长无论是browser-use还是midscene都还在快速迭代中。它们目前更像是一个充满潜力的“研究预览”产品。但毋庸置疑的是AI正在改变我们构建和维护UI自动化测试的方式。它把测试用例的编写从“如何做”How的部分解放出来让我们更专注于“做什么”What和“验证什么”Verify。对于测试工程师而言未来的核心能力可能不再是精通某一种测试框架的API而是如何精准地定义测试意图、设计鲁棒的任务描述以及分析和优化AI测试智能体的行为。