老实说，

在现代移动应用开发与运维中。UI 自动化测试往往成为瓶颈。团队需要面对漫长的用例迁移周期、低效的调试流程还有跨网站维护成本翻倍等痛点。AI UITester 提出一种全新的 AI 原生 UI 测试范式，真正变成可持续、可自愈、可跨网站的智能工作流。

一、为什么需要 AI Native 的 UI 测试

传统方案的三大痛点

痛点一：用例迁移成本高昂

测试用例网站积累了大量描述性用例，但不可直接执行。老实说，QA 需要逐条手动翻译：理解业务逻辑、编写元素定位、调试执行方法。一个中等规模的模块，转化成本可能需要数人天。

痛点二：调试效率低，人工介入多

用例失败后的排查流程是：看截图、对比页面、判断失败原因、修改脚本、重新执行。当失败原因为 “弹窗遮挡”“流程变更” 等非显性因素时调试成本极高。说起来，

痛点三：三端各写一套。维护成本翻倍

iOS、Android 与 HarmonyOS 的元素定位方式完全不同，UI 改版时三套脚本同步失效，导致维护难度和时间线性增长。其实，

AI Native 的解法

二、能力一：用例网站数据自动转化

问题场景

内部测试用例网站导出的 JSON 为多层树形结构。每条用例携带面包屑方法、优先级、标签等字段。说起来，以某业务模块为例。该结构包含数百个节点、上百条测试用例，最大深度十余层。传统处理方式为 QA 逐条手动翻译，上百条用例需耗费数人天。

从方法来看，自动化 Pipeline

# 网站 JSON 导出
Phase : 树结构展平 — 提取所有叶节点及面包屑方法
Phase : 用例解析 — 面包屑方法 → 结构化用例数据
Phase : 去重 — 与已有 suite 去重
Phase : LLM 提高 — 生成可执行步骤 + 注入 Wiki 知识
Phase : 持久化 — 写入配置文件
Phase : 版本归档 — 记录版本历史

主要阶段的观点是。LLM 提高

LMM 提高模块将 “描述性用例” 转化为 “可执行脚本”。输入为 Checkpoint 描述，输出是包含 App、Tap、Wait、Assertion、Swipe 等步骤类型的完整 JSON 脚本。

Prompt 工程：让 LLM 生成高质量步骤

• 步骤类型规范：
• 条件弹窗用 Action 类型； 不规范步骤降级，每个用例必须包含 App 步骤，否则校验直接报错。话说回来，
• 关键决策示例如下：
• - 条件弹窗 Action 类型;
• - 不规范步骤自动降级到校验器兜底；宁可修正也不丢弃，
• - 必须包含 App 步骤，否则校验报错。

并行提高与断点续传

• LLM 提高支持高并发处理。并实现模块级 Wiki 预加载——同一模块共享同份 Wiki 内容，避免重复调用。
• Pipeline 每个阶段完成后写入检查点文件，中断后自动跳过已完成阶段。完全失败时构造 Fallback 用例，以多级降级策略确定名称。

实际效果 / Wiki 知识库消费场景概览：

• Wiki 知识库不是独立文档集合，而是嵌入 ai_uitester 多个主要模块基础设施层："消费全景与主要原则"
• "宁缺毋滥" 原则贯穿始终——五层降级匹配确保注入 Prompt 的知识准确可靠。"

三、能力二：AI 智能调试与自愈 diff

... diff

bash
bash

bash

###

✅ 调整后的章节：

---

I – 为什么需要 AI Native 的 UI 测试

• 传统方案存在 高迁移成本 ➜ 低调试效率 ➜ 跨端维护难题。

II – 能力① — 用例网站数据自动转化

• 问题 – 用例 JSON 深层树形结构，人手翻译耗费天。
• Pipeline – 树展平 ➜ 用例解析 ➜ 去重 ➜ LLM 强化 ➜ 持久化 ➜ 历史归档。不过，
• LLM 提高 – 把自然语言描述转成可执行 JSON。
• Prompt 工程 – 步骤类型严格约束；其实，条件弹窗专属 Action；必含 App 步骤，
• 并行 & 截止 – 高并发+模块 Wiki 缓存；断电恢复，失败 Fallback。

III – 能力② — AI 智能调试与自愈

详细流程请参考前面示意图。