1. 先把CTS验的是什么想明白，再动手敲命令

第一次接触CTS测试的人，最容易犯的错是拿到测试包就开始跑，跑了十几个小时，屏幕上红了一片，然后整个人是懵的——不知道这些 fail 到底意味着什么，也不知道哪些该修、哪些可以忽略。我在早期也踩过这个坑，后来才慢慢意识到，CTS 不是"跑一遍看结果"的工具，它本质上是一份契约的自动化落地。

说得直白点：平台方定义了一份兼容性规范文档，里面写满了"一台设备要能被称作合格设备，必须满足哪些行为"；而 CTS 就是把这份规范里可自动化的部分，拆成几十万个测试用例，用统一的框架跑一遍，跑完输出一份可复核的结果。所以它的判定逻辑天然是"非黑即白"的——要么过，要么不过，不存在"差不多过"。

这篇内容适合三类人看：一是刚接手兼容性测试的新人，需要知道这套东西的边界在哪；二是负责设备软件定版的工程师，需要在版本迭代中把 CTS 稳定跑绿；三是想把 CTS 接进流水线的工程同学，需要理解结果结构和失败分类。不管你基础如何，我会尽量把原理、命令、坑点都摊开讲。

1.1 兼容性套件的本质：把"行为约束"变成"可执行断言"

很多人把 CTS 理解成"功能测试集"，这个认知偏差会直接导致排查方向跑偏。功能测试关心的是"这个功能能不能用"，比如相机能不能拍照、蓝牙能不能连上；而兼容性测试关心的是"这个功能的行为是否符合统一约定"。

举个具体的例子。相机模块里有一条用例，验证的是"调用预览接口后，返回的画面宽高比是否与请求参数一致"。如果你只是自己拍张照看看效果，那这个功能完全正常；但如果你的驱动层对分辨率做了内部裁剪却没有回报真实值，这条用例就会挂。它挂的不是"相机坏了"，而是"你的实现和约定不一致，第三方应用按约定写代码会拿到错的数据"。

理解这一点之后，看测试结果的心态会完全不同：每一个 fail 都是在告诉你"这里有一处对外承诺没有兑现"，而不是"这里有个 bug 需要修一下"。

这套约束的价值在于生态一致性。同一个应用装到不同设备上，行为应该是可预期的，否则应用开发者就要为每一台设备做适配，成本会失控。CTS 就是把这个"可预期"守住的那道闸门。

1.2 CTS、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 主机侧：版本锁定比"装最新"更靠谱

主机环境的核心原则是稳定优先于新。测试框架本身对运行时版本有明确要求，装太高或太低都可能出现框架启动失败、模块加载异常这类问题。

我一般按这个顺序准备：

1. 操作系统：选长期支持版本，别用滚动更新的发行版。测试套件里有些脚本依赖特定路径和系统库，滚动更新容易踩到兼容问题。
2. 运行时环境：严格按测试包内附带的说明文档指定版本安装，装完执行一次版本检查命令确认。
3. 命令行工具：设备通信工具必须用测试包自带的版本，不要用系统里已有的。这一点很多人忽略——系统里那套可能是很久以前装的，版本不匹配会导致设备识别不稳定、传输大文件时中断。
4. 磁盘空间：至少预留 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 这东西的投入产出比在前期很低——你要花大量时间搭环境、跑全量、追失败，感觉全是苦活。但一旦把环境脚本化、把失败分类流程化、把回归映射表建起来，后面每个版本的验证成本会断崖式下降。真正的门槛不在测试本身，而在于你有没有把这套东西变成可复用、可自动化的工程流程。