AI搞UI测试？这届QA终于不用再当“人形复读机”

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/HHX_01

前言

说实话，我干这行这么多年，见过最离谱的职场场景是这样的：

凌晨两点，一位 QA 同事盯着屏幕上的红色报错，嘴里念念有词：“这个按钮昨天还在左下角，今天怎么跑到右上角去了？产品经理你是不是偷偷加班了？”

旁边另一位同事头也不抬：“别问了，iOS 版的按钮在右上角，Android 版的在中间，HarmonyOS 版的…… HarmonyOS 版的按钮说你找错 App 了。”

这就是传统 UI 自动化测试的日常。不是你在测试 App，是 App 在测试你的耐心。

一、先说说那些年我们踩过的坑

1.1 用例迁移：从"人话"到"机器话"的翻译费

你们公司是不是也有个测试用例平台？那里面存了几百条、上千条用例，写得跟小说似的——“进入商品详情页，检查价格是否正常展示，向下滑动查看更多信息，点击购买按钮……”

写得挺好，人类一看就懂。

问题是机器看不懂啊。

于是 QA 的工作就变成了：把"人话"逐条翻译成"机器话"。理解业务逻辑、写元素定位、调试执行路径、改完再跑、跑完再改。一个中等模块，翻译成本数人天起步。

这让我想起大学考四六级的痛苦——明明每个单词都认识，组合在一起就是不知道该怎么写。

更惨的是，四六级考完了就完了，这翻译工作每个版本都要重新来一遍。

1.2 调试失败：找 Bug 的 Bug 比 Bug 本身还多

用例跑失败了，传统排查流程是这样的：

看截图 → 对比页面 → 判断失败原因 → 修改脚本 → 重新执行 → 又失败了 → 再看截图 → 再对比页面……

循环往复，无穷匮也。

有时候失败原因特别玄学。弹窗遮挡？流程变更？网络抖动？还是开发小哥顺手把按钮颜色从蓝色改成了绿色，导致你的 XPath 当场去世？

最绝望的是，你花了两小时排查，最后发现是测试环境的数据被人清空了。那一刻，你想的不是怎么修脚本，是怎么把清数据的人从工位上搬走。

1.3 三端维护：一个功能，三套脚本，三倍快乐

iOS、Android、HarmonyOS，三端的元素定位方式完全不同。

Android 用 resource-id，iOS 用 accessibilityLabel，HarmonyOS 用 componentId。同一个"登录"按钮，在三端的名字比我的微信昵称还多。

每次 UI 改版，三套脚本同步失效。QA 团队的工作状态就像在玩"打地鼠"——刚按下去 Android 的坑，iOS 的又冒出来了。

别人写代码是 DRY 原则（Don’t Repeat Yourself），我们写测试是 WET 原则（Write Everything Twice，或者 Thrice）。

二、AI 来了：不是辅助，是换赛道

有人说，那用 AI 辅助一下传统方案不就行了？比如用 CV 模型替代 XPath，用 NLP 理解自然语言定位。

想法很好，但本质没变——还是在"找元素、点元素"的框架里打转转。元素真没了，AI 也找不到。流程变了，AI 也懵圈。

所以得物搞了个狠的：直接换赛道。不找元素了，让 AI 像人一样"看"屏幕、"理解"页面、"决策"操作。

简单来说，以前是"盲人摸象"——靠 ID、XPath 这些"拐杖"在 DOM 树里摸来摸去。现在是"睁眼看世界"——直接截图扔给 VLM（视觉语言模型），AI 自己看、自己判断、自己点。

三、能力一：用例自动生成，QA 终于不用当翻译了

3.1 _pipeline 的魔法：从 JSON 到可执行脚本

得物内部有个测试用例平台，导出的 JSON 结构复杂得很——树形目录、面包屑路径、优先级标签，深度十几层，节点几百个。

以前 QA 得逐条手动翻译。现在？扔给自动化 Pipeline，六步走：

平台 JSON 导出 ↓ Phase 1: 树结构展平 — 提取所有叶节点及面包屑 ↓ Phase 2: 用例解析 — 面包屑 → 结构化数据 ↓ Phase 3: 去重 — 跟已有 suite 比对 ↓ Phase 4: LLM 增强 — 生成可执行步骤 + 注入 Wiki 知识 ↓ Phase 5: 持久化 — 写入配置文件 ↓ Phase 6: 版本归档 — 记录历史

