银河手机中控系统

苹果手机群控工具在我们团队落地之前，多版本并行测试一直是个挺尴尬的事情，iOS应用每次发版前后，测试机上经常要同时装着三四个包：App Store线上包、TestFlight灰度包，还有开发分支的调试包。

每个包对应的后端环境、功能开关、账号状态都不一样，如果用纯手工操作，光是把同一组用例在几台设备上各跑一遍，大半天就没了，后来我们开始用群控方案，把一批iPhone通过USB集线器接到测试主机上，由中控端统一发送安装、启动、点击、截图和日志抓取指令。

起初只是想省点人力，真正用起来才发现，适配iOS多版本并行测试并不是简单把屏幕镜像出来就行，里面涉及设备分组、系统权限、脚本兼容和稳定性一堆细节，这篇文章就按我们实际推进的顺序，拆成五个部分来聊。

1、多版本并行测试为什么需要群控

多版本并行的压力主要来自业务节奏，线上版本要回归，灰度版本要验证核心链路，新功能分支要跑冒烟，偶尔还有热修包要紧急确认，如果每个版本都单独安排一轮人工测试，时间上根本排不开，而且重复操作太多，人在执行到第三四轮的时候很容易疲劳漏项。

手机群控在这里的价值不是替代测试思维，而是把安装、启动、登录、点击固定路径、截图留证这些机械动作集中处理，我们试过在8台iPhone上同时跑4个不同版本的安装包，原本要两个人折腾两天的量，后来压缩到两个多小时。

关键是步骤一致性上来了，不会出现A版本测了登录、B版本忘了点弹窗这种低级偏差，当然，前提是设备分组和脚本适配得先做好。

2、设备分组与系统版本匹配是基础

很多人以为群控就是一台电脑控制多台手机，插上就能用，实际上在iOS环境里，最麻烦的反而是前面的准备，不同版本的应用对iOS系统要求不一样，有的灰度包只支持iOS 16以上，线上包还要兼容iOS 15。

如果不提前给设备打好标签，中控端按同一套参数发指令，很容易出现低系统装不上、高系统界面错位甚至闪退，我们会在中控台维护一张设备表，除了UDID、型号、系统版本，还记录电池健康度、是否越狱、WDA端口占用情况。

每次跑任务前先按系统版本和机型做一次匹配，再决定哪些设备进哪一组，这个分组逻辑要是乱了，后面脚本写得再稳也白搭，而且iOS系统小版本之间权限弹窗位置和文案有差异，分组不细的话，异常处理脚本会经常误判。

3、iOS端脚本适配的几个关键点

iOS自动化不像Android那么开放，真机操作绕不开签名、描述文件和WebDriverAgent，我们在适配多版本并行测试时，遇到的一个明显问题就是不同iOS版本对WDA的兼容性不一致，后来干脆针对iOS 15、16、17分别固定了不同版本的WDA，并在中控端配置了自动切换。

安装不同版本应用时，Bundle ID冲突也很常见，同一个应用的不同测试包如果共用一套Bundle ID，直接覆盖安装会丢掉旧版本数据，所以我们会在打包阶段给不同版本设置不同Bundle ID，或者用不同的描述文件做隔离。

群控脚本不能把目标应用写死，得能动态读取当前设备组对应的包名和启动参数，还有一个容易忽略的是弹窗处理，系统权限弹窗、TestFlight提示、登录页会在并行执行时交叉出现，中控端必须有一个统一的弹窗拦截队列，否则脚本会卡在某一台设备上不动。

4、稳定性问题比功能实现更难缠

功能跑通之后，真正让人头疼的是长时间运行时的稳定性，我们最早用USB Hub连接8台iPhone，跑不到半小时就有设备掉线，后来发现是供电不足，换成独立供电的工业级Hub后掉线少了，但WDA session偶尔还是会僵死，设备画面卡住，中控端却还在傻等。

现在的做法是每跑完一轮用例就强制重启一次WDA，同时给设备加健康检查，响应超时就自动踢出队列，手机发热也是个大问题，温度一高系统会降频，UI响应变慢，脚本点击坐标就会偏移。

我们让设备每执行两小时自动息屏降温五分钟，效果还不错，时间同步这个细节也值得注意，多台设备系统时间如果有几秒差异，日志和截图对不上，排查问题会非常浪费时间。

5、把群控能力沉淀进日常回归

现在这套东西已经不只是测试团队在用了，开发提测前也会自己跑一遍冒烟，我们在群控平台上预设了几条任务流：多版本安装、并行冒烟、崩溃日志收集、UI截图对比，新版本进来以后，只要选好设备组和脚本集，就能自动执行，测试人员把精力放在分析结果和探索性测试上。

手机群控在这里从省事工具变成了质量流程的一部分，回头来看，适配iOS多版本并行测试的关键不在于把某一家工具用得多熟，而是对设备状态、系统差异和脚本容错有持续投入，每个团队的机型池和业务场景不同，方案也不能照搬，但把分组、稳定性、异常处理这三件事做扎实，基本能少走很多弯路。