- 选择器维护这件事，几乎每个做 UI 自动化的团队都算过账：一次前端重构，几百个用例里的 `data-testid` 与 CSS 路径批量失效，修的人比写的人多。于是「用视觉或自然语言来定位元素」这条路线，这两年一直在被讨论。
- 
- 摆在负责人面前的问题很具体：投哪条。市面上至少三种形态——Midscene 这类由字节开源的 GUI 视觉方案，用自然语言描述动作、由模型结合视觉理解执行；各类「自然语言转选择器」封装，把一句人话翻译成 Playwright 定位器再执行；以及最朴素的一条，继续用 Playwright，但把定位方式从 CSS 路径全面换成 `getByRole`、`getByLabel` 这类语义 locator。
- 
- 这份报告不给「哪个最好」的答案，因为没有统一答案。它给的是五个可量化维度的对照、一份可以直接跑的复现方法，以及每条路线的适用边界——让你在自己的页面上测一遍，自己下结论。
- 
- ## 一、横评结论摘要
- 
- 先给结论，再给依据。三条路线的取舍可以压成三句话。
- 
- 第一，语义 locator 是被低估的基线：没有模型调用费用、没有网络抖动、失败信息精确到具体元素，集成成本几乎为零。大多数团队所谓的选择器地狱，根因不是 Playwright 不行，而是一直在用脆弱的 CSS 路径与 XPath。
- 
- 第二，视觉驱动路线解决的是语义 locator 覆盖不到的场景：没有可访问性语义的 canvas 与图形化编辑器、语义信息缺失的老旧页面、需要跨端一致描述的移动端流程。代价是执行更慢、单次任务产生调用费用、失败信息不如原生断言精确。
- 
- 第三，自然语言转选择器这条中间路线，稳定性取决于翻译层的实现方式。要特别注意：有些方案宣称「视觉驱动」，实际读的是无障碍树而不是像素，这决定了它在 canvas 类页面上会不会直接失效——选型时必须问清楚它到底看什么。
- 
- 推荐动作：先把定位方式升级为语义 locator，把这层收益吃干净；再挑十到二十条覆盖不了的高价值流程做视觉驱动试点；试点期间用第五节的 harness 采自己的数据，不要用别人的跑分做决策。
- 
- ## 二、横评框架：五个维度各自怎么量
- 
- 维度定不下来，横评就会变成印象分。这五个维度都必须能被测出来。稳定性看两个数：同一条用例重复跑 N 轮的通过率，以及一次纯样式重构（不改语义、不改文案）之后还剩多少用例能过——前者衡量随机性，后者衡量对重构的容忍度，而那正是引入新方案最想解决的问题。
- 
- 执行成本也看两个数：单轮端到端耗时与单轮调用费用。耗时要区分首次执行与缓存命中后执行，两者差距可能很大；费用要按团队实际的日跑次数去乘，而不是看单次绝对值。
- 
- 可诊断性看一个动作：用例失败后，从报告里拿到「哪一步、哪个元素、为什么」需要多久——这个维度最容易被忽略，却决定日常维护成本。集成成本看改造量：接入现有 Playwright 与 CI 要动多少代码、是否需要额外的环境变量与密钥、能否与既有 fixture 和页面对象共存。适用边界不是一个分数，而是一份清单：哪类页面适合、哪类不适合、哪类必须人工兜底；横评报告没有这一节，前面的分数就只是好看。
- 
- ## 三、三条技术路线 × 五维度横评总表
- 
- 下面这张总表是本篇的主表。表中标注「自测」的行，其数值为本文用于说明对照方式的设定值，读者应用第五节的 harness 在自己的页面上实测替换；官方基准单独放在第四节，不与自测值混排。
- 
- | 维度 | Playwright 语义 locator | 自然语言转选择器封装 | Midscene 视觉驱动（aiAct／aiAssert） |
- |---|---|---|---|
- | 重复执行通过率（自测，20 轮） | 20/20 | 17/20 | 18/20 |
- | 样式重构后存活率（自测） | 约九成 | 约七成 | 约八成五 |
- | 单轮耗时（自测，四步流程） | 6 秒 | 9 秒 | 31 秒 |
- | 单轮调用费用 | 无 | 视翻译层实现，通常无或极低 | 有，按任务计（见第四节官方口径） |
- | 缓存命中后耗时 | 无变化 | 无变化 | 明显下降（官方口径 51 秒降至 28 秒） |
- | 失败信息粒度 | 精确到定位器与断言，含元素快照 | 取决于翻译层，常见为「未找到匹配选择器」 | 给出自然语言步骤与执行报告，需结合截图定位 |
- | 集成成本 | 零，只改定位写法 | 中，需引入翻译层与提示词维护 | 中，需引入依赖、配置模型与密钥 |
- | canvas／图形化页面 | 基本无能为力 | 若读无障碍树则同样失效 | 可处理，这是它的主场 |
- | CI 中的确定性 | 高，可重复、无外部依赖 | 中 | 受模型与网络影响，需重试与预算兜底 |
- 
- 这张表要横着读一行、竖着读一列。横着读「单轮耗时」那行，视觉驱动比原生慢一个量级，这直接决定它不适合放进每次提交都跑的快速反馈环；竖着读 Midscene 那列，它的强项集中在 canvas、移动端与样式重构容忍度上，而不是全面胜出。
- 
- ## 四、Midscene 的基准与成本口径：数字要连着口径一起读
- 
- 官方基准是选型的重要输入，也是最容易被读错的部分。下面这张表把数值、口径来源与注意事项分开列，建议照这个格式写进你自己的选型报告。
- 
- | 指标 | 数值 | 口径来源 | 读这个数时要注意什么 |
- |---|---|---|---|
- | AndroidWorld Pass@1 | 93.1% | Midscene 官方站，核实于 2026-09-10 与 2026-09-15 | Pass@1 是单次尝试的通过率 |
- | AndroidWorld Pass@3 | 97.4% | 同上 | 三次尝试内成功的口径，与 Pass@1 是两套数，不能混读，更不能与代码类评测综述里的 97.00 混为一谈 |
- | MobileWorld | 78.6%（92/117） | 同上 | 分母是 117 个任务、通过 92 个；任务集不同，不能与 AndroidWorld 直接比高低 |
- | AppControlBench | 96.7% | 同上 | 偏单步操作粒度，不等于一整条业务流的端到端成功率 |
- | 60 个任务费用 | 约 0.59 美元 | 官方早前公布口径 | 只是量级参考；实际费用随模型定价、页面复杂度、步骤数变化，要按自己的流程重算 |
- | 缓存生效耗时 | 51 秒降至 28 秒 | 官方早前公布口径 | 指同一任务在缓存命中前后的耗时对比，不是所有场景都能命中 |
- | API 名称 | `aiAct()` | 官方站现行文档 | 接入前以官方文档为准，不要照抄旧博客里的写法 |
- 
- Pass@1 回答「一次就做对的概率」，Pass@3 回答「给三次机会至少做一次对的概率」。做 CI 里的自动化用例，你关心的是前者，因为没人愿意为一条用例重试三次并付三份费用；把 Pass@3 当成日常稳定性来引用，是这类报告里最常见的误读。
- 
- 另外两个误读同样常见：一是跨基准比较，AndroidWorld、MobileWorld、AppControlBench 是三套不同任务集，93.1%、78.6%、96.7% 之间不存在「哪个更强」的关系；二是把官方基准当成自己项目的预期值，而基准任务与你的业务页面在复杂度、语义完备度、网络条件上都不同。费用与缓存沿用官方早前口径，报告里应标注公布时间并附一句「以当前官方站为准」。
- 
- ## 五、同一业务流两种写法：可直接跑
- 
- 横评要可信，前提是两条路线跑完全相同的业务流。下面用「登录→搜索→加购→断言购物车数量为 1」给出两种写法，每步耗时与成败都记进同一个 tracer。
- 
- ```javascript
- // flows.mjs —— 同一条业务流的两种实现
- // 依赖：npm i playwright @midscene/web
- // Midscene 侧需要环境变量：OPENAI_API_KEY（或你所用模型网关的变量）、MIDSCENE_MODEL_NAME
- // 可选：MIDSCENE_RUN_DIR 指定执行报告输出目录
- import { PlaywrightAgent } from '@midscene/web/playwright';
- 
- export const STEPS = ['login', 'search', 'add_to_cart', 'assert_cart'];
- 
- // 每一步的耗时与结果都记进 tracer，横评数据就是这么攒出来的
- async function step(tracer, name, fn) {
-   const t0 = Date.now();
-   try {
-     await fn();
-     tracer.push({ step: name, status: 'pass', ms: Date.now() - t0, error: '' });
-   } catch (err) {
-     const message = String((err && err.message) || err).slice(0, 200);
-     tracer.push({ step: name, status: 'fail', ms: Date.now() - t0, error: message });
-     throw err;
-   }
- }
- 
- async function assertText(locator, expected) {
-   const got = ((await locator.textContent()) || '').trim();
-   if (got !== expected) {
-     throw new Error(`购物车数量断言失败：期望 ${expected}，实际 ${got}`);
-   }
- }
- 
- // 路线 A：Playwright 语义 locator（改良传统写法，零模型依赖）
- export async function runPlaywrightFlow(page, ctx) {
-   const tracer = [];
- 
-   await step(tracer, 'login', async () => {
-     await page.goto(`${ctx.baseUrl}/login`);
-     await page.getByLabel('用户名').fill(ctx.user);
-     await page.getByLabel('密码').fill(ctx.password);
-     await page.getByRole('button', { name: '登录' }).click();
-     await page.waitForURL('**/home');
-   });
- 
-   await step(tracer, 'search', async () => {
-     const box = page.getByRole('searchbox', { name: '搜索商品' });
-     await box.fill(ctx.keyword);
-     await box.press('Enter');
-     await page.getByRole('list', { name: '搜索结果' }).waitFor();
-   });
- 
-   await step(tracer, 'add_to_cart', async () => {
-     const card = page.getByRole('listitem').filter({ hasText: ctx.keyword }).first();
-     await card.getByRole('button', { name: '加入购物车' }).click();
-   });
- 
-   await step(tracer, 'assert_cart', async () => {
-     await assertText(page.getByTestId('cart-count'), '1');
-   });
- 
-   return tracer;
- }
- 
- // 路线 B：Midscene PlaywrightAgent，自然语言驱动 + 视觉理解
- export async function runMidsceneFlow(page, ctx) {
-   const agent = new PlaywrightAgent(page, { testId: 'shop-flow-visual' });
-   const tracer = [];
- 
-   await step(tracer, 'login', async () => {
-     await page.goto(`${ctx.baseUrl}/login`);
-     await agent.aiAct(`在用户名输入框填入 ${ctx.user}，在密码输入框填入 ${ctx.password}，然后点击「登录」按钮`);
-     await agent.aiWaitFor('页面已经进入首页，可以看到商品搜索框', { timeoutMs: 20000 });
-   });
- 
-   await step(tracer, 'search', async () => {
-     await agent.aiAct(`在搜索框中输入 ${ctx.keyword} 并回车，等待搜索结果列表出现`);
-   });
- 
-   await step(tracer, 'add_to_cart', async () => {
-     await agent.aiAct('在搜索结果中第一个商品卡片上，点击「加入购物车」按钮');
-   });
- 
-   await step(tracer, 'assert_cart', async () => {
-     await agent.aiAssert('页面右上角购物车图标上的数量角标显示为 1');
-   });
- 
-   return tracer;
- }
- ```
- 
- ```javascript
- // harness.mjs —— 横评复现器：每条路线跑 N 轮，记录每步耗时与成败
- // 运行：node harness.mjs --repeats 20 --baseUrl http://127.0.0.1:5173 --out bench.csv
- import { chromium } from 'playwright';
- import { writeFileSync } from 'node:fs';
- import { runPlaywrightFlow, runMidsceneFlow } from './flows.mjs';
- 
- const argv = process.argv.slice(2);
- const args = {};
- for (let i = 0; i < argv.length; i += 2) {
-   if (String(argv[i]).startsWith('--')) args[String(argv[i]).slice(2)] = argv[i + 1];
- }
- 
- const REPEATS = Number(args.repeats || 20);
- const OUT = args.out || 'bench.csv';
- const CTX = {
-   baseUrl: args.baseUrl || 'http://127.0.0.1:5173',
-   user: 'ui_bench_user',
-   password: 'Bench#2026',
-   keyword: '无线耳机',
- };
- 
- const ROUTES = [
-   { name: 'playwright-locator', run: runPlaywrightFlow },
-   { name: 'midscene-visual', run: runMidsceneFlow },
- ];
- 
- function summarize(rows, routeName) {
-   const totals = rows.filter((r) => r.route === routeName && r.step === '__total__');
-   const passed = totals.filter((r) => r.status === 'pass');
-   const ms = passed.map((r) => r.ms).sort((a, b) => a - b);
-   const p50 = ms.length ? ms[Math.floor(ms.length / 2)] : NaN;
-   const avg = ms.length ? Math.round(ms.reduce((a, b) => a + b, 0) / ms.length) : NaN;
-   const stepFail = {};
-   for (const r of rows) {
-     if (r.route === routeName && r.status === 'fail') stepFail[r.step] = (stepFail[r.step] || 0) + 1;
-   }
-   return { rounds: totals.length, passed: passed.length, p50, avg, stepFail };
- }
- 
- async function main() {
-   const browser = await chromium.launch({ headless: true });
-   const rows = [];
- 
-   for (const route of ROUTES) {
-     for (let round = 1; round <= REPEATS; round++) {
-       const context = await browser.newContext({ viewport: { width: 1440, height: 900 } });
-       const page = await context.newPage();
-       const t0 = Date.now();
-       let tracer = [];
-       let status = 'pass';
-       try {
-         tracer = await route.run(page, CTX);
-       } catch (err) {
-         status = 'fail';
-         console.error(`[${route.name}] 第 ${round} 轮失败：${(err && err.message) || err}`);
-       }
-       for (const s of tracer) {
-         rows.push({ route: route.name, round, step: s.step, status: s.status, ms: s.ms, error: s.error });
-       }
-       rows.push({ route: route.name, round, step: '__total__', status, ms: Date.now() - t0, error: '' });
-       await context.close();
-     }
-   }
-   await browser.close();
- 
-   const header = ['route', 'round', 'step', 'status', 'ms', 'error'];
-   const csv = [header.join(','), ...rows.map((r) => header.map((h) => JSON.stringify(r[h] ?? '')).join(','))];
-   writeFileSync(OUT, csv.join('\n'));
- 
-   for (const route of ROUTES) {
-     const s = summarize(rows, route.name);
-     console.log(`\n${route.name}`);
-     console.log(`  轮次通过 ${s.passed}/${s.rounds} ｜ 成功轮 p50=${s.p50}ms ｜ 均值=${s.avg}ms`);
-     console.log(`  失败步骤分布：${JSON.stringify(s.stepFail)}`);
-   }
-   console.log(`\n明细已写入 ${OUT}（可导入表格做样式重构前后的存活率对比）`);
- }
- 
- main().catch((err) => {
-   console.error(err);
-   process.exit(1);
- });
- ```
- 
- 为什么这么写：两条路线共用同一个 `step()` 包装器与同一份 `STEPS` 定义，是为了让「步骤」粒度在两边完全对齐——横评最怕 A 路线把搜索与加购算一步、B 路线算两步，耗时对比就失去意义。tracer 里同时记 `status` 与 `ms`，失败轮也保留已完成步骤的耗时，这样才看得出「慢在哪一步」，而不是只知道「这轮挂了」。
- 
- 踩过的坑有四个。一是每一轮都要新建 context，复用同一个 page 会因缓存与页面状态让后几轮偏快。二是模型侧有网络抖动，20 轮是下限，轮次太少通过率没有统计意义。三是费用要自己记：harness 只测耗时，调用费用得从模型网关账单侧同步拉一份，按轮次对齐才算得清单轮成本。四是别拿这套 harness 去压生产环境，视觉驱动路线的重试会放大请求量。
- 
- ## 六、适用边界与建议动作
- 
- 语义 locator 适用于页面有基本可访问性语义、元素有可读角色或稳定 testid、流程以表单与列表为主的场景——这也是绝大多数 Web 后台与电商页面的情况。视觉驱动适用于 canvas 与图形化编辑器、语义信息缺失的老旧页面、一份描述同时驱动 Web 与移动端的流程，以及探索性测试里「让 agent 自己找路径」的场景；不适用于每次提交都要跑的快速反馈环、确定性要求极高的资金与权限类核心流程，以及完全离线的环境。自然语言转选择器封装则适合已积累大量自然语言用例资产、想渐进迁移而非重写的团队，选型时必问一句：它读的是像素还是无障碍树？
- 
- 建议动作四条：把现有用例的定位方式统一升级为语义 locator，收益确定、成本最低；挑十到二十条覆盖不了的高价值流程做视觉驱动试点，用本文 harness 采自己的通过率、耗时与费用；试点用例放进独立 CI 阶段，配重试与预算上限，不与快速反馈环混跑；报告里官方基准与自测数据分表呈现，Pass@1 与 Pass@3 分开写，费用与缓存注明口径时间。
- 
- 报告能帮你的是把维度定清楚、把口径标明白；真正的结论只能来自你自己页面上跑出来的那二十轮。
- 
- **工具横评最有价值的产出不是排名，而是让每个人都能复现同一份排名的那套方法。**
- 
- > 你团队的 UI 自动化，卡在选择器维护还是卡在跑一轮太慢？评论区聊聊。


选择器维护这件事，几乎每个做 UI 自动化的团队都算过账：一次前端重构，几百个用例里的 data-testid 与 CSS 路径批量失效，修的人比写的人多。于是「用视觉或自然语言来定位元素」这条路线，这两年一直在被讨论。

视觉驱动 UI 测试横评报告：Midscene 与自然语言选择器方案的稳定性/成本对照

测试

开发工具

人工智能

三种元素定位路线横评：语义locator是最低成本基线，零依赖且失败信息精确；视觉驱动解决canvas等复杂场景，但耗时高、有费用；自然语言转选择器稳定性取决于实现。提供五维对照与可运行harness，建议先升级语义定位，再试点视觉方案。

JavaScript

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

视觉驱动 UI 测试横评报告：Midscene 与自然语言选择器方案的稳定性/成本对照-腾讯云开发者社区-腾讯云

视觉驱动 UI 测试横评报告：Midscene 与自然语言选择器方案的稳定性/成本对照

视觉驱动 UI 测试横评报告：Midscene 与自然语言选择器方案的稳定性/成本对照

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