整个过程多久？

展平解析去重：秒级。Wiki 预加载：数秒。LLM 增强（并行）：数十秒。持久化：秒级。

总计约一分钟。以前需要数人天的工作，现在泡杯咖啡的功夫就搞定了。QA 终于有时间去……去写更多用例？不，去摸鱼，去生活，去楼下便利店看看有没有新口味薯片。

3.2 LLM 增强：把"人话"变成"机器话"的 Prompt 艺术

核心在于 Phase 4 的 LLM 增强模块。输入是平台里的描述性用例，比如"某列表正常展示，可滑动查看更多"。

输出是什么？完整的 JSON 脚本，包含 App、Tap、Wait、Assertion、Swipe 等步骤。

但让 LLM 生成高质量步骤，Prompt 设计得很讲究。每种步骤类型都有严格的格式规范：

• **tap：**必须描述点击目标的位置和特征。好例子：“点击右上角的「确认」按钮”。坏例子：没有坏例子，因为不写清楚就直接报错。
• **swipe：**必须包含起点、终点方向和滑动区域。好例子：“从列表右侧向左滑动”。坏例子：“滑动页面”——这说了跟没说一样，AI 会一脸问号。
• **input：**必须包含输入位置和内容。好例子：“在搜索框中输入关键词”。
• **wait：**必须描述具体的视觉信号。好例子：“等待页面出现搜索框”。坏例子：“等待页面加载完成”——AI 问你，什么叫"加载完成"？是转圈消失？还是某个特定元素出现？

这就好比教一个刚入职的实习生做事。你说"去把那个弄一下"，他肯定懵。你得说"去把第三排第二个文件复印三份，然后放在老板桌上"。AI 同理，而且 AI 不会反问"哪个弄一下"，它只会给你生成一堆垃圾然后让你 debug。

3.3 断点续传：Pipeline 比我还怕从头再来

Pipeline 每个阶段完成后都会写检查点文件。中断了？没关系，下次自动跳过已完成的阶段。

LLM 增强完全失败了？系统会构造 Fallback 用例，名字通过多级降级策略确定，确保至少有个东西能跑。

这让我想起自己写论文的时候——Word 崩溃，三小时白干。如果 Word 也有断点续传，我能少掉一半头发。

3.4 Wiki 知识库：AI 的"入职培训手册"

Wiki 不是独立文档，而是嵌入系统的基础设施。五个场景都在消费它：用例增强、自愈诊断、运行时执行、技能消费、反馈闭环。

Wiki 质量直接影响三个核心指标：用例生成准确性、自愈诊断准确率、运行时知识查找频率。

Wiki 充分的时候，步骤精确，导航路径符合实际页面。Wiki 缺失的时候，LLM 只能凭猜测生成，步骤可能偏离实际——就像让一个没有地图的司机自己找路，开到哪算哪。

所以系统坚持"宁缺毋滥"原则，五层降级匹配确保注入 Prompt 的知识准确可靠。错误知识比无知识更有害——给 AI 喂假情报，后果比不给情报严重多了。

这就好比新员工入职，你给一本错误的员工手册，他能把公司当成竞争对手的公司去拜访客户。

四、能力二：AI 自愈，测试用例也会"自我疗伤"了

4.1 传统调试：一场没有尽头的循环

用例失败后的排查循环，我前面吐槽过了。但这里有个更扎心的真相：很多时候，用例失败不是因为 App 有 Bug，而是因为——UI 变了。

按钮从底部移到顶部了。文案从"下一步"改成"确认了"。中间多了一层页面。弹窗突然冒出来挡路。

在传统模式下，这些都不是 Bug，是"用例过时"。QA 得手动更新脚本，重新跑，再失败再更新，周而复始。

这就好比你每天上班走同一条路，某天市政把路牌换了，你就不会上班了。正常人不会这样，但传统测试脚本会。

4.2 AI 智能调试：失败分类 + 自动诊断

ai_uitester 内置了 AI 智能调试模式。用例跑起来是一个 while 循环，支持动态步骤变更。

