上个月一个做 App 测试的朋友来找我，说他手上那套 Appium 用例又集体挂了。
不是用例逻辑错了。是版本一更新，十几个页面的元素定位全变了，他要挨个去查哪个按钮的 id 改了、哪个列表的层级动了。他花了整整两天，最后改完发现还有两条是红的，原因是等待时间不够——页面加载慢了两秒。
他说了一句挺实在的话：写用例花的时间，大概只有维护的三分之一。
这不是他一个人的问题。如果你的团队也在做真机自动化，下面这套对比可能对你有用。
先说清楚 Appium 的消耗到底在哪
Appium 本身没问题，它是行业标准，文档全、社区大、能力强。问题出在它的工作方式上。
它的核心是元素定位：通过控件的 id、class 或者 xpath 找到目标，再对它操作。这条路精确、可断言，工程化程度高。代价是——它依赖界面的结构。
具体来说，有几件事会反复消耗你的时间：
| 消耗点 | 具体表现 |
|---|---|
| 环境维护 | 手机、驱动、Appium Server、客户端库版本要配套，换台机器就得重配一遍 |
| 元素定位失效 | 界面一改版，原来靠层级或绝对路径定位的用例就找不到元素 |
| 等待时间调不准 | 加载快的机器两秒够，慢的机器五秒才出来，写死哪边都有问题 |
| 定位到但操作不到 | 元素在 DOM 里存在，但被遮挡、没进入可点击状态，点击照样失败 |
| 设备分散 | 十几台真机各自连着电脑，哪台掉线、哪台被占用，管理起来又是一摊事 |
复杂业务系统的自动化测试，这些成本是值得的——它换来的是可断言、可集成、可沉淀。但如果你的场景只是「把某个固定流程在真机上重复跑一遍」，这套成本就显得重了。
另一条路是「看懂屏幕」，不是找元素
另一条路线不找元素，而是看懂屏幕。
做法是截图，识别屏幕上的文字和图像，判断当前在哪个界面，再决定点哪里。技术上靠视觉模型（VLM）和 OCR 配合。它不需要控件树，因此也不关心 id 有没有变。
| 对比项 | 元素定位路线（Appium 等） | 看懂屏幕路线（iEasyRun） |
|---|---|---|
| 找目标的方式 | 控件的 id / class / xpath | 识别屏幕上的文字、图标、图像 |
| 界面改版的敏感度 | 高（层级和 id 一变就失效） | 低（按钮还在屏幕上就能找到） |
| 能不能严格断言 | 能，可读控件属性 | 弱，主要看屏幕内容判断 |
| 环境复杂度 | 驱动 + Server + 客户端库 | 装一个工作站，手机接上 |
| 适合的活儿 | 复杂业务、需要断言的回归 | 固定流程、界面操作、快速验证 |
| 谁上手快 | 有编程基础的人 | 懂业务但不会写代码的人 |
有一点要说清楚：这两条路不是谁替代谁。 我见过的团队里，两个并用的反而多——需要数据校验和 CI 集成的走代码，界面流程和日常冒烟走 AI 操作。硬要二选一，通常是没想清楚自己要解决什么。
判断该不该换，看三个问题
第一条，你的用例里有多少是做断言的？如果一半以上在验数据、验接口返回、验状态，那代码框架更适合你，别折腾。如果大部分只是「打开、点进去、看界面对不对」，那可以试试另一条路。
第二条，你多久改一次界面？两周一个小版本、每周都在调 UI 的项目，元素定位的维护量会一直压着你。这种项目换过去收益最明显。
第三条，谁在用这套东西？如果只有两个开发在用，现状可能就够。如果有运营、测试、产品的同事也要跑真机验证，他们不会为了跑个冒烟去学 Appium——这时候工具的选择就变成人的问题。
如果只是想「跑真机验证」，还有一类更轻的做法：把固定流程做成模板，谁用谁点。这点在 移动端 UI 自动化测试 那篇里展开过。
换成 AI 操作手机，实际怎么跑
从装到跑其实就四步。
先把手机接上。按 安装选型 装好工作站，手机上装好端上的程序。安卓走 WiFi 连，iOS 可以插 USB 线也可以走无线，鸿蒙走 USB。验收标准很简单：工作站首页能打开，设备 页里至少有一台手机显示在线。
然后用中文把流程说一遍。在 对话 页描述你要干什么。这里有个细节值得学：第一次跑的时候，把提交这类不可逆的动作留在人工确认，等流程稳定了再去掉限制。
接着跑一遍看结果。结果会记进 执行历史，能看到每一步的状态、目标设备和报错信息。失败的时候先看报错里有没有「自动化环境」「设备离线」这类词，多数问题出在这。
跑顺了就固化成模板。当一条流程连续几天都没问题，把它存成 工作流。版本更新之后重复跑，不用再重写一遍——这是相对元素定位最实在的一个差别。跑已保存的工作流不需要调模型，也不消耗对话 Token。
流程里如果遇到纯图标按钮（没有文字可识别），配一条 找图模板 告诉它这个按钮长什么样，比反复调参数有效。
迁移时注意三件事
别一次全搬。挑一条最稳定的核心流程先跑通，比如登录加一个主流程。跑通了再决定要不要扩。一次搬全部，出问题的时候你分不清是用例写得不对还是工具不适应。
用例的思路可以保留。原来那条用例里的步骤顺序、检查点，直接翻译成中文描述就行，不用重新设计。
两套并存没什么不好。需要断言的留在 Appium 里，界面流程和日常冒烟交给 AI 操作。维护成本反而比全放一边低。
回到我那个朋友。他没有换掉 Appium，而是把十几条「打开、点进、截图留证」的冒烟流程挪了出来，交给 AI 操作手机在真机上跑；需要校验数据的用例还留在原来的框架里。按他的说法，前两周就回了本——省下来的时间主要是每次版本更新后的那一轮确认。
工具换来换去，真正要解决的还是那个问题：把重复而且不需要判断的动作交出去，把需要判断的留下来。如果你手上也有这类流程，先装起来拿一台手机试一条，比看十篇对比文章都直接。
常见问题
- Appium 和 AI 操作手机，根本区别在哪？
- 定位方式不同。Appium 靠元素定位（找控件的 id、class、xpath），AI 操作手机靠看懂屏幕（识别文字和图像，再决定点哪里）。前者精确、可断言，但对界面结构有依赖；后者不依赖控件树，界面改版时受影响小，但做不到像断言那样的严格校验。
- 界面改版之后，Appium 用例要改多少？
- 取决于你原来的定位写得稳不稳。用 text 或 resource-id 定位的，通常不用改；用绝对路径 xpath 或坐标的，往往要重写一批。团队里更常见的消耗不是改一次，而是每次版本迭代都要花时间确认哪些用例受影响了。
- 那套 AI 的方式，能替代 Appium 做回归测试吗？
- 能覆盖一部分，但不是全部。流程固定、以界面操作为主的回归场景，用它写起来快、维护量低；需要严格断言、数据校验、接口联调的场景，还是得靠代码框架。两个并用的团队不少，各管一段。
- 不写代码真的能做真机测试吗？
- 以界面操作和视觉校验为主的场景可以。你用中文描述「打开 App、进某个页面、点哪个按钮、看到什么算通过」，它在真机上执行。但如果要取返回值、做复杂判断、跟 CI 集成，还是得写代码。
- 支持哪些手机？
- 安卓、iOS、鸿蒙都能接。安卓走 WiFi 连接，iOS 有 USB 线和无线两种接法，鸿蒙走 USB。具体选哪种装法可以看安装选型文档。
- 一台电脑能同时跑几台手机？
- 没有固定的台数上限，取决于电脑的 USB 口、网络和设备性能。多台手机建议先在设备页分好组，批量任务按组下发更省事，也更容易定位是哪台出的问题。
- 跑测试要花钱吗？
- iEasyRun 软件本身完全免费，功能没有付费墙。它会用到你自己的大模型 API：AI 对话和让 AI 生成流程会计费；运行已经保存好的工作流不消耗对话 Token，也不需要配模型。
- 从 Appium 迁过来，工作量大概多少？
- 看你有多少条用例、原来怎么组织的。建议先挑一条最稳定的核心流程试：把步骤用中文描述一遍，让它跑通，再看结果能不能接受。跑通一条再决定要不要整体迁，不要一次全搬。