一、为什么需要 AI Native 的 UI 测试传统方案的三大痛点痛点一用例迁移成本高昂测试用例平台积累了大量描述性用例但不可直接执行。QA 需要逐条手动翻译理解业务逻辑、编写元素定位、调试执行路径。一个中等规模的模块转化成本可能需要数人天。痛点二调试效率低人工介入多用例失败后的排查流程是看截图、对比页面、判断失败原因、修改脚本、重新执行。当失败原因为 “弹窗遮挡”“流程变更” 等非显性因素时调试成本极高。痛点三三端各写一套维护成本翻倍iOS、Android、HarmonyOS 的元素定位方式完全不同UI 改版时三套脚本同步失效。AI Native 的解法二、能力一用例平台数据自动转化问题场景内部测试用例平台导出的 JSON 为多层树形结构目录节点 用例节点每条用例携带面包屑路径、优先级、标签等字段。以某业务模块为例该结构包含数百个节点、上百条测试用例最大深度十余层。传统处理方式为 QA 逐条手动翻译完成上百条用例的转化需耗费数人天。解决方案自动化 Pipelineai_uitester 设计了自动化 Pipeline将用例平台 JSON 自动转化为可执行脚本。平台 JSON 导出 ↓ Phase 1: 树结构展平 — 提取所有叶节点及面包屑路径 ↓ Phase 2: 用例解析 — 面包屑路径 → 结构化用例数据 ↓ Phase 3: 去重 — 与已有 suite 去重 ↓ Phase 4: LLM 增强 — 生成可执行步骤 注入 Wiki 知识 ↓ Phase 5: 持久化 — 写入配置文件 ↓ Phase 6: 版本归档 — 记录版本历史核心阶段LLM 增强LLM 增强模块将 “描述性用例” 转化为 “可执行脚本”。输入为用例平台的 Checkpoint 描述如 “某列表正常展示可滑动查看更多”输出是包含 App、Tap、Wait、Assertion、Swipe 等步骤类型的完整 JSON 脚本。Prompt 工程让 LLM 生成高质量步骤StepGenerator 使用精心设计的 Prompt关键约束包括步骤类型规范每种类型有严格的 Instruction 格式关键设计决策条件弹窗用 Action 类型弹窗存在时处理不存在时自动跳过不规范步骤自动降级校验器兜底宁可修正也不丢弃每个用例必须包含 App 步骤否则校验直接报错。并行增强与断点续传LLM 增强支持高并发处理并实现模块级 Wiki 预加载 —— 同一模块的用例共享同一份 Wiki 内容避免重复调用。Pipeline 每个阶段完成后写入检查点文件中断后自动跳过已完成阶段。增强完全失败时构造 Fallback 用例名称通过多级降级策略确定。实际效果Wiki 知识库消费全景与核心原则Wiki 知识库不是独立文档集合而是嵌入 ai_uitester 多个核心模块的基础设施层。它被 5 大场景消费用例增强阶段将 Wiki 知识注入用例生成使生成步骤更精确自愈诊断阶段按模块加载 Wiki辅助 LLM 区分 “UI 变更” 和 “用例描述错误”运行时执行阶段每次操作时注入索引LLM 遇到盲区时按需加载对应页面技能消费多个下游技能读取 Wiki 作为背景知识反馈闭环每次执行后记录查找日志持续优化匹配策略。Wiki 质量直接影响三个核心指标“宁缺毋滥” 原则贯穿始终 —— 五层降级匹配精确匹配 → 去除优先级后缀 → 去除括号 → LLM 语义匹配 → 跳过并缓存确保注入 Prompt 的知识准确可靠错误知识比无知识更有害。三、能力二AI 智能调试与用例自愈传统调试的困境用例失败后的排查循环失败 → 看截图 → 判断原因 → 修改脚本 → 重新执行 → 又失败 → ……一个用例可能要调试多次才能通过。AI 智能调试模式ai_uitester 内置了 AI 智能调试模式实现自动诊断和自愈修复用例执行while 循环支持动态步骤变更 ↓ 步骤失败 失败分类器规则引擎 ├─ device / timeout / network → 自动换机或重试 └─ business → 进入 AI 诊断 ↓ AI 诊断VLM ├─ 输入✓✗○ 标注的步骤 错误信息 失败截图 Wiki 知识 └─ 输出diagnosis confidence complete_steps resume_from_index ↓ ┌──────────────────────────────────────────────┐ │ 置信度 阈值 │ 置信度 阈值 │ │ → 自动应用修复 │ → 弹出人工审核 │ │ → 替换执行步骤 │ → 展示步骤 diff │ │ → 从 resume_from_index │ → 超时倒计时 │ │ 重新执行 │ → Accept/Reject │ │ → 执行通过 → 固化用例 │ → 超时自动 Reject│ │ → 执行失败 → 回退原用例 │ │ └──────────────────────────────────────────────┘失败分类器先过滤再诊断不是所有失败都需要 AI 诊断。系统通过规则引擎过滤设备故障、超时、网络问题等非业务失败自动重试只有业务逻辑失败才进入 AI 诊断流程。五类根因诊断三个真实自愈案例案例一UI 变更 — 功能按钮位置移动Confidence: 0.9原始[tap] 点击底部工具栏的某功能按钮 → 失败找不到按钮 修复[tap] 点击页面顶部功能菜单栏的对应按钮案例二UI 变更 — 进入页面需要额外操作Confidence: 0.8原始[tap] 点击入口 → 失败点击后未进入目标页面 修复在步骤后插入等待然后重新点击 [tap] 点击入口 [wait] 等待目标页面加载完成 ← 新增 [tap] 再次点击入口按钮 ← 新增案例三前置步骤失效 — 弹窗遮挡导致后续步骤全部失效Confidence: 0.9冷启动 App 后弹出确认弹窗遮挡了首页。AI 诊断洞察到中间步骤虽标记为 ✓ 但实际未产生预期效果诊断结果为 “前置步骤失效”将执行指针回退到步骤 2并在启动 App 后插入条件 Action 处理弹窗。置信度机制宁可漏点不可误点在自动化测试中“点错位置” 比 “没有点” 危害大得多。置信度校准锚点两条铁律(1) MatchedText 必须从截图中逐字符复制不允许脑补(2) 宁可不点击也不点错。四、能力三VLM 驱动的跨平台统一VLM 方案的革命性ai_uitester 的核心执行模型是 “截图 → 理解 → 执行” 闭环。VLM 看到的是像素级截图而非 DOM 结构。这意味着跨平台天然统一同一套指令三端通用、天然免疫 UI 变更按钮移位照样能找到、所见即所得测试逻辑与人类看到的界面完全一致。统一 API 接口执行引擎提供涵盖操作、断言、查询、等待等类别的统一 API屏蔽底层平台差异。同一条 JSON 脚本在 Android、iOS、HarmonyOS 上都能执行无需任何修改。底层驱动自动选择根据设备类型自动选择对应的底层驱动框架上层代码完全无感知。核心执行引擎BaseAIDriverBaseAIDriver 作为全平台驱动的抽象基类实现了 “截图→大模型解析→决策执行→记录日志→重新截图” 的感知-决策核心循环该循环最多执行 20 轮点击操作配套置信度校验机制查询知识库后还会强制继续运行。Prompt 工程的四大约束约束一每次只做一个动作。每步操作后屏幕状态变化逐步执行确保每步决策基于最新画面。约束二元素匹配的严格规则。MatchedText 必须从截图逐字符复制Confidence 0.5 时必须返回 Action: Null。约束三高优先级知识自动注入。弹窗、权限、登录页等无需在用例中显式编写VLM 自动处理。约束四平台差异化适配。Prompt 根据平台自动切换系统操作指令上层代码无感知。深度思考模式开启深度思考模式后模型获得子目标分解、进度跟踪✓/→/○ 可视化、前后截图对比三项能力适用于复杂业务流程。五、架构设计取舍为什么 “逐步执行” 而非 “一次规划”UI 测试的核心挑战是状态不确定性 —— 每步操作后屏幕变化预先规划可能基于过时信息。代价是单次操作可能多轮 LLM 调用最多 20 轮通过深度思考子目标分解来平衡。为什么置信度阈值设为0.5经过大量实测调优在准确率和覆盖率之间取得平衡 —— 阈值过高则大量操作被拒绝、执行效率低阈值过低则误点风险上升。当前阈值确保 “通过即正确” 的高可信度。为什么自愈返回完整步骤列表而非增量 Diff增量 Diff 在多次修复后索引容易偏移完整列表更直观可靠。Token 消耗更大但避免了 “修复引入新 Bug”。六、行业对比为什么是新范式目前业界 UI 自动化测试主要有三条技术路线我们从核心技术栈、跨平台能力、维护成本、自愈能力四个维度做一次系统对比。传统方案Appium / Selenium / XCUITest核心原理基于元素定位 —— 通过 ID、XPath、Accessibility ID、Class Name 等定位器找到 UI 元素再执行 Click/Input/Swipe 等操作。底层通过各平台的 Accessibility API 或 UIAutomator 获取 View Tree/DOM 结构。典型代码# AndroidAppium driver.find_element(By.ID, com.example.app:id/btn_login).click() # iOSXCUITest app.buttons[登录].tap() # HarmonyOSHypium driver.find_component(登录).click()优势执行速度快单步操作毫秒级社区成熟CI/CD 集成方案完善断言能力丰富。劣势跨平台重复建设同一功能三套脚本三套定位器。一个按钮Android 用 resource-idiOS 用 accessibilityLabelHarmonyOS 用 componentId三端定位器完全不同UI 变更即失效按钮文案从 “下一步” 改为 “确认”定位器失效页面改版增加一层嵌套XPath 断裂。一个中等规模 App 每次版本迭代约 15-30% 的用例需要修改维护成本线性增长用例数越多维护成本越高。大规模用例集的回归一次 UI 改版可能需要数周的修复时间无自愈能力失败即停需要人工介入判断原因并修改脚本。AI 辅助方案Test.ai / Applitools核心原理该方案在传统自动化框架基础上叠加 AI 能力主要分为两大实现方向。 AI 元素定位Test.ai依靠 CV 或 NLP 模型替代硬编码的 ID/XPath可通过截图区域视觉特征匹配元素或是以自然语言描述替代定位器 AI 视觉对比Applitools借助 VLM 对比截图 Diff自动判断 “是否视觉回归”但不会替代底层执行引擎。优势降低了定位器维护成本自然语言描述比 ID 更具可读性视觉回归测试能发现传统断言遗漏的 UI 问题。劣势本质仍是元素定位虽然用 AI 做了柔性匹配但执行模型没变——仍然需要找到元素、点击元素。当元素不存在UI 真的变了AI 定位也找不到跨平台仍需适配Android 和 iOS 的截图分辨率、字体渲染、组件样式不同AI 模型需要平台特异性的训练或适配自愈仅限于重定位如果按钮从底部移到顶部AI 定位能找到它但如果交互流程变了新增中间页面、操作顺序改变AI 定位毫无办法。这是元素级自愈不是流程级自愈无业务理解不知道业务规则不知道为什么某个步骤失败只能报告找不到元素。AI Native 方案本文 ai_uitester核心原理以 VLM 为执行引擎以 “截图→理解→执行” 闭环替代元素定位。VLM 不仅识别 UI 元素还理解页面语义、业务流程和上下文。知识库Wiki将业务规则与测试执行解耦。典型代码{ steps: [ {type: tap, instruction: 点击底部导航栏第一个Tab「社区」}, {type: tap, instruction: 点击页面右上角的发布按钮}, {type: assertion, instruction: 断言页面出现功能入口} ] }同一段 JSON 脚本Android、iOS、HarmonyOS 三端通用无需任何修改。与传统方案和 AI 辅助方案的核心差异三条路线的演进关系三者的关系不是替代而是能力维度的跃迁传统方案Appium └─ 解决能不能测 → 提供基础执行能力 └─ AI 辅助方案Test.ai └─ 优化好不好测 → 降低定位器维护成本 └─ AI Native 方案ai_uitester └─ 重新定义谁来测 → 从人驱动变为 AI 驱动关键差异一句话总结传统方案和 AI 辅助方案的假设是 “UI 不变”所以需要人维护定位器AI Native 方案的假设是 “UI 一定会变”所以让 AI 理解变化并适应变化。这是测试哲学的根本转变 —— 从 “抵抗变化” 到 “拥抱变化”。七、业务成果数据ai_uitester 在得物 App 客户端测试中已落地运行核心指标如下核心效率指标质量提升指标注自愈成功率受知识库质量和执行场景影响复杂流程变更仍需人工确认。以上数据基于多个核心业务模块的实测均值。八、总结ai_uitester 代表了 AI Native 的 UI 自动化测试新范式这不仅是工具的升级而是测试范式的转变 —— 从 “代码驱动” 转向 “视觉驱动”从 “人工调试” 转向 “AI 自愈”从 “三端分离” 转向 “统一抽象”。Wiki 知识库的闭环设计确保了这不是一次性工具而是越用越智能的测试基础设施。往期回顾1.从狂野代码到按目标生产得物推荐 AI Harness 的工程化实践AICon 演讲整理2.从表单到 Agent得物社区活动搭建的 AI 实践之路3.从埋点需求到规则资产Hermes Agent 重构得物数仓工作流4.让 Claude Code 拥有自我进化和记忆系统得物技术5.用 LLM Agent 重构告警排查流程得物技术文 / 林霖关注得物技术每周更新技术干货要是觉得文章对你有帮助的话欢迎评论转发点赞未经得物技术许可严禁转载否则依法追究法律责任。