步骤失败了？先过失败分类器（规则引擎）：

• 设备故障、超时、网络问题 → 自动换机或重试，不麻烦 AI。
• 业务逻辑失败 → 进入 AI 诊断。

AI 诊断的输入很豪华：带 ✓✗○ 标注的步骤 + 错误信息 + 失败截图 + Wiki 知识。输出更豪华：诊断结果 + 置信度 + 完整修复步骤 + 恢复执行的位置。

置信度 >= 阈值？自动应用修复，替换执行步骤，从恢复位置重新跑。跑通了？固化用例。又失败了？回退原用例。

置信度 < 阈值？弹出人工审核，展示步骤 diff，倒计时等你确认。超时自动拒绝。

这个置信度机制设计得很有人性——宁可漏点，不可误点。在自动化测试里，"点错位置"比"没点到"危害大得多。点错了可能把用户数据删了，没点到最多就是测试失败。AI 深谙职场生存之道：多做多错，少做少错，但不做不错在这里不适用，因为不做测试就白跑了。

4.3 五类根因诊断：AI 的"病历本"

AI 诊断能识别五类根因：

• **UI 变更：**按钮位置移动、文案变更、新增/删除元素 → 修正步骤描述。
• **流程变更：**操作顺序改变、新增中间页面 → 插入/调整步骤。
• **App Bug：**功能异常、错误提示、崩溃 → 不修复，标记为 Bug，甩锅给开发。
• **数据问题：**特定页面数据或内容不存在 → 指出数据问题，甩锅给数据组。
• **前置步骤失效：**前面步骤标记为 ✓ 但实际没产生预期效果 → 回退到更早步骤重新来。

看到没，AI 不仅会修，还会甩锅。UI 变更和流程变更，它自己修。App Bug 和数据问题，它明确标记"这不是我的锅"。前置步骤失效，它懂得"从源头解决问题"。这情商，比很多职场老油条还高。

4.4 三个真实自愈案例：AI 的"妙手回春"

案例一：按钮搬家了

原始步骤：“点击底部工具栏的某功能按钮”。结果失败了，找不到按钮。

AI 一看截图，按钮跑到页面顶部功能菜单栏去了。诊断：UI 变更，置信度 0.9。修复：“点击页面顶部功能菜单栏的对应按钮”。

这就像一个朋友问你"我钥匙放哪了"，你说"在桌上"，结果不在。AI 不是傻乎乎地继续找桌子，而是环顾四周，发现钥匙在沙发上，然后告诉你"在沙发上"。

案例二：进页面需要额外操作

原始步骤：“点击入口”。结果点击后没进入目标页面。

AI 诊断后发现，页面需要额外等待和二次点击。修复方案：在步骤后插入等待，然后重新点击。

原始：[tap] 点击入口 → 失败 修复：[tap] 点击入口 [wait] 等待目标页面加载完成 ← 新增 [tap] 再次点击入口按钮 ← 新增

这就好比你去敲门，没人开。正常人不会一直敲，而是等一会儿再敲。AI 现在也学会这个道理了。

案例三：弹窗遮挡导致后续全崩

冷启动 App 后弹出确认弹窗，遮挡了首页。后续步骤全部失效。

AI 洞察到中间步骤虽标记为 ✓，但实际未产生预期效果。诊断结果：“前置步骤失效”。执行指针回退到步骤 2，在启动 App 后插入条件 Action 处理弹窗。

这个案例最精彩。传统脚本遇到这种情况，只会一路报错到底，像多米诺骨牌一样全倒。AI 能看出来"第一张牌倒的方式不对"，然后把牌扶起来重新摆。这已经不是自动化测试了，这是自动化"擦屁股"。

4.5 置信度：AI 的"胆小心态"

系统有两条铁律：

1. MatchedText 必须从截图中逐字符复制，不允许脑补。
2. 宁可不点击，也不点错。

置信度校准锚点：1.0 精确匹配正常执行；0.8 微小差异正常执行；<= 0.5 语义相关但文本不同，拒绝执行；<= 0.2 完全没有匹配元素，拒绝执行。

