1. 先把CTS验的是什么想明白再动手敲命令第一次接触CTS测试的人最容易犯的错是拿到测试包就开始跑跑了十几个小时屏幕上红了一片然后整个人是懵的——不知道这些 fail 到底意味着什么也不知道哪些该修、哪些可以忽略。我在早期也踩过这个坑后来才慢慢意识到CTS 不是跑一遍看结果的工具它本质上是一份契约的自动化落地。说得直白点平台方定义了一份兼容性规范文档里面写满了一台设备要能被称作合格设备必须满足哪些行为而 CTS 就是把这份规范里可自动化的部分拆成几十万个测试用例用统一的框架跑一遍跑完输出一份可复核的结果。所以它的判定逻辑天然是非黑即白的——要么过要么不过不存在差不多过。这篇内容适合三类人看一是刚接手兼容性测试的新人需要知道这套东西的边界在哪二是负责设备软件定版的工程师需要在版本迭代中把 CTS 稳定跑绿三是想把 CTS 接进流水线的工程同学需要理解结果结构和失败分类。不管你基础如何我会尽量把原理、命令、坑点都摊开讲。1.1 兼容性套件的本质把行为约束变成可执行断言很多人把 CTS 理解成功能测试集这个认知偏差会直接导致排查方向跑偏。功能测试关心的是这个功能能不能用比如相机能不能拍照、蓝牙能不能连上而兼容性测试关心的是这个功能的行为是否符合统一约定。举个具体的例子。相机模块里有一条用例验证的是调用预览接口后返回的画面宽高比是否与请求参数一致。如果你只是自己拍张照看看效果那这个功能完全正常但如果你的驱动层对分辨率做了内部裁剪却没有回报真实值这条用例就会挂。它挂的不是相机坏了而是你的实现和约定不一致第三方应用按约定写代码会拿到错的数据。理解这一点之后看测试结果的心态会完全不同每一个 fail 都是在告诉你这里有一处对外承诺没有兑现而不是这里有个 bug 需要修一下。这套约束的价值在于生态一致性。同一个应用装到不同设备上行为应该是可预期的否则应用开发者就要为每一台设备做适配成本会失控。CTS 就是把这个可预期守住的那道闸门。1.2 CTS、CTS Verifier、GTS、VTS 各自管哪一段刚入行时我一度把这些缩写混着叫后来被纠正过一次才理清。它们的边界大致是这样套件覆盖范围执行方式典型用途CTS平台 API 行为、系统应用基础行为全自动版本定版前必跑CTS Verifier需要人工介入的硬件与外设行为半自动人工操作传感器、音频、指纹等GTS平台服务与生态应用的集成行为全自动需要服务授权时使用VTS底层接口与内核模块行为全自动驱动与内核变更后必跑从工程角度看CTS 是主干其余是补充。VTS 更偏底层通常由驱动团队负责GTS 依赖外部服务环境要求更高CTS Verifier 因为要人盯着操作一般安排在整机测试阶段集中做完。有个细节值得注意CTS 和 VTS 有部分重叠用例但判定标准不完全一样。我曾经遇到一个底层改动CTS 全绿但 VTS 挂了原因是 VTS 对某个接口的返回时序要求更严格。所以如果你动了内核或 HAL 层两个都得跑别只跑一个就放心。1.3 什么样的团队真正需要长期跟CTS打交道不是所有团队都要把 CTS 当成日常任务。我总结下来真正需要长期投入的是这几类整机方案团队每次版本升级、每次大版本合并都必须完整回归因为任何一处系统层改动都可能影响某个 API 行为。驱动与底层团队改动集中在 HAL、内核、固件时重点跑相关模块不必全量。系统应用团队改动了设置、媒体、电话这类系统应用需要关注对应的 Cts 模块。持续集成团队负责把测试接进流水线关注的是稳定性、耗时和失败自动归类。反过来如果你只是做上层应用开发CTS 跟你基本没关系——你既不需要跑它也不需要为它负责。搞清楚自己处在哪一环能省下大量无效投入。2. 环境搭建文档一笔带过的地方往往最容易翻车官方文档给的环境要求看起来很简单一台主机、一根数据线、装好依赖、解压测试包。但实际搭下来光是依赖版本对不上和设备状态不干净这两件事就足够让人耗掉一整天。我见过最离谱的一次测试跑到一半突然大面积失败排查了三个小时最后发现是主机系统时间比设备快了四分钟导致证书校验全部超时。2.1 主机侧版本锁定比装最新更靠谱主机环境的核心原则是稳定优先于新。测试框架本身对运行时版本有明确要求装太高或太低都可能出现框架启动失败、模块加载异常这类问题。我一般按这个顺序准备操作系统选长期支持版本别用滚动更新的发行版。测试套件里有些脚本依赖特定路径和系统库滚动更新容易踩到兼容问题。运行时环境严格按测试包内附带的说明文档指定版本安装装完执行一次版本检查命令确认。命令行工具设备通信工具必须用测试包自带的版本不要用系统里已有的。这一点很多人忽略——系统里那套可能是很久以前装的版本不匹配会导致设备识别不稳定、传输大文件时中断。磁盘空间至少预留 200GB。全量测试的日志和截图非常占空间一个完整轮次的日志目录轻松到几十 GB。我曾经因为磁盘写满导致测试中途崩溃日志只写了一半白跑了一夜。提示把测试包解压到一个路径不含空格、不含中文的目录下。有些脚本对路径处理不严谨遇到特殊字符会直接报错而且报错信息完全不指向真实原因。依赖安装完之后先做一次自检启动测试控制台执行设备列表命令确认能列出设备。这一步能过说明基础链路是通的。2.2 设备侧从刷机到干净状态的完整清单设备准备是整件事里最琐碎、也最影响结果的一段。我整理了一份自己一直在用的检查清单每次开测前逐条过一遍系统版本必须是待测的正式候选版本不能用调试版本。调试版本带了额外权限和日志输出很多安全类用例会直接判失败。恢复出厂设置刷完机后必须做一次完整恢复清掉所有残留账户和数据。残留账户会导致账户相关用例异常。屏幕设置关闭自动息屏或者把息屏时间调到最长关闭锁屏密码亮度调到中间值并关闭自动调节。UI 类用例对这几项极其敏感。语言与地区设为英文加默认地区。部分用例断言依赖特定的字符串资源语言不对会直接挂。网络连接一个稳定的无线网络且该网络能访问外网。网络类用例占比不小断网状态下会连片失败。时间同步开启自动同步或手动校准到标准时间。时间偏差超过容差会导致证书、令牌类用例失败。开发者选项按测试要求开启或关闭不要凭感觉。有些用例检测到调试开关被打开会直接判失败。外部存储插入一张格式化过的存储卡如果测试计划要求并确保容量符合最低要求。电量与供电全程插着电源。低电量状态下系统会降频某些性能相关用例会超时。这份清单看着啰嗦但每一条我都见过它导致失败。尤其是锁屏和息屏这两项几乎是新人第一次跑测试的必经之路——测试跑到 UI 相关模块屏幕黑了后面几十条用例连环失败日志里全是找不到控件。2.3 测试包组织目录结构决定你能不能快速定位问题测试包解压后会有几个固定目录理解它们的作用能省很多时间android-cts/ ├── tools/ # 控制台启动脚本 ├── testcases/ # 各模块测试包 ├── results/ # 每轮结果输出 ├── logs/ # 运行期日志 └── repository.xml # 模块清单与配置testcases目录下是成百上千个模块包命名通常是被测范围 测试用例的形式。你不用记全但要知道怎么列出来——控制台里有专门的命令可以列出所有可用模块配合过滤参数能快速找到目标模块。results目录下每跑一轮会生成一个带时间戳的子目录。这个目录是排查的主战场后面会详细讲怎么看。还有一点测试包里通常还会附带一个媒体资源包需要单独下载并放到指定位置。这个包里有测试用的图片、音频、视频样本缺了它媒体类模块会有一大片用例直接报资源不存在。我第一次跑的时候就漏了这一步媒体模块整整挂了三百多条全是同一个原因。3. 跑通第一轮命令背后的调度逻辑命令本身不难难的是理解我敲下这条命令之后系统内部发生了什么。理解了调度模型你才能在测试卡住的时候判断是正常等待还是真的挂死也才能合理地做并行和切分。3.1 调度模型一个指挥官加一堆执行器测试框架的结构可以类比成一个指挥官带一堆执行器。指挥官负责读配置、排任务、收集结果执行器负责在具体设备上跑具体模块跑完把结果回传。这个模型带来两个直接影响第一指挥官是单点。如果指挥官所在的主机出问题比如磁盘满、进程被杀整轮测试就断了。所以主机要做减法——别在上面跑别的重活。第二执行器可以并行。挂多台设备指挥官会把模块分发下去理论上设备数翻倍耗时减半。但实际提速远达不到线性因为有些模块本身就长比如媒体编解码、图形渲染是木桶里最短的那块板。我在一个项目里做过对比单设备跑全量大约 9 小时四台设备并行降到 3 小时出头八台设备并行只降到 2 小时 40 分左右。再往上加设备收益极小因为剩下的是几个超长模块在拖后腿。所以并行数不是越多越好先把耗时最长的几个模块找出来单独优化它们的执行策略比盲目堆设备有效得多。3.2 常用命令组合与参数含义控制台启动后常用的操作大致分四类我把高频命令整理成表目的命令形式说明查看已连接设备设备列表命令确认设备被正确识别状态为可用列出所有模块模块列表命令配合过滤参数可只显示匹配项跑指定模块运行命令加模块参数最常用的形式适合定点验证跑指定用例运行命令加模块与用例参数精确到单个方法排查时用跑整个计划运行命令加计划参数全量回归用查看历史结果结果列表命令列出每轮的通过率摘要几个实战中特别有用的参数分片参数把一个大模块切成若干份分发到多台设备。用法是运行命令后面加数量参数。注意分片数不要超过设备数否则会有设备空转。重试参数只重跑上一轮失败的用例。这个在收尾阶段极其好用能把几小时的回归压缩到十几分钟。超时参数给单个模块设置最长执行时间。有些模块遇到设备异常会一直挂着不返回设了超时能自动跳过避免整轮卡死。输出目录参数指定结果输出位置。做流水线时必用方便按构建号归档。举个实际的组合先在单台设备上跑目标模块确认能过再上多设备做分片全量最后用重试参数收尾。这个三段式流程我用了很久比一上来就全量并行稳得多。3.3 结果目录里真正该看的是这几个文件一轮跑完结果目录里文件不少但真正需要看的就三类第一类是汇总结果文件。通常是结构化格式记录了每个模块、每条用例的执行状态、耗时、失败信息。这个文件是做统计分析的基础写个脚本解析一下就能出通过率报表。第二类是按模块和方法组织的日志目录。结构大致是模块名/用例名/里面装着这条用例执行期间的设备日志、截图、以及可能的堆栈信息。定位问题时 90% 的时间花在这里。第三类是运行期日志。记录框架自身的执行过程包括设备连接、模块下发、异常中断等。测试跑着跑着不动了这类问题看这个日志能快速判断是设备掉线还是模块挂死。注意结果目录里的截图非常有用但数量可能上千张。别一张张翻先按失败用例名筛选出对应的目录再看那个目录里的截图效率高得多。4. 失败项分类把一片红变成可定位的问题跑出失败不可怕可怕的是面对几百条失败没有分类思路。我的习惯是先做一次粗分类把失败按环境型、设备型、测试自身型三堆分开再逐堆深挖。这个动作能把看似无从下手的红海压缩到真正需要人肉排查的十几条。4.1 环境型失败特征明显排除成本最低环境型失败的典型特征是成片出现、集中在特定模块、失败信息指向资源缺失或连接异常。常见的有这几种媒体资源缺失媒体类模块大面积失败失败信息里出现文件不存在读取失败。原因是资源包没放对位置或者放的位置和配置里写的不一致。网络不可达网络类、账户类模块连片失败失败信息里出现超时、连接拒绝。检查设备是否真的连上了外网有些企业网络需要认证设备连上了但出不去。时间偏差证书、令牌、签名类用例失败。检查主机和设备的时间差超过容差就会出问题。语言地区不匹配字符串断言类用例失败。检查设备语言设置。磁盘写满测试跑到后半段突然大面积失败且失败信息五花八门没有规律。看主机磁盘占用。环境型失败处理起来最快因为根因单一、影响面广。我一般的做法是先看失败是否集中在某几个模块如果是优先怀疑环境如果失败散落在各个模块且数量不多那更可能是真实问题。4.2 设备型失败需要看日志才能定性设备型失败的特征是失败点分散、失败信息指向具体行为不符、重跑结果可能不一致。这类才是真正需要投入的部分。按我处理过的案例大致可以分成几类模式失败模式典型表现排查方向时序问题偶发失败重跑能过检查是否存在异步回调未等待、竞态条件数值偏差返回值接近但不等于期望值检查精度处理、单位换算、取整方式权限与安全安全类用例失败检查版本类型、调试开关、签名状态资源竞争多模块并行时失败率上升检查内存、文件句柄、线程池配置硬件相关特定外设模块失败检查驱动、固件版本、硬件连接其中时序问题最磨人。我曾经追一个偶发失败追了两周最后发现是某个服务启动比预期慢了 200 毫秒导致依赖它的用例在等待超时前拿不到结果。这种问题的排查方法是把失败用例单独拎出来连续跑几十次统计失败率同时抓取完整日志对比成功和失败两次的时序差异。资源竞争这一类在并行场景下特别容易冒出来。单设备跑全绿一上四设备并行就出一堆失败八成是资源竞争。这时候要么降低并行度要么给关键模块单独分配设备。4.3 测试自身与版本适配问题不是所有失败都该你修这一点必须说清楚因为很多新人会陷入所有失败都要修的误区。实际上有一部分失败和你无关测试用例本身有缺陷用例实现有 bug或者断言写死了不适用的假设。这种情况在跨版本时尤其常见。规范变更导致的旧用例失效平台规范更新了旧版本测试包里的用例还在按老标准断言。已知问题清单里的条目测试包通常会附带一份已知问题说明里面列了当前版本下预期会失败的用例。这些不属于你的责任范围。处理这类失败的正确姿势是先查已知问题清单再查测试包版本是否匹配待测系统版本。如果版本对不上换对应版本的测试包重跑很多失败会自动消失。我在一个项目里遇到过升级系统大版本后用旧测试包跑安全模块挂了两百多条。当时差点组织人去排查后来发现是测试包版本没跟上换成匹配版本后只剩三条真实失败。这个教训是——开跑前先确认测试包版本和系统版本的对应关系比什么都重要。4.4 一条完整的排查链路复盘讲一个印象最深的案例把前面的方法论串起来。某轮回归图形模块出现 12 条失败失败信息是渲染结果与参考图差异超阈值。第一反应是渲染管线改动导致的但改动清单里没有相关修改。第一步确认是否环境问题。检查资源包完整性——完整检查设备状态——正常检查是否只有这个模块失败——是。排除环境型。第二步确认是否偶发。单独跑这 12 条连跑五轮失败率 100%稳定复现。排除时序问题。第三步看具体日志。打开失败用例目录对比设备日志和截图。截图显示渲染出来的画面比参考图整体偏暗一档。这个信息很关键——不是内容错了是亮度错了。第四步反查配置。顺着亮度这条线查到设备的显示配置里有一项背光曲线被调整过属于另一个需求带入的改动。这个改动让默认亮度输出比标准值低了约 8%。第五步验证结论。把那项配置临时改回默认值重跑这 12 条全绿。确认根因。第六步决定处理方式。这个改动本身是合理的产品需求但影响了兼容性断言。最终的处理是把亮度曲线调整为在测试可接受的容差范围内偏向产品需求而不是简单回退。这个案例说明一件事失败信息往往只告诉你现象真正的根因要靠日志和截图去推。别盯着失败信息本身死磕去看设备在那一刻到底发生了什么。5. 从跑过到稳定跑过工程化的几件事单次跑绿不难难的是每次都能跑绿而且能快速判断这次没跑绿是不是真的有问题。这中间差的是工程化能力。5.1 分模块并行与时间预算前面提过并行的收益递减这里给一个更具体的思路先测一次全量拿到每个模块的耗时数据然后按耗时做装箱。具体做法是从结果文件里解析出每个模块的执行时长排序找出排名前 20% 的模块——它们通常占了总耗时的 60% 以上。然后把这些长模块单独分配设备剩下的短模块打包分发。这样能显著压缩总时长。时间预算上给个参考值一套完整回归在中等规模设备上单设备大约 6 到 10 小时四设备并行大约 3 到 4 小时。如果你的一轮超过 15 小时基本可以确定有模块在异常挂起去查超时设置。提示给长耗时模块单独设一个较长的超时给短模块设短超时。统一设一个大超时会让异常挂起的模块白白浪费时间。5.2 版本变更后的回归策略按改动面裁剪全量回归成本高所以日常迭代更适合做按改动面裁剪的定向回归。我的做法是维护一张改动范围 → 需要跑哪些模块的映射表改了显示相关配置 → 图形、显示、界面模块改了媒体编解码 → 媒体、音频、视频模块改了网络协议栈 → 网络、连接、账户模块改了权限模型 → 安全、权限、账户模块改了电源管理 → 电源、性能、休眠模块动了内核或底层接口 → 全量加底层接口套件这张表不是拍脑袋来的是靠历史失败数据积累出来的。每次出现没想到这个改动会影响那个模块的情况就往表里补一条。跑得越久这张表越准后面定向回归的命中率就越高。大版本合并、发布候选版本这类节点还是要老老实实跑全量。定向回归只是日常提效手段不能替代节点验证。5.3 几个反复出现的误区最后列几条我自己踩过、也见过别人反复踩的误区误区一把测试当作验收而不是发现问题的手段。CTS 跑绿只说明符合约定不说明没有 bug。把它当成质量门禁的一部分而不是全部。误区二忽略失败用例的重跑价值。有一批失败是偶发的重跑一次就过了。我一般会对失败项做一次自动重跑只有重跑仍然失败的才进入人工排查。这个动作能过滤掉三到五成的环境噪声。误区三不做结果归档和趋势分析。每轮结果只存本地跑完就删。等到某天发现通过率莫名下降却找不到历史数据对比。建议按构建号归档结果文件至少保留最近十轮能画出通过率曲线异常波动一眼就能看出来。误区四设备状态管理靠人肉。每次开测前手动检查一遍费时且容易漏。条件允许的话写个脚本自动完成恢复出厂、设置项校准、资源下发这套动作把开测准备时间从二十分钟压到三分钟。误区五只看总数不看分布。通过率 98%这个数字意义有限关键是看失败集中在哪。如果 2% 的失败全集中在某一个模块那这个模块就是风险点如果散布在二十个模块各挂一条那更可能是环境噪声。我在实际项目里的体会是CTS 这东西的投入产出比在前期很低——你要花大量时间搭环境、跑全量、追失败感觉全是苦活。但一旦把环境脚本化、把失败分类流程化、把回归映射表建起来后面每个版本的验证成本会断崖式下降。真正的门槛不在测试本身而在于你有没有把这套东西变成可复用、可自动化的工程流程。
