1. 编译 CTS
编译 CTS 很简单,只需要如下 3 步。(黑色字体表示命令,灰色背景表示输入命令后的输出信息)
(进入 android 源代码路径)
localhost ~ # cd /work/android_src
localhost android_src # source build/envsetup.sh (进行一些初始化工作)
including device/htc/dream/vendorsetup.sh
including device/htc/passion/vendorsetup.sh
including device/htc/sapphire/vendorsetup.sh
(编译 CTS)
localhost android_src # make cts
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=2.2
TARGET_PRODUCT=generic
TARGET_BUILD_VARIANT=eng
TARGET_SIMULATOR=
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=FRF85B
============================================
.......................................(略)
编译过程可能并不是一帆风顺,一般需要遇到 2 个问题。
1)没有设置 android 的 java 环境变量
没有设置 Java 的环境变量,编译时会出现以下错误:
make: *** No rule to make target `run-java-tool', needed by `out/target/common/docs/api-stubs-timestamp'. Stop.
解决方法:
使用如下命令,设置环境变量。
localhost android_src # export ANDROID_JAVA_HOME=$JAVA_HOME
2)修改编译发现的文件冲突
在编译中会多次出现文件编译冲突现象,这里列举一例:
java.util.zip.ZipException: duplicate entry: hyts_Foo.c
at java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:175)
at java.util.jar.JarOutputStream.putNextEntry(JarOutputStream.java:92)
at sun.tools.jar.Main.addFile(Main.java:713)
at sun.tools.jar.Main.update(Main.java:567)
at sun.tools.jar.Main.run(Main.java:202)
at sun.tools.jar.Main.main(Main.java:1149)
make: *** [out/target/common/obj/JAVA_LIBRARIES/core-tests_intermediates/javalib.jar]
Error 1
make: *** Deleting file `out/target/common/obj/JAVA_LIBRARIES/core-
tests_intermediates/javalib.jar'
解决办法:
出现这个问题是由于源代码中存在多个叫做 hyts_Foo.c 的源文件,只需要把重名的文件删除掉或改名即可。重复文件一般位于 dalvik 目录内。(千万不要把所有叫做 hyts_Foo.c 的文件都删除,那样你就糗大了。一定要留下来一个,建议改名,不要删除文件。)
(在 dalvik 目录内查找 localhost android_src # find dalvik -name hyts_Foo.chyts_Foo.c 文件)
./dalvik/libcore/support/src/test/resources/hyts_Foo.c
./dalvik/libcore/luni/src/test/resources/hyts_Foo.c
localhost android_src #mv dalvik/libcore/luni/src/test/resources/hyts_Foo.c
dalvik/libcore/luni/src/test/resources/hyts_Foo.c.bak
(使用 mv 命令,把 hyts_Foo.c 文件重命名为 hyts_Foo.c .bak)
localhost android_src # make cts (再次 make 即可)
2. 配置开发板上网
要测试 android 网络功能,必须要正确设置开发板的网络功能。看这部分内容之前,大家可能已经看过别人总结的内容了,这里就再罗嗦的提一下,介绍之前,首先
要感谢任云 TX 的帮忙。
主要有以下几步:
1)给开发板开通网络权限,个人电脑开通 USB 和串口权限(这一步是必须的。)
2)连接好网线和串口,通过 mimicom 命令,配置开发板的 IP 地址。
localhost ~ # minicom (启动 mimicom)
启动开发板,可以看到串口打印的信息。
Booted Device: eMMC
Board: EM/EV ES2 (Rev.48044220)
Core: 1.15v
DRAM: 256 MB
Flash: 32 MB
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
## Booting kernel from Legacy Image at 40007fc0 ...
Image Name: Linux-2.6.29
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3914080 Bytes = 3.7 MB
Load Address: 40008000
Entry Point: 40008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
........................(略)
(启用 busybox 的 shell 模式 )
localhost ~ # busybox sh
(配置网卡 IP 地址为 192.168.22.111)
localhost ~ # ifconfig eth0 192.168.22.111
localhost ~ # busybox route add default gw 192.168.22.1 (配置缺省网关为192.168.22.1)
localhost ~ # setprop net.eth0.dns1 192.168.100.200 (配置网口的 dns 服务器地址为 192.168.100.200 )
localhost ~ # setprop net.dns1 192.168.100.200 (配置 DNS 地址为 192.168.100.200 )
(注:以上网络地址仅是个例子,用的时候需要根据具体网络情况进行修改。在配置route 命令的时候,需要开发板预先安装 busybox 软件,不然会配置不成功。板子重
启后,需要重新配置一遍,不然板子会又上不了网。)
3. CTS 测试
用 USB 连接开发板和办公电脑,就可以开始进行 cts 测试了。
测试步骤如下:
1)进入 cts 目录,启动 cts。
localhost bin # pwd
/work/android_src/out/host/linux-x86/bin (cts 可执行程序放在 android 源代码/work/android_src 中的/out/host/linux-x86/bin 路径下。)
localhost bin # ./cts (启动 cts)
启动开发板会在屏幕上显示下面信息。
Android CTS version 2.2_r1
Device(0123456789ABCDEF) connected (开发板已经连接,说明 USB 已经连接好,可以进行 CTS 测试了)
cts_host > start --plan VM (启动 cts 的 VM 测试计划)
start test plan VM
==============================================================
Test package: android.core.vm-tests
dot.junit.opcodes.add_double_2addr.JUnit_Test_add_double_2addr#testB1....(pass)
dot.junit.opcodes.add_double_2addr.JUnit_Test_add_double_2addr#testB2...(pass)
dot.junit.opcodes.add_double_2addr.JUnit_Test_add_double_2addr#testB3....(pass)
........................(略)
如果以前跑过 VM 测试,或由于某种原因导致 VM 测试暂停,在下次 cts 测试,会显示如下信息:
localhost bin # ./cts
Android CTS version 2.2_r1
Device(0123456789ABCDEF) connected
cts_host > start --plan VM
cts_host > There are 1 existing session(s) for plan VM.
Create a new session or choose an existing one?
(表示对 VM 重新进行测试)
Create a new session [0]
(表示从上次中断的地方开始继续进行测试)
Choose a session [1]
(输入 1,从上次中断处继续进行测试)
(VM 如果重新测试过两次及以上,会出现下面的信息,session 值越小,表示上次测试时间离目前时间越远)
Please choose a session from the existed session(s):
1 [0]
7 [1]
(从最早一次开始进行测试)
0
resume test plan VM (session id = 1)
==============================================================
Test package: android.core.vm-tests
dot.junit.opcodes.add_float_2addr.JUnit_Test_add_float_2addr#testN5...(pass)
........................(略)
测试中存在着很多意想不到的情况,会导致 cts 测试中断,可见 cts 功能做得很贴心。上面这点一定要知道,因为它非常重要。
2)测试时注意事项:
如果测试中出现板子跑死了,需要重新开始测试,只需要把板子重新启动,千万不要通过 Ctrl+C 的方式把正在运行的 cts 中断掉,因为在享受(Ctrl+C)带来快感的
同时,很有可能会导致测试结果毁于一旦。这一点非常重要,我在测试 VM 的时候,就多次遇到这种问题,导致测试进度缓慢,一天也没有把 VM 测试完。
(注:这一点也并不是每次必现的,在测试 Java 部分的时候,一次失败都没有遇到 ,但在测试 VM 的时候却多次出现,搞的我真的很郁闷,看来,以后只能多攒点 RP 了 。
通过(Ctrl+C)中断测试真的很爽,如果测试进度要求很紧的话,还是不用为妙,按板子的 reset 键,对于 cts 测试来说,更迅速点,可以一键搞定问题。)
4. 修改 CTS 测试结果(仅限特殊情况下使用)
CTS 测试完成,会生成测试报告,存放在下面路径下:
/work/android_src/out/host/linux-x86/cts/android-cts/repository/results
(/work/android_src 是本人电脑上 android 源代码的存放路径)
以一个 CTS 测试结果为例,生成的目录结构如下:
├── 2010.10.19_10.39.00
│ ├── cts_result.css
│ ├── cts_result.xsl
│ ├── logo.gif
│ ├── newrule-green.png
│ └── testResult.xml
├── 2010.10.19_10.39.00.zip
CTS 测试结果会生成一个按照测试时间命名的 2010.10.19_10.39.00.zip .zip 压缩包,和一个同名的文件夹。可以进入测试结果文件夹中用浏览器打开 testResult.xml 文件,就可以看到 CTS 的测试结果。(注意,测试结果中的 5 个文件一个都不能少,不然用浏览器打不开。)
CTS 默认情况测试时会把所有的测试选项全部测试一遍,但有时,有些功能由于板子不支持,不需要进行测试,就可以通过下面介绍的方法修改 cts 的测试结果。千
万不要为了有个好看的测试结果而使用 ! 以下面这个测试结果为例,介绍下如何把测试结果修改为“notExecuted”。修改之前,一定要记得把需要修改的测试结果备份一下,以防意外。
4.1 把测试结果中的“pass”修改为“notExecuted”
用 gedit 打开 testResult.xml 文件,通过“Ctrl+F”键查找到需要修改的测试选项testGetDefault,查找结果如下图所示。
修改方法:
把 result="pass"修改为 result="notExecuted"即可。
4.2 把测试结果中的“fail”修改为“notExecuted”
通过查找,fail 的结果如下图所示。从测试结果可以看到<StackTrace>之间的内容为测试失败的堆栈调用顺序,这对于定位故障有很好的参考作用。
修改方法:
1)把测试结果中的 result="pass"修改为 result="notExecuted"。
2)删除<FailedScene messag 开始到</FailedScene>的所有内容。
修改后的结果如下:
4.3 修改测试结果的 Summary
用浏览器打开的测试报告,最上面会有个 TestSummary 一栏,修改了测试报告结果之后,还需要把 Tests Passed、Tests Failed、Tests Timed out、Tests Not Executed 值修改正确,也就是简单的算术加减法,同样在 testResult.xml 文件中修改。
下面是修改之前的 Test Summary。
要把它修改为下面的结果。
修改方法:
查找“Summary”,找到测试结果。把修改上面的内容即可,修改结果如下:
4.4 检验修改是否正确
用浏览器打开 testResult.xml 文件,如果浏览器打开时有报错,说明有的地方修改不正确了,可以根据错误提示修改过来。
5. 测试单个测试包或用例
CTS 允许测试单个 package 或 test,这对于重新测试那些没有通过的项目省下了很多时间。以下面的测试结果为例,介绍下测试命令。
5.1 测试单个 packet
上图中 testSendMessages 测试项没有通过,可以把它所在的 package android.telephony.gsm.cts.SmsManagerTest 重新测试一下。测试命令如下。
cts_host > start --plan Java -p android.telephony.gsm.cts.SmsManagerTest
(注:--plan 表示这个 Packet 所在的测试计划,-p 表示所要测试的 packet)
5.2 测试单个 test
如果觉得测试 packet 测试项目太多,也可以对单个测试失败的 testSendMessages 进行测试。测试命令如下。
cts_host > start --plan Java -t android.telephony.gsm.cts.SmsManagerTest#testSendMessages
(注:--plan 表示 test 所在的测试计划,-t 表示具体的 test,android.telephony.gsm.cts.SmsManagerTest#testSendMessages 是由两部分组成,测试的packet 和测试的 test,他们通过#分割开。)
不管是 packet 测试还是 test 测试,一定要建立一个新的 session,因为新 session中的测试项目都是“NotExecuted”,不然由于之前存在的 session 中的测试包或测试项目可能已经测试过,CTS 就不会再重新进行测试。
6. 总结
Android 希望建立一个开放性的平台,可以让开发者在这个平台上面开发出具有创新性的移动应用软件,为了保证这些软件可以运行在各种终端设备上,Android 兼
容性项目定义了 Android 平台的各种技术细节,并提供了测试工具 CTS。CTS 具有多达 2 万多个的测试用例,可以测试 Android 的各个方面。因此,如果一款应用软件可以通过 CTS 测试,说明它具有相当好的兼容性,按照 Android 官方的说法,这款软件就可以在 Android market 上发布了。希望大家都能够用好这款测试工具。
cts_host > start --plan Performance
start test plan Performance
==============================================================
Test package: android.performance2
android.performance2.cts.AppStartup#testStartup..............................................(timeout)
==============================================================
CTS_INFO >>> Max ADB operations reached. Restarting ADB...
CTS_INFO >>> Restarting device ...
CTS_INFO >>> Restart complete.
==============================================================
Test package: android.performance3
android.performance3.cts.AppStartup#testStartup.......(pass)
CTS_INFO >>> Max ADB operations reached. Restarting ADB...
CTS_INFO >>> Restarting device ...
CTS_INFO >>> Restart complete.
==============================================================
Test package: android.performance4
android.performance4.cts.AppStartup#testStartup......(pass)
CTS_INFO >>> Max ADB operations reached. Restarting ADB...
CTS_INFO >>> Restarting device ...
CTS_INFO >>> Restart complete.
==============================================================
Test package: android.performance5
android.performance5.cts.AppStartup#testStartup...(fail)
Unable to find instrumentation target package: com.android.alarmclock
CTS_INFO >>> Max ADB operations reached. Restarting ADB...
CTS_INFO >>> Restarting device ...
CTS_INFO >>> Restart complete.
==============================================================
Test package: android.performance
android.performance.cts.MultiAppStartupTest#testMultipleApps....(fail)
android.content.ActivityNotFoundException: Unable to find explicit activity class {com.android.alarmclock/com.android.alarmclock.AlarmClock}; have you declared this activity in your AndroidManifest.xml? at android.app.Instrumentation.checkStartActivityResult(Instrumentation.java:1404)
at android.app.Instrumentation.checkStartActivityResult(Instrumentation.java:1404)
at android.app.Instrumentation.execStartActivity(Instrumentation.java:1378)
at android.app.ContextImpl.startActivity(ContextImpl.java:622)
at android.performance.cts.MultiAppStartupTest.launchActivity(MultiAppStartupTest.java:52)
(部分略去)
Test summary: pass=2 fail=2 timeOut=1 notExecuted=0 Total=5
Time: 599.253s
本站仅提供存储服务,所有内容均由用户发布,如发现有害或侵权内容,请
点击举报。