苹果群控怎么跑多机型真机验证？从装包到留证的完整步骤

手上有五台机器。一台 iPhone 11、两台 12、一台 13 mini，还有一台边框磕过但还能跑的备用机。新版本发出去之前，主要路径都得在这几个机型上过一遍。

以前的做法是挨个插线、装包、手指头点一遍。跑完一轮天都黑了，第二天测试包一更新，又得从头再来。

问题不在用例本身，而在流程。每次都在重复同样的准备动作，重复同样的人肉核对。把这套流程往群控里搬一次，后面每一轮验证就只剩「重新下发一遍」这件事。

下面按实际顺序走一遍，从清点设备到归档截图，每一步都能照着做。

第一步：开工前把电脑、机型、账号和测试包备齐

这一步最容易被跳过，也最容易在后面还债。

电脑。中控跑在 Windows 上最省事。五到十台设备，普通办公本够用；再往上走，先看 USB 口数量。十几台直接插机箱，供电和带宽都吃紧，配一个带独立供电的 USB Hub 能省掉很多莫名其妙的问题。走无线投屏的话，路由器的并发也要能兜住这些设备同时在线。

机型覆盖。先写清楚这轮要验哪几个机型，再决定上哪几台机器。老机型和小屏机型排在前面，界面元素在小屏上挤成一团的情况最多，出问题也最早暴露。机型定下来就别中途换，换一台就要重新对一遍页面和等待时间。

账号与测试包。账号得是你自己能支配的，用途先想清楚。测试包放本地目录，按版本号建子目录，像 builds/v2.4.1/ 这样，同一个版本里 debug 和 release 各留一份，脚本里用参数决定装哪一份。

数据线。这条单独拎出来说。线要原装或者 MFi 认证的，便宜的第三方线只能充电不能传数据，表现出来就是设备列表里一直不出现这台机器。桌面布线也别偷懒，线头贴个机器编号的标签，拔插的时候省事。

清单对了，后面出问题才好判断：是流程本身有问题，还是某台机器有问题。

第二步：设备接完，顺手把命名规则定死

设备插上之后，中控的设备列表里会冒出一串默认名称，通常是一长串串号。这时候别急着开任务，先把名字改掉。

命名规则建议带上三样：机型、分组、序号。

ip11-test-01
ip12-test-01
ip12-test-02
ip13mini-test-01
spare-test-01

中间那段是分组，末尾两位是序号。日志里如果冒出 ip12-test-02 用例失败，你不用去数设备，看一眼就知道该拿哪台机器出来。

改名不用一台台点。在中控里选中整组设备，右键批量设置别名，填一个批量起始名，系统会先把改名结果预览给你看，确认序号排得对再点确定，整组一次改完。

上面这张是中控的批量别名设置。起始名填好之后先看预览列表，序号自动递增，确认顺序跟机器对得上再保存。

顺序上也别搞反：先接线，再改名，分组放到后面。接一台改一台，比全部接完再回头认哪台是哪台省事得多。

iOS 这边免越狱是前提，链路上有三条可选：USB 加自动化服务，要装代理 IPA，能力最全；无自动化截图配合 USB_HID，手机端不装 App，iOS 17 起；主程序录屏配合 USB_HID，免付费签名，也是 iOS 17 起。选哪条看这轮验证要不要抓控件节点，要抓就走第一条，只做点击和看图就走后面两条。三者差别看 iOS 自动化三种模式对比。

第三步：按机型分组，把设备状态核一遍

命名完了就分组。分组标准按你这轮的验证方式来定，最省事的做法是按机型分：

• test-ip11
• test-ip12
• test-ip13mini

为什么按机型分而不是按机架位置分？因为下发任务的时候，你多半是「这个用例只在 13 mini 上跑」，或者「这轮先跑 12 那两台」，按机型分组正好对上这种下发方式。设备挪了位置不用改组，机型变了才需要动。

中控里设置分组就三步：右键设备、选设置分组、挑一个组保存。分组本身不改设备的连接状态，一台设备随时可以调到别的组。

分完组，下发之前再看一眼状态。中控状态栏会显示设备总数、在线数和异常数，这几个数字对不上就先别往下走。掉线的设备先处理掉，不然这一轮结束你分不清是它没跑还是跑了失败。

顺手把三件事设了：自动锁屏改成永不，系统自动更新关掉，亮度调低。用例跑到一半锁屏，后面所有步骤都是空转，而且排查的时候很难往锁屏上想。

第四步：用例脚本怎么组织，参数怎么外置

脚本组织这块，建议是一个用例一个文件，公共动作抽成函数。目录大概长这样：

scripts/
  lib/
    common.js        // 启动 App、等元素、登录
    report.js        // 截图与结果回传
  cases/
    login.js
    search.js
    checkout.js
params/
  ip12.json
  ip13mini.json

cases/ 里只写用例本身的步骤，lib/ 放到处都要用的动作。改一个公共动作，所有用例一起受益；某个用例要单独调，也不会带歪别的用例。

参数单独放 params/，一个分组一个文件：

// params/ip12.json
module.exports = {
  group: 'test-ip12',
  build: './builds/v2.4.1/release.ipa',
  account: 'test-account-02',
  waitMs: 8000,
  retry: 2,
  shotDir: './shots/2026-09-24/ip12'
};

