为什么 iOS UI 自动化仍然难
在真实业务里，UI 自动化往往卡在几类问题上：
- 门槛高：需要熟悉 XCTest、页面抽象、CI 集成，非客户端同学很难独立推进。
- 维护贵：界面一改，选择器、坐标、等待逻辑跟着失效，修复成本像还技术债。
- 反馈慢：过度依赖截图或视觉比对时，脚本和排障都变慢，协作也不顺畅。
近期探索方向是：用系统无障碍（Accessibility）能力看见界面，用 命令行工具 驱动模拟器；把写脚本交给 AI，把测什么、对不对交给人（其实交给AI应该也可以）。
这样可以把自动化从少数工程师专属（如测试开发岗位）拉回到测试与交付都能参与的节奏里。
核心思路：无障碍树 + AXe
iOS 为视障用户暴露的无障碍信息，会在系统侧形成一棵无障碍树：控件文案、（若开发配置）唯一标识、大致几何信息都可以被读取。类比前端：界面是渲染结果，无障碍树更接近可被程序消费的语义结构。
在命令行驱动模拟器这一层，目前AXe 在易用性、能力完整度和可脚本化程度上综合表现最好，因此方案明确为 无障碍树 + AXe：
- 用 AXe 读取无障碍树、点击、输入、手势、截图等，再配合 Shell 或步骤文件做编排。
- 脚本层负责稳定可重复的执行；
- 人 + AI 负责把业务语言翻译成脚本，并在失效时快速迭代。
AI 具体降低了哪些难度
除下文分条说明外，这里想单独强调 一点：编写与排障时，describe-ui 拉起的无障碍树 仍是最快、成本最低 的定位与断言手段；但在结构复杂 的原生页面，或 WebView / H5 等无障碍信息不完整、控件不可见的场景里，完全可以把 AXe 截屏交给 AI 分析 ------既可用于结果校验 （布局是否异常、关键视觉元素是否出现），也可在 AI 协助下从画面反推点击坐标 / 热区 ，再固化为 touch、像素级辅助脚本等步骤。相比过去「只能死磕无障碍树或完全依赖人工看图写坐标」的传统做法，可选路径更多：树优先、截图与 AI 作补充；人工判断与模型辅助看图可以组合使用，而不必二选一。
从写脚本到描述流程：协作时序
传统模式下，测试同学往往要先补编程与框架知识；AI 辅助时，自然语言 + 页面结构文本即可闭环迭代：
降低的难度：不必从零掌握语法与定位细节，把翻译为可执行步骤外包给模型。
排障成本：默认走文本通道而非截图通道
同一类问题（例如点不到、断言失败），用文本无障碍树通常比反复传图更省、更稳：
降低的难度：排障从猜界面加大量截图对话变成结构化文本 diff，更适合日常高频使用。
成本结构：AI 管「写脚本、修脚本」，不管「跑脚本」
把 token 与人力集中在编写与改版修复，执行阶段不依赖模型：
降低的难度：把自动化从持续烧对话/烧图变成可沉淀的脚本资产，更容易在团队里推广。
经验法则：默认仍以 describe-ui 无障碍树为主；遇到复杂原生页、Web 页树信息不足时，再用 AXe 截图 + AI 做结果校验或反推坐标，与「只靠树或只靠人眼」相比，路径更灵活。
工程落地：三种编写方式怎么选
按复杂度递进，避免一上来就做大而全框架：
- 交互模式：在终端逐条执行看树、点击、再验，适合探索页面与验证定位。
- 批量步骤文件 （如
.steps）：适合线性、无分支的流程，结构简单、可读性强。 - Shell 脚本 ：需要条件判断、重试、关闭弹窗、拼装环境变量时再用；可与公共函数库复用高频动作。选型建议：能线性顺序完成的用步骤文件；一旦出现如果出现某文案则、最多重试 N 次就上升到 Shell。不确定时，把业务口述给 AI，让它帮你选载体即可。
工程内案例：跨页面资源链路冒烟
该小节展示目前已经在工程中应用的案例。
辅助 QA 验证某类资源是否生效 ------从打开 App，进入资源相关页面并选用资源 ，再进入另一处资源应用 页面触发使用 ，最终以 截图 呈现结果，形成可重复结论（中途可配合 describe-ui 做关键状态断言）。
落地要点 ：关键路径优先 accessibilityIdentifier 或稳定 label；WebView 区域用 touch 或坐标兜底；异步生效处加重试或等待；截图偏重最终留档与对非研发可读的佐证，日常仍以无障碍树文本断言为主。
不足之处
- 仅支持模拟器（AXe） ：当前 AXe 面向模拟器；若要在真机 上跑同类 UI 自动化，通常需转向 XCUITest ，或评估各厂商付费真机云 / 设备农场等方案，并在证书、并发、脚本形态与成本之间做权衡。
- WebView / H5：内部细粒度控件往往不出现在无障碍树里，常见做法是坐标触摸或截图后做像素/区域启发式分析，这类脚本更依赖评审与设备基准。
- 多语言包 ：按文案定位会在语言切换后失效；更稳的是推动客户端为关键控件补齐 accessibilityIdentifier。
- 坐标定位：不同机型逻辑分辨率不同，应作为最后手段，或结合比例计算。
- 音视频与强动画：更适合接口层、状态层或人工探索性测试，不宜对 UI 脚本抱有过高期望。
小结
- 用无障碍树 + AXe把看见界面变成可脚本化、可 diff 的文本问题。
- 用 AI 把脚本编写与失效修复从专业技能降维成自然语言协作。
- 用文本优先、控制模型介入频率把成本压到可持续的水平。若你也在做 iOS 交付质量与回归效率，可先让模拟器上的端到端跑通，再逐步资产化用例，而不是先搭一座无人维护的测试金字塔。