传统 UI 自动化框架，门槛在哪
谈到移动端 UI 自动化测试，多数团队第一个想到的是 Appium 这类框架。它们能力确实强，但在实际落地中，团队付出的成本往往不在「写用例」上，而在两个更容易被低估的地方。
第一道门槛是环境。要跑真机测试，得把手机驱动、SDK、服务端、客户端连接一整套配好，还要处理机型差异、系统版本差异带来的各种兼容问题。环境没配平时，测试同学的大部分时间会花在「为什么连不上设备」上，而不是验证功能。
第二道门槛是脚本维护。基于元素定位的方案，写的时候要选定位方式，跑的时候要处理等待和弹窗，改版之后还要回头修——每一个控件调整，都可能让一批用例集体失效。用例越多，维护成本越高，最后常常演变成「投入不少、跑得不多」。
| 维度 | 传统脚本方案 | 用对话 + 工作流 |
|---|---|---|
| 起步成本 | 要搭环境、写代码 | 说清楚步骤即可开跑 |
| 用例表达 | 代码块 + 断言 | 自然语言描述 |
| 改版影响 | 元素定位失效需改脚本 | 按屏幕内容执行，更抗改版 |
| 多机型 | 逐套环境分别配 | 设备分组统一选 |
| 结果查看 | 测试报告框架 | 执行历史统一记录 |
下面讲的思路不是要替代所有测试工程，而是给「快速验证」和「重复回归」这两类高频需求，提供一条门槛更低的路。工具是 iEasyRun，本地运行在自己电脑上，支持安卓、iOS、鸿蒙，多台手机统一管理。
换一条路：用「对话」把用例说成步骤
第一步是把写用例的动作，换成说用例。
先按 安装选型页 装好工作站和手机端程序，在 设备 页确认测试机在线——离线设备只能看不能跑，这是所有执行的前提。
然后到 对话 页新建会话，选中在线测试机，用大白话把用例讲一遍。关键是说清楚三件事：
- 前置条件：从哪个界面开始，需要先登录还是先清数据；
- 操作步骤：先点哪、再输入什么、等什么界面出现；
- 预期结果：界面应该出现什么文字、跳转到哪个页面。
对话页有两种模式，按用例的清晰程度选：
- 对话模式：用例步骤你已经很清楚，直接发指令，AI 立刻规划并在真机上执行；
- AI 细化模式：只知道要测什么、步骤还没想全，先和 AI 多轮对话，把界面、顺序、边界条件补全，整理成可执行步骤后再发送。
一条可以照抄起步的用例描述大致是这样：
打开应用，用测试账号登录，进入「我的」页面，点击头像进入个人资料，修改昵称为 test001，保存后返回上一页，确认昵称显示为 test001。
细化过程中沉淀下来的描述，可以保存到 提示词 页。同一条用例下次再跑，直接从提示词调出来，不用重新组织语言。
用「工作流」把用例固化成回归模板
对话适合探索和试跑；一旦某条用例连续几次都跑得稳，就应该固化下来，避免每次重新描述。
在 工作流 页的工作流库里新建一条，进入画布编辑。常见步骤类型有「启动自动化环境」「等待」「打开应用」「手势-滑动」等，把用例排成固定顺序即可。画布上这几项能力，在测试场景里各有用途：
| 画布能力 | 在测试场景里的用途 |
|---|---|
| 校验 | 上线前检查步骤连线与参数，避免跑一半才暴露配置错误 |
| 排版 | 步骤变多后自动整理布局，用例结构一眼看清 |
| AI 工作流协作 | 让 AI 帮忙生成或补充步骤，长用例不必从零搭 |
| 试跑 | 选一台测试机先验证模板，再推广到整组设备 |
固化的重点是把测试数据留成参数：账号、昵称、关键词这类每次可能变化的内容不要写死在模板里，运行时传入。这样一条「修改昵称」模板既能做正常值验证，也能顺手跑边界值。
配好之后先试跑一台测试机。试跑结果会进执行历史，和正式执行的记录格式一致，便于对照。
执行历史：怎么看结果和报错
看测试结果不需要盯屏幕。所有任务的结果都汇总在 执行历史 页，每条记录包含四个关键字段：
- 任务来源：来自对话会话、定时任务，还是工作流试跑；
- 执行状态：成功、失败或进行中；
- 目标设备：这次用例跑在哪台手机上；
- 错误信息：失败时的日志摘要，用来定位问题。
多机型回归时，按目标设备筛选是最高效的看法——能直接看出是哪台机器、哪个系统版本出了问题，而不是笼统地知道「这批没跑过」。
报错里的关键词基本可以直接指向处理动作：
- 「自动化环境」→ 回安装页检查手机端设置；
- 「设备离线」→ 回设备页排查连接状态；
- 「未授权 / 已过期」→ 在工作流库查看模板状态；
- 找图或识别失败 → 补 找图模板，或检查 能力与模型 里的相关配置。
多机型怎么管：设备分组
移动端测试躲不开机型差异，而机型差异的管理成本，在设备少的时候不明显，设备一多就会失控。解法仍然是设备分组。
在 设备 页按四步走：扫描 → 入库 → 起别名 → 分组。测试场景建议按两种维度分组：
- 按系统版本分组（如「安卓 13」「安卓 14」「iOS 17」），用于验证兼容性差异；
- 按用途分组（如「冒烟机」「回归机」），用于区分执行频率不同的设备批次。
分好组之后，下发回归任务时按组选目标设备，一次覆盖组内所有在线手机，每台独立执行同一条用例模板。新增一台测试机时，只要入库并归到对应分组，后续任务自动覆盖到它。
流程稳定后，还可以用 定时 页把回归放到固定时间：配置工作流定时，选模板和目标分组，设定时间规则，到点自动执行。三条前提和所有定时任务一样——电脑上的工作站保持开启（调度是本地的，没有云端）、目标设备在线或到点能自动连上、走 USB 的设备到点时连接仍然可用。
边界在哪：什么适合，什么还不行
把这条路的适用范围说清楚，比一味说好更重要。
适合交给它的：关键路径冒烟、发版前的重复回归、多机型一致性验证、界面元素和文案的可见性检查。这类测试的特点是步骤明确、需要反复执行、对响应速度要求不高，正是自动化最划算的部分。
仍然需要传统方案的：需要精确断言数值与接口返回的测试、涉及复杂并发和性能指标的测试、需要嵌入 CI 流水线并产出结构化测试报告的场景。iEasyRun 提供的是真机操作能力和执行记录，不是完整的测试报告框架。两者并不冲突——可以用它承担回归中「点得最多、最枯燥」的那部分。
回头看整条链路，移动端 UI 自动化测试的难点，一是环境，二是维护。把用例从代码里搬回自然语言，用 对话 描述、用 工作流 固化、用 执行历史 看结果、用设备分组管多机型，门槛和改版维护成本都会明显下降。
建议的起步方式很轻：接一台测试机，挑一条最常跑的用例，用对话跑通，再存成工作流模板；跑顺之后再按机型分组、加上定时。iEasyRun 软件完全免费，功能没有付费墙，装在自己电脑就能跑，数据留在本地。装法见 安装选型。
常见问题
- 不写代码真的能做移动端 UI 自动化测试吗？
- 可以。用自然语言在「对话」页描述用例，AI 在真机上执行；需要反复回归时，把用例存成「工作流」模板，下次选手机直接跑，全程不需要写脚本。
- 这种方式和 Appium 是什么关系？
- 定位不同。Appium 靠代码维护元素定位与断言，适合结构化的大型测试工程；这套方式面向快速验证与重复回归，用描述驱动、按屏幕内容执行，改版时更省维护。
- App 改版后用例会失效吗？
- AI 依据屏幕内容判断操作对象，比写死的元素定位更抗改版。如果出现纯图标按钮或识别不准的位置，补一条「找图模板」描述它长什么样即可恢复。
- 怎么查到用例在哪一步失败、报错是什么？
- 在「执行历史」页查看。每条记录包含任务来源、执行状态、目标设备和错误信息，常见原因有设备离线、自动化环境未就绪、工作流未授权、找图识别失败。
- 多机型测试要一台台配吗？
- 不用。把测试机在「设备」页入库、起别名，再按机型或系统版本分组。运行时按分组选择目标设备，同一批用例就能覆盖组内多台真机。
- 这些测试机必须一直插着数据线吗？
- 不一定。iEasyRun 支持插 USB 和连 WiFi 两种接法。要保证的是执行时设备在线——离线设备只能看不能跑，插 USB 的到点那一刻连接也要正常。
- 能只跑一条冒烟用例，不做完整回归吗？
- 可以。用例颗粒度由你自己定。常见做法是日常用对话快速跑关键路径冒烟，发版前用工作流定时对整组设备跑一遍回归模板。
- 测试过程中产生的数据安全吗？
- iEasyRun 本地运行在自己电脑上，不需要服务器，设备和任务数据留在本机。具体说明可以看站内的安全与多租户文档。