【测试】Android CTS系统测试指导手册【详细版】

CTS测试介绍及执行手册

版 本： V0.2
完成时间：20xx-01-30
目录
CTS测试介绍及执行手册
一、 简介 1
1.1 简绍 1
1.2 CTS测试的目的 1
1.3 CTS测试运行原理 1
二、 PC端预置条件 2
2.1 CTS测试工具与测试用例下载 2
2.2 CTS测试Media资源下载 2
2.3 CTS测试环境–SDK下载及其更新 2
2.4 CTS测试环境–JDK安装 3
2.5 PC环境变量设置 3
2.6 相关文件解压后示意 3
三、 测试机端预置条件 5
四、 执行 CTS 6
4.1 测试执行 6
4.2 测试结束 6
4.3 常见问题 7
五、 CTS测试结果解读 9
5.1 测试结果 9
5.2 各文件解析 9
5.3 报告查看（解析报告结构查看） 10
5.4 Bug处理规范 11
六、 更新记录 12
附录1：兼容性测试举例 13
附录2：Ubuntu_Android逆向分析工具 14
附录3：CTS命令（部分，待补充） 16
补充： 错误!未定义书签。

一、 简介
1.1 简绍

1. CTS介绍
   CTS测试全称为系列兼容测试（Compatibility Test suite），CTS是为了测试手机是否符合google定义的兼容性规范（Compatibility Definition）。从而基于Android的应用程序能在基于同一个api版本的设备上面运行。通过CTS测试的设备可以获得Android的商标，并且享受Android Market的权限。
   CTS测试是一个基于uiautomator安卓原生自动化框架运行的自动化测试。通过CTS测试，保证系统的安全性和稳定性。
2. GTS介绍
   GMS：Google MobileService，即谷歌移动服务。GMS是Google开发并推动Android的动力，也是Android系统的灵魂所在。GTS主要是对安卓手机上的GMS应用相关性能测试。
3. CTS Verifier 介绍
   CTS verifier保证应用程序的可靠运行和用户有一个很好的体验,相对CTS和GTS 最大的不同是verifier 不能自动化测试，只能手工测试。
   1.2 CTS测试的目的
   由于Google系统的开源性，很多手机厂商基于安卓系统做出了深度优化，从而造成了安卓移动终端的碎片化，导致android终端的兼容性差的问题，严重影响用户体验。手机通过CTS测试，是市场得到了一个通过的规范：
4. 让App提供更好的用户体验，用户可以选择更多的适合自己设备的app
5. 让开发者设计更高质量的app
6. 通过CTS的设备可以运行Android market
7. CTS是免费的，很简单
   1.3 CTS测试运行原理
   在pc端安装CTS测试套件，安装完成后，就可以通过连接到pc端的数据线将测试用户发送至手机上，完成测试用例的执行，并且把执行结果返回给PC端。CTS测试套件下载连接如下： https://source.android.com/compatibility/cts/downloads
   需要下载文件有：对应手机系统、架构的的测试套件以及CTS Verify、Android Compatibility Defination Document(CDD)、Compatibility Test Suite(CTS) User Manual、CTS Media1.1（音视频资料）。

二、 PC端预置条件
2.1 CTS测试工具与测试用例下载
下载地址：https://source.android.com/compatibility/cts/downloads#cts-media-files；
或服务器路径 ：\10.125.125.125\tools\CTS,下载最新版测试用例；
如当前版本: android-cts-9.0_r8-linux_x86-arm.zip ，如图2-1所示。

图2-1 CTS测试工具与测试用例下载
2.2 CTS测试Media资源下载
下载地址：https://source.android.com/compatibility/cts/downloads#cts-media-files；
或服务器路径: \10.125.125.125\tools\CTS下载最新版测试Media；
如当前版本: android-cts-media-1.4，如图2-2所示。
2.3 CTS测试环境–SDK下载及其更新
a. 获取路径：
服务器路径: \10.125.125.125\tools\CTS
文件名: android-sdk-linux，如图2-3所示。
b. 解压下载文件并切换路径至：.~/android-sdk-linux/android-sdk-linux
c. 执行：
tools/android update sdk --no-ui
（说明文档在：.~/android-sdk-linux/android-sdk-linux /SDK Readme.txt）

图2-2 CTS测试Media资源下载

图2-3 CTS测试环境–SDK下载及更新
2.4 CTS测试环境–JDK安装
https://blog.csdn.net/micheal890915/article/details/76033742
2.5 PC环境变量设置
进入Ubuntu系统用户目录下vim .bashrc，在最后面加：
export PATH=$PATH:$HOME/bin:
/home/your/workspace/CTS/android–sdk-linux/platform-tools: /home/your/workspace/CTS/android-cts/tools:
(红色字体部分需修改为本地地址)
2.6 相关文件解压后示意
操作示例：如图2-4所示（当前版本9.0 r5）