0.5 的阈值怎么来的？大量实测调优的结果。阈值太高，大量操作被拒绝，执行效率低；阈值太低，误点风险上升。0.5 这个数，确保"通过即正确"的高可信度。就像相亲，宁缺毋滥，宁可单身也不能随便找个人凑合。AI 的婚恋观，比很多人都正。

五、能力三：VLM 跨平台，一套脚本打天下

5.1 截图即真理：像素级理解

ai_uitester 的核心执行模型是"截图 → 理解 → 执行"闭环。VLM 看到的是像素级截图，不是 DOM 结构。

这意味着什么？

跨平台天然统一。同一套指令，Android、iOS、HarmonyOS 都能执行。因为 AI 看的是"图"，不是"代码"。按钮在截图里长什么样，AI 就认什么样，不管底层是 Java、Swift 还是 ArkTS。

天然免疫 UI 变更。按钮移位了？AI 照样能找到，因为它看的是视觉位置，不是固定的坐标或 ID。

所见即所得。测试逻辑与人类看到的界面完全一致。人类说"点击右上角那个红色的按钮"，AI 也是这么理解的。

这就好比以前请三个翻译，分别懂英语、法语、日语。现在请了一个会看图说话的人，你给他看菜单图片，他直接告诉你点什么。简单粗暴，但有效。

5.2 统一 API：说人话就能驱动

执行引擎提供了一套统一 API，涵盖操作、断言、查询、等待等类别：

• ai_action：自然语言驱动的多步操作。比如"打开得物 App，搜索 AJ1"。
• ai_tap：单次点击。比如"点击登录按钮"。
• ai_swipe：滑动。比如"向上滑动浏览商品列表"。
• ai_assert：断言验证。比如"断言页面显示’登录成功’"。
• ai_query：从截图提取数据。比如"提取当前商品价格"。

同一条 JSON 脚本，三端通用，无需任何修改。

{"steps":[{"type":"tap","instruction":"点击底部导航栏第一个Tab「社区」"},{"type":"tap","instruction":"点击页面右上角的发布按钮"},{"type":"assertion","instruction":"断言页面出现功能入口"}]}

以前写三端测试，相当于同一个笑话要讲三遍，每次还得换方言。现在讲一遍，AI 自动翻译成各地方言。这就是技术进步带来的……摸鱼自由。

5.3 底层驱动自动选择：上层无感知

根据设备类型，系统自动选择对应的底层驱动框架：

• Android 本地 → LocalAndroidDriver（OpenATX）
• Android 云端 → AppiumAndroidDriver
• iOS 本地 → LocalIOSDriver（OpenATX + WDA）
• iOS 云端 → AppiumIOSDriver
• HarmonyOS → HosDriver（Hypium）
• Web → PlaywrightWebDriver（Chromium）

上层代码完全无感知。你写"点击登录按钮"，底层是 Android 还是 iOS，不用关心。

这就像打车。你打开 App，输入目的地，点"确认呼叫"。至于派来的是比亚迪还是特斯拉，司机是老王还是小李，你不需要知道。你只关心能不能到。这就是封装的艺术，也是偷懒的艺术。

5.4 BaseAIDriver：感知-决策的核心循环

BaseAIDriver 是全平台驱动的抽象基类，实现了核心循环：

截图 → 大模型解析 → 决策执行 → 记录日志 → 重新截图

这个循环最多执行 20 轮。点击操作配套置信度校验，查询知识库后还会强制继续运行。

Prompt 工程有四大约束：

1. 每次只做一个动作。每步操作后屏幕状态变化，逐步执行确保每步决策基于最新画面。
2. 元素匹配严格规则。MatchedText 必须从截图逐字符复制，Confidence <= 0.5 返回 Action: Null。
3. 高优先级知识自动注入。弹窗、权限、登录页等无需在用例中显式编写，VLM 自动处理。
4. 平台差异化适配。Prompt 根据平台自动切换系统操作指令，上层代码无感知。

20 轮上限怎么来的？怕 AI 陷入死循环，像某些人一样在 App 里转来转去找不到出口。强制继续运行是为了防止 AI 查完 Wiki 就偷懒不干活。这些约束设计得很像管理一个聪明但有点懒的员工——给他明确目标，设定时间限制，检查工作质量，还不能让他摸鱼。

六、架构设计的灵魂拷问

