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

最新推荐文章于 2024-06-11 21:21:16 发布

魔都吴所谓

最新推荐文章于 2024-06-11 21:21:16 发布

阅读量3k

点赞数 6

分类专栏：实用工具 Ubuntu 文章标签： android

本文链接： https://blog.csdn.net/qq_41604569/article/details/129473817

版权

实用工具同时被 2 个专栏收录

121 篇文章 5 订阅

订阅专栏

Ubuntu

8 篇文章 0 订阅

订阅专栏

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 简绍

CTS介绍
CTS测试全称为系列兼容测试（Compatibility Test suite），CTS是为了测试手机是否符合google定义的兼容性规范（Compatibility Definition）。从而基于Android的应用程序能在基于同一个api版本的设备上面运行。通过CTS测试的设备可以获得Android的商标，并且享受Android Market的权限。
CTS测试是一个基于uiautomator安卓原生自动化框架运行的自动化测试。通过CTS测试，保证系统的安全性和稳定性。
GTS介绍
GMS：Google MobileService，即谷歌移动服务。GMS是Google开发并推动Android的动力，也是Android系统的灵魂所在。GTS主要是对安卓手机上的GMS应用相关性能测试。
CTS Verifier 介绍
CTS verifier保证应用程序的可靠运行和用户有一个很好的体验,相对CTS和GTS 最大的不同是verifier 不能自动化测试，只能手工测试。
1.2 CTS测试的目的
由于Google系统的开源性，很多手机厂商基于安卓系统做出了深度优化，从而造成了安卓移动终端的碎片化，导致android终端的兼容性差的问题，严重影响用户体验。手机通过CTS测试，是市场得到了一个通过的规范：
让App提供更好的用户体验，用户可以选择更多的适合自己设备的app
让开发者设计更高质量的app
通过CTS的设备可以运行Android market
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= $P A T H :$ 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 相关文件解压后示意图
三、测试机端预置条件

将设备的语言设置为英语（美国）：设置 > 语言和输入法 > 语言（设置成英文后将中文删除）；
如果设备具有 GPS 或 WLAN/移动网络功能，则打开位置信息设置：设置 > 位置信息 > 开启；
连接到满足以下要求的 WLAN 网络：支持 IPv6，连接到互联网：设置 > WLAN；
确保设备上未设置锁定图案或密码：设置 > 安全 > 屏幕锁定 > 无；
在设备上启用 USB 调试：设置 > 开发者选项 > USB 调试；
确保将时间设置为 12 小时格式：设置 > 日期和时间 > 使用 24 小时制 > 关闭；
依次选择：设置 > 开发者选项 > 不锁定屏幕 > 开启；
依次选择：设置 > 开发者选项 > 允许模拟位置 > 开启；
依次选择：设置 > 开发者选项 > 通过 USB 验证应用 > ；
30min无锁屏
camera应用停用（AOSP版本，GMS版本不需要）
打开opencamera，进入设置点击运行访问
使用 USB 数据线连接用于测试设备的台式机；
需要可供使用的蓝牙设备，并处于打开状态；
复制 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 是有效的。
（待补充）