一、背景与挑战

在移动端测试这个领域，有一个问题始终困扰着所有团队：怎样才能持续降低手工测试的工作量？围绕这个核心目标，我们的团队已经搭建了两条行之有效的创新路径：

1. 在老功能的回归测试上，我们用UI录制回放技术，彻底碘伏了传统手写脚本的模式。简单说，就是实现脚本的“零代码”生成和大规模覆盖，从根上解决了自动化普及难的问题。
2. 在新功能测试上，我们推出了多机同步模式，绕开了传统脚本的局限，做到“一端操作、多端覆盖”，有效缓解了多机型、多端口带来的效率瓶颈。

基于这些实践，我们逐步构建起货拉拉移动端测试的提效体系。但现实总是充满挑战——效率提升的红利正在触及天花板，新的难题又浮出水面：

• 自动化测试依然需要“人工维护”。当脚本规模超过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大模型融合弹窗知识库，识别干扰弹窗类型并智能处理；第四步利用视觉语言模型分析页面加载状态与内容完整性；最后基于控件画像与历史基线进行多模态大模型比对，精准感知元素变更。整个流程采用递进式决策机制，每一步都会输出结构化的修复指令（比如“弹窗中断→安全关闭”、“元素变更→动态重构定位器”）。

五步诊断流程由自愈引擎服务来驱动，各层级诊断结果会输出结构化的可执行修复指令。自愈引擎服务的时序图如下：

4.2 弹窗智能处理引擎

4.2.1 跨平台弹窗碎片化挑战

跨平台弹窗碎片化是个大的麻烦。在Android、iOS、HarmonyOS多平台，加上OPPO、vivo、小米等品牌及其定制系统（MIUI、ColorOS等），同类弹窗（比如位置权限申请）呈现出高度差异化的UI表现。来看下图，仅仅是位置权限弹窗，在不同设备上的按钮布局、文案表述和交互模式就存在明显差异。

Android方面，传统方案（比如基于DeviceOwner权限自动授权）只能覆盖部分场景，面对厂商深度定制的Rom（隐私合规、系统通知类，尤其是OPPO系弹窗），依然存在适配盲区。iOS和Harmony方面则缺少自动授权模式。所以目前还有部分方案靠规则来匹配，但无论加多少层规则，下次执行时总会冒出新的问题。

4.2.2 结构化弹窗特征建模

我们的解法不是继续做穷举，而是构建特征弹窗认知体系：VL大模型从视觉布局、语义关键词等维度抽象出弹窗的本质特征，对弹窗进行多维度、语义化的归类建模（比如按权限、系统通知等类型），将其泛化为可理解的结构化知识，最后交给大模型分析并推理出弹窗的类型和决策处理方式。

这里列举常见的弹窗类型：

1. 权限申请类：位置、存储、通知、电话、信息等；
2. 系统通知类：系统更新、电量警告、系统推送、存储不足等；
3. 隐私合规类：数据收集、隐私合规等；
4. 厂商定制类：优化建议、自启动、省电模式激活等。

与传统的枚举法相比，这次升级是从“机械匹配”到“智能认知”的质变，优势非常明显：

4.3 页面变化智能感知引擎

从历史数据来看，常见的UI变更可以归纳为几类：

• 文案调整类。比如产品为了优化用户提示体验，将“确定加价5元吗?”调整为“您确定加价 5元吗?”。从文本变更角度看，包含两处微小但典型的调整：句首新增敬语“您”，以及“5元”前插入空格。

• ID重构类。出于安全、混淆或工程规范考虑，控件ID的动态化越来越普遍。开发团队常将静态ID（如btn_confirm）替换为运行时生成的动态ID（如btn_confirm_a6p6a8，甚至完全移除ID），导致传统的resource-id或accessibility-id定位策略彻底失效。

• 布局重构类。为提升UI渲染性能，开发团队常对控件布局与层级结构进行优化（比如减少嵌套层级、替换容器类型等）。这类结构性调整往往会导致高度依赖DOM路径的XPath定位器集体失效。

总结一下，页面变化包括文本和元素的调整。传统的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获取当前控件树结构。将这些多模态数据融合后，生成目标控件的结构化描述（即控件画像）。为降低大模型推理耗时与Token消耗，我们在采集过程中会对截图进行压缩和非关键区域（状态栏、导航栏）剪切，并对控件树进行冗余节点清洗。

• 变化感知阶段。测试中断时，相关自愈引擎启动：

  • 文案引擎：结合控件画像和基线，通过VL大模型进行语义、功能、结构分析，得出期望文本。
  • 元素引擎：结合控件画像和基线，通过大模型对当前DOM的认知，分析出期望元素。

  随后进行多维度匹配，从三个层面验证控件一致性：

  • 语义层面：语义相似度分析核心意图，判断“您确定加价 5元吗?”与“确定加价5元吗?”是否功能等价；
  • 位置层面：验证控件拓扑关系，通过视觉边界和相邻节点匹配，确认控件位置变化是否与功能匹配；
  • 结构层面：分析DOM树变化比对关键路径，识别层级重构的场景。

• 智能修复阶段。结合多维度匹配和推理置信度，对有效变更自动生成两种修复策略：选择器优化（调整现有定位条件）与选择器重构（生成全新定位）。

  • 变更类型输出：文案优化、元素重构、布局调整；
  • 定位器输出：选择器重构、健壮性优先的定位器；
  • 步骤级别重试：精准定向修复，保留业务数据状态，避免重复之前的步骤。

页面变化智能感知与传统UI自动化的执行模式对比：

五、实践效果与收益

我们构建的AI自愈体系，核心价值在于突破传统UI自动化的维护瓶颈，将脚本维护模式从“人工被动响应”升级为“系统主动免疫”。自愈体系上线3个月以来，已在货拉拉移动端核心业务线验证了显著成效：

• 稳定性跃升：脚本平均通过率从80%提升至90%以上；
• 规模化验证：在325个高频执行脚本中成功实施自愈，覆盖了司机端和用户端的核心路径；
• 维护效率提升：节省脚本维护人力40%，让团队可以转向更高价值的测试场景探索。

六、未来展望

面对移动端测试效能的“最后一公里”挑战，我们基于视觉大模型技术构建的自适应新范式，正在逐步破解传统UI自动化测试的局限。这里想借用《荀子·修身》中的一句话：“道阻且长，行则将至，行而不辍，未来可期”。在AI技术飞速发展的今天，我们秉持“AI增强而非替代人类”的理念，通过持续的技术创新与工程实践来提升测试效率与软件质量。接下来，AI自愈能力将持续演进：

• 从自愈到自建：智能生成自动化测试用例。当前AI自愈系统在应对局部UI调整时效果显著，但对需求变更引发的交互流程重构，还存在能力边界。未来我们将构建从用例智能生成到自愈优化的全链路闭环。
• 赋能其他智能体。提供MCP或OpenAPI能力，让手工测试用例AI执行Agent、智能下单遍历服务等都能接入。
• 减少成本。针对AI自愈多模态输入的高Token消耗问题，出于成本考量，我们将通过多模态数据精简与流程优化等方式来节省Token。