作者介绍:胡嘉椿,来自货拉拉/技术中心/质量保障部,专注于移动测试效能方向。
一、背景与挑战
在移动端测试中,我们始终面对着同一个核心挑战:如何持续降低手工测试的工作量? 为此,我们团队已经建立起两条成熟的创新提效路径:
- 在老功能回归测试上,我们以UI录制回放(参考《 货拉拉App录制回放的探索与实践 》) 技术,颠覆了传统手写脚本模式,实现了脚本的“零代码” 生成与大规模覆盖,从根本上解决了自动化普及的瓶颈。
- 在新功能测试上,我们推出了多机同步模式(参考《 货拉拉云真机多机同步探索与实践 》) ,绕开了传统脚本的局限,实现了“一端操作、多端覆盖”,缓解了多机型、多端口的效率瓶颈问题。
基于这些创新实践,为我们构建了货拉拉移动端测试的提效体系。然而,效率提升的红利正逐渐触达瓶颈,而且也有新的挑战:
- 自动化测试,仍需要“人工维护” :随着脚本规模超过18,000条,App UI频繁迭代带来的脚本失效问题,使我们陷入了新的“脚本修复”循环。
- 新功能,仍是“人工驱动” :多机同步本质上是将 N 次在手机上的操作变成 1 次,测试执行本身依然需要依赖人工。
因此,我们需要从上述两个方向上寻求突破,打通“最后一公里”的障碍,真正实现测试提效的闭环。针对新功能测试仍依赖“人工驱动”的瓶颈,我们团队已在积极探索相关解决方案,并计划在后续进行分享;本文则将聚焦于 UI 自动化测试实践中的稳定性和效能瓶颈,深入探讨其挑战与实践路径。
二、UI自动化的局限性
我们通过分析UI自动化测试的历史报告与脚本维护人员的实际痛点,发现两大核心困境正吞噬着测试效能:
- 脚本维护的“循环”困境 传统 UI 脚本高度依赖元素定位策略(如 ID 、图像或文本匹配),在货拉拉单周迭代App 的冲击下带来的UI微调,每周都有不少的脚本陷入“抢救式”修复。
- 执行稳定性的瓶颈 面对品牌碎片化带来的各类弹窗“突袭”(如系统推送、权限申请、App广告等),自动化脚本的平均通过率长期徘徊在80%的瓶颈线上;为保障稳定性,需要持续在脚本中叠加各类弹窗识别与处理逻辑,进一步拉高维护成本。
这两大困境如同一个永远填不满的沙漏,不断的在蚕食宝贵的测试资源。
三、AI介入UI自动化
传统UI自动化测试元素定位策略暴露出严重的脆弱性和维护成本,我们通过在测试执行过程中引入AI 自愈能力(多模态特征融合+视觉模型+语义分析能力), 为UI脚本提升鲁棒性。AI介入时机如下图所示:
AI驱动的UI自动化,突破传统“脚本失效即中断”的脆弱模式,构建感知-诊断-决策-修复的智能闭环体系,其核心优势在于:
- 精准问题定位: 当用例执行中断时,AI自愈通过多模态数据(截图、OCR、DOM、Exception)进行智能诊断,结合知识库、控件画像精准识别问题类型(弹窗中断、元素变更等)。
- 闭环自愈能力: 诊断结果直接生成结构化
Action指令(如“弹窗关闭”或“定位器修复”),通过映射脚本重试,任务成功后自动更新用例库,实现“发现问题→分析问题→解决问题”的完整闭环,无需人工介入。
四、AI自愈能力构建
AI驱动的UI自动化新范式系统架构采用多层能力设计,各层职责明确、协同运作:
-
能力建设层面 提供四大核心能力,弹窗智能处理、文本自愈、元素自愈、智能等待,直接面向测试场景中的困难解决具体问题。
-
数据采集层面
- 多模态数据基线:整合APP信息、用例步骤、设备快照、OCR与DOM数据;
- 用例库管理:通过脚本映射、自愈标记实现用例智能更新,确保修复成果持续沉淀。
-
UI自愈Agent层面
- 知识库:沉淀业务知识、历史经验、弹窗特征与规则模板;
- 智能引擎:驱动弹窗分析、文本/元素变更感知等核心能力;
- 智能决策体:实现问题诊断与行动决策的闭环,是“自愈大脑”。
4.1 五步诊断法
当测试任务异常中断时,AI自愈会执行五步分层诊断流程:首先检测设备健康状态(内存/磁盘/网络/物理连接),其次验证自动化框架可用性(会话状态与驱动服务),第三步通过AI大模型融合弹窗知识库识别干扰弹窗类型智能处理,第四步利用视觉语言模型(VLM)分析页面加载状态与内容完整性,最后基于控件画像与历史基线进行多模态大模型比对,精准感知元素变更。AI自愈采用递进式决策机制,每步输出结构化修复指令(如“弹窗中断→安全关闭”、“元素变更→动态重构定位器”)。
五步诊断流程由自愈引擎服务来驱动,各层级诊断结果会输出结构化的可执行修复指令。自愈引擎服务时序图如下:
4.2 弹窗智能处理引擎
4.2.1 跨平台弹窗碎片化挑战
跨平台弹窗碎片化挑战:在Android/iOS/HarmonyOS多平台、OPPO/vivo/小米等品牌及MIUI/ColorOS等定制系统环境下,同类弹窗(如位置权限申请)呈现高度差异化的UI表现。如图所示,仅位置权限弹窗在不同设备上的按钮布局、文案表述及交互模式均存在显著差异。
Android方面,传统方案(如基于DeviceOwner权限自动授权)仅能覆盖部分场景,对厂商深度定制的Rom(隐私合规、系统通知类,OPPO系弹窗)仍存在适配盲区,iOS和Harmony方面则缺少自动授权模式。所以还有部分方案还是通过规则来匹配,但是无论我们加多少层匹配,下次执行的时候还是会出现新的问题。
4.2.2 结构化弹窗特征建模
我们的解法不再穷举模式,而是构建特征弹窗认知体系:VL大模型从视觉布局、语义关键词维度抽象弹窗本质特征,对弹窗进行多维度、语义化的归类建模(如按权限、系统通知等类型),将其泛化为可理解的结构化知识,最后输入给大模型分析并推理弹窗和决策处理。
这里列举一下常见的弹窗类型:
- 权限申请类:位置、存储、通知、电话、短信等;
- 系统通知类:系统更新、电量警告、系统推送、存储不足等;
- 隐私合规类:数据收集、隐私合规等;
- 厂商定制类:优化建议、自启动、省电模式激活等等。
暂时无法在飞书文档外展示此内容
与先前探索的传统方式比较,从“机械匹配”升级为“智能认知”处理,优势如下:
| 维度 | 枚举法 | AI智能处理 | AI优势 |
|---|---|---|---|
| 处理逻辑 | 基于固定规则匹配 | 基于语义理解与特征泛化 | 能处理未见过的弹窗变体 |
| 决策精度 | 易受UI变动影响 | 差异化处理:同意、确认、好的... | 具备鲁棒性,可以动态自适应 |
| 复用价值 | 脚本内嵌,难共享 | 平台通用能力 | 独立的数据资产 |
| 维护成本 | 需人工添加规则,线性增加 | 特征库轻量较准,微调即可 | 维护成本低 |
| 演进能力 | 静态固化 | 动态学习 | 具备知识学习能力 |
4.3 页面变化智能感知引擎
结合我们的历史数据整理分析,常见的UI变更包括:
-
文案调整类
产品为优化用户提示体验,例如,将文案从 “确定加价5元吗?” 调整为 “您确定加价 5元吗?”。从文本变更角度看,包含两处细微但典型的调整:
- 句首新增敬语“您”,提升语气友好度;
- “5元”前插入空格;
-
ID重构类
ID的重新命名和出于安全、混淆或工程规范考虑,控件 ID 的动态化也日益普遍。开发团队常将静态 ID(如
btn_confirm)替换为运行时生成的动态 ID(如btn_confirm_a6p6a8或完全移除 ID),导致传统基于resource-id或accessibility-id的定位策略彻底失效。 -
布局重构类
为提升 UI 渲染性能,开发团队常对控件布局与层级结构进行优化(如减少嵌套层级、替换容器类型等等)。然而,这类结构性调整往往导致高度依赖 DOM 路径的 XPath 定位器集体失效。
我们可以归纳页面的变化包括文本(Text)和元素(Element)调整,针对于这些UI的调整,传统的UI自动化并不能自适应,此时,需引入页面变化感知能力:基于多模态基线(截图、OCR、DOM)与控件画像(类型、层级、上下文),对 UI 变更进行结构化比对,准确识别变更性质,从而在Text、ID、 XPath 等定位器失效时,精准触发自愈修复,避免无效重试。对比方案图参考:
4.3.1 赋予控件“数字身份证”
在实践过程中,我们发现,由环境噪音等非UI变更因素导致的临时性失败,测试中断后 AI 自愈泛化后会误判,做了一些无效重试,既增加了测试时长影响效率,也拉低了整体自愈成功率。为解决这一问题,我们引入控件画像机制。控件画像是对 UI 界面中任一交互元素(如文本、按钮、输入框等)进行的多维度、结构化特征刻画,包含其内在属性(类型)、结构关系(层级)与环境上下文(周围),形成该控件的“数字身份”,在基线采集阶段,我们为用例的关键操作步骤生成对应的控件画像,作为后续变更感知与智能修复的核心依据。
控件类型:描述控件的功能类别和视觉表现,可以从控件的类名(id、Class)、功能类型(语义角色)、文本内容、视觉特征、交互的属性等维度描述,目的是为了识别“这是一个橙色的确认按钮”,而非简单的“一个id为btn_confirm”的元素。
关系上下文: 描述控件所处的页面语义与交互上下文,可以页面全文理解、业务上下文等方面描述,理解“这是隐私政策协议底部的同意按钮”,而非任意“同意”文本。
结构关系:描述控件在 UI 树中的结构位置与父子关系,可以从DOM路径、深度层级、父容器、兄弟节点、子节点等维度描述,目的是为了抗布局微调。
控件画像相较于传统定位器仅依赖单一属性,控件画像通过多维度特征融合(类型、层级、上下文),显著提升了控件识别的鲁棒性与可解释性。更为重要的是,在基于大模型的基线比对流程中,控件画像作为结构化先验知识,可以有效约束大模型输出,减少其因过度泛化而产生误判,是实现“智能但不失控”的关键机制。 如图所示,大模型在引入控件画像后的诊断结果的差异:
- 未引入控件画像 : 大模型将“专票(撮合)”泛化成类似语义的“开票”;
- 引入控件画像 : 大模型将“专票(撮合)”判定为移除。
4.3.2 文本、元素变化自愈
对于页面变化感知和自愈引擎的实现,可以简单分为三阶段流程实现对页面变化的精准感知与智能修复能力,如图所示:
- 基线构建阶段
在用例成功执行时,我们会同步采集三类数据: 通过 adb (Android)、tidevice (iOS)、hdc (HarmonyOS) 获取设备截图快照,PaddleOCR 提取页面文本内容, Appium、hdc 获取当前控件树结构。将这些多模态数据融合后,同时生成目标控件的结构化描述(即控件画像)。为降低大模型推理耗时与 tokens消耗,我们在采集过程中会对截图进行压缩和非关键区域(状态栏、导航栏)剪切,并对控件树进行冗余节点清洗。
-
变化感知阶段
-
测试中断时,相关自愈引擎启动:
- 文案引擎:结合控件画像和基线,通过VL大模型进行语义、功能、结构分析出期望文本。
- 元素引擎:结合控件画像和基线,通过大模型对当前DOM 认知,分析出期望元素。
-
多维度匹配,从三个层面验证控件一致性:
- 语义层面:语义相似度分析核心意图,判断“您确定加价 5元吗?”与“确定加价5元吗?”是否功能等价;
- 位置层面:验证控件拓扑关系,通过视觉边界和相邻节点匹配,确认控件位置变化是否和功能匹配;
- 结构层面:分析 DOM 树变化比对关键路径,识别层级重构的场景;
-
-
智能修复阶段
结合多维度匹配和推理置信度,对有效变更自动生成两种修复策略:选择器优化(调整现有定位条件)与选择器重构(生成全新定位)。
- 变更类型输出:文案优化、元素重构、布局调整;
- 定位器输出:选择器重构、健壮性优先的定位器;
- 步骤级别重试:精准定向修复,保留业务数据状态,避免重复之前的步骤。
页面变化智能感知相较于传统UI自动化执行模式对比:
| 维度 | 传统UI自动化 | 页面变化智能感知 | AI关键能力差异 |
|---|---|---|---|
| 问题应对机制 | 脚本失效即失败,依赖人工修复 | 自动介入 | AI自动生成新定位器并动态替换执行 |
| 维护成本 | 每次UI变更需人工更新定位器 | 无需人工介入 | 降低维护成本 |
| 自适应能力 | 仅支持预定义场景,无法处理未知变更 | AI自动捕获元素、文本、布局变化 | 多模态比对 + LLM语义分析,精准定位 |
| 资源效率 | 全量步骤重跑,设备资源浪费严重 | 精准步骤级重试,保留业务上下文 | 只消耗大模型推理时间 |
五、实践效果与收益
我们构建的AI自愈体系,核心价值在于突破传统UI自动化的维护瓶颈,将脚本维护模式从“人工被动响应”升级为“系统主动免疫”。自愈体系上线3个月以来,已在货拉拉移动端核心业务线验证显著成效:
| 弹窗智能处理 | 元素智能修复 | 文案智能修复 |
|---|---|---|
- 稳定性跃升:脚本平均通过率从80% 提升至90%+ ;
- 规模化验证:在325个高频执行脚本中成功实施自愈,覆盖了司机端和用户端核心路径;
- 维护效率提升:节省脚本维护同学人力40% ,可以转向高价值测试场景探索;
六、未来展望
“道阻且长,行则将至,行而不辍,未来可期”。——《荀子·修身》
面对移动端测试效能的“最后一公里”挑战,我们基于视觉大模型(VLM)技术构建自适应的新范式正逐步破解传统UI自动化测试局限的难题。这里,我们再次引用《荀子·修身》:“道阻且长,行则将至,行而不辍,未来可期”。在AI技术飞速发展的今天,我们秉持“AI增强而非替代人类”的理念,通过持续的技术创新与工程实践来提升测试效率与软件质量。接下来,AI自愈能力将持续演进:
- 从自愈到自建:智能生成自动化测试用例
当前AI自愈系在应对局部UI调整时效果显著,但对需求变更引发的交互流程重构存在能力边界。未来我们将构建用例智能生成到自愈优化的全链路闭环。
- 赋能其它智能体
提供MCP或者OpenAPI能力,手工测试用例AI执行Agent、智能下单遍历服务的接入。
- 减少成本
针对AI自愈多模态输入的高tokens消耗问题,出于成本考量,我们将通过多模态数据精简与流程优化等方面节省tokens。