夜雨聆风
哈喽，宝子们，做了测试这么久是不是感慨：为什么 iOS UI 自动化测试总是这么难？
熬夜写好的UI自动化脚本，第二天开发一改UI，瞬间“红”了一片；
团队里除了测试开发，没人敢碰那一坨坨复杂的XCTest代码；
排查失败原因时，来回传截图、对坐标，效率低到令人发指……
今天，我们不聊空泛的概念，直接深入一个已经被验证可行的、低成本的、由AI加持的iOS UI自动化新路径。
01
真实业务里，UI 自动化往往卡在几类问题上：
门槛高：需要熟悉 XCTest、页面抽象、CI 集成，非客户端同学很难独立推进。
维护贵：界面一改，选择器、坐标、等待逻辑跟着失效，修复成本像还技术债。
反馈慢：过度依赖截图或视觉比对时，脚本和排障都变慢，协作也不顺畅。
02
针对上述的三条痛点，有大佬探索出的解决方式是：用系统无障碍（Accessibility）能力看见界面，用命令行工具驱动模拟器；把写脚本交给 AI，把测什么、对不对交给人（其实交给AI应该也可以）。
这个思路的核心，是找到了一个比截图更稳定、比坐标更语义化的中间层——无障碍树 (Accessibility Tree)。
什么是无障碍树？ iOS系统为了服务视障用户，会将界面控件的信息（文案、标识、位置等）提取出来，形成一棵结构化的“树”。我们可以把这棵树理解为前端页面的DOM树，它是可被程序直接消费的语义化结构。
用什么工具？ 在命令行驱动模拟器这一层，目前 AXe 在易用性、功能完整性和可脚本化程度上综合表现最佳。我们的方案就是 无障碍树 + AXe。
这套组合拳，让UI自动化从“看图猜谜”变成了“结构化文本处理”，稳定性、可读性、可维护性都上了一个大台阶。
03
AI不是万能的，但用对地方，它就是神助攻。在这个方案里，AI主要在以下环节发力：
1、从“写脚本”到“描述流程”：过去，测试同学需要把“点击登录按钮 -> 输入用户名 -> 输入密码”翻译成代码。现在，你只需要用自然语言描述这个流程和验收点，AI就能结合无障碍树的结构文本，直接为你生成可执行的脚本（.steps文件或Shell脚本）。
降低的难度：不必从零掌握语法与定位细节，把翻译为可执行步骤外包给模型。
2、排障成本：默认走文本通道而非截图通道
同一类问题（例如点不到、断言失败），用文本无障碍树通常比反复传图更省、更稳：
降低的难度：排障从猜界面加大量截图对话变成结构化文本 diff，更适合日常高频使用。
3、成本结构：AI 管「写脚本、修脚本」，不管「跑脚本」
把 token 与人力集中在编写与改版修复，执行阶段不依赖模型：
降低的难度：把自动化从持续烧对话/烧图变成可沉淀的脚本资产，更容易在团队里推广。
经验法则：默认仍以 describe-ui 无障碍树为主；遇到复杂原生页、Web 页树信息不足时，再用 AXe 截图 + AI 做结果校验或反推坐标，与「只靠树或只靠人眼」相比，路径更灵活。
04
我们不鼓励一上来就造“万能框架”，而是按复杂度递进，选择最合适的编写方式：
交互模式：在终端用describe-ui看树，用tap、type命令操作，适合探索页面和快速验证想法。
批量步骤文件（.steps）：适合线性、无分支的冒烟流程。结构简单，可读性强，是AI生成脚本的绝佳格式。
Shell脚本：当需要条件判断（如果出现弹窗则关闭）、重试机制、环境变量时，再上升到Shell。你可以把高频动作封装成公共函数。
选型口诀：线性流程用.steps，条件分支上Shell。拿不准时，把需求说给AI，让它帮你选。
05
流程：打开App -> 进入资源页选择目标资源 -> 跳转到应用页使用资源 -> 截图留存。
要点：
关键路径优先使用accessibilityIdentifier或稳定的label。
异步等待处加重试或智能等待。
断言主要基于无障碍树文本，快速精准。
截图作为最终留档，对非研发人员友好。
不足之处：
任何方案都不是银弹，我们也要看到它的局限性：
仅支持模拟器：目前AXe主要面向模拟器。真机方案仍需回归XCUITest或依赖厂商的云测服务。
WebView/H5是硬骨头：内部控件通常不在无障碍树中。常用解法是坐标点击或截图+AI分析，这部分脚本更脆弱，需要额外维护。
多语言挑战：依赖文案定位会在切换语言后失效。最佳实践是推动开发为关键控件补全accessibilityIdentifier。
坐标定位不靠谱：不同机型分辨率不同，应作为最后手段，或结合比例进行动态计算。
音视频与强动画：这类场景不适合UI自动化，应通过接口或专项工具覆盖。
总结：
这套“无障碍树 + AXe + AI”的方案，本质上是在做三件事：
把“看见界面”变成文本问题：通过无障碍树，让界面变得可脚本化、可diff。
把“编写脚本”变成协作问题：通过AI，将专业技能降维成自然语言协作。
把“运行成本”控制在可持续水平：通过文本优先、按需调用AI，将成本压到最低。
给大家的小建议：不必一上来就追求构建完美的“测试金字塔”。不妨从一个模拟器上的核心端到端场景开始，用这套方法把它跑通、跑稳。
当你积累了一批可沉淀、易维护的脚本资产后，你会发现，UI自动化不再是团队的包袱，而是交付信心的加速器。
看完上述的分享，大家是不是迫不及待的想去尝试啦？
但别急，参与下方话题讨论，领取《软件测试从业红宝书职场跃迁与AI之战》书籍1本再去哦~
讨论1：在你的工作中，最让你头疼的ios UI自动化难题是什么？
讨论2：AI在UI自动化里，你觉得“写脚本”和“修脚本”哪个价值更大？
讨论3：如果让你在真实项目中做一次技术选型，你愿意尝试这套方案吗？
以上话题，任选其一，欢迎评论区留言，小编会在2026年5月11日下午，选取1位“关注+点赞+留言”的幸运用户，送出《软件测试从业红宝书“职场跃迁与AI之战”》1本，快来评论区互动吧~
文章思路参考：https://juejin.cn/post/7631066410278846516
