之前分享过 Android 和 iOS 平台的 AI 辅助 UI 自动化方案。不少伙伴看完之后，都希望能配套鸿蒙端的实现。
鸿蒙 UI 自动化的实战落地并不简单。
相比 Android 和 iOS，鸿蒙生态下 UI 自动化相关的实战资料还不算多。经过多轮调研与踩坑验证，整理出基于 Hypium + HDC 的鸿蒙 APP UI 自动化完整实践方案。
覆盖自动化落地全链路：从前期技术调研与方案探索、脚本编码开发、用例执行与测试报告输出，再到问题定位、脚本迭代修复。希望可以给正在做鸿蒙端自动化的同学提供参考，减少重复踩坑。
为什么选择 Hypium + HDC
做鸿蒙 APP UI 自动化，绕不开两个基础能力。
Hypium 是鸿蒙生态下常用的自动化测试框架，可以用于编写和执行 UI 自动化用例。
HDC 可以理解为鸿蒙侧的设备调试工具，负责和模拟器或真机通信，例如查看设备、安装应用、拉取文件、执行命令等。
整体方案设计
这套鸿蒙 UI 自动化方案主要由 4 个 Skill 组成。
从执行链路上看，可以分成四个阶段：
1. 探索界面：启动应用，遍历关键页面，获取界面结构和截图；
2. 生成计划：根据页面信息和测试目标，整理可确认的测试计划；
3. 生成并执行代码：把计划转换为 Hypium 自动化脚本并执行；
4. 报告与修复：查看执行报告，根据失败原因进行脚本修复和重跑。
这几个阶段的边界要尽量清晰。探索阶段不要急着写代码，先把页面状态、可操作元素和业务路径搞清楚；代码生成阶段也不要一次性追求覆盖所有页面，而是先围绕核心路径生成可执行脚本；执行失败后先分析原因，再决定是否修复脚本。
完整Skill获取见文末
前置准备
在使用这套流程前，需要先准备好鸿蒙开发和运行环境，至少包括：
- DevEco Studio；
- 鸿蒙模拟器或可调试真机；
- Python 运行环境；
- Hypium 相关依赖；
- 被测应用的包名，也就是
bundle_name。。
案例实践
第一步：探索界面
探索界面是整个流程里非常关键的一步。
很多 UI 自动化脚本不稳定，问题并不在代码本身，而是在写代码之前没有充分理解页面结构。比如按钮文案是否固定、控件层级是否稳定、进入页面前是否有弹窗、同一个页面是否存在多个相似入口等。
所以在生成代码之前，先让 Skill 帮我们把页面探索清楚。
使用格式如下：
 text /hypium-expolore 包名 其他信息
下面是示例：
1. 检查执行环境
执行开始后，Skill 会先检查本地环境
2. 启动并连接模拟器
环境检查通过后，流程会尝试启动或连接鸿蒙模拟器。
3. 操作页面并获取界面信息
连接设备后，Skill 会在模拟器中操作页面元素，进入目标页面，并获取当前界面的结构信息。
4. 产出测试计划
探索完成后，会生成两个关键文件。
一个是 Markdown 文件，主要给人看。它会把探索到的页面、操作路径、测试点整理成更容易确认的内容。
另一个是 JSON 文件，内容会更结构化，主要提供给后续代码生成环节使用。
第二步：生成 Hypium 自动化代码
确认计划后，就可以进入代码生成阶段。
这一阶段会根据前面生成的计划文件、页面 dump、截图和元素信息，生成对应的 Hypium 自动化代码。
*
第三步：执行代码并查看报告
代码生成后，可以通过执行 Skill 运行用例。
执行完成后，会生成多类结果文件，例如：
日常查看时，重点看 HTML 报告即可。
报告里可以看到每条用例的执行结果、步骤日志、截图信息和失败原因。
*
第四步：失败修复与重跑
UI 自动化执行失败很常见，尤其是在移动端和鸿蒙这类环境依赖比较多的场景里。
失败后不建议直接让 AI 大范围改代码。更稳妥的方式是先看报告，判断失败类型，
确认需要修复脚本时，可以触发修复 Skill。
AI 会读取执行报告和失败日志，结合已有代码进行分析。修复后，可以只重跑失败用例，避免每次都执行全部用例。
*
小结
鸿蒙 APP UI 自动化的难点，不只是写 Hypium 脚本，而是把环境、设备、页面探索、元素信息、测试计划、代码生成、执行报告和失败修复组织成一条稳定链路。
基于 Hypium + HDC 的 Skill 方案，适合把这些重复但容易出错的环节流程化：先探索页面，再确认计划，再生成代码，最后执行和修复。
