一个歌单场景，六个操作步骤，外包同事手动执行只要 30 秒。但你让他把这 30 秒变成一段稳定的自动化脚本——不好意思，三天之后脚本就挂了。
1. 为什么需要一个「低代码」自动化平台
6 年前部门想做 UI 自动化，但外包测试人员写不了代码。他们原本是手动测试转过来的，代码基础薄弱。如果要招有脚本能力的人，成本会提升很多，肯定不行。
不增加成本，又想把自动化跑起来，办法只有一个——做一个足够简单的自动化平台，让他们直接上手。
说一个典型的测试场景：打开音乐 App，进入歌单详情页，点击「播放全部」，选一首歌进去看详情，然后点赞，最后判断点赞有没有成功。流程不算复杂，但要把它变成一段稳定的自动化脚本，问题就一路铺开了。
团队开始从开源项目里筛选。当时看下来，Open DX 最符合这个诉求：在 Web 页面上写脚本，操作基本都是可视可读的自然语言，几乎不需要编程知识。所以选了它。
但初步调研就发现了致命问题——它不支持循环和 if-else。 偏偏这个歌单场景里到处都是循环和条件判断：遍历歌单列表找到目标歌曲，判断当前是否正在播放，进入歌曲详情后检查点赞按钮是「已赞」还是「未赞」，根据不同状态决定是跳过还是点下去。由于循环和判断条件很多是 int 类型或者复杂表达式，直接通过模板渲染不过来。
没有逻辑控制能力，能做的测试场景非常有限。没办法，只能二次开发。
2. JSON + 模板引擎：让「低代码」也能写逻辑
原项目的核心思路很简单：前端操作 → JSON → FTL 模板引擎 → TestNG 脚本 → 执行。
在这基础上，我对循环和逻辑判断做了特殊处理——在 JSON 里标记逻辑节点，解析的时候走专用模板。比如歌单场景，我专门设计了循环类型的模板和逻辑判断的模板：
- 前端调用循环，直接用对应模板将 JSON 数据渲染成循环代码
- 对每一首歌标记一个判断点赞状态的 if-else 节点
这样前端依然是「低代码」的操作界面，外包同事在页面上拖拖配置就能搭出完整流程，但底层脚本已经具备了完整的逻辑表达能力。
比起让外包人员直接写脚本，这个方案门槛低得多，而且模板化的结构也更容易维护。在那段时间里，这套 JSON + 模板引擎的方案帮我们撑住了早期的自动化需求。
3. Appium 的坑：元素定位走到死胡同
但随着深入落地，另一个问题冒了出来——Appium 的元素定位，越来越走不通了。
歌单场景就是典型：歌单列表的每一行、播放按钮、点赞图标，全是自定义控件，不是标准 Android/iOS 组件。歌词页面更不用说了，很多元素压根没有可定位的属性。
Android 端：越来越多的界面控件是自定义的，不再使用系统原生控件。这意味着大量元素无法通过属性定位。更糟的是，就连元素 ID 这种最基础的属性也靠不住——开发为了方便，用了一套自动化生成 ID 的机制，每次打包 ID 都会变。
iOS 端：也好不到哪去。元素属性本来就少，很多压根没有按可自动化的标准去写。
能覆盖的场景非常少，脚本写出来，下个版本大部分就废了。
4. 视觉定位方案：能看到的就能操作
元素定位走到死胡同，就必须换条路走。视觉定位的方案开始进入视线——既然想定位的元素没有稳定的「属性」，那就直接**「看」它在哪里。**
2022 年开始调研，两个方向：OCR 和图像识别。
OCR：文字识别定位
OCR 解决的是所有跟文字相关的元素——解析文字，定位位置，然后操作它。
回到歌单场景，歌名、歌手名、专辑名这些文字元素，OCR 天然能处理。我们选的是 PaddleOCR，百度旗下的开源方案，准确率高、速度快，模型迭代也比较积极。实际用下来，大多数场景都能稳定识别——无论是标准的白底黑字歌单列表，还是带渐变色背景的歌词页，都能正常定位。
只有在背景特别复杂、文字和图案叠在一起的时候偶尔出错，但整体在可接受范围内。
YOLO：图标/按钮识别
图像识别处理的是图标、按钮这类非文字元素。
回到歌单场景，播放全部那个三角形按钮，还有详情页的心形点赞图标，它们没有文字，OCR 无能为力。这就是 YOLO 的用武之地。我选的是当时比较新的 YOLOv5，自己训练模型来识别界面中的对应元素。
只要有足够的训练数据，准确性不成问题。但代价是只要图标有变化，或者有新场景要覆盖，就得重新训练。单次成本不高，多个版本累积下来工作量还真不少。
多模态大模型：新选项，还不够稳
到了 2026 年，多模态大模型逐渐成熟，我们又多了一个选项——直接把截图扔给大模型，用提示词描述要定位的元素，让它返回位置。
但这个方案的准确度非常依赖模型本身的能力。我们测过几家国内厂商的模型，效果还行。但受限于成本，内部能用的模型水平要低一档，有些场景还是识别不准。
歌单场景里的点赞按钮就是活生生的例子：已赞的实心心形和未赞的空心心形，同一个图标、同一个位置、同一个形状，只差一个填充状态。 大模型在这种细微差异上经常判断失误，你让它回答「这个心是空的还是实的」，它可能给了错误答案。
所以它更多是辅助方案，不能完全信任。
混合执行策略
传统定位 + OCR + YOLO + 多模态大模型——这几套方案叠在一起，基本覆盖了大部分场景。前端根据情况选择用哪种方式，混合执行。
还是以歌单为例：
| 元素 | 方案 |
|---|---|
| 歌名、歌手 | OCR |
| 播放按钮、点赞图标 | YOLO |
| 点赞状态判断 | YOLO 优先，分不清了交给大模型做备选 |
当然，就算用上了这么多技术，自动化也还是有盲区。支付账号的注销、多账号之间的交互、APP 之外的设备操作，这些就不是靠 UI 自动化能解决的了。
5. 超出预期的收获，和没躲过的坑
收获：双端用例直接复用
视觉方案最大的意外收获在于——用例具备了跨端能力。
就拿歌单这个场景来说，Android 和 iOS 的界面布局完全不同，但业务流程完全一样——进入歌单、播放、看详情、点赞。视觉定位不依赖两端各自的控件实现，一套脚本同时跑两个端，用例复用率直接翻倍。
这种思路其实还有很大的延伸空间——未来多模态大模型更成熟了，用例的编写和维护成本还能进一步降低，机器可以帮我们跑更多的用例、覆盖更广的范围。
坑：OCR 不准、截图问题、YOLO 持续训练
OCR 偶尔不准，不过随着模型迭代，准确率在慢慢提升。
频繁截图是另一个头疼的问题。视觉识别依赖截图，而对手机操作时截图频率非常高。像歌单这个场景，每一步操作前后都要截图来定位元素和验证结果，六个步骤至少十二次截图。Appium 默认的截图 API 每次调用都会反复建立连接和断开，对稳定性影响很大。这块必须做优化，不能简单套用。
YOLO 持续训练——只要 UI 有变化就得重新训练，单次便宜，长期累积成本不低。
6. 下一步
自动化平台走到现在，用例编写的投入越来越大。成本问题又变成了新的瓶颈。
AI 编码时代的到来，或许能从这里找到突破口。这也是我接下来想改造的方向——让平台从 JSON + 模板引擎，逐步向新的 AI 驱动架构转型。 下一篇细聊。
你们团队在 UI 自动化上踩过哪些坑？用了什么方案解决的？评论区聊聊。
