用 AI 降低 iOS 客户端 UI 自动化测试难度

songgeb
59 阅读6分钟

为什么 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 辅助时，自然语言 + 页面结构文本即可闭环迭代：

sequenceDiagram
    participant QA as 测试/业务
    participant AI as AI 助手
    participant SIM as 模拟器 + CLI
    QA->>AI: 用自然语言描述端到端流程与验收点
    AI->>SIM: 按需读取无障碍树（describe-ui 或等价能力）
    SIM-->>AI: 返回页面结构文本
    AI-->>QA: 交付可执行脚本（.steps / Shell 等）
    QA->>SIM: 本地执行脚本
    SIM-->>QA: 某步失败或状态不符
    QA->>AI: 反馈失败步骤 + 当前页面结构文本
    AI->>SIM: 必要时再次拉取树或调整定位策略
    AI-->>QA: 修改后的脚本
    Note over QA,SIM: 人负责测什么、怎样算对；AI负责怎么点、怎么判、怎么改

降低的难度：不必从零掌握语法与定位细节，把翻译为可执行步骤外包给模型。

排障成本：默认走文本通道而非截图通道

同一类问题（例如点不到、断言失败），用文本无障碍树通常比反复传图更省、更稳：

flowchart LR
    subgraph fail["脚本失败 / 状态异常"]
        A["失败步骤 + 上下文"]
    end

    subgraph pathText["推荐：文本路径"]
        T1["拉取无障碍树输出"]
        T2["grep / 条件分支 / 贴给 AI 分析"]
        T3["改 label / id / 等待 / 分支逻辑"]
    end

    subgraph pathImg["必要时：视觉路径"]
        I1["截图"]
        I2["人工或 AI 看布局 / H5 等"]
        I3["改坐标或视觉辅助逻辑"]
    end

    A --> T1
    T1 --> T2
    T2 --> T3
    A -.->|"仅当树不够用"| I1
    I1 --> I2
    I2 --> I3

降低的难度：排障从猜界面加大量截图对话变成结构化文本 diff，更适合日常高频使用。

成本结构：AI 管「写脚本、修脚本」，不管「跑脚本」

把 token 与人力集中在编写与改版修复，执行阶段不依赖模型：

flowchart TB
    subgraph once["一次性 / 低频"]
        W1["新流程：描述需求"]
        W2["AI 生成首版脚本"]
        W3["人确认可重复跑通"]
    end

    subgraph daily["高频：回归执行"]
        R1["CI 或本地直接跑脚本"]
        R2["零模型调用"]
    end

    subgraph rare["偶发：UI 改版"]
        U1["脚本失效"]
        U2["贴新无障碍树 + 失败信息"]
        U3["AI 小步修补"]
    end

    W1 --> W2
    W2 --> W3
    W3 --> R1
    R1 --> R2
    R1 --> U1
    U1 --> U2
    U2 --> U3
    U3 --> R1

降低的难度：把自动化从持续烧对话/烧图变成可沉淀的脚本资产，更容易在团队里推广。

经验法则：默认仍以 describe-ui 无障碍树为主；遇到复杂原生页、Web 页树信息不足时，再用 AXe 截图 + AI 做结果校验或反推坐标，与「只靠树或只靠人眼」相比，路径更灵活。

工程落地：三种编写方式怎么选

按复杂度递进，避免一上来就做大而全框架：

  1. 交互模式：在终端逐条执行看树、点击、再验，适合探索页面与验证定位。
  2. 批量步骤文件（如 .steps）：适合线性、无分支的流程，结构简单、可读性强。
  3. Shell 脚本：需要条件判断、重试、关闭弹窗、拼装环境变量时再用；可与公共函数库复用高频动作。选型建议：能线性顺序完成的用步骤文件；一旦出现如果出现某文案则、最多重试 N 次就上升到 Shell。不确定时，把业务口述给 AI，让它帮你选载体即可。

工程内案例：跨页面资源链路冒烟

该小节展示目前已经在工程中应用的案例。

辅助 QA 验证某类资源是否生效——从打开 App，进入资源相关页面并选用资源，再进入另一处资源应用页面触发使用，最终以 截图呈现结果，形成可重复结论（中途可配合 describe-ui 做关键状态断言）。

flowchart TD
    A[启动并进入 App] --> B[进入资源入口页]
    B --> C[选用目标资源]
    C --> D[进入资源应用页]
    D --> E[触发资源使用]
    E --> F[无障碍树断言关键状态]
    F --> G[截图固化结果]

落地要点：关键路径优先 accessibilityIdentifier 或稳定 label；WebView 区域用 touch 或坐标兜底；异步生效处加重试或等待；截图偏重最终留档与对非研发可读的佐证，日常仍以无障碍树文本断言为主。

不足之处

  • 仅支持模拟器（AXe） ：当前 AXe 面向模拟器；若要在真机上跑同类 UI 自动化，通常需转向 XCUITest，或评估各厂商付费真机云 / 设备农场等方案，并在证书、并发、脚本形态与成本之间做权衡。
  • WebView / H5：内部细粒度控件往往不出现在无障碍树里，常见做法是坐标触摸或截图后做像素/区域启发式分析，这类脚本更依赖评审与设备基准。
  • 多语言包：按文案定位会在语言切换后失效；更稳的是推动客户端为关键控件补齐 accessibilityIdentifier。
  • 坐标定位：不同机型逻辑分辨率不同，应作为最后手段，或结合比例计算。
  • 音视频与强动画：更适合接口层、状态层或人工探索性测试，不宜对 UI 脚本抱有过高期望。

小结

  • 用无障碍树 + AXe把看见界面变成可脚本化、可 diff 的文本问题。
  • 用 AI 把脚本编写与失效修复从专业技能降维成自然语言协作。
  • 用文本优先、控制模型介入频率把成本压到可持续的水平。若你也在做 iOS 交付质量与回归效率，可先让模拟器上的端到端跑通，再逐步资产化用例，而不是先搭一座无人维护的测试金字塔。
avatar
文章
阅读
粉丝