图2-4 相关文件解压后示意图
三、 测试机端预置条件

1. 将设备的语言设置为英语（美国）：设置 > 语言和输入法 > 语言（设置成英文后将中文删除）；
2. 如果设备具有 GPS 或 WLAN/移动网络功能，则打开位置信息设置：设置 > 位置信息 > 开启；
3. 连接到满足以下要求的 WLAN 网络：支持 IPv6，连接到互联网：设置 > WLAN；
4. 确保设备上未设置锁定图案或密码：设置 > 安全 > 屏幕锁定 > 无；
5. 在设备上启用 USB 调试：设置 > 开发者选项 > USB 调试；
6. 确保将时间设置为 12 小时格式：设置 > 日期和时间 > 使用 24 小时制 > 关闭；
7. 依次选择：设置 > 开发者选项 > 不锁定屏幕 > 开启；
8. 依次选择：设置 > 开发者选项 > 允许模拟位置 > 开启；
9. 依次选择：设置 > 开发者选项 > 通过 USB 验证应用 > ；
10. 30min无锁屏
11. camera应用停用（AOSP版本，GMS版本不需要）
12. 打开opencamera，进入设置点击运行访问
13. 使用 USB 数据线连接用于测试设备的台式机；
14. 需要可供使用的蓝牙设备，并处于打开状态；
15. 复制 CTS 测试所需要的Media资源，切换目录至：android-cts -media-X.Y，该文件下有copy_media.sh 与copy_image.sh两个文件；分别执行sh copy_ media.sh 与 sh copy_image.sh,待结束即可；

四、 执行 CTS
4.1 测试执行
执行命令：（共两条）
1.$ ./android-cts/tools/cts-tradefed (终端显示，如图4-1所示)

图4-1 CTS执行第一步终端显示
2.run cts (终端显示，如图4-1所示)

图4-2 CTS执行第二步终端显示
上述两条命令为PC端连接一台手机时，运行所有测试用例；若PC端连接两台手机在执行测试用例时由”run cts” 改为 “run cts –s XXX(手机SN号)”即可； 如若单独跑测试包中的某一条测试用例：run cts -m XXXX(用例名称)；
备注：
若无法正常运行，并提示aapt相关问题请参考附录2。
4.2 测试结束
执行结束：蓝色框代表执行结束后各结果的保存路径
红色框代表执行结束后所需要的时间以及最终执行结果，pass多少，fail多少，如图4-3与图4-4所示；
备注：
每次测试保证把CTS测试用例全部执行，用 “l r”查看，本次CTS测试是否全部执行结束，即not executed一列的数值是0，如果数值不为0，则表示还存在未执行的用例。在某些情况下测试机会出现“冻结（freeze）”、“重启（reset）”以致adb 无法识别设备，所以测试用例之后的状态为：not executed。
首先保证整个测试用例均已执行，not executed数值为0。之后把“失败的测试用例”中的测试用例再执行三遍，排除测试机系统稳定性尤其是“冻结（freeze）”、“重启（reset）”导致的测试失败。
测试用例新建测试计划，然后执行新建的测试计划。新建测试测试使用命令“add derivedplan --plan plan_name -s sessionID -r [pass/fail/notExec uted]”，添加一个新的plan，再用命令“run cts --plan plan_name”运行即可测试没测的项测试SessionID为2的所有fail项，输入命令应为：

add derivedplan --plan cts_fail_1 -s 2 -r fail

图4-3 CTS执行结束

图4-4 终端测试结果呈现
4.3 常见问题
Q1: 运行的过程中会一直处于下载状态：
A1：在执行cts之前先将android-cts-media文件夹下面的media拷贝到Sdcard，切记先拷贝；
Q2: 如果手机与PC断开连接；
A2：不要关闭terminal,插上手机，等候2分钟，cts会继续运行。
Q3: 在执行cts的过程中会发现手机多次重启；
A3：这是正常现象，是因为有的case就是会有重启动作，类似于Monkey模块就会有让手机重启。
Q4: 在运行cts的过程中可能会出现ramdump；
A4：如果遇到此问题，保存asrlog,上报bug,重新run起cts；
Q5: 有时候会发现在runcts的过程中会终止，提示location error；
A5：此时去确认一下手机环境设置有没有将地理位置开启。

