27、CTS与GTS测试：CTS测试策略，GTS（Google Mobile Services）测试要点
CTS和GTS，这两个词在Android系统开发圈里，几乎是每个工程师的“老朋友”。
说白了，CTS是Google给你发的一张“入场券”，证明你的设备能跑Android应用。而GTS，是Google Mobile Services的“通行证”，没有它，你的设备就别想预装Google全家桶。
我刚开始接触CTS时，觉得不就是跑个测试嘛，能有多难？结果第一次跑完，看到满屏的FAIL项，整个人都懵了。嗯，从那以后，我再也不敢小看这两个测试了。
核心观点：CTS保证兼容性，GTS保证服务可用性。两者缺一不可，但策略完全不同。
CTS测试策略：别想着一次跑完
CTS测试用例成千上万，你不可能一次性全部跑完。我个人的习惯是，分阶段、分模块进行。
1. 模块化测试
CTS按模块划分，比如Camera、Media、Telephony等。我的做法是：
- 先跑核心模块：比如ActivityManager、PackageManager、SystemUI。这些模块出问题，设备基本没法用。
- 再跑硬件相关模块：Camera、Sensor、GPS等。这些跟硬件驱动强相关，容易出问题。
- 最后跑边缘模块：比如Accessibility、DevicePolicyManager。这些模块影响面小，但也不能忽视。
我的经验：我曾经在一次项目里，只跑了核心模块就以为万事大吉。结果在最后阶段，发现Accessibility模块有个测试项挂了，导致整个版本回炉。从那以后，我坚持所有模块至少跑一遍。
2. 增量测试
每次修改代码后，不需要跑全量CTS。我建议：
- 只跑受影响模块：比如你改了Camera HAL，那就只跑Camera相关的CTS用例。
- 使用CTS的--module参数：指定模块名，节省时间。
- 定期跑全量：每周至少一次全量测试，确保没有回归问题。
# 只跑Camera模块
./cts-tradefed run cts --module CtsCameraTestCases
# 跑全量测试（建议晚上跑，第二天看结果）
./cts-tradefed run cts --plan CTS3. 失败用例分析
CTS测试失败，不一定是你的代码有问题。我遇到过的情况：
- 测试环境问题：比如网络不稳定、设备连接松动。先重跑一次看看。
- 测试用例本身问题：有些CTS用例有已知的bug，可以查一下Google的issue tracker。
- 代码问题：这才是我们需要重点关注的。定位到具体模块，分析log。
注意：不要盲目修改代码去“适配”CTS。我曾经见过有人为了通过某个测试项，改了系统核心逻辑，结果导致其他功能异常。CTS测试的目的是保证兼容性，不是让你去“作弊”。
GTS测试要点：Google服务的“守门员”
GTS测试，说白了就是Google用来检查你的设备能不能正常使用Google服务的。比如Google Play、Gmail、Maps等。
GTS测试和CTS最大的区别在于：CTS测试的是Android系统本身，而GTS测试的是Google服务框架。
1. GTS测试的核心模块
| 模块 | 测试内容 | 常见问题 |
|---|---|---|
| GmsCore | Google服务框架的稳定性 | 权限管理、账号同步 |
| GooglePlayServices | Google Play服务的API兼容性 | 地图、定位、支付 |
| GoogleBackupTransport | 备份与恢复功能 | 数据备份失败 |
| GoogleFeedback | 用户反馈功能 | 崩溃报告无法上传 |
2. GTS测试的“坑”
GTS测试里有些“隐藏”的坑，我踩过不少。这里分享几个：
- 时间同步问题：GTS测试要求设备时间与网络时间同步。如果设备时间不准，很多测试项会直接失败。我建议在测试前，先手动同步一下时间。
- 网络要求：GTS测试需要稳定的网络连接。有些测试项需要下载数据，如果网络不稳定，会超时失败。最好用有线网络或者稳定的Wi-Fi。
- Google账号：部分GTS测试需要登录Google账号。测试前，确保设备上已经登录了一个有效的Google账号。
避坑指南：我曾经在一次GTS测试中，发现某个测试项一直失败。查了半天，发现是设备时间慢了5分钟。同步时间后，所有测试项都通过了。所以，测试前一定要检查时间同步。
3. GTS测试的执行策略
GTS测试不像CTS那样可以分模块跑，它更倾向于全量测试。我的建议是：
- 先跑一次全量：看看整体情况，记录所有失败的测试项。
- 分析失败原因：GTS的log比CTS更详细，通常能直接定位到问题。
- 修复后重跑：每次修复后，只跑相关的测试项，而不是全量。
# 跑全量GTS测试
./cts-tradefed run gts --plan GTS
# 跑单个模块
./cts-tradefed run gts --module GtsGmsCoreTestCasesCTS与GTS的协同策略
在实际项目中，CTS和GTS通常是并行进行的。我的做法是：
- CTS先行：先确保CTS通过，再开始GTS测试。因为CTS是基础，如果CTS都过不了，GTS基本没戏。
- GTS跟进：CTS通过后，立即开始GTS测试。GTS的问题通常比CTS少，但修复起来更麻烦，因为涉及到Google服务。
- 回归测试：每次修改代码后，CTS和GTS都要跑一遍。不要只跑其中一个。
我的习惯：我会在项目初期就搭建好CTS和GTS的自动化测试环境。每天凌晨自动跑一次，早上来公司看结果。这样能第一时间发现问题，避免后期积压。
知识体系图：CTS与GTS测试流程
这张图展示了CTS和GTS测试的完整流程。从开始测试，到CTS模块化测试，再到判断是否通过。如果不通过，就修复代码并返回。如果通过，就进入GTS测试阶段。最后，所有测试完成。
嗯，CTS和GTS测试，说白了就是一场“持久战”。你不可能一蹴而就，但只要你掌握了策略，就能事半功倍。我个人的经验是：不要怕失败，每次失败都是一次学习的机会。把失败用例分析透彻，你的系统就会越来越稳定。
最后提醒：CTS和GTS测试不是终点，而是起点。通过测试只是证明你的设备“能用”，但要让用户“好用”，还需要更多的优化和打磨。