做了这么多年UI自动化我有一半的时间不是在写用例而是在修选择器。按钮的class改一个字母层级里多包一层div几十条用例跟着塌方页面加个骨架屏几秒的时序波动整条流水线就飘红。传统UI测试这套玩法越来越像是在流沙上盖楼——地基本身就脆。直到我接触了以Midscene.js为代表的AI视觉自动化方案让AI直接“看”界面、理解界面用自然语言下达操作指令才真正感觉测试可以写得像人话一样自然。这篇内容我会围绕AI视觉自动化这个话题结合Midscene.js的实际项目经验重点拆解5个能直接落地的实战技巧。不管你是刚接触自动化测试的新手还是被选择器折磨到想转行的老手这5个技巧都能让你少踩几轮坑。1. AI视觉测试的革命性传统UI测试为什么会崩溃1.1 传统UI测试的痛点逐一拆解先说结论传统UI测试的核心毛病不是框架不好而是“定位”这件事本身太脆弱。过去我们写自动化用例本质上是给元素发“身份证”——用ID、class、XPath、CSS选择器把某个按钮、某个输入框唯一地揪出来。问题在于前端开发是高度动态的尤其是现在组件化开发流行之后class名经过混淆器一处理完全没有规律样式重构、响应式布局调整、A/B实验切版本都会让选择器瞬间失效。我做过一次统计一个中大型后台系统的回归用例集大约1200条用例每次前端发版后平均有15%到20%的用例因为选择器失效而失败其中真正是功能Bug的不到三分之一。也就是说我们每天花大量时间在做“修选择器”这种纯机械劳动而不是在验证业务逻辑。更麻烦的是很多布局类问题、视觉类回归问题根本没法用传统断言去捕捉比如“弹窗遮挡了按钮”“文字溢出到容器外面”这类问题在传统自动化里几乎是无解的只能靠人工点一遍。这里不是要否定传统自动化它在接口稳定、结构规范的场景下依然高效只是面对现代前端的高频迭代维护成本已经高到反噬效率。这也是AI视觉测试出现的背景既然DOM结构不稳定那就跳过DOM直接让AI理解渲染出来的画面用人眼一样的视觉能力去定位和操作。1.2 Midscene.js的核心原理AI如何“看懂”界面Midscene.js的思路其实很直接它把多模态视觉大模型的能力接进了浏览器自动化流程里。你不需要给AI描述元素的DOM路径而是直接给它一张页面截图、一段自然语言指令比如“点击右上角的登录按钮”或者“找到表格中状态为已完成的订单点击操作列里的详情”。AI理解截图中的视觉内容结合指令推理出要操作的位置然后转换为真实的光标点击、输入、滚动等动作。这个流程看起来像魔法本质上是一次“感知-推理-行动”的闭环。感知阶段AI把截图像素变成视觉特征推理阶段结合自然语言指令判断意图和元素位置行动阶段由自动化底座把坐标或意图变成浏览器事件。关键点是Midscene.js在行动前会把AI给出的结果映射回页面结构而不是盲目地按像素坐标点击这比纯粹的图像坐标识别要稳得多。用生活类比来解释传统自动化就像一个盲人摸象靠手摸到固定的纹理来识别物体物体换个摆放方式就不认识了AI视觉测试就像一个视力正常的人扫一眼就知道“那个红色按钮在右上角”即使按钮换了个皮肤、挪了个位置只要还是“红色按钮”它就能认出来。1.3 影响范围从测试到研发流程的连锁变化这套技术带来的影响远不止“少改几个选择器”。最直接的变化是写测试用例的门槛大幅降低。传统自动化要求测试人员会写代码、懂DOM结构、了解框架API而AI视觉测试只需要会描述需求——这一点产品经理、运营、设计师都能做到。我身边已经有个别团队开始尝试让业务同学直接写验收场景再由测试同学做二次封装。更深一层的影响是测试左移的可行性变高了。以前UI用例是最后一道关卡因为准备成本和维护成本太高等提测阶段再写已经来不及。现在用例写得快、改得快开发过程中就可以拿AI视觉用例做冒烟验证。另外一个容易被忽略的影响在于视觉回归传统方案对“好不好看”无能为力而AI视觉方案天然能感知布局、颜色、遮挡这类视觉特征这让UI回归测试从“功能有没有”升级到“界面对不对”这是质的区别。2. 环境准备与首个DemoMidscene.js落地前的必修课2.1 运行环境与依赖选型在动手写第一个用例之前先把环境说清楚。Midscene.js不是一个独立的“一键安装”工具它需要依托一个浏览器自动化底座在你安装好的环境里作为一个增强层存在。我建议用支持Chromium内核的自动化框架作为底座这样视觉采样的稳定性和无头模式的成熟度都更好。具体到项目里我一般会新建一个独立的Node项目单独管理依赖版本不混进业务工程里。原因有两个一是AI视觉测试的依赖升级频率相对高混在业务项目里容易引发版本冲突二是这个项目要跑定时任务、出测试报告保持独立可以避免CI配置里各种上下文干扰。依赖安装完之后需要确认两件事本地是否安装了对应版本的浏览器内核以及配置文件里是否把浏览器路径指对了。很多新手第一次跑通Demo之后换台机器就乱绝大部分是因为浏览器路径硬编码在代码里换环境没同步改。建议把浏览器路径抽到配置项里用环境变量覆盖。2.2 首个AI视觉测试用例的写法示例直接上代码这个是我在模拟项目X里跑通的第一个用例只做了一件事打开首页找到搜索框输入关键词点击搜索按钮然后断言搜索结果里出现了预期内容。import { setup } from midscene-sdk; // 初始化连接拿到一个可执行的runner const runner await setup({ // 这里的air-console/remote等参数按实际环境配置 browserEndpoint: ws://127.0.0.1:9222, }); // 用自然语言驱动AI执行打开页面、定位元素、交互 await runner.ai(打开首页等待页面完全加载完成); await runner.ai(在顶部的搜索框里输入关键词自动化测试); await runner.ai(点击搜索按钮); // 用AI断言页面状态 const result await runner.aiAssert(页面标题应包含“自动化测试”相关结果如果没有结果显示抛出明确提示); console.log(断言结果, result.pass ? PASS : FAIL);你可能会觉得这也太简单了吧对这就是关键——你不用再关心那个搜索框的id是search-input还是search_input_wrap你只需要描述它的特征。第一次跑通这种用例的时候我确实有种“以前那些定位方法都白学了”的感慨。不过这只是开始实际项目中会遇到大量细节问题后面会逐个展开。2.3 核心概念任务、提示词与执行模式Midscene.js的使用过程中会反复遇到几个概念提前建立清晰认知能省很多折腾。任务(Task)一次完整的AI驱动操作流程可能包含多条指令。我习惯把一个业务场景拆成一个任务比如“下单流程”“登录流程”这样任务之间可以独立运行也方便排查具体是哪一步出了问题。提示词(Prompt)这是给AI的自然语言指令。提示词的写法直接决定AI理解的准确度。核心原则是具体、可验证、无歧义。我刚上手时经常写“点击那个按钮”AI只能靠猜正确率自然不高改成“点击页面上唯一一个带‘立即购买’文字、背景为橙色的按钮”之后准确率明显提升。执行模式Midscene.js可以做全自动执行AI自主决定操作序列也可以做步骤化执行每一步由你指定动作AI只负责定位。在关键业务流程上我强烈建议用步骤化执行因为全自动模式下AI可能出现创造性的步骤跳跃——它觉得自己已经完成了任务但实际上跳过了某个必要环节这在支付、提交订单这类流程里是绝对不能接受的。3. 实战技巧才是重头戏5个让AI视觉测试真正可用的方法3.1 技巧一自然语言提示词的“人话翻译术”第一个技巧也是最基础最重要的学会把你的操作意图翻译成AI最容易理解的指令。这不是写作文不需要修饰词但需要足够的约束信息。我总结了一个公式操作对象核心特征 操作动作具体动词 边界约束位置、范围、前提条件。举例来说如果你的需求是“在订单列表中把第一笔已取消订单删除”提示词不要写成“删除一个订单”而应该写成“在页面左侧订单列表中找到状态标签为‘已取消’的第一行订单点击该行的‘删除’按钮如果页面上没有已取消的订单请停止操作并提示‘无已取消订单’”。这里有几个细节值得注意。第一AI对“唯一性”非常敏感你要帮它排除歧义比如“页面顶部”“侧边栏”“表格倒数第二行”这类方位词能加就加。第二条件分支要提前说明“如果…就…如果没有…就提示”这种句式能极大减少AI自作主张的概率。第三动词要明确“点击”“双击”“输入”“悬停”不要混用AI不会自动脑补你想要的交互方式。经验表明提示词每增加一个有效的约束维度定位准确率能提升一个档次。我在模拟项目X中做过统计只写“点击按钮”时准确率不到70%加上文字特征后提升到90%再加上方位特征后稳定在96%以上。多花十秒钟把指令写得严谨比出错后反复调试一个钟头划算得多。3.2 技巧二拿捏AI视觉执行的等待节奏AI视觉模型的一次推理通常需要几秒钟这意味着它不是一个瞬时动作。很多人第一次跑AI测试时最大的不习惯就是“怎么这么慢”。这个慢不是Bug而是AI理解画面的必要开销。真正的坑在于如果你没有为AI执行设置合理的等待策略很多操作会在页面还没渲染完成时就触发导致AI看到一张残缺的截图做出错误判断。我的做法是给关键动作前加一个“视觉稳定等待”。场景是动态加载的列表比如表格数据来自接口我会先加一条指令“等待页面列表区域的加载状态图标消失并确认表格内出现至少一条数据”。这比传统自动化里的固定sleep(3)要聪明得多因为它是基于画面状态判断的列表1秒加载完就只等1秒加载10秒就等10秒。另外要控制任务里的指令密度。不要在一条任务里堆二十个动作让AI一口气跑完每执行五六个动作我就会做一次阶段性校验比如断言当前页面URL是否正确、某个关键元素是否出现。这种“每走几步回头看看”的做法能避免AI一路狂奔跑到错误页而不自知。说到底AI是个聪明的执行者但它没有方向感导航这件事还得靠你自己。3.3 技巧三混合定位策略——别把所有鸡蛋放进AI篮子里很多接触AI视觉测试的人会走向一个极端什么都让AI来做。我的建议恰恰相反——保持混合定位策略。稳定的、频繁使用的、性能敏感的元素优先用传统选择器动态的、复杂的、布局多变的元素交给AI。简单来说能用选择器就用选择器搞不定了再请AI出马而不是反过来。这么做的理由很实际。第一AI视觉推理有成本无论从时间还是算力消耗上都比直接走DOM选择器高一个数量级第二AI存在幻觉偶发性地定位错误是天然的对稳定性要求极高的支付场景你总不能接受100次里有1次点错按钮。混合策略的好处是用传统方式守住底线用AI拓展边界。实操中我给每个AI动作都加了传统方式兜底。具体做法是优先尝试用稳定的选择器定位元素如果元素不存在再调用AI视觉定位。用一个简单的函数封装这个逻辑让调用方无感知。这套机制上线后我的用例集稳定性从94%提升到了99%以上执行时间也缩短了大约40%因为大部分高频操作都走了快速路径。3.4 技巧四把AI当作数据提取器——结构化断言很多人的认知停留在“AI视觉测试就是AI帮忙点击元素”其实AI在数据提取方面的能力同样有价值这可能是最容易忽略的实战技巧之一。传统断言只能判断“在不在”“是不是”而AI可以直接把页面上的非结构化视觉信息抽取成结构化数据供你进行更丰富的校验。举个例子页面上有一张数据报表里面有销售额、转化率、订单数等多个指标传统做法是分别给每个数字写定位和文本断言。用Midscene.js我直接给一条指令“提取页面中核心指标区域的所有数据返回JSON格式包含指标名称和对应数值。”AI能把画面里的数字和标签解析出来形成干净的结构化数据。虽然不同项目的写法略有差异但核心思路一致。拿到结构化数据之后我一般做三件事第一与接口返回值做交叉比对验证前端展示的数据准确性第二做趋势判断比如“当天的订单数不能低于昨天”这不再是简单的存在性断言而是业务层面的规则校验第三把提取到的数据直接落到测试报告里作为人工复核的依据。这个方法让AI测试从“界面操作验证”升维到“业务数据验证”含金量高了一个层级。3.5 技巧五视觉回归与多场景复用最后一个技巧是把我前四个技巧串起来的“组合拳”。AI视觉测试天然适合做视觉回归测试因为AI本身就是靠“看”来理解界面的。你可以让AI描述当前页面的关键视觉特征比如布局、颜色、组件状态然后与一个基准描述做相似度比对。这个能力在传统自动化里几乎无法实现但现在只需要一段自然语言指令。我在项目中是这样做的每次发版前让AI对几个核心页面进行一次“视觉巡检”指令类似于“检查登录页是否包含背景图为蓝色系、卡片圆角、按钮文案为‘登录’检查是否有元素重叠、文字溢出或遮挡”。这些描述在传统自动化里是无从谈起的即使有截图对比工具也只会机械地报像素差异不知道差异是不是问题而AI能直接理解“文字溢出”这种语义层面的异常。多场景复用则是更高阶的用法。我的做法是把页面特征描述和操作步骤做分离页面特征写在一个配置文件里操作步骤写成一个通用脚本。新项目接入时只需要替换配置文件脚本主体完全复用。这样一套AI视觉测试框架我可以在多个后台系统之间迁移实际搭过之后你会发现这比传统自动化每换一个项目就从头写定位器要爽太多了。4. 实战中的坑与排查实录稳定性是第一生命线4.1 高频问题速查表把这段时间踩过的典型问题整理成一张速查表方便你遇到类似情况时快速定位。现象可能原因解决思路AI点击位置偏移总是点偏一点点截图分辨率与页面渲染比例不一致浏览器缩放比例不是100%统一设置浏览器窗口大小关闭浏览器缩放确保设备像素比一致连续多次返回同一个错误结果提示词存在歧义AI在多个候选目标之间摇摆增加约束维度方位、颜色、文字、相对位置完全空白的页面AI还在继续操作页面加载失败或接口超时AI看到的是错误页强制在任务开头加“确认页面已加载出XX元素”的前置校验执行速度慢到难以接受任务里指令过多单次任务串行执行大量动作拆分任务大批量操作批量场景用传统选择器兜底偶发性定位到不同元素AI模型的概率性相同截图可能给出不同结果固定提示词格式增加关键描述必要时连续两次交叉验证弹窗遮挡导致AI点击无效AI识别到目标元素但没有感知弹窗遮挡提示词里显式描述遮挡条件“如果存在弹窗先点击关闭按钮”4.2 稳定性建设的三个关键步骤问题排查只是止血真正的稳定性要从机制上解决。我稳定使用了三个月之后总结出三个最有效的做法。第一步统一固定的浏览器视口配置。AI视觉定位严重依赖截图内容的一致性。如果有的用例在1920宽度的窗口跑有的在1440宽度跑AI对“右上角”这类方位描述的理解就会失真。现在所有项目的用例都固定使用同一个视口尺寸横竖屏模式也统一锁定这一个动作直接减少了大约30%的偶发定位问题。第二步建立AI动作的自愈重试机制。AI偶尔会点错但概率不高没必要每次失败都人工介入。我给每次AI操作包了一层自动重试逻辑第一次定位失败或操作后页面状态不符合预期等待1.5秒后自动重试第二遍。实测重试后成功率显著提升而且重试导致的时间开销完全可以接受。第三步可视化日志与截图留痕。AI测试最大的噩梦是“到底AI刚才看到了什么”。我一律开启了全链路日志和操作截图每一步AI的输入、输出、最终点击位置都记录下来。这不仅是排查问题的依据也是反向优化提示词的素材——每次偶发问题我都会翻出当时的截图与AI原始回复找出是哪段描述让AI产生了误解然后把提示词改得更严谨。这套反馈闭环是AI测试稳定性持续提升的真正引擎。5. 选型建议与适用场景不是所有项目都适合上AI视觉测试5.1 哪些场景值得用AI视觉测试AI视觉测试不是银弹我在实际项目中有明确的取舍标准。第一类适合的是高度图形化、动态布局的C端应用。这类应用UI变化频繁动画多、响应式场景多传统选择器非常容易失效而AI视觉测试几乎是为这类场景量身定制的。第二类适合的是视觉合规性要求高的项目。比如支付结果页、合同签署页、活动页这些页面不能有遮挡、重叠、文案溢出需要“长得对”而不只是“功能对”。第三类是跨项目复用的内部系统。多个后台管理项目共用一套组件库外观和行为高度一致用AI视觉测试做一套框架在多个项目间复制边际成本极低。不适合的场景也要说清楚如果页面完全静态、结构长时间不变、对执行速度和消耗极其敏感传统自动化仍然是更优的选择。另外如果业务对操作步骤有严格的路径依赖比如必须经过特定顺序的流程AI全自主执行模式可能反而危险这种情况下请务必使用步骤化执行。5.2 选型对比AI视觉测试与传统自动化怎么配合最后聊一个大家都会纠结的问题上了AI视觉测试传统自动化是不是可以扔了我的态度很明确它们是互补关系不是替代关系。从我的对比经验来看AI视觉测试最大的价值是覆盖“语义复杂”和“视觉敏感”两类场景而传统自动化在“高频回归”和“性能敏感”场景下依然效率更高。实操中最稳的组合方案是高频主流程回归用传统自动化跑得快、够稳定复杂动态流程、视觉巡检、跨版本视觉对比用AI视觉测试看得懂、防得住。这两个体系维护各自的脚本资产通过同一个测试调度框架集成跑完统一汇总到一个报告页面里。前面提到的混合定位策略本质就是这种思想在单条用例内部的延伸。我个人的体会是没有必要去争“谁取代谁”而是把每种工具的边际成本算清楚。凡是让AI理解画面比人写定位器更划算的地方就是AI视觉测试的甜区。凡是成本低见效快的场景继续用老办法也不丢人。工具是拿来解决问题的不是拿来信仰的。最后再分享一个小技巧就算你暂时不打算全面引入AI视觉测试也可以先用Midscene.js这类工具做“线上巡检机器人”让AI每天定时把核心页面逛一遍异常自动截图并描述问题。这个用途不需要维护任何选择器几乎零成本就能获得一套24小时在岗的“视觉哨兵”。我是从这个小切口开始才一步步把AI视觉自动化带进了整个测试流程你不妨也从最小的一步试试。