五、 CTS测试结果解读
5.1 测试结果
在/CTS/android-cts/results文件夹下面会生一个以开始时间为名称的文件夹，而且还有一个同名的zip文件保存同样的内容，如图5-1与图5-2所示。

图5-1 测试结果文件位置及结构1

图5-1 测试结果文件位置及结构2
5.2 各文件解析

图5-3 文件简要解析

图5-4 总测试报告示例

图5-5 失败用例测试报告示例
5.3 报告查看（解析报告结构查看）
1） Results： 路径；
2） Device Information： SN:XX +测试机编号：XX；
3） Test Summary： 列出case开始结束时间，用例pass与fail数量；
4） Test Summary by Package： 标明cts包名，例如9.0-r5；
5） Test Failures ： 从报告中查数据 ；

图5-6 报告细则解析
6） Detailed Test Report
1、先从报告里面查找到所有的fail项，双击对应的test report 文件下test_result_failures.html文件里面的fail后高亮的testcase去查找fail的详细信息
2、提交bug的时候需要将这些详细信息附在所提交的问题说明下面
问题与解答 ：报告里面分armeabi-v7a和armeabi-v8a的结果，不要看错了模块
5.4 Bug处理规范
Bug提交
1） Subject [Autotest][CTS][Phone][AOSP]XXXXXXXXXXXXXXXXXXXXXXX
2） Assignee 需要整理模块负责人，提交bug按照列表提交，持续更新，没有明确模块的选择 other
3） Category 根据Fail项目，选择对应的模块
4） Description
a.测试版本，AP版本，CP版本
b.CTS的Package
c.测试步骤
d.问题现象
e.手机编号及SN号码
f.log路径

Bug处理		及时处理各类状态的Bug		
		1）	回归	Verified、In_build、Intesting
		2）	待处理	Moreinfo、Reject、Assignee是自己的bug
	
问题与解答 1、多个手机的同一个case均fail了，但是fail的detail可能不一样，需要查看具体fail内容去提交相应的Bug。

六、 更新记录
No. Version Updater Time Note
1 V0.1 Wsw 2
2 V0.2 Wsw 2
3
4
5

附录1：兼容性测试举例
（1）如果需要执行可访问性方面的兼容性测试，则安装“CtsDelegatingAccessibilityService.apk”（adb install –r */android-cts/repository/ testcases/ CtsDelegatingAccessibilityService.apk），并将Settings-> Accessibility -> Delegating Accessibility Service选项打开。假如目录中没有此文件，就省去这一步，一般情况下是没有的。
(2) 如果需要执行设备管理方面的兼容性测试，则安装“CtsDeviceAdmin.apk” (adb install –r */android-cts/repository/testcases/ CtsDeviceAdmin.apk)，并将Setting->Security->DevicesAdministrators->android.devicesadmin.cts.CtsDevicesAdmin等选项打开
(3). 如果需要执行多媒体方面的兼容性测试，则需要执行:
从http://source.android.com/compatibility/downloads.html 下载android-cts -media-X.Y.zip并解压。（我们目前使用的是android-cts-media-1.4）进入解压后的文件夹，并执行sh copy_media.sh, 把测试所需文件copy到手机放置的sdcard中，假如copy失败，可能是手机路径不对，请用gedit打开copy_media.sh文件，同时adb shell进入手机终端，查看手机内存目录与copy_media.sh文件中的目录是否一致。如果不一致，请更改copy_media.sh文件，必须保证copy到手机内存（copy完之后可以打开gallery进行查看），否则会影响后边android.media等与media相关测试包的执行，如下图所示。

附图1 Media资源导入示意

附录2：Ubuntu_Android逆向分析工具
----apktool以及aapt
一、安装apktool
1.下载&安装
官网地址：https://ibotpeaches.github.io/Apktool/install/ 。参考Linux下的安装方式进行安装：

附图2 aapt安装操作
（1）右击wrapper script下载，保存为apktool；
（2）下载apktool的最新版；
（3）将jar包改名为apktool.jar；
（4）分别进入下载的2个文件所在的目录，将其复制到/usr/local/bin/下：
如 sudo cp apktool /usr/local/bin；
（5）将两个文件修改为可执行权限：
进入/usr/local/bin目录下，sudo chmod 755 apktool apktool.jar。
2.测试：
打开终端输入apktool -version，显示对应的版本信息，则说明安装成功。
二、安装aapt
1.新建aapt目录：
在/usr/local/目录下新建aapt目录；
2.解压apktool.jar文件：
将apktool.jar文件解压到任一目录下，我的解压后目录为apktool，找到aapt文件（一般在apktool/prebuilt/ aapt/linux/aapt）。将该aapt文件复制到/usr/local/aapt/目录下。（此时apktool目录则可以删除了）
3.赋予aapt可执行权限：
（1）进入aapt目录下：cd /usr/local/aapt
（2）赋予可执行权限：sudo chmod +x aapt
4.将aapt加入环境变量：
（1）修改/etc/profile：sudo vim /etc/profile
（2）在profile文件末尾添加以下内容：
export PATH=$PATH:/usr/local/aapt
（3）保存文件并退出：按Esc，然后输入冒号（: 注意是英文环境下的冒号），然后输入wq
（4）使配置文件生效：source /etc/profile
5.测试：
重启机器，即可使用aapt。（此时若不重启电脑，在当前终端已经可以使用，可以先做下测试，看是否安装成功。但是再次打开终端就无法使用了，因此需要重启）输入aapt进行测试。会出现如下图所示内容，则说明安装正确：

