4、执行CTS测试：使用cts-tradefed命令行、单模块测试、全量测试、并行测试与超时设置
CTS测试跑起来，说白了就是跟设备较劲的过程。你写好了配置，搭好了环境，接下来就是真刀真枪地执行了。我个人习惯把这一步分成几个场景：单模块调试、全量回归、并行加速，还有最让人头疼的超时问题。咱们一个一个说。
4.1 cts-tradefed 命令行基础
CTS测试的入口是 cts-tradefed 这个命令。你进入 CTS 目录后，直接敲：
cd android-cts
./cts-tradefed
然后你会看到一个 tf> 提示符。这就是 TradeFed 的控制台。嗯，这里要注意，第一次启动可能会慢一点，因为它要加载一堆模块。
我个人习惯把常用命令写成别名，比如：
alias cts='cd ~/android-cts && ./cts-tradefed'
省得每次敲一长串。你在控制台里输入 help 就能看到所有命令。但我建议你重点记住这几个：
run cts– 跑全量测试run cts --module– 跑单个模块list modules– 查看所有可用模块list plans– 查看测试计划
./cts-tradefed run cts --plan CTS 这种一行命令搞定。我在项目中经常用这种方式写自动化脚本。
4.2 单模块测试：精准定位问题
你想想看，全量测试跑一次可能要几个小时。如果只是改了一个小功能，比如蓝牙或者相机，没必要跑全部。单模块测试就是干这个的。
举个例子，我只想测试 Camera 相关的 CTS：
run cts --module CtsCameraTestCases
模块名怎么找？用 list modules 命令，它会列出所有模块。我遇到过新手直接猜模块名，结果拼错了跑不起来。其实你可以用 list modules | grep -i camera 来过滤。
有时候你只想跑某个测试类里的几个方法，可以这样：
run cts --module CtsCameraTestCases --test android.hardware.camera2.cts.CameraTest#testCapture
注意那个 # 号，后面跟的是具体方法名。我曾经在调试一个HAL层bug时，就靠这种精准定位，把问题缩小到了三个测试用例，省了大把时间。
android-cts/results/ 目录下。每个测试结果都有一个时间戳文件夹，别搞混了。我建议你跑之前先 date 看一眼时间，方便对应。
4.3 全量测试：回归的硬仗
全量测试，说白了就是 run cts 或者 run cts --plan CTS。这个命令会跑所有 CTS 模块，包括 ARM 和 X86 的测试。我建议你在发布正式版本前至少跑一次全量。
全量测试的典型输出是这样的：
05-12 14:30:22 I/TestInvocation: Starting invocation: 'cts' on device 'ABCD1234'
05-12 14:30:25 I/Module: Starting module: CtsCameraTestCases
05-12 14:30:25 I/Module: [1/142] CtsCameraTestCases
...
看到那个 [1/142] 了吗？142 是总模块数。我一般会盯着这个数字，如果长时间不动，可能就是卡住了。
全量测试的时间取决于设备性能。我记得有一次在低端设备上跑，整整花了 12 个小时。所以，我建议你：
- 用性能好一点的设备跑全量
- 确保设备不锁屏、不休眠
- USB 线要稳，别中途断开
4.4 并行测试：让时间减半
全量测试太慢了怎么办？并行测试是个好办法。CTS 支持同时跑多个模块，利用多核 CPU 的优势。
启用并行测试很简单：
run cts --shard-count 4
这个 4 表示分成 4 个分片并行执行。你想想看，如果你的机器是 8 核的，设成 4 或者 8 都能明显提速。我一般设成 CPU 核心数的一半，留点资源给系统。
并行测试的输出会有点乱，因为多个模块同时打印日志。但最终结果会汇总到一个文件夹里。你可以用 --shard-index 指定只跑某个分片：
run cts --shard-count 4 --shard-index 2
这个在调试时很有用。比如你发现第 3 个分片总是失败，就可以单独跑它看看。
4.5 超时设置：别让测试卡死
测试卡死是家常便饭。有时候一个测试用例跑着跑着就没反应了，整个测试就停在那里。这时候超时设置就派上用场了。
CTS 支持两种超时：
| 超时类型 | 默认值 | 设置方式 |
|---|---|---|
| 测试用例超时 | 10 分钟 | --test-timeout 600000 |
| 模块超时 | 60 分钟 | --module-timeout 3600000 |
单位是毫秒。比如你想把测试用例超时改成 5 分钟：
run cts --test-timeout 300000
我遇到过一种情况：某个测试用例在特定设备上会死锁，默认 10 分钟超时根本不够。后来我把超时改成 30 分钟，虽然慢了点，但至少能跑完。
还有一个全局超时参数 --max-testcase-run-time，它控制整个测试运行的最大时间。比如：
run cts --max-testcase-run-time 7200000
这个参数适合在 CI 环境中用，防止测试跑太久占用资源。
4.6 综合实战：一条命令搞定
说了这么多，给你一个我常用的实战命令：
./cts-tradefed run cts --plan CTS --shard-count 4 --test-timeout 600000 --module-timeout 3600000 --skip-preconditions --skip-system-status-check
解释一下：
--plan CTS– 跑全量计划--shard-count 4– 4 路并行--test-timeout 600000– 每个用例 10 分钟超时--module-timeout 3600000– 每个模块 1 小时超时--skip-preconditions– 跳过前置条件检查（比如 Wi-Fi 连接）--skip-system-status-check– 跳过系统状态检查（比如电池电量）
这两个 skip 参数在调试时很有用，但正式测试时我建议去掉，因为前置条件检查能帮你发现环境问题。
好了，执行 CTS 测试的核心就这些。单模块调试、全量回归、并行加速、超时控制，这四个点你掌握好了，大部分场景都能应对。下一章咱们聊聊测试结果的分析和报告生成，那个才是真正头疼的地方。