上个月一个做 App 测试的朋友来找我，说他那套 Appium 用例又一起挂了。
用例逻辑没改过。版本一更新，十几个页面的元素定位全变了，他要逐个查哪个按钮的 id 改了、哪个列表的层级动了。改了两天，还有两条是红的，因为等待时间不够，页面加载慢了两秒。
他算过一笔账：写用例花的时间，大概只有维护的三分之一。做真机自动化的团队里，这种账很常见。
Appium 的时间花在哪
Appium 是行业里常用的框架，文档和社区都全。消耗来自它的工作方式。
它靠元素定位：用控件的 id、class 或 xpath 找到目标再操作。定位准，也能做断言。界面结构一变，原来的定位就失效。
| 消耗点 | 具体表现 |
|---|---|
| 环境维护 | 手机、驱动、Appium Server、客户端库版本要配套，换台机器就得重配一遍 |
| 元素定位失效 | 界面一改版，原来靠层级或绝对路径定位的用例就找不到元素 |
| 等待时间调不准 | 加载快的机器两秒够，慢的机器五秒才出来，写死哪边都有问题 |
| 定位到但操作不到 | 元素在 DOM 里存在，但被遮挡、没进入可点击状态，点击照样失败 |
| 设备分散 | 十几台真机各自连着电脑，哪台掉线、哪台被占用，管理起来又是一摊事 |
复杂业务要断言、要接 CI、要沉淀用例，这些成本换得回来。如果只是把某个固定流程在真机上重复跑一遍，环境和对控件树的维护就偏重。
另一条路：看懂屏幕
这条路截图，识别屏幕上的文字和图像，判断当前在哪个界面，再决定点哪里。技术上是视觉模型（VLM）加 OCR。它不用控件树，id 变了也不影响，只要按钮还在屏幕上。
| 对比项 | 元素定位路线（Appium 等） | 看懂屏幕路线（iEasyRun） |
|---|---|---|
| 找目标的方式 | 控件的 id / class / xpath | 识别屏幕上的文字、图标、图像 |
| 界面改版的敏感度 | 高（层级和 id 一变就失效） | 低（按钮还在屏幕上就能找到） |
| 能不能严格断言 | 能，可读控件属性 | 弱，主要看屏幕内容判断 |
| 环境复杂度 | 驱动 + Server + 客户端库 | 装一个工作站，手机接上 |
| 适合的活儿 | 复杂业务、需要断言的回归 | 固定流程、界面操作、快速验证 |
| 谁上手快 | 有编程基础的人 | 懂业务但不会写代码的人 |
AI 操作手机盖不住 Appium 那类断言。我见过的团队里，两套一起用的更多：数据校验和 CI 集成走代码，界面流程和日常冒烟走 AI 操作。
判断该不该换，换了怎么跑
先看用例里有多少在做断言。一半以上在验数据、验接口返回、验状态，继续用代码框架。大部分只是打开、点进去、看界面对不对，可以试看屏幕这条路。
再看界面改得多勤。两周一个小版本、每周都在调 UI，元素定位的维护会一直在。这类项目换过去，少改的是定位，不是用例本身。
最后看谁在跑。只有两个开发在用，现有框架可能就够。运营、测试、产品也要在真机上验一遍，他们通常不会为了冒烟去学 Appium。
只想跑真机验证的话，还可以把固定流程做成模板，谁用谁点。 移动端 UI 自动化测试 里写过这种做法。
从装到跑是四步。
按 安装选型 装好工作站，手机上装好端上的程序。安卓走 WiFi，iOS 可以插 USB 也可以走无线，鸿蒙走 USB。工作站首页能打开，设备 页里至少有一台手机显示在线，才算接上。
在 对话 页用中文描述要干什么。第一次跑，提交这类不能撤回的动作留在人工确认，流程稳定后再放开。
结果记在 执行历史，能看到每一步的状态、目标设备和报错。失败时先看报错里有没有「自动化环境」「设备离线」，多数问题在这里。
一条流程连续几天都通过，存成 工作流。版本更新后重复跑，不用按新的 id 重写定位。跑已经保存的工作流不调用模型，也不消耗对话 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 迁过来，工作量大概多少？
- 看你有多少条用例、原来怎么组织的。建议先挑一条最稳定的核心流程试：把步骤用中文描述一遍，让它跑通，再看结果能不能接受。跑通一条再决定要不要整体迁，不要一次全搬。