附图3 aapt安装成功界面

附录3：CTS命令（部分，待补充）
help: 显示最常用命令的摘要；

help all: 显示可用命令的完整列表；
version: 显示版本；
exit: 正常退出 CTS 控制台。所有当前正在运行的测试完成后，控制台将关闭；
3.1 运行说明
run cts
运行默认的 CTS 计划（即完整的 CTS 调用）。 在测试过程中，CTS 控制台可以接受其他命令。 如果没有连接任何设备，CTS 台式机（或主机）将等待连接设备后再开始测试。 如果连接了多台设备，则 CTS 主机将自动选择一台设备。
–plan <test_plan_name>
运行指定的测试计划。
–module/-m <test_module_name> [–module/-m <test_module2>…]
运行指定的测试类和/或方法。例如，run cts --module CtsGestureTestCases 会执行手势测试模块（该命令可以简化为 run cts -m Gesture）。 run cts -m Gesture --test android.gesture.cts.GestureTest#testGetStrokes会运行指定的包、类或测试。
–subplan <subplan_name>
运行指定的子计划。
– module/-m <test_module_name> – test <test_name>
运行指定的模块并进行测试。例如，run cts -m Gesture --test android.gesture.cts.GestureTest#testGetStrokes 会运行指定的包、类或测试。
–retry
重新尝试运行在以前的会话中失败或未执行的所有测试。 使用 list results 获取会话 ID。
–shards <number_of_shards>
将 CTS 运行分为指定数量的独立块，以便在多台设备上并行运行。
–serial/-s
在特定设备上运行 CTS。
–include-filter <module_name> [–include-filter …]
仅使用指定的模块运行。
–exclude-filter <module_name> [–exclude-filter …]
运行时排除指定的模块。
–log-level-display/-l <log_level>
以显示给 STDOUT 的最小指定日志级别运行。有效值：[VERBOSE, DEBUG, INFO, WARN, ERROR, ASSERT]。
–abi <abi_name>
强制要求测试在给定的 ABI（32 或 64）上运行。默认情况下，CTS 会为设备支持的每个 ABI 运行一次测试。
–logcat、–bugreport 和 --screenshoot-on-failure
显示更详尽的故障信息并帮助进行诊断。
–device-token
指定具有给定令牌的给定设备，例如 --device-token 1a2b3c4d:sim-card.。
–skip-device-info
跳过收集设备相关信息的过程。注意：运行 CTS 以寻求批准时，请勿使用此选项。
–skip-preconditions
绕过对设备配置的验证和设置，例如推送媒体文件或检查 WLAN 连接。
3.2 列表说明
list modules： 列出存储区中的所有可用测试模块。
list plans 或 list configs： 列出存储区中的所有可用测试计划（配置）。
list subplans： 列出存储区中的所有可用子计划。
list invocations： 列出设备上当前正在执行的“运行”命令。
list commands： 列出当前在队列中等待分配给设备的所有“运行”命令。
list results： 列出当前存储在存储区中的 CTS 结果。
list devices： 列出当前连接的设备及其状态。 “可用”设备是可正常运行的空闲设备，可用于运行测试。 “不可用”设备是可通过 adb 查看但不响应 adb 命令的设备，不会分配用于测试。 “已分配”设备是当前正在运行测试的设备。
3.3 转储说明
dump logs：为所有正在运行的调用转储 tradefed 日志。
3.4添加说明
add subplan --name/-n <subplan_name> --result-type pass | fail | timeout |notExecuted
创建从上一会话衍生的子计划；此选项会生成可用于运行测试子集的子计划。 唯一的必选项是 --session。其他选项都是可选的，但如果选用这些选项，必须后跟一个值。–result-type 选项可重复使用；例如 add subplan --session 0 --result-type passed --result-type failed 是有效的。
（待补充）