Android 4.0.3 CTS 测试_移动开发_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > 移动开发 > Android 4.0.3 CTS 测试

Android 4.0.3 CTS 测试

 2015/2/27 15:32:56  流柯  程序员俱乐部  我要评论(0)
  • 摘要:Android-CTS4.0.3测试基本配置1.DownloadCTSCTS的获取方式有两种:1.1.由Google提供1.1.1.打开浏览器输入连接:http://source.android.com/compatibility/downloads.html1.1.2.下载所需文件选择对应Android版本的CDD文档(介绍CTS测试),CTS测试包下载(测试包会不断更新),android-cts-verifier-4.0.3_r1-linux_x86-arm.zip,android-cts
  • 标签:android 测试

Android-CTS 4.0.3测试基本配置

1. Download CTS

CTS的获取方式有两种:

1.1.由Google提供

1.1.1.打开浏览器输入连接: http://source.android.com/compatibility/downloads.html

1.1.2.下载所需文件

选择对应Android版本的CDD文档(介绍CTS测试),CTS测试包下载(测试包会不断更新),android-cts-verifier-4.0.3_r1-linux_x86-arm.zip,android-cts-media-1.0.zip

1.1.3.基本文件结构

将下载的CTS测试包解压到相应文件夹里面:android-cts文件夹里面包含Docs、Repository、Tools三个文件夹。

1.1.4.下载android SDK

1.2.通过4.0.3的源码编译得来

在Google提供的Android源码中是包含CTS测试的,源码下可以看到有一个CTS文件夹,里面就是CTS的测试源码。

在Android项目源码下使用命令:

(切换分支,并保证自己的项目源码最新)

./source build/envsetup.sh

choosecombo 1 18 1(仅针对公司自己的手机,我们这儿选择Variant choices :user模式)

make cts

来得到,生成的android-cts包在~/<源码目录>/out/host/linux-x86/cts中。

2.RUN CTS 前期准备工作

2.1.先确定Linux 系统的adb path是否设置正确(我是在虚拟机Ubuntu下模拟的)

Shell 命令:(配置环境变量)

shz@ubuntu:$ cd ~

shz@ubuntu:$ gedit .bashrc

在.bashrc文件中添加

PATH=$PATH:/home/shz/java/jdk1.6.0_35/bin:

PATH=$PATH:/home/shz/sdk/android-sdk-4.0.3/platform-tools:

PATH=$PATH:/home/shz/sdk/android-sdk-4.0.3/tools:

(根据你自己的实际的文件路径来配置)

2.2.确保你所配置的环境变量都正确

shz@ubuntu:$ java

shz@ubuntu:$ adb

查看信息是否正确,如果没有配置好,会有提示

(例如adb: command not found)

2.3.确保手机已正确连接上

shz@ubuntu:$ adb devices 

有的时候会出现这种情况

class="p0" style="margin-left: 30px;">

解决办法:权限问题,给予root权限并在root权限下重启adb server即可。

具体步骤:

shz@ubuntu:$ cd sdk/android-sdk-4.0.3/platform-tools

shz@ubuntu:~/sdk/android-sdk-4.0.3/platform-tools$ sudo su

[sudo]password for shz: (输入密码,回车,root权限)

 

退出root模式:

 

Look,一切OK。

3.调整系统状态

3.1.执行系统重置,恢复为出厂状态

3.2.测试前需要安装apk:adb install android-cts/repository/testcases/CtsDelegatingAccessibilityService.apk

然后在设置里面的辅助功能中会多一个Delegating Accessibility Service选项,将这个选项打开

3.3.测试前需要安装apk:adb install android-cts/repository/testcases/CtsDeviceadmin.apk

3.4.测试前需要安装apk:adb install CtsVerifier.apk

(之前下载下来的android-cts-verifier-4.0.3_r1-linux_x86-arm.zip解压有)

然后在设置安全->选择设备管理器对多出三个选项,将这三个选项勾选并激活

3.5.测试Media相关项需要用到官方提供的一个media包,有三种方式

a).在SD卡中建目录test, 将android-cts-media-1.0.zip解压到test目录中,将SD卡插入设备中。确定SD卡为可读可写状态。

b).在Ubuntu环境下,可以再android-cts-media-1.0.zip解压出来的文档中放在一个新建的test文件夹汇中,直接运行文件夹下的

./copy_media.sh

即可。

 

它会自动把这些media文件拷贝到你的sd卡中。

c).当知道自己的设备适应的视频分辨率,使用

. copy_media.sh 1280x720

将该分辨率及以下的分辨率的视频复制到手机的SD卡中进行测试。