这几个字段几乎每轮都要动。测试包一更新，只改 build 一行；截图目录按日期走，跑完就是归档好的。参数和脚本分开这件事，写 iOS 脚本的细节可以对照 USB HID 写 iOS 自动化脚本 那篇里的写法。

写用例时有三个习惯值得提前养成。

定位优先用控件和文字，别写死屏幕坐标。iOS 脚本支持找图、OCR 和控件查找，控件找得到就别去猜坐标，页面一改坐标全废，还很难看出是哪里错了。

等元素出现，别写固定秒数。sleep(5000) 这种写法，在快的机器上白等五秒，在慢的机器上又不够用，两头不讨好。

每一步结束就把结果写进日志。失败时先截图再退出，别只抛一句错误了事，回头看的时候你只有一句「失败了」，等于没有线索。

第五步：分批下发，按组推执行

脚本和参数准备好，先在一台设备上跑完整条链路。跑通了再上批量，这一步别省。一台都没跑通就推给一整组，出了问题是十几份同样的困惑。

下发的时候选中一个分组，把脚本和参数一起推下去，中控会在这批设备上依次执行。别一次把所有组全点下去，一组一组来，前一组的结果看一眼再推下一组。

一组跑完，看三个东西：

• 成功和失败的条数，用来看是普遍问题还是个例；
• 失败停在哪一步，日志停在具体动作上，比一个错误码有用得多；
• 设备在线状态，掉线一般是连接或者供电的事，跟用例逻辑没关系。

同一个失败集中在多台机器上，八成是用例或者页面变了；只出现在一台，先查那台机器本身。返工的时候只跑失败的设备，成功过的别重跑，省得把已经验过的流程再走一遍。

一个分组跑顺了，可以把它变成固定动作。中控的定时任务支持设置执行周期，按天、按间隔分钟、按间隔秒都行，执行次数填 0 表示不限。回归验证用不上定时，但夜间长跑和重复轮次验证用得上。设备第一次批量初始化怎么走，可以看 iOS 批量初始化。

第六步：截图和日志怎么留证，结果怎么核对

这一步是很多人偷懒的地方，也是真出问题时最想回去翻的地方。

截图要带上下文。光截一张失败界面没用，得看得出来是哪台机器、哪个用例、哪一步。文件名按 设备名_用例_时间戳 拼，落到按日期分的目录里：

shots/2026-09-24/ip12/ip12-test-02_checkout_fail_1042.png

这样命名有个好处：翻目录的时候，光看文件名就能筛出「这个用例在所有机型上的失败截图」，不用一张张打开看图。

日志留在中控里。中控有实时日志，脚本每跑一步都会往里写。这一批任务全部收尾之前别清，中间要回看的时候，日志里的时间和步骤比记忆靠谱得多。

核对结果按机型横向比。同一套用例在不同机型上的结果摊开看，比一台台看更容易发现问题。如果某个机型的失败集中出现在同一步，问题基本就在这个机型的界面差异上，不在用例逻辑上。

补一句：核对完把这一轮的结论落到一处，哪怕只是一个文档里的一行「哪些机型过、哪些机型没过、没过的是哪一步」。下一轮再跑的时候，这一行就是你的起点。

卡住了，按这个顺序查

排查的顺序比技巧重要，按下面这个次序走能少走不少弯路。

设备列表里没有这台机器。先换线换口，再确认手机上有没有点过「信任此电脑」。用了 USB Hub 的先直插机箱试一次，把 Hub 排除掉。

设备在列表里，状态是离线。多半是锁屏或者线松了。解锁、重插，再看自动锁屏有没有设成永不。

iOS 17 以下的机器跑不了免装 App 的模式。后两条 USB_HID 链路有版本要求，低版本回到 USB 加自动化服务那条，代价是要装代理 IPA 并签名。

脚本跑起来但界面不动。先确认这组设备的连接状态，再看脚本第一步等的元素是不是根本没出现。截一张当前页面看一眼，比猜快得多。

投屏画面卡。先怀疑供电。一批设备同时跑，普通 Hub 顶不住，表现就是画面一帧一帧跳。分到带独立供电的 Hub 上，每路别挂太多。

同一台机器反复失败。把这台从分组里移出来，单独跑一次同一个用例。还失败，就换一台机器跑同样的用例，立刻能区分是机器的问题还是用例的问题。

第一次配环境就卡住的，新手配苹果群控最容易卡在哪一步 里按卡点整理了排查路径，可以先照着走一遍。

下一步可以做什么

一轮验证跑顺之后，有三件事值得做。

把这套命名和分组规则写进团队文档。规则不是给你自己看的，是给下一个接手的人看的。没有文档的时候，换人接手的第一周基本都在认设备。

把常用用例整理成固定组合。每轮跑哪几个用例、覆盖哪几个机型，定成默认动作，不用每次重新想一遍。

把设备规模往上走之前，先看设备和网络这两块。设备上到几十台，关注点会从「脚本怎么写」转到「机器和网络扛不扛得住」，这块可以看 苹果群控设备容量与运维实践。

多机型验证这件事，难的不是某一台跑不起来，是几十次重复里每次都保持一致。命名、分组、参数、留证这四样做到位，一致性就是流程自带的，不靠人记。

---

iEasyClick：手机自动化脚本与群控方案站，覆盖安卓免 root、iOS 免越狱、鸿蒙 Next，提供脚本开发教程、中控投屏与批量运维方案。官网 ieasyclick.net