6.1 为什么"逐步执行"而不是"一次规划"？

UI 测试的核心挑战是状态不确定性。每步操作后屏幕都会变，预先规划可能基于过时信息。

代价是单次操作可能多轮 LLM 调用（最多 20 轮）。但通过深度思考子目标分解来平衡。

这就像下棋。你不能开局就把所有步数想好，因为对手每走一步，局面都变了。AI 测试也一样，App 每响应一次，下一步的判断基础就变了。所以得走一步看一步，而不是闭着眼睛冲。

6.2 为什么置信度阈值是 0.5？

大量实测调优的结果。在准确率和覆盖率之间取得平衡。

阈值太高，大量操作被拒绝，执行效率低。阈值太低，误点风险上升。

0.5 确保"通过即正确"的高可信度。

这个数值背后，是无数测试用例的血泪史。就像你设手机密码，太简单容易被破解，太复杂自己记不住。0.5 就是那个"既安全又能记住"的甜蜜点。

6.3 为什么自愈返回完整步骤列表而不是增量 Diff？

增量 Diff 在多次修复后索引容易偏移。完整列表更直观可靠。

Token 消耗更大，但避免了"修复引入新 Bug"。

这就像装修。你是愿意要一份完整的施工图纸，还是只给你看"改了哪几块砖"？完整图纸费纸，但靠谱。局部修改省纸，但容易把承重墙拆了。

七、行业对比：三条路线的殊途同归

7.1 传统方案：Appium / Selenium / XCUITest

基于元素定位，通过 ID、XPath、Accessibility ID 等找元素，再执行操作。

优势：执行速度快（毫秒级），社区成熟，CI/CD 集成完善。

劣势：跨平台重复建设，UI 变更即失效，维护成本线性增长，无自愈能力。

这就好比用地图导航。地图准的时候很快，但地图一过期，你就得下车问路。而且每个城市的地图还不一样，你得出差带三张地图。

7.2 AI 辅助方案：Test.ai / Applitools

在传统框架上叠 AI。要么用 CV/NLP 替代硬编码定位器，要么用 VLM 对比截图 Diff 做视觉回归。

优势：降低定位器维护成本，自然语言可读性好，视觉回归能发现传统断言遗漏的问题。

劣势：本质仍是元素定位，跨平台仍需适配，自愈仅限于重定位（按钮从底部移到顶部能找到，但交互流程变了就没办法），无业务理解。

这就像给自行车装了个电动马达。确实省力了，但遇到墙该撞还是撞。AI 辅助方案能帮你找元素，但理解不了"为什么这个步骤失败了"。

7.3 AI Native 方案：ai_uitester

以 VLM 为执行引擎，"截图→理解→执行"闭环替代元素定位。VLM 不仅识别 UI 元素，还理解页面语义、业务流程和上下文。知识库将业务规则与测试执行解耦。

这就不是给自行车装马达了，这是直接换了一辆自动驾驶汽车。你告诉他去哪，他看路、理解路况、自己做决策。你甚至可以在后座睡一觉——当然，目前还不建议真睡，毕竟置信度阈值才 0.5。

八、写在最后

AI Native 的 UI 自动化测试，不是"让 AI 帮忙写 XPath"，而是"让 AI 像人一样看屏幕、理解业务、做出决策"。

它解决了传统测试的三个核心痛点：用例迁移成本高、调试效率低、三端维护成本翻倍。通过 VLM 视觉理解、LLM 智能生成、Wiki 知识库、自愈诊断等能力，把 QA 从"人形复读机"和"人肉翻译器"的困境中解放出来。

当然，这不是说 QA 要失业了。相反，QA 可以把精力放在更有价值的事情上——设计测试策略、分析业务风险、优化用户体验。让 AI 做重复劳动，让人做创造性工作。

毕竟，AI 能看截图、能点按钮、能修脚本，但 AI 不会在产品上线前夜，一边吃着泡面一边跟开发说："这个 Bug 必须修，不修我不签字。"这种职场魄力，暂时还是人类专属。

技术的终极目标不是取代人，而是让人更像人。
—— 一个刚被 AI 抢了翻译饭碗、但获得了摸鱼自由的 QA 如是说。

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/HHX_01