先算一笔账，再定设备分工
安卓自动化测试该不该上，这个问题在会议上经常变成技术选型之争，它首先是一道算术题。先把手动的一轮全量回归拆开算。假设 40 条用例，每条平均 6 分钟，就是 4 小时；要在 3 台不同机型上跑，就是 12 小时；一个人一天按 8 小时算，一轮全量回归要花掉 1.5 个人日。再看频率，双周发版一个月两轮就是 3 个人日，一年按 24 轮算是 36 个人日——超过一个半人月，全花在重复执行上。算到这里答案清楚了一半：如果你的回归频率和用例规模接近这个量级，自动化几乎必然回本；如果一个月才发一次版、用例不到十条，手动的成本反而更低。别为了「行业都在做」上自动化。算这笔账有什么用？至少能让讨论有个共同的数。而且这个数会随规模变化——用例从 40 条涨到 80 条、机型从 3 台加到 5 台，人日翻倍地涨，自动化的性价比是越往上越好的。
把上面的算式反过来，有三个信号。一是用例数量过了 20 条，少于这个数，跑一轮的时间和调脚本的时间差不多。二是回归频率高于每月一次，一个月才跑一次，脚本半年不用可能已经跟界面脱节，每次跑之前都要修。三是要在多台设备上重复跑，一台手动还能忍，三台五台就变成纯粹的体力活，设备越多，效率提升的幅度越大。三条里满足两条就可以动手，满足三条基本是必做。顺便说一句，很多人是先买了设备、搭好框架，才发现手里的用例根本不够多。
账算完，真正动手时先把设备定下来。
做安卓自动化测试绕不开一个问题：设备从哪来。选型上也别一开始就纠结 Appium 还是别的框架，先想清楚设备怎么摆。真机测试的价值在真实硬件行为——摄像头、传感器、蓝牙、不同厂商的系统表现，模拟器还原不了；用例里涉及扫码、拍照、切后台、来电打断这类场景，真机是唯一选择。云测的价值在覆盖和并发：自己搭机房，设备采购、维护、折旧都是钱；云测按需付费，机型覆盖也更容易拉齐，适合发版前跑一轮机型覆盖。比较省事的做法是分两层：本地真机跑主流程和日常调试，云测跑发版前的机型覆盖，两边都留、职责分开，别指望一套设备解决所有问题——云测省钱但摸不到硬件，真机真实但要养。
第一个用例别选登录，这是 UI 测试选题上最常见的错。很多人做自动化的第一个用例就是登录，理由很合理：登录是入口，后面都要用。但登录恰恰是最不稳定的一段，验证码、短信、设备校验、异地登录风控，任何一条都能让脚本卡住，卡住几次人就放弃了。更稳的开局是选流程短、结果明确、不依赖外部条件的用例，比如列表页上滑加载、详情页进入再返回、设置页开关切换。这类用例不需要特殊权限，免 root 就能跑，跑通很快，能让你先把「脚本怎么跑起来、结果怎么收」这条链路走通。等这条链路稳了，再回头啃登录，这时候你已经知道怎么处理等待和异常，登录那些坑也就不那么劝退了。
成本在维护，什么时候不如继续手动
自动化测试的成本不在第一版，在维护。三个来源，一是界面改版：用固定坐标点来点去的脚本，改版之后基本全废；用控件属性、文本内容定位，外面套一层「等元素出现」的等待机制，改版时通常只需要调整少量位置——写法上这点差别，决定你每次改版的返工量是一天还是一小时。二是测试数据：用例依赖某个账号、某条订单、某个状态，而这些数据会被别的测试用掉，数据没准备好，用例就会以各种奇怪的方式失败。三是失败结果的可信度：第一版脚本的失败里，相当一部分是脚本自己的问题，不是被测应用的问题，得先把脚本调稳、让失败结果可信，它才能进流程，否则开发会被误报搞到不信自动化。还有第四个来源是设备环境：不同系统版本、不同厂商的 ROM，同一套脚本在不同机器上的表现会有差别，用例越多、机型越杂，这部分越明显。误报多了会怎样？整个自动化就成了摆设。
有三种情况，我建议先别上自动化。版本发布很稀疏——半年发一次版，脚本写完放半年，下次跑之前先修脚本，省下的时间还不够修。界面还在大改——产品形态没定、界面每周都变，这时候写自动化是在追一个还在移动的目标。用例主要靠人的判断——体验好不好、文案顺不顺、交互是否自然，这类判断自动化给不出答案，交给它只会产出不可信的结论。自动化的定位是「把人从重复执行里拿出来」，去做探索性测试、新功能首轮验证、体验把关这些机器做不了的事；按这个定位用它，投入产出比会很正常，指望它替代全部人工测试，期待就会落空。先把定位想清楚，再决定投入多少，比一上来就买设备、搭框架要省事得多。
关于 EasyClick：手机自动化 AI 智能体平台，覆盖安卓免 root、iOS 免越狱、鸿蒙 Next 三大生态，提供脚本开发、苹果群控、本地中控投屏与云控系统。→ 了解全部产品
想要真实跑起来？
本文介绍的方案均可在 EasyClick 手机自动化平台落地。官网提供完整文档、开发工具与群控云控产品，免费体验。