上周有个做移动端质量的同学问我他们团队今年准备换掉手上那套已经跑了三年的真机云服务让我帮忙列一份对比清单。我问他为什么换他给的理由很朴素不是不能用是每次跑全量回归都得排四十分钟队等的时间比跑的时间还长赶上发版窗口测试同学只能干坐着刷手机。这个场景几乎每年都在不同的团队里重演一遍所以每年都值得把云测试平台这件事重新捋一遍。云测试平台说白了就是把真机、模拟器、浏览器、压测节点这些平时要自己买、自己插线、自己维护的东西变成按需租用的服务。它能干的事很具体把自动化脚本丢上去批量跑、把兼容性矩阵铺开扫一遍、把性能数据采回来、把测试报告生成出来。适合看这篇的人有三类一类是正在做第一次选型、完全没有历史包袱的团队一类是像上面那位同学一样想换供应商、但不知道从哪几个维度下手的团队还有一类是自建机房已经撑不住了、在评估要不要迁到云上的团队。三类人的诉求差别很大后面会分开讲。1. 先想清楚2026年重新审视云测试平台的三个理由1.1 终端碎片化没有消失只是换了个形态前几年大家讨论兼容性焦点集中在安卓机型太多、分辨率太杂。到了今年问题的形态变了。机型数量本身反而趋于收敛主流厂商的旗舰和中端产品线都在精简但系统版本的分叉、折叠屏的展开态、高刷屏的刷新率档位、以及各种厂商定制层的差异叠在一起组合数并没有变少。我自己统计过一个中等规模项目的兼容性矩阵把需要覆盖的机型、系统版本、屏幕形态三者相乘去掉明显冗余的组合之后仍然有六十多个格点。六十台设备买下来是钱摆在机架上占地方一年之后折旧、两年之后系统停更还得重新买。云测试平台在这件事上的价值从来不是设备多这三个字本身而是你不用为了一年只跑四次的那台冷门机型付全款。租赁的本质是把设备的使用率从你自己的百分之几提升到平台侧的百分之几十。这个账算得过来云测试平台就有存在意义算不过来自建就更划算。1.2 自建机房的成本账单大多数团队只算了前三项我见过太多团队在做自建和云上对比时只列了设备采购、机架空间、网络带宽这三项然后得出结论说自建三年回本。这个算法漏掉了后面几项而且漏掉的恰恰是大头。成本项容易被忽略的原因实际占比感受设备采购与折旧只算首年支出忽略两年后的换机周期显性容易算机架、供电、网络通常被归到公司公共成本里不计入项目半隐性设备维护人力一个人管五十台设备插拔、刷机、系统升级、坏机返修隐性最贵稳定性损耗设备离线、USB 掉线、系统自动更新导致第二天全挂隐性最难量化排期冲突多人抢同一批设备回归窗口打架隐性直接影响交付节奏第五项是我认为最容易被低估的。自建机房的设备数是硬上限发版前一晚三个小组同时要跑回归就只能排队。云测试平台之所以能解决问题核心不是设备更便宜而是它把硬上限变成了软上限用别人的设备池削平了你自己的波峰。1.3 三类团队该问的问题完全不一样第一次选型的团队最容易犯的错是拿着一张几十项的功能清单去逐条打勾最后选了一个功能最全但也最贵的平台结果一年下来只用了其中三成功能。我的建议是先回答一个问题你的自动化脚本成熟度到哪一步了。脚本还在手工阶段、主要靠人肉点、想上云只是为了做兼容性扫描的团队关注点应该放在设备覆盖和手工操作体验上别为执行并发付溢价。脚本已经跑在 CI 里、每天几十次触发的团队关注点必须转向调度能力、任务排队策略、失败重试机制、报告回调这些工程化指标。而自建机房已经撑不住的团队最该问的其实是迁移成本——现有脚本改造成本、测试数据怎么搬、历史报告怎么留。这三个问题的答案指向完全不同的平台类型选型前不搞清楚后面全是返工。2. 把云测试平台这四个字拆开看它到底卖的是什么2.1 设备云只是最外面那一层大部分人提到云测试平台第一反应就是上面有很多手机可以远程点。这确实是它最直观的部分远程真机、屏幕投屏、ADB 通道、日志抓取、截图录屏一套下来体验好的平台确实很顺手。但设备云是最容易同质化的一层头部平台之间的设备池差距在主流机型上已经很小了差距主要在冷门机型、老旧系统版本、以及新兴形态设备比如各种折叠态、车机屏、穿戴设备的补货速度上。选型时我建议把设备清单要到手然后做一件很枯燥但很有用的事拿你近半年线上出问题的机型版本组合去和对方的设备清单做交集。交集覆盖率低于八成后面谈什么都没意义。这个动作比看任何宣传材料都直接。2.2 执行云的调度能力才是真正的分水岭脚本能跑起来不算本事几十个任务同时在跑、还能保证每个任务拿到干净的设备状态、跑完之后设备能被正确回收这才是本事。我实测过几家平台差异最大的一块就在这里。具体表现是什么举个我自己遇到的例子。同样是一百个用例分到十台设备上并行A 平台会在任务开始前做设备预检——检查电量、检查系统是否被上一个任务改过设置、检查是否有残留进程预检不过就换设备这个动作会多花十几秒。B 平台不做预检任务直接下发快是快但大概有百分之五的任务会因为设备状态脏而失败失败之后重跑整体时间反而更长。表面上快的那一方在长周期批量场景里往往更慢这一点在 POC 阶段如果不刻意设计用例是测不出来的。调度能力还包括排队策略。好的平台会区分任务优先级紧急的发版验证可以插队日常回归走低优先级队列差的平台就是一个先进先出的大池子谁先提交谁先跑。这个差异在团队规模超过十人之后会被急剧放大。2.3 用例管理和测试数据是粘性最强也最容易被低估的部分很多团队选型时只看执行忽略了用例组织和测试数据管理。等到用了一年想换平台才发现几百个用例的平台侧配置、几百组测试账号、几十套设备偏好设置全都要重建迁移成本高到干脆忍着不换。这块能力具体包括用例的分组与标签体系、参数化数据的管理、公共前置步骤的复用、环境配置的切换测试环境、预发环境、以及测试数据的清理与隔离。其中测试数据的隔离是我最看重的一项尤其是涉及账号登录状态的场景如果平台不能在任务之间把登录态彻底清掉就会出现单跑能过、批量跑就挂的玄学问题而且极难排查。选型时可以直接问对方任务之间的设备状态重置是怎么实现的是重启应用、清数据、还是恢复快照三种方式的重置彻底程度和耗时都不一样答案能侧面反映平台做得细不细。2.4 AI 辅助能力要看清它落在哪一环今年几乎所有平台都在讲 AI。我的态度是能力是真的有但要看它具体嵌在哪一步。目前比较落地的有三类。第一类是脚本自愈元素定位失效时自动尝试备选定位策略这个在 UI 改版频繁的项目里确实能省不少维护时间但要看清它的修复是改了脚本还是只在运行时兜底前者会影响你的脚本仓库后者只影响执行结果。第二类是失败归因把失败日志、截图、堆栈自动聚成几类标注出是环境问题、脚本问题还是真缺陷这个对降低排查时间帮助很大。第三类是视觉比对截图差异检测这个成熟度最高但也最容易误报阈值调不好会淹没在噪音里。我的经验是把 AI 能力当作加分项而不是决策项。它能帮你省百分之十到二十的维护成本但省不了选型选错带来的返工。优先级排在设备覆盖、调度稳定性、报告可用性之后。3. 测评维度怎么设计把好用拆成能打分的项3.1 设备覆盖度不能只看总数平台宣传页上写覆盖三千款设备这个数字基本没有参考价值。有价值的问法是三个主流在售机型的覆盖率、你需要的特定系统版本的保有量、以及单机型的设备冗余数。第三个最容易被忽略。一个机型只有一台设备和有三台设备在并发场景下的体验天差地别。单机型只有一台意味着同一时间只能有一个任务用它团队里两个人同时要测这台机器就得排队。我一般会做一张这样的表来量化维度提问方式合格线参考主流机型覆盖近一年销量前五十机型有几台不低于四十系统版本跨度是否保留三个大版本以上的旧系统至少覆盖主流版本减二单机型冗余热门机型平均有几台设备不低于三台形态覆盖折叠屏、平板、车机是否单独提供按业务需要判断补新速度新机发布到上架的平均周期一个月内算合格最后一项要特别问。新机发布之后如果你的业务是抢先适配的那一类补新速度直接决定你能不能赶上第一波用户。3.2 排队时长要用你自己的任务特征去测POC 阶段最容易做假的一项就是跑得快。你在工作日的上午十点提交十个任务各家平台都很流畅因为那是非高峰。真实场景是什么晚上八点到凌晨两点全行业的回归都在跑。所以 POC 一定要包含高峰时段的排队实测最好是连续三天在同一时间段提交相同规模的任务记录提交到开始的等待时间、执行耗时、失败率三个数。我建议的记录表长这样指标采集方式关注点排队时长任务提交到开始执行的时间差看 P95不看平均值执行耗时单任务从开始到结束与自建基线对比任务成功率无环境原因失败的占比低于九成要追问原因设备准备耗时任务下发到设备就绪反映预检机制是否到位重跑率因环境问题重跑的比例高于一成说明稳定性有问题平均值是骗人的一定要看长尾。一个平台平均排队五分钟、但有百分之十的任务要等四十分钟对发版节奏的伤害远大于平均排队十分钟、但最长不超过十五分钟的平台。3.3 脚本兼容性决定了迁移成本的大头这一项直接对应钱。你现有的脚本是用什么框架写的、什么语言写的、有没有依赖特定的驱动版本这些都要在 POC 阶段实际跑一遍。我见过的坑包括平台只支持特定版本的驱动你的脚本用了新特性跑不起来平台的设备上预装的应用版本和你需要的冲突平台对某些系统权限做了限制导致你的脚本拿不到需要的系统信息。改造成本的估算方法很朴素挑十个有代表性的脚本涵盖简单点击流、复杂手势、需要读取系统信息的、需要多应用切换的、需要长连接的在目标平台上实际改一遍记录每个脚本的改动行数和耗时然后乘以你脚本库的规模。这个系数通常在一点二到一点五之间因为越往后遇到的边角情况越多。如果对方平台宣称零改造迁移我建议直接把上面那五类脚本丢过去现场验证。3.4 报告的价值在于缩短定位时间而不是好看报告这块我有个很直接的评价标准一个没写过这个脚本的人能不能只看报告就判断出问题出在哪。好的报告会包含失败步骤的截图、当时的界面层级结构、完整的日志片段、以及前后若干秒的录屏。差的报告只有一句断言失败和一个堆栈。还有一个细节经常被忽略报告的可检索性。跑了一千个用例挂了三十个如果只能一个个点开看光是翻完就要半小时。好的平台支持按失败类型聚合、按用例标签筛选、支持把报告导出成结构化数据供二次分析。如果你的团队有质量看板还要问清楚报告数据能不能通过接口拉出去很多平台的报告是只读的网页导不出来接了看板也只能放个链接。3.5 计费模型的坑通常藏在括号里计费方式是选型里最容易被销售话术带偏的一环。常见的几种模型按设备时长计费、按任务数计费、按并发数包月、按分钟数预付费包。每一种都有自己的适用边界。按设备时长计费看着最公平但如果你的脚本里有大量等待时间比如等待网络请求返回、等待动画结束这些等待也在计费成本会显著高于预期。按并发数包月适合任务量稳定的团队波峰来了要么排队要么加钱。按任务数计费适合用例数不多但单个用例很长的场景。我一般会做一件事拿过去三个月的真实执行数据套进各家的计费公式里算出月度账单然后对比。这个动作花两个小时能避免后面一年的预算争议。还要问清楚几个括号里的问题任务失败重跑算不算钱、设备准备时间算不算钱、提前释放的设备退不退时长、超出套餐的部分按什么单价结算。这几条加起来的差异有时候能到总费用的两成。4. 三类主流平台形态的实测差异4.1 综合型平台能力全但要用得上才划算这类平台的特点是产品线长设备云、自动化执行、性能压测、测试管理、甚至研发协作工具都有账号体系打通一站式解决。优势很明显不用在多个系统之间倒数据报告、缺陷、需求能串起来采购也简单一个合同搞定。劣势同样明显。第一是单价通常偏高因为你在为整套体系付费而你可能只用其中两块。第二是单项能力的深度未必是最强的尤其是压测这类专业性很强的模块综合型平台往往是集成而非自研参数调优的空间有限。第三是耦合风险一旦核心执行跑在它上面后面想换任何一块都会牵动全身。我的判断标准是如果你的团队规模在五十人以上、已经有比较完整的研发流程体系、希望减少系统数量而不是追求单项极致综合型平台是合理选择。规模小、诉求聚焦的团队为全付费是浪费。4.2 垂直专精型平台单点强但要接受拼装这类平台只做一件事比如只做移动端真机自动化或者只做浏览器兼容性。优势是深度。我实测过的一家在设备状态重置这件事上做得非常彻底每个任务结束之后会做一次完整的快照恢复耗时比同行多二十秒但任务失败率明显低一截。这种细节只有长期专注在一个点上的团队才会去打磨。代价是你要接受拼装。设备用一家的、压测用另一家的、报告汇总自己在看板上做数据打通的成本要自己承担。另外这类平台的商务稳定性需要评估规模小的服务方在续约、调价、甚至存续上的不确定性更高签长约之前要看清退出条款。4.3 私有化与混合部署合规和稳定的折中方案有一类团队的诉求很明确测试数据不能出内网。这时候公有云平台基本被排除只能选支持私有化部署的方案或者做混合——设备在本地调度和报告在云上。私有化部署的坑在于它把运维设备换成了运维一整套系统。服务器、存储、升级、故障排查全都回到自己身上。我见过一个团队上了私有化之后专门配了半个人力做平台运维算下来并不比自建省。所以选私有化之前要算清楚你省下的是设备维护付出的是系统维护中间那部分差价才是真实收益。混合部署相对务实一些但要注意网络链路的质量云上调度到本地设备的指令延迟如果超过一定阈值脚本的超时设置全都要跟着调。4.4 三类形态的横向对照对比维度综合型垂直专精型私有化/混合上手速度快文档体系完整中需要自己拼慢部署周期长单项深度中高取决于方案系统整合度高低中单次执行成本偏高中等前期投入大长期看量数据可控性低低到中高迁移退出成本高中极高适合团队规模五十人以上十到五十人有明确数据要求这张表不是让你照着选而是让你看清楚每一项背后的代价。没有哪一类是全赢的选型本质上是挑一个你能接受的代价。5. 从需求清单到 POC 验收的完整流程5.1 需求盘点先写不要什么大部分团队的需求清单是加法的列了一堆想要的功能。我更建议先做减法把明确的排除项写下来预算上限是多少、数据能不能出内网、必须支持哪几个框架、必须兼容现有的 CI 系统。这几条写清楚候选名单通常能从十几家缩到三四家。然后才是加分项。我会把需求分成三档必须满足不满足直接出局、重要影响体验但能妥协、加分有更好没有也行。必须满足这一档我建议控制在五条以内超过五条基本找不到合适的。重要档可以放宽到十条POC 阶段逐条验证。加分档就别在 POC 里花时间了那是签完合同之后慢慢摸索的事。5.2 POC 用例设计刻意制造压力POC 最容易失败的地方是设计得太友好。用十个简单用例、在非高峰跑一遍每家平台表现都不错最后只能靠价格决定这是最糟糕的结果。我的做法是刻意设计四组用例。第一组是规模组两百个用例分到二十台设备测调度和排队。第二组是稳定性组同一个用例连续跑五十次测设备状态重置是否彻底看失败率会不会随次数上升。第三组是边界组涵盖长时任务、需要多应用切换的、需要弱网模拟的、需要读取系统信息的测能力边界。第四组是故障组故意在任务执行中制造中断看平台的恢复机制和报告完整性。这四组跑完差异会非常明显。我印象最深的一次某平台在前三组表现都很好第四组直接把任务卡死设备没释放第二天还在占着配额这种问题不上生产根本发现不了。5.3 商务条款把口头承诺写进合同POC 通过之后进入商务环节这一步的技术含量不比前面的少。几个必须落到纸面上的点服务可用性的具体定义和补偿方式、设备下架或系统停更的提前通知期、价格调整的触发条件和幅度上限、数据导出的格式和频率、合同终止时的数据迁移协助义务。最后一条特别重要。我见过一个团队换平台时要求对方导出历史测试报告对方只能提供网页截图几千条记录全部作废。签合同的时候加一句支持以结构化格式导出全部历史数据成本几乎为零价值极高。5.4 上线之后先并行再切换技术选型确定之后我强烈建议保留至少一个月的并行期。新旧两套同时跑用同一批用例对比结果重点看两件事一是结果一致性两边都失败的用例是不是同一批如果一边过一边挂说明其中一边的环境有问题二是耗时对比用真实数据验证之前的 POC 结论。并行期还是团队适应期。新平台的界面、报告结构、任务配置方式都和旧的不同测试同学需要时间形成肌肉记忆。这段时间的产出会下降要有预期别在并行期就砍掉旧平台。6. 那些文档里不会写的实操细节6.1 在线和可用是两个概念平台界面上显示设备是绿色的在线状态不代表这台设备现在能跑你的脚本。我遇到过的情况包括设备在线但存储空间只剩几百兆安装应用直接失败设备在线但系统时间被上一个任务改乱了导致证书校验失败设备在线但预装的辅助服务挂了脚本连不上。这些在设备列表里全都显示正常。规避办法是在脚本的最前面加一段环境自检检查剩余存储、检查系统时间偏差、检查关键服务是否响应、检查目标应用是否已安装且版本正确。自检不过就直接标记为环境失败不要进入业务逻辑。这段代码写一次能用很久能省掉大量这用例昨天还好好的的困惑。6.2 并发数的文字游戏销售说的支持一百并发和你能实际用上的一百并发中间可能隔着好几层。第一层是账号级并发和项目级并发的区别一个账号一百并发分到十个项目组每组只有十。第二层是并发任务的类型限制有的平台只对特定类型的任务放开高并发复杂任务有单独的配额。第三层是设备池的实际供给即使平台允许你提交一百个并发任务设备池里能同时分配给你的可能只有三十台剩下的排队。验证方法很直接POC 的时候按你预期的峰值并发提交一次看实际同时开始执行的任务数是多少这个数字才是真实并发。问清楚这个数字是固定的还是会随平台负载浮动。6.3 截图、录屏、日志的留存策略要提前定跑一次全量回归产生的截图和录屏可能有好几个 G。平台的默认留存期通常是七天到三十天过期自动清理。问题在于有些缺陷的复现要等到版本发布之后才被发现那时候证据已经没了。我的做法是分层留存失败用例的完整证据长期保留成功用例只留摘要。大部分平台支持按结果配置留存策略如果没有这个功能就用接口把失败用例的证据同步到自己的存储里。另外要注意录屏的清晰度和帧率有些平台为了省空间把录屏压得很糊看的时候根本分不清是渲染问题还是录制问题。6.4 网络隔离环境下的超时设置是个隐形雷如果你的测试环境在内网、平台在公网中间隔着通道那么所有涉及网络等待的地方都要重新调超时。脚本里写死的三秒等待在跨通道场景下可能变成十秒。表现是用例大批量超时失败但单独跑又能过。处理方式是把所有硬编码的等待时间抽成配置项按环境分别设置。同时给脚本加一层重试逻辑针对网络类异常做有限次重试针对断言失败不重试。这个区分很重要断言失败重试只会浪费时间网络抖动重试能救回大量误报。我在实际项目里用这套配置误报率从一成多降到了百分之三左右效果比换平台还明显。7. 关于预算分配的一点个人判断最后说个容易被忽略的角度。很多团队在选型时把预算全部押在平台采购上没有给迁移和适配留额度。按我的经验平台年费和迁移适配投入的比例大概在二比一比较合理。也就是说如果一年平台费用是二十万那就应该预留十万左右的人力成本用于脚本改造、流程对接、团队培训。这个比例听起来高但省下来的代价更大。我见过一个团队为了省适配成本硬是把新平台当成旧平台用所有高级能力一概不碰一年之后复盘发现除了设备不用自己买其他体验和自建没区别。选型的意义在于用上新能力而不是把旧包袱搬个家。提示POC 阶段一定要用自己团队的真实脚本不要用平台提供的示例用例。示例用例是被人反复优化过的跑得好不代表你的脚本跑得好。注意签合同前把历史数据可结构化导出和设备下架提前通知期这两条写进条款这两个条款在换平台时的价值远超你现在的想象。我自己这几年的体会是云测试平台这个品类已经过了拼设备数量的阶段现在的差异全在调度细节、报告质量和工程化程度上。选型时少看宣传页上的数字多花时间做几组自己设计的压力测试答案会比任何对比表格都清楚。