Google一共提供了五种分辨率的视频文件,176x144、480x360、720x480、1280x720、1920x1080。根据自己设备的具体情况添加,公司手机最大支持1080p的视频,但是超过720p之后的视频播放都会很卡,所以我暂定为选择720p的视频来测试。

3.6.在 android设备设置中:安全->屏幕安全保护->自动锁定设为“无”

3.7. 在 android设备设置中:显示->休眠->休眠时间调节到最长

3.8.在 android设备设置中:开发人员选项->保持唤醒状态,允许模拟地址两项勾选(当然了,USB调试也是需要打开的)

3.9.将 android设备的语言设置为英文。

3.10.需要有一张有话费的可正常使用的SIM卡。 

3.11.将WIFI打开,连接一个可用AP(我所在公司的手机为双卡,需要设置好手机的语音、数据、短消息的默认卡)设置->双卡设置

3.12.设置->输入语言设为android 

3.13.手机屏幕停留在主界面

4.RUN CTS

4.1.打开终端,进入android-cts/tools目录

执行命令:

shz@ubuntu:$ cd android-cts/tools

4.2.进入CTS,执行cts-tradefed脚本

执行命令:

shz@ubuntu:~/android-cts/tools$: ./cts-tradefed

 

当手机连接好的时候,执行该命令,会显示出Android设备的ID, 如果没有这句话,说明手机没有和PC连通。调整手机和PC的连接,连接好了之后,就重复第二步里面的内容并给与手机权限:

之后再重复之前的步骤就可以看见Android设备的ID了。

注:有时候进入CTS测试状态后无法出现cts-tf >,此时电脑按一个回车键就可以了。这算是CTS的一个小bug。

4.3开始整个CTS测试

4.3.1.首先我们先使用help命令来看一下cts-tf >里面的信息:

 

在这个里面会显示出CTS测试包的版本:

CTS-tradefed host version 4.0.3_r3

我们可以看一下都有哪些测试plan:

 

测试packages:

 

后面还有许多就不都贴出来了。

4.3.2.开始执行命令

a) 执行一个plan:run cts --plan <plan名称>

全部测试一遍命令:

run cts --plan CTS

b) 仅测试一个包:run cts -p <测试包名称>

例如:run cts -p android.acceleration

c) 因为是基于JUnit测试,属于白盒测试,所有基本上我们都知道它的内部是如何运行的,所以我们也可以根据某个测试包中某一个具体的类或者方法进行测试:

run cts –p <packages name> –c <class name> [-m  <method name>]

d) 多台Android设备同时测试:

run cts –s 设备名称 -plan <plan名称>

注:

 (1)、这儿有一个很重要的命令

我们在进行CTS测试的时候总会有一些因为各种原因引起的不成功的测试项,但是,要完全进行一次全部的CTS测试又是一项很费时的操作,这个时候这个命令就派上用场了,它可以让我们之前测试的结果的基础上,新建一个根据测试结果为fail/not Executed /time out的集合组建出一个新的plan,之后测试这个plan,就可以只需要测试那些之前测试没有通过的项目,而不用再把已经通过的项目再测一遍,就节约了很多时间。

 (2)、在Google的官网上有这么提到过,当我们在测试一个整的包的时候,成功率比单独测一个类和方法要高。

所以,我们再重测一些失败项的时候,根据情况选择测试一个包的模式也是一个不错的选择。

5.测试结果

测试结果在android-cts/repository/results目录下;

测试日志在android-cts/repository/logs目录下。

6. 失败项目重测及xml文档整合

我们在测试一些项目的时候,完全跑一遍CTS测试,很多项都会失败fail,但是我们在对这些失败项单独测得时候,这些项目pass,这时,我们不可能再去重新完全跑一次CTS,这样既耗时,也不能确保该项一定会pass,这样,我们就可以用下面的方法来对失败项操作,做到失败项的pass结果整合。

原理:

将fail项修改成not Executed项,使用该命令进行重测。

6.1. 定位

找到那些测试fail的项,对它们进行源码的修改、调试,之后进行单独测试,直到它不再fail。使用文本编译器打开result的xml文件,找到该项

 

6.2. 修改

找到项目之后,将[result=”fail”]改成[result=”not  Executed”],记得在xml文件的开头将fail总数和not Executed的总数根据你修改的数目进行修改

修改之后:

 

6.3. 测试

session_ID是之前查看result前面的ID。

运行,测试完成,结果就被整合到了原来的result集中,pass项将会把原来的fail的log在result的xml文件中也一并删除。

注意事项:CTS测试中不能对终端做任何操作。

发表评论
用户名: 匿名