一、什么是CTS?
CTS测试全称为系统兼容测试(Compatibility Test suite),CTS是为了测试手机是否符合google定义的兼容性规范(Compatibility Definition)。从而基于Android的应用程序能在基于同一个api版本的设备上面运行。通过CTS测试的设备可以获得Android的商标,并且享受Android Market的权限。
1.1CTS测试目的
由于Google系统的开源性,很多手机厂商基于安卓系统做出了深度优化,从而造成了安卓移动终端的碎片化,导致android终端的兼容性差的问题,严重影响用户体验。手机通过CTS测试,使市场得到了一个通用的规范:
1.1.1 让App提供更好的用户体验,用户可以选择更多的适合自己设备的app
1.1.2 让开发者设计更高质量的app
1.1.3 通过CTS的设备可以运行Android market
1.1.4 CTS 是一套单元测试,其目的是尽早发现不兼容性,并确保软件在整个开发过程中保持兼容性。
1.2CTS测试运行原理
在pc端安装CTS测试套件,安装完成后,就可以通过连接到pc端的数据线将测试用例发送至手机上,完成测试用例的执行,并且把执行结果返回给PC端。
二、本地怎么进入CTS状态
2.1手机端设置
打开开发者模式
打开不锁定屏幕的开关 (Don't lock screen → on)
打开直接进入系统的开关 (Skip screen lock → on)
打开USB调试;USB安装;USB调试(安全设置)) (USB debugging → on ; Install via USB → on ; USB debugging (security settings) → on )
选择日志级别为Verbose (Select log level → Verbose)
2.2PC端设置
直接下载Google 原生 CTS工具
下载地址 CTS Release
在android-cts/tools 执行 ./cts-tradefed
进入CTS模式
三、本地跑CTS进行测试
3.1进入CTS模式
运行CTS命令
-
整模块测试:
run cts -m [模块] -t [测试模块的类]
-
测试某一个用例:
run cts -m [模块] -t [测试模块的类]#[测试的某一个用例]
-
示例
run cts -m CtsWindowManagerDeviceTestCases -t android.server.wm.PinnedStackTests#testConfigurationChangeOrderDuringTransition
四、测试结果
4.1CTS log和CTS结果
4.1.1log路径
android-cts/logs/cts命令执行时间点/
4.1.2结果路径
android-cts/results/cts命令执行时间点/
4.2结果查看
4.2.1最直接的结果查看在终端输出,直接从终端查看结果
4.2.2文件夹查看log
4.1 中 logs/cts命令执行时间点/ 路径下查看如下两个文件
device_logcat_testxxxxx.txt 为测试的CTS的adb log输出
host_log_xxxxxx.txt 为测试的CTS的结果输出和终端输出几乎无差别
查看测试结果
浏览器打开4.1 中 results/cts命令执行时间点/test_result.html
4.3 感觉log 信息打印不全面/添加log信息
4.3.1开放protolog
如果感觉log显示不全,可以添加log 编译进手机里面进行测试。
也可以使用logging打开protolog开关进行测试(framework)
adb shell dumpsys window logging
adb shell wm logging
4.3.2修改CTS PAK添加log
当测试CTS报错之后,无法暂时无法确定问题原因,可以添加 log进行打印堆栈方便定位问题
CTS测试CASE全部在 源码的 cts目录下,修改的时候需要导入CTS目录
-
编译CTS 测试 APK
-
查找离修改文件最近的Android.bp
-
查找 android_test 便签里面的name信息
-
ninja/make 编译 name
-
将编译好的 CtsWindowManagerDeviceTestCases.apk 放置 qcts/google/cts/cts-12.0_R4/android-cts/testcases 文件夹下,并进行替换。
-
然后用qts测试CTS,查看log输入
示例:
如下图的修改添加堆栈信息
-
执行 ninja/make CtsWindowManagerDeviceTestCases -j16
- 将编译好的 CtsWindowManagerDeviceTestCases.apk 放置 qcts/google/cts/cts-12.0_R4/android-cts/testcases 文件夹下,并进行替换。
- 然后用qts测试CTS,查看log输入。
五、实战案例解析
运行
run cts -m CtsWindowManagerDeviceTestCases -t
android.server.wm.KeyguardLockedTests#testDismissKeyguardActivity_method_cancelled
报错如下:
java.lang.AssertionError: FAILED because unsatisfied: onDismissCancelled of ComponentInfo{android.server.wm.app/android.server.wm.app.DismissKeyguardMethodActivity}
1.报错为testDismissKeyguardActivity_method_cancelled 报错首先找到 testDismissKeyguardActivity_method_cancelled 所在的测试用例查看所测试的项目。
cts/tests/framework/base/windowmanager/src/android/server/wm/KeyguardLockedTests.java#196
2.发现测试用例使用的是 DISMISS_KEYGUARD_METHOD_ACTIVITY 而 DISMISS_KEYGUARD_METHOD_ACTIVITY 是指向的 DismissKeyguardMethodActivity
cts/tests/framework/base/windowmanager/app/src/android/server/wm/app/Components.java#40
3直接找到DismissKeyguardMethodActivity ,查看其内部的实现
cts/tests/framework/base/windowmanager/app/src/android/server/wm/app/DismissKeyguardMethodActivity.java
还有部分权限
cts/tests/framework/base/windowmanager/app/AndroidManifest.xml#299
public class DismissKeyguardMethodActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
getSystemService(KeyguardManager.class).requestDismissKeyguard(this,
new KeyguardDismissLoggerCallback(this, DISMISS_KEYGUARD_METHOD_ACTIVITY));
}
}
将关键代码摘出来 然后单独写成APK,运行在PASS和非PASS的手机上,对比界面和log信息哪里异常。
六、CTS处理方法
6.1 正面分析方法(耗时较长)
代码正面分析有利于理解测试用例的逻辑,可以增加对业务逻辑的理解,增长自己的知识储备。
需要对比Pixel的log定位置问题。
竞品机器反编译代码对比。
6.2 二分法(适合项目紧急,新报的问题)
查看Bug上报的时间,然后选取上报时间前一个星期的版本进行测试,如果PASS 则进行二分法定位到某天提交的代码导致。
如果一个星期前FAIL,则刷取一个月前的版本测试,如果测试PASS,则用二分法继续定位到某天提交的代码导致。
定位到某天之后可以查看自己刷取包的起包时间,将时间范围缩小到最小。
如果未定位到需要正面分析。
无论是那种方法定位到的问题,都要深入分析rootcase的原因。