android_CTS资料大全

1.CTS简介

Android兼容性测试套件标准

CTS 测试就是用来确保某手机或者模拟器符合该兼容性规范。

CTS 测试基于 Android instrumentation 测试， 其又基于 JUnit 测试。 说白了， CTS 就是一堆单元测试用例。 这也是 Java 语言的擅长部分。 

目前 CTS 主要包括功能方面的测试，有少数的性能方面的测试。 性能测试未来会越来越多。 

总的来说， 它只包括自动化测试，目的主要是保证 API 的兼容性。由于基于单元测试， CTS 本身不能用于测试多应用交互的情况。 

对我们的帮助： 

1）   应用程序的开发者可以开发出自己应用的单元测试，并将其加入 CTS 测试集。 

2）   设备制造商可以通过周期性运行 CTS 测试，确保没有对 Android 伤筋动骨。

2.CTS目录说明

CTS中主要目录有：tests，tools，apps，development，libs  分别说明如下：

TESTS 文件目录

├─accessibilityservice  

│  

├─ApiDemosReferenceTest  //API   Demo测试用例

│  

├─appsecurity-tests  //放置应用程序安全性测试用例

│  

├─assets //用来放置“原料”文件的，在这个目录中可以包含为流媒体和动画准备的音频文件。

├─anim //卡通动画

  ├─color  //色彩

  ├─drawable //图片

  ├─layout //布局文件

  ├─menu  //菜单

  ├─raw  //未加工文件mp3,video

  ├─values //风格，字符串，数组

│ 

├─config_demo //存放配置测试用例，包括API检验测试，TestPlan  TestResult 

│ 

├─core   // mk, AndroidManifest.xml

│  

├─jni

├─ProcessTest  //放进程测试用例

│  

├─res  //项目资源放置并且编译应用程序的地方。当创建一个新的Android项目，res目录包含3个子目录:drawable,layout,values。前两个是放置并显示图形和布局，values目录放置了XML文件命名字符串，string.xml文件是用来放置遍及程序全局的字符串。在此目录上放置的文件会在R.java（gen目录中）中生成相应的ID，使用时就引用这些ID就行了（引用方式如：@string）。

│  

├─SignatureTest  //存放有关签名的测试用例

│  

├─src    //此目录包含项目里所有的源文件，

│  

├─tests  //源码对应的测试用例，网上下的CTS用例包比SVN上的tests\ests测试用例中 少了一个preference 包

│  

└─vm-tests

Android.mk

AndroidManifest.xml  //此文件是一个指定全局设定的地方，包括程序许可，活动，和意向过滤器等的设定。如果创建一个应用程序，这个文件里相应的也要增加信息。此文件相当于是ASP.NET中的Web.config和Global.asax的二合一。该文件是每个应用都必须定义和包含的，它描述了应用的名字、版本、权限、引用的库文件等

tools (工具包)

    ├─annotation-helper (注解帮助，输入某个符号如：可以获得帮助信息)

    │  └─src

    │      └─spechelper

    ├─cts-api-coverage (Tool that generates a report of what Android framework methods are being called  可生成txt|xml|html形式文件，不知道怎么用)

    │  └─src

    │      ├─com

    │      │  └─android

    │      │      └─cts

    │      │          └─apicoverage (程序入口类：com.android.cts.apicoverage.CtsApiCoverage)

    ├─cts-reference-app-lib  (Base Class that provides common functionality for all Reference Application Tests，主要对activity的startTime及snapShot(屏幕) time控制)

    │  └─src

    │      └─android

    │          └─cts

    │              └─refapp

    ├─dasm (反编译 .d文件(不是很清楚，好像是配置文件))

    │  ├─etc

    │  ├─src

    │  │  ├─dasm

    │  │  │  └─tokens

    │  │  └─java_cup

    │  │      └─runtime

    │  └─test

   (需要在看看) ├─device-setup 

    │  └─TestDeviceSetup(DeviceInfoActivity收集device信息，DeviceInfoInstrument主)

    │      └─src

    │          └─android

    │              └─tests

    │                  ├─getinfo

    │                  └─util (DisableKeyguardReceiver使键盘锁无效，)

    ├─dex-tools

    │  ├─dex

    │  ├─src

    │  │  └─dex

    │  │      ├─reader 主要是对structure的接口的实现(DexAnnotationImpl(签名的注解，解析时用到)DexClassImpl获取class的信息(如，methods,name,fields等),

                                   DexFileImple获取该文件下的class类（  DexClass clazz = dexFile.getDefinedClasses().get(0);）

    │  │      └─structure 接口，定义了结构

    │  └─test

    │      └─dex

    │          └─reader  测试dex下的类

    │              └─util  测试dex下的类 的工具类

    ├─dx-tests

    │  ├─etc

    │  │  └─morescripts

    │  ├─lib

    │  ├─scripts

    │  ├─src    java VM的test，可以运行CollectAllTests.java(对root进行分析取得testCase)

    │  │  ├─dxc

    │  │  │  └─junit

    │  │  ├─dxconvext

    │  │  │  └─util

    │  │  └─util(收集test ； 编译jasmin语言（JAVA 组合语言）)

    │  └─utilclasses

    │      └─util

    ├─host (重要，跟运行框架有关系)

    │  ├─etc

    │  ├─src (对应于android-CTS/tools/cts.jar)

    │  └─test (对应于host/src的testCase)

    ├─signature-tools  (签名，主要分compare 和converter转换)

    │  ├─src  源码

    │  │  └─signature

    │  │      ├─compare

    │  │      ├─converter

    │  │      ├─io

    │  │      └─model

    │  ├─templates

    │  │  ├─delta

    │  │  └─model

    │  └─test  (signatrue-tools/src的testCase)

    │      └─signature

    │          ├─comparator

    │          └─converter

    ├─spec-progress    (检查DOC文档的完整性和正确性)

    ├─test-progress    (test android_doc.html生成)

    ├─test-progress-new (test android_doc.html生成，还不是很清楚多了什么)

    ├─utils  通过分析XML配置文件，取得相应的testCase

    └─vm-tests  (dalvik VM的test,类似于dx-tests)

        ├─etc

        ├─lib

        └─src

            ├─dot

            │  └─junit

            │      ├─format

            │      ├─opcodes

            │      └─verify

            └─util

                └─build  (BuildDalvikSuite  Main class to generate data from the test suite to later run from a shell)

E:\\ANDROID2.2\\CTS\Development 文件目录

    ├─ide 集成开发环境

        ├─eclipse

                ├─.classpath, genclasspath.sh

E:\\ANDROID2.2\\CTS\Libs 文件目录

  ├─ Annotation  用于指定哪些特性需要执行测试用例，为了能执行所有的应用设备都要有特定的注解。

E:\\ANDROID2.2\\CTS\\APPS

└─CtsVerifier

    ├─arduino-helper  //帮助信息

    ├─jni      //mk,cpp  C++代码

    ├─res    //项目资源放置并且编译应用程序的地方

    ├─src  //有关verifier的源码

    └─tests  //src目录对应的测试用例

3.相关文件说明

CTS中有很多Android.mk文件，

Android.mk是整个工程的“Makefile”，其内容如下所示：

LOCAL_PATH:= $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE_TAGS := tests

# Only compile source java files in this apk.

LOCAL_SRC_FILES := $(call all-java-files-under, src)

LOCAL_PACKAGE_NAME := CtsTestStubs

LOCAL_SDK_VERSION := current

include $(BUILD_PACKAGE)

# Use the following include to make our test apk.

include $(call all-makefiles-under,$(LOCAL_PATH))

其中LOCAL_PACKAGE_NAME表示了这个包的名字。这个文件是最终生成的包（*.apk）的名称，注意，包的名称和应用程序目录的名称无关，而与这里的CtsTestStubs的名称有关。

AndroidManifest.xml工程的描述文件说明：

AndroidManifest.xml 是每个android程序中必须的文件。它位于application的根目录，描述了package中的全局数据，包括了package中暴露的组件（activities, services, 等等），他们各自的实现类，各种能被处理的数据和启动位置。 

    此文件一个重要的地方就是它所包含的intent-filters。这些filters描述了activity启动的位置和时间。每当一个 activity（或者操作系统）要执行一个操作，例如：打开网页或联系簿时，它创建出一个intent的对象。它能承载一些信息描述了你想做什么，你想处理什么数据，数据的类型，和一些其他信息。Android比较了intent对象中和每个application所暴露的intent-filter中的信息，来找到最合适的activity来处理调用者所指定的数据和操作。

    除了能声明你程序中的Activities, Content Providers, Services, 和Intent Receivers,你还能指定permissions和instrumentation（安全控制和测试）在AndroidManifest.xml文件中

      package="com.android.app"

      android:versionCode="1"

      android:versionName="1.0">

                          android:label="@string/app_name">

值得一提一些常用之处：

•    几乎所有的AndroidManifest.xml（以及许多其他Android的xml的文件）在第一个元素中包含了命名空间的声明 xmlns:android="http://schemas.android.com/apk/res/android"。这样使得Android中各种标准属性能在文件中使用，提供了大部分元素中的数据。 

•    大部分manifests包含了单个的元素，它定义了所有的application级别组件和属性，并能在package中使用。 

•    任何被用户看作顶层应用程序，并能被程序启动器所用的package,需要包含至少一个Activity组件来支持 MAIN 操作和 LAUNCHER 种类，如上述代码中所见。 

这里是AndroidManifest.xml文件结构的一个详细的列表，描述了所有能被使用的标记。

manifest 

    根节点，描述了package中所有的内容。在它之下能放置：

    uses-permission 

        请求你的package正常运作所需赋予的安全许可。

    permission 

        声明了安全许可来哪些程序能你package中的组件和功能。

    instrumentation 

        声明了用来测试此package或其他package指令组件的代码。

    application 

        包含package中application级别组件声明的根节点。此元素也可包含application中全局和默认的属性，如标签，icon，主题，必要的权限，等等。一个manifest能包含零个或一个此元素（不允许多余一个）。在它之下能放置零个或更多下列组件声明：

        activity 

            Activity 是用来与用户交互的主要工具。当用户打开一个应用程序的初始页面时一个activity,大部分被使用到的其他页面也由不同的activity所实现并声明在另外的activity标记中。

            注意 ：每一个activity必须要一个标记对应，无论它给外部使用或是只用于自己的package中。如果一个activity没有对应的标记，你将不能运行它。

            另外，为了支持运行时迟查找你的activity,你能包含一个或多个元素来描述你activity所支持的操作：

在Activity中可以放置很多控件，一个Activity就是一个类，而且要继承Activity，需要重写onCreate方法。当Activity运行的时候就会通过Android操作系统调用onCreatey方法。

每一个Activity都需要在AndroidManifest.xml文件中配置，Activity中通过来判断执行优先级。

            intent-filter 

                声明了指定的一组组件支持的Intent 值，从而形成了IntentFilter 。除了能在此元素下指定不同类型的值，属性也能放在这里来描述一个操作所需的唯一的标签，icon和其它信息。

                action 

                    组件支持的Intent action 。

                category 

                    组件支持的Intent Category .

                type 

                    组件支持的Intent data MIME type .

                schema 

                    组件支持的Intent data URI scheme .

                authority 

                    组件支持的Intent data URI authority .

                path 

                    组件支持的Intent data URI path .

        receiver 

            IntentReceiver 能使的application获得数据的改变或者发生的操作，即使它当前不在运行。利用activity标记，你能选择地包含一个或多个receiver所支持的元素；

        service 

            Service 是能在后台运行任意时间的组件。利用activity标记，你能选择地包含一个或多个receiver所支持的元素；

        provider 

            ContentProvider 是用来管理持久化数据并发布给其他应用程序使用的组件。

在工程描述文件中，package的名称需要和JAVA文件中包的名称相同，activity 的名称必须和JAVA文件中JAVA类的名称相同，JAVA文件的文件名也必须和其中类的名称相同。

　　而那个android:label的名字既是应用程序在菜单中的名字，也是应用程序启动后的标题.

用到的service和Activity都要在AndroidManifest.xml中声明一下。

android将UI与代码彻底分开，UI以xml的形式存放于res中的layout中，程序可以通过R.java来调用layout中定义的UI元素。strings.xml定义了string、color、style等元素，这些元素可以通过Resources获取。

上面说的R.java是自动生成的文件，它索引了项目中所有的资源，在源代码中作为一种快捷方式使用，来索引已经包括在项目中的资源。

Android“四大天王”：

Activity(用户接口，应用程序中的数据显示)，Intent(传输数据)，Service(数据处理)，Content Provider(存数据，并让有需要的应用程序访问这些数据)

Intent包含的：

Component name

Action

Data

Category

Extras

Flags

为Activity增加控件：

LinearLayout 线形布局

RelativeLayout 相对布局

4.CTS测试环境搭建步骤：

a)Android-sdk安装

1.   平台：虚拟机 + Ubuntu9.10

2.下载android-sdk 2.2   网址：http://androidappdocs.appspot.com/sdk/index.html选   择：linux 环境android2.2 

3.安装android-sdk 2.2 解压下载所得的android-sdk到安装的目录（任意），如：/home/tester/cts/ android-sdk-linux_86。进入/home/tester/cts/ android-sdk-linux_86/tools，运行android可执行文件：双击，点击“在终端运行”，出现

在左菜单中选择“Installed package”选项，点击下方“update All…”按钮，进入更新界面：

选择左边的的package，选择“Reject”，不会更新该package，点击Install。进入更新状态，需要一段时间，长短取决于网速。

4.将platfrorm-tools目录下的adb文件拷贝到tools目录下（安装CTS时会用到）

安装完成。

b)CTS搭建

1.下载CTS包http://source.android.com/compatibility/cts-intro.html

2.在手机或者模拟器上安装CtsDelegatingAccessibilityService.apk

（1）$sudo ./adb install -r /home/tester/cts/android-cts/repository/testcases

/CtsDelegatingAccessibil

ityService.apk

（2）手机或模拟器设置 Settings > Accessibility > Accessibility > Delegating Accessibility Service 

3.进入android/out/host/linux-x86/cts /android-cts/repository/tools目录下，修改startcts脚本文件。将脚本中的SDK_ROOT该成自己的 android SDK路径.

$cd  home/tester /cts/android-cts/repository/tools $vim startcts 修改脚本中出现的第一个SDK_ROOT,如"SDK_ROOT=/home/tester/cts/android-sdk-linux_86"。

4.执行startcts脚本。在执行CTS 测试计划时（执行一段时间后，大于5分钟）会出现没有足够权限启动devices，使用$sudo ./startcts可解决该问题。

5.出现如下提示符表示启动cts并连接设备成功。（红色部分未deviceID，视设备号而定）

Android CTS version 2.1_r2

Device(CB511KADGR) connected

cts_host > cts_host >

6.在“cts_host >”提示符下输入命令,以下为几个常用的命令

help 查看所有

exit 退出

ls -p 列出所有的测试包

ls --plan 列出所有的测试方案

start --plan plan_name 运行一个测试方案，如：start --plan CTS

start --plan plan_name --package package_name 运行一个特定的测试包，如：start --plan CTS --package android.bluetooth 

查看测试报告 

运行测试时，在CTS运行界面能看到测试报告与运行状况。测试完成后可在android-cts/repository/results/下生成详细的测试报告和一些附加信息，其中用日期和时间命名的文件夹下为所有的测试结果，同时文件夹也会被打成一个对应的.zip包方便提交。用浏览器打开.xml文件（默认就是，直接双击）就可以查看所用的测试报告了

常见问题：

a)问题描述：在执行paln时，执行一段时间后会抛异常，异常如下：

CTS_INFO >>> Restarting device ...

Device(HC09MPL00037) disconnected

Exception in thread "Thread-17" com.android.ddmlib.AdbCommandRejectedException: insufficient permissions for device

   at com.android.ddmlib.AdbHelper.setDevice(AdbHelper.java:736)

   at com.android.ddmlib.SyncService.openSync(SyncService.java:1)

   at com.android.ddmlib.Device.getSyncService(Device.java:253)

   at com.android.cts.DeviceManager$DeviceServiceMonitor.run(DeviceManager.java:217)

解决方案：是因为权限不够，提升至root权限可解决，命令如下$sudo ./startcts    

b)问题描述：输入./adb shell 出现如下异常：

error: insufficient permissions for device

解决方案：输入：

$ sudo -s

./adb kill-server

./adb devices

c)问题描述：出现如下异常：Unable to locate  android-sdk-linux_86/tools/adb.

解决方案：是因为android-sdk-linux_86的tools目录下没有adb文件，可以从将platfrorm-tools目录下的adb文件拷贝到tools目录下，或者去SVN上取下（svn路径：https://10.36.158.2/svn/Spirit/02.DevelopLibrary/12.SupportTools/HTC/adb/adb)

d)问题描述：error: device not found。

解决方法：（1）请确认你的手机是否连接电脑，（2）以连接PC，重新拔下来，在连一次（3）如果2操作后还不行，看下USB连接方式是否为默认（仅充电），选htc或USB连接。

e)写入测试结果时报Too many open files的错误，这是因为网络请求过多，也就导致了系统打开的文件过多。每一个连接都会当成“文件”看待的。

解决方案：用ulimit –a 命令查看每个用户允许打开的最大文件数，看到是的1024，把它改大点，用命令：ulimit -n 4096

补充说明：

为了避免一些没必要的错误，在测试前先更改一下手机设置：

1.You need to download the TTS files via Settings > Speech synthesis > Install

voice data before running CTS tests. (Note that this assumes you have Android

Market installed on the device, if not you will need to install the files manually via

adb)

2. It is advisable to log in to the device with a test Google account, not an account

that you actually use.

3. Make sure the device has a SD card plugged in and the card is empty. Warning:

CTS may modify/erase data on the SD card plugged in to the device.

4. Do a factory data reset on the device (Settings > SD Card & phone storage >

Factory data reset). Warning: This will erase all user data from the phone.

5. Make sure no lock pattern is set on the device (Settings > Security & location >

Require Pattern should be unchecked.

Google Confidential

6. Make sure the "Screen Timeout" is set to "Never Timeout" (Settings > Sound &

Display > Screen Timeout should be set to "Never Timeout".

our board have not this selection, so we can select the longest time 30min

7. Make sure the "Stay Awake" development option is checked (Settings >

Applications > Development > Stay awake).

8. Make sure Settings > Application > Development > Allow mock locations is set

to true.

9. Make sure the device is at the home screen at the start of CTS (Press the home

button).

10. While a device is running tests, it must not be used for any other tasks.

11. Do not press any keys on the device while CTS is running. Pressing keys or

touching the screen of a test device will interfere with the running tests and may

lead to test failures.

CTS Study

1. CTS简介

CTS 全称Compatibility Test Suite兼容性测试工具。当电子产品开发出来，并定制了自己的Android系统后，必须要通过最新的CTS检测，以保证标准的android application能运行在该平台下。通过了CTS验证，需要将测试报告提交给Google，已取得android market的认证。

CTS是一款通过命令行操作的工具。目前cts没有提供windows版本，只能在Linux下测试。在我们实际使用CTS的过程中，很可能需要根据特定的要求，来定制自己的Test Plan。这时就需要自己编译CTS，因此，本文主要向大家介绍如何编译CTS，及使用编译出的CTS工具。至于从android官网上取得的CTS，其使用方式与我们自己编译的工具类似，本文只做简单介绍。

2.获取CTS工具

假定Developer之前已经搭建好，linux环境。以下操作均在linux下进行。由于google的原因，Android 2.3 Gingerbread中的CTS是不完整的，所以我们选择Android2.2 Froyo的CTS作为本文的研究对象。以下附上Google的回复：

Theoretically, CTS for Gingerbread should be built the same way as for Froyo.

However (and this is important), please note that the CTS version

that's currently in the gingerbread branch is incomplete. We're

working on that, but the long holiday breaks have made progress slower

than usual.

http://groups.google.com/group/android-building/browse_thread/thread/53de18db6af17513

从回复中看， Gingerbread中CTS的编译过程和Froyo是一样的，命令使用方法是一样的。我猜测，有可能在Gingerbread中加入了一些新的测试，毕竟android对硬件的要求是越来越高了，从CDD可以看出。

2.1 下载编译源码获取CTS工具

2.1.1 下载

git下载的android源码里包含cts，位置在/cts目录下（android2.1以后版本）

如果没有也可以从此处下载git://android.git.kernel.org/platform/cts.git（源码70M左右）

2.1.2 bit System步骤 

我们一般配置的是32bit系统，没有对bit system 操作CTS做详细研究，仅仅从网上摘抄CTS工具编译步骤。

● bit System

在Linux下进入android源码根目录，输入以下命令：

$ build/envsetup.sh

$ make cts

此时生成测试计划，测试包，测试用例，和测试报告生成的目录

2.1.3 32bit System步骤

●32 bit System

修改默认的Java环境：

sudo apt-get install sun-java6-jdk

sudo update-java-alternatives -s java-6-sun

修改以下文件：

◆\\external\\clearsilver\\java-jni\\Android.mk

◆\\external\\clearsilver\\cgi\\Android.mk

◆\\external\\clearsilver\\cs\\Android.mk

◆\\external\\clearsilver\\Android.mk

将m改为m32

◆\\build\\core\\main.mk

将 改为 i686

◆/build/core/tasts/cts.mk

◆/out/host/linux/cts/android-cts/tools/startcts

◆/development/testrunner/test_defs/host_test.py

◆/cts/tools/utils/startcts

将DDMS_LIB = ddmlib.jar 改为 DDMS_LIB= ddmlib-prebuilt.jar 

或者编译完成后，在\out\\host\\linux-x86\\framework目录下输入linux命令：

cp ddmlib-prebuilt.jar ddmlib.jar 这样比较方便。

方法比较多，只要保证让脚本找到所需的jar文件。

编译：

在Linux下进入android源码根目录，输入以下命令：

$ chmod 777 build/envsetup.sh 

$ build/envsetup.sh

$ make cts

此时生成测试计划，测试包，测试用例，和测试报告生成的目录，

编译好cts后生成的文件位置如下：

#mydroid/out/host/linux-x86/

在该目录下包含如下测试文件

◆Package CTS : out/host/linux-x86/cts/android-cts.zip

◆cts make file : mydroid/build/core/tasks/cts.mk

◆run cts program : mydroid/out/host/linux-x86/bin/cts

◆test plans : mydroid/out/host/linux-x86/cts/android-cts/repository/plans

◆test packages : mydroid/out/host/linux-x86/cts/android-cts/repository/testcases

◆test results : mydroid/out/host/linux-x86/cts/android-cts/repository/results

◆CTS program settings value : mydroid/cts/tools/utils/host_config.xml

配置Framework环境变量：

export ANDROID_ROOT=/[MyAndroid]/out/host/linux-x86

2.2 下载gongle发布的CTS工具

点击Android 2.2 R4 Compatibility Test Suite (CTS) 下载CTS工具

现在Google最新发布的CTS工具是android 2.2 froyo本版的，以后可以针对需要下载对应的CTS版本。

3.使用

3.1 修改环境变量

3.1.1编译的CTS

CTS 和android SDK工具目录如下：

/out/host/linux-x86/bin

/android-sdk-linux_86/platform-tools

/android-sdk-linux_86/tools

将CTS工具路径和android SDK 工具路径加入环境变量，在linux下输入以下命令：

env

查阅原有环境变量，其中环境变量PATH的值为：

PATH=/home/hanqigcxy/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/hanqigcxy/bin:

export PATH=/home/hanqigcxy/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/hanqigcxy/bin:/home/hanqigcxy/android-source/out/host/linux-x86/bin:/home/hanqigcxy/android-sdk-linux_86/platform-tools:/home/hanqigcxy/android-sdk-linux_86/tools 

将CTS和android SDK工具目录加入到环境变量中，如上红色部分所示。注意要求输入完整路径，各路径以分号间隔。

3.1.2 Goole发布的CTS

如果使用的是Google发布的CTS工具路径为：

CTS 和android SDK工具目录如下：

/android-cts/tools 

/android-sdk-linux_86/platform-tools

/android-sdk-linux_86/tools

将CTS工具路径和android SDK 工具路径加入环境变量，在linux下输入以下命令：

env

查阅原有环境变量，其中环境变量PATH的值为：

PATH=/home/hanqigcxy/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/hanqigcxy/bin:

export PATH=/home/hanqigcxy/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/hanqigcxy/bin:/home/hanqigcxy/android-cts/tools:/home/hanqigcxy/android-sdk-linux_86/platform-tools:/home/hanqigcxy/android-sdk-linux_86/tools 

将CTS和android SDK工具目录加入到环境变量中，如上红色部分所示。注意要求输入完整路径，各路径以分号间隔。

进入/out/host/linux-x86/cts /android-cts/repository/tools目录下，修改startcts脚本文件。将脚本中的SDK_ROOT该成自己的 android SDK路径。 

$cd /home/hanqigcxy/Downloads/android-cts/tools $vim startcts 

修改脚本中出现的第一个SDK_ROOT,如：

"SDK_ROOT= /home/hanqigcxy/android-sdk-linux_86 "。

注意：启动CTS的时候，应该输入startcts。

3.1.3 将环境变量写入系统

上面配置环境变量使用Linux命令：

export

使用该命令设定的环境变量仅仅对当前的shell有效。如果用户再开启一个shell，那么需要再次设定环境变量。这是使用export命令的局限。但是最大的好处就是保证的系统的纯净，每次操作仅仅对当前有效。

下面提供一种将环境变量写入配置文件的方法。户用不必每次启动Shell后，都要设定环境变量：

Step1：输入命令，切换到root权限：

su

输入password回车

Step2：进入用户文件夹，编辑.bashrc文件，例如在ubuntu下我有一个用户hanqigcxy

cd  /home/hanqigcxy

ls  -al

vim  .bashrc

修改export PATH=$PATH:$HOME/bin:为：

export  PATH=$PATH:$HOME/bin:

/home/hanqigcxy/android-source/out/host/linux-x86/bin:

/home/hanqigcxy/android-sdk-linux_86/platform-tools:

/home/hanqigcxy/android-sdk-linux_86/tools

Step3：启动系统

reboot –n

3.2 连接设备

3.2.1 模拟器测试

由于我们只需要用模拟器来模拟设备，因此不必搭建完整的linux下android开发环境。

仅需要下载Android SDK并安装。见以下步骤：

◆安装Android SDK

Step1：点击下面链接，进入下载页面

  http://developer.android.com/sdk/index.html

Step2：点击android-sdk_r08-linux_86.tgz下载SDK

Step3：解压后文件目录

Step4：添加环境变量，在linux下输入以下命令

export Path =………….：/home/hanqigcxy/android-sdk-linux_86/tools

其中省略号代表环境变量Path原来的值，对系统原有的环境变量不能删除，仅仅在末尾加入一个新的换进变量路径即可。/home/hanqigcxy/android-sdk-linux_86/tools为android-sdk-linux_86/tools目录的全称，根据用户解压路径来定，修改的值可通过右键------属性来查阅。

Step5：输入以下命令，开启android SDK and AVD Managerment

$ android

Step6：设定代理

Step7：选定需要安装的插件

◆创建AVD

◆启动模拟器

$ emulator -avd CTS

◆启动连接

再开启一个Shell，输入以下命令：

$ adb start-server

$ cts

如果连接成功将显示一下提示：

Android CTS version 2.2_r1

Device(emulator-5554) connected

cts_host > cts_host >

3.2.2 Device测试

（网络资源加自己的推测，需要设备做验证）

◆在手机上安装CtsDelegatingAccessibilityService.apk 

$sudo adb install -r 

………………………………………………./out/host/linux-x86/cts/android-cts/repository/testcases/CtsD

elegatingAccessibilityService.ap k 

省略号代表CtsDelegatingAccessibilityService.ap k所需要的完整路径

◆设置手机

Settings->Accessibility->两个选项都选上；Settings > Application > Development 三个选项都选上；Settings > Sound & Display > Screen Timeout should be set to "Never Timeout"; 

◆修改脚本

export Path =………….：/home/hanqigcxy/android-sdk-linux_86/tools

其中省略号代表环境变量Path原来的值，对系统原有的环境变量不能删除，仅仅在末尾加入一个新的换进变量路径即可。/home/hanqigcxy/android-sdk-linux_86/tools为android-sdk-linux_86/tools目录的全称，根据用户解压路径来定，修改的值可通过右键------属性来查阅。

◆启动连接

再开启一个Shell，输入以下命令：

$ adb start-server

$ cts

如果连接成功将显示一下提示：

Android CTS version 2.2_r1

Device(emulator-5554) connected

cts_host > cts_host >

題目1：CTS 在手機上的測試步驟？（測試機 HTC G7）

    Step 1. 通過USB 連接手機和PC

    Step2. 調整HTC G7 USB的連接方式為 【HTC sync】，使G7允許USB調試。

    上述操作後，自動彈出以下界面

    Step3. 在Linux下輸入以下命令：

    切換到root權限

    hanqigcxy@ubuntu:~$ sudo -s

    [sudo] password for hanqigcxy:

    root@ubuntu:~# adb kill-server

    root@ubuntu:~# adb devices

    顯示以下結果

    Step4. 安裝CtsDelegatingAccessibilityService

    root@ubuntu:~# adb install -r /home/hanqigcxy/android-source/out/host/linux-x86/cts/android-cts/repository/testcases/CtsDelegatingAccessibilityService.apk

    顯示以下結果

    Step5. 配置手機

    可能根据不同的手機，設定也会不一樣，例如網上的例子要求

    Settings->Accessibility->两个选项都选上；    

Settings > Application > Development 三个选项都选上；

Settings > Sound & Display > Screen Timeout should be set to "Never Timeout";

    HTC G7 的實際設定：

    在Step2.中 選擇 【保持喚醒狀態選項】

    進入設置 > 應用程序 > 開發  把三个选项都选上；

進入設置 > 輔助功能 把兩個選項都選上

    总之不管什么设备，需保证一下几点：

    1. 設備的默認連接為USB調式，不能為USB充電或者USB磁盤驅動器

    2.設定設備始終為喚醒狀態

    3.設定權限，保證Host端操作無阻礙。

    Step 開啟CTS工具進行CTS測試

題目2  adb 如何知道設備被接入？

    adb usb                      - restarts the adbd daemon listening on USB

    會有一個監聽USB的daemon，當設備通過USB介入後，可以做判斷。

connect [:] - connect to a device via TCP/IP

    另外還有一通過TCP/IP的接入方法。模擬器應該是採用此方法連接。

        下圖，是我同時開啟模擬器和 HTC G7後，調用adb查看的設備列表

    當一台PC機上連接有多個設備時（例如多個android 手機），CTS可以指定在特定的設備中運行，但需要保證，同一時間是有一個設備上在運行CTS, 

    並且CTS內部也有單例模式。保證一個Host端，只能運行一個CTS。

題目3 ：CTS測試需要多少時間？

    Host ：Ubuntu 10.04（虛擬機上運行）

    Client： HTC G7

    報錯：Log 信息如下，也可見附件

CTS_DEBUG >>> 1295313461352 mark mNeedRestartAdbServer to true

CTS_DEBUG >>> 1295313461353 Need restart ADB server

    CTS_INFO >>> Max ADB operations reached. Restarting ADB...

CTS_DEBUG >>> 1295313461461 device HC09MPL002 changed with changeMask=4

CTS_DEBUG >>> 1295313461461 Device state:ONLINE

    Device(HC09MPL002) connected

CTS_DEBUG >>> 1295313461617 device HC09MPL002 changed with changeMask=2

CTS_DEBUG >>> 1295313461621 Device state:ONLINE

CTS_INFO >>> Restarting device ...

TS_INFO >>> Restarting device ...

CTS_DEBUG >>> 1295315511400 executeCommand(): cmd=adb -s HC09MPL002 reboot

CTS_DEBUG >>> 12953155200 device HC09MPL002 changed with changeMask=2

CTS_DEBUG >>> 12953155202 Device state:ONLINE

    Device(HC09MPL002) disconnected

    分析：

    錯誤出現在ADB 操作超過了最大，必須重啟ADB

    之後手機自動重啟，重新啟動後，CTS測試失敗。

    嘗試修改CTS  的配置文件   host_config.xml中的參數

    防止手機重啟。結果失敗

    網上的解答是，USB驅動出現問題，要完成測試需要做修改，我判斷是HTC修改了USB驅動，了通過USB進行調試。過多的adb命令將到時重啟

    我分析不像是這個原因，有個能是廠商對USB調式做了，或者是adb內部有問題下面用模擬器驗證一下

    用模擬器進行了CTS完成測試：

    創建了性模擬器，包含了所有可模擬的硬件：

    結果：用了一天时间，發現CTS Plan仍然没有完整的执行完毕。但是单独执行CTS中的某一package确实比较快，分别执行CTS包含的52个package。每個平均耗時10 -15分鐘

             以此計算， 9 -13小時可以完成測試

    分析：

    1. 為什麼執行完整的CTS plan 會如此耗時？

        主要原因是，CTS Plan 的测试过程中，adb总会出现 以下几个问题：

        Max ADB operations reached. Restarting ADB...     造成设备多次重启

        Installing met timeout due to Unknown reason.     造成某个apk总是安装不上， 就卡在哪里不停的重新安装，当到时adb操作超过上限时，测试机重启

        Uninstalling met timeout due to Unknown reason. 造成某个apk总是卸载不了，就卡在哪里不停的重新卸载，当到时adb操作超过上限时，测试机重启

    2. 為什麼執行單個package時間也不短？

    首先，執行單個package，重複使用adb的命令的次數少，出現問題1的概率小，不會造成adb出問題

    那麼主要原因因該是：在WIN7系統上用虛擬機跑linux。這樣host端（linux）和clien端（Android AVD）都運行在虛擬機上。硬件的利用率不高。

    如果用Linux系統直接測試設備，時間應該會短一點。

    結論：

    1. 建議不要執行整個Plan，分Package 或Test執行，比較好

    2. 在一次測試結束後，不論結果成功與否，都要將CTS所安裝的apk完全卸載，避免下次測試失敗。

    3. 建議不要在虛擬機上跑Linux，直接裝Linux系統。

另外需要更正一點：

測試結果，包含package的測試是否通過

也包含每個test item 的測試情況。

3.2 CTS 命令详解

在讲解CTS命令之前，先阐述CTS测试中几个概念：

Test Plan（Plan）：测试计划，Test package的集合，每次Plan中都包含若干个测试包

Test Package（Package）：测试包，Test case的集合

Test case：测试用例，Test的集合

Test：测试，每一个测试对应一个或者多个Instrumentation Test

Instrumentation Test：Android测试环境的核心是一个Instrumentation框架，在这个框架下，你的测试应用程序可以精确控制应用程序。使用Instrumentation，你可以在主程序启动之前，创建模拟的系统对象，如Context；控制应用程序的多个生命周期；发送UI事件给应用程序；在执行期间检查程序状态。Instrumentation框架通过将主程序和测试程序运行在同一个进程来实现这些功能。关于Instrumentation将在下一节CTS测试的含义及原理中详细介绍。这里只要明确一个概念。

Result_Type：CTS的测试结果可以通过命令查阅，也可以通过浏览器查看下結果文件

命令查阅结果：

其中Test result 有四种类型的值：Pass， Fail， Timeout， NoExecuted

    浏览器查看XML文件：

运行Performance 测试Plan

结果文件testResult.xml. 

路径： /out/host/linux-x86/cts/android-cts/repository/results/2011.01.04_00.16.40

上图为performance plan所包含的Test package的测试结果，可以看到这次测试每一个Test package的测试结果类型（result_type）都为Timeout，关于测试结果的分析，我们将在CTS Debug分析中介绍，这里主要让大家明确result_type的含义。

小结一下，为了理解CTS命令的意义，我们必须明确Plan，Package，Testcase，Test，result_type,session的含义：

CTS将Test组合为Testcase，Testcase再组合为Package，最后由Package组合为Plan。

CTS可以执行一个Plan，一个Plan的某个Package，一个Plan的某个Test。

CTS执行的结果以Session_ID来标识一个测试结果。

CTS的结果类型result_type包含Pass， Fail， Timeout， NoExecuted四种

上面的介绍，主要想帮助大家理解CTS命令。下表详细列出的CTS命令。

参考资料：Compatibility Test Suite (CTS) Framework UserManual选择红色部分下载。

◆Avaiable commands and options:

4.1 CTS Plan

在android 2.2的 cts中包含8个可用的Test Plan

1)CTS：包含21000个测试，这些测试是检验兼容性所必须的，性能测试不包含在本计划中。随本版的跟新，本测试计划也将更新。

2)Signature：包含所有针对公有APIs的署名测试。

3)Android： 包含针对android APIs的有所测试

4)Java：包含所有针对Java核心library的测试

5)VM：包含针对虚拟机的所有测试

6)RefApp：包含针对参考应用程序的所有测试，随本版的跟新，本测试计划也将更新。

7)Performance：包含所有针对性能的测试，随本版的跟新，本测试计划也将更新。

8)AppSecurity：没有官方说明，猜测是针对Application安全性的测试集合

4.2 CTS Test和Instrumentation Test

编译好的CTS工具存放在android-cts文件夹中，CTS包含的含的Plan和Package存放在repository目录中：

Plans文件夹存放CTS Plan

Testcase文件夹存放 CTS Package，Package 以apk 和xml文件形式存在

Host_config.xml为配置文件，主要设置Plan中最大的test个数，测试Timeout时间等参数，比较简单，可以自行查看。

输入命令查看某个Plan的内容：

~/mydroid/out/host/linux-x86/cts/android-cts/repository/plans$ cat CTS.xml

…………………………………..

可见，某个 test plan 只需要包括一个到具体测试用例的 uri 申明即可。该 uri 的定义在 test cases 子目录下，例如以上面的一个uri="android.apidemos.cts”为例，我们可以到test cases 子目录下查找名称中带有“apidemos”字符的XML文件，我们找到ApiDemosReferenceTest.xml，打开查看：

查看对应package的xml文件

~/mydroid/out/host/linux-x86/cts/android-cts/repository/testcases$

 cat ApiDemosReferenceTest.xml

appNameSpace="android.apidemos.cts" appPackageName="android.apidemos.cts" jarPath=""

name="ApiDemosReferenceTest" packageToTest="com.example.android.apis" 

referenceAppTest="true" runner="android.test.InstrumentationTestRunner" 

targetBinaryName="" targetNameSpace="" version="1.0">

从xml文件中红色标识部分：

apkToTestName="ApiDemos"

appPackageName="android.apidemos.cts"

name="ApiDemosReferenceTest"

我们可以看出CTS Plan中包含的Package “android.apidemos.cts”正是对应着Package 中：

ApiDemosReferenceTest.apk

ApiDemosReferenceTest.xml

ApiDemos.apk

从xml文件中紫色标识部分：

runner="android.test.InstrumentationTestRunner"

Test name="testNumberOfItemsInListView"

可以看出CTS Plan中包含的Package “android.apidemos.cts”调用

InstrumentationTestRunner来执行一个InstrumentationTest。这个test就是

testNumberOfItemsInListView。当然这里只执行了一个InstrumentationTest，其他例子中也

可能执行多个。

综上所述 , CTS 在 Android 的 Instrumentation Test 上又包了一层。

4.3 Android Instrumentation Test简介

上一节说明了android CTS的实质就是 Android Instrumentation Test的封装。那么Android Instrumentation Test又是什么呢？这一节将向大家介绍。目的是，当我们遇到CTS测试失败后，可以定位到是那些Instrumentation Test出错。帮助我们定位错误的根源。

JUnit作用

JUnit是由Erich Gamma和Kent Beck编写的一个回归测试框架（regression testing framework）。Junit测试是程序员测试，即所谓白盒测试，因为程序员知道被测试的软件如何（How）完成功能和完成什么样（What）的功能。Junit是一套框架，继承Test Case类，就可以用Junit进行自动测试。基于这套框架，已经port了很多版本

如C#中的NUnit。对于Java，JUnit被编译成一个Jar文件，供程序员使用。

JUnit在android中使用有限

普通的Java单元测试，和Android没有任何关系。你无法测试任何关于Android系统中的API，你写的Activity，人机界面等等。所以，如果你想测试仅仅是一些封装数据的对象，或者是纯粹的数值计算，还是可以用这种方法的。原因就一个，不能测试与UI相关的代码。

Android Instrumentation Test 诞生

Instrumentation Test针对Android的环境，扩展了业内标准的JUnit测试框架。在集成JUnit TestCase的基础上，拓展其对UI控制的能力。比如，可以向某个AP发送UI事件等。

Android Instrumentation测试环境的主要特征有：

1)可以访问Android系统对象。

2)Instrumentation框架可以控制和测试应用程序。

3)创建Android系统常用对象的模拟版本。

4)运行单个test或test suite的工具。

5)支持以Eclipse的ADT插件和命令行方式管理Test和Test工程。

但是使用Android Instrumentation Test仍然需要Developer编写测试程序，对于复杂兼容性检测，这显然是不符合要求的。因此Google以Instrumentation Test为基础，集成了诸多Testcase，达到自动化测试的目的。这就是如今的Android CTS

命令行操作Android Instrumentation Test 

Android Instrumentation Test的使用方法比较多，本节主要简介如何使用命令行操作Instrumentation Test，这是因为在分析CTS测试结果时，可能需要单独调试CTS Plan中的一个test，这时在命令行中使用Instrumentation Test就是最好的方法。

运行包中所有的Test：

$ adb shell am instrument -w MyInstrumentationTestRunner

参数MyInstrumentationTestRunner：可选择

android.test.InstrumentationTestRunner 

android.test.InstrumentationCtsTestRunner 

android.test.InstrumentationCoreTestRunner之一

Eg. 如果假设com.android.foo是你的测试代码的包的根。当执行以下命令时，会执行所有的 

    TestCase的所有Test：

adb shell am instrument -w  

com.android.foo/android.test.InstrumentationTestRunner

运行一个Testcase：

$ adb shell am instrument \

     -e class MyInstrumentationTestCase \

     -w MyInstrumentationTestRunner

Eg. 如果你想运行一个TestSuite，首先继承android.jar的junit.framework.TestSuite类，实现一个 TestSuite（比如叫com.android.foo.MyTestSuite），然后执行以下命令执行此TestSuite

adb shell am instrument -e class com.android.foo.MyTestSuite -w com.android.foo/android.test.InstrumentationTestRunner

运行一个test：

$ adb shell am instrument \

     -e class MyInstrumentationTestCase#myTestMethod \

     -w MyInstrumentationTestRunner

Eg. 如果仅仅想运行一个Test（比如就是上面MyTestCase的testFoo方法）：

　　adb shell am instrument -e class com.android.foo.MyTestCase#testFoo -w com.android.foo/android.test.InstrumentationTestRunner

4.4 CTS Debug分析

一般使用的方法

$ startcts           注意如果用手机设备调试，用root权限执行

cts_host > ls --plan   列出所有plan

out/host/linux-x86/cts/android-cts/repository/plans中有plan的具体内容

cts_host > start --plan VM    运行某个plan

测试结果在out/host/linux-x86/cts/android-cts/repository/results目录下，用浏览器看时间目录下的xml文件即可

注意在改动cts后，还要make cts重新编译，若只在cts目录中编译不能生效

cts_host > ls -p                                 查看当前可用的用例包

cts_host > start --plan Android -p android.app        只运行某个用例包，节约时间

cts_host > start --plan Android -p android.app -t

                                    android.app.cts.AlertDialogTest#testAlertDialog

                                    只运行某个用例包中的某个用例

遇到问题时方便调试的方法

$ adb install xxx/andandroid-cts/repository/testcases/SginatureTest.apk 安装某个用例包

$ adb shell pm list instrumentation  pm用于管理package，看当前机器安装了什么用例

$ adb shell am instrument -w android.tests.sigtest/.InstrumentationRunner             

am用于管理activity   运行某一Testcase

$ adb shell am instrument -e class android.app.cts.AlertDialogTest#testAlertDialog -w com.android.cts.app/android.test/InstrumentationCtsTestRunner          

单独运行一个Test，该命令和在CTS环境下的

start --plan Android -p android.app -t android.app.cts.AlertDialogTest#testAlertDialog

等效

如果在一个时间很长的plan（如Android）中，某处错了，而错误信息又不全，需要单独跑一个Test，用-e指明class明就可以节约很多时间

一般仅仅看failure的log就能判断错误的根源，需要长时间的经验积累，推荐按以上方法找到不能通过测试的Tests，根据4.2节的内容找到对应的源代码，分析错误原因。

Android CTS 测试研究

分类： Android Testing2010-05-29 16:138191人阅读评论(15)收藏举报

Android CTS 测试研究

前言¶

从各种渠道了解到 Android CTS 测试， 是一种类似于 Windows Mobile LTK 的测试。

大体 Google 一下, 发现关于 CTS 的信息非常至少， 只说它有两万多个测试用例。

然后它只对 OHA 成员开发。

本着不抛弃，不放弃的原则，继续 Google...

终于发现了参考1：Cezary Statkiewicz's blog。

搞笑的是该 Blog 的前言部分还写着 CTS 不开放。 后面又纠正了 Google 刚刚开放 CTS 信息（见参考2）。

大喜！

先学习¶

原来 Google 定义了一个兼容性规范（Compatibility Definition）， 而 CTS 就是用于确保某个测试符合该规范。

从而基于 Android 的应用程序能够在基于同一 API 版本的各种设备上运行。

由于我们使用Android 2.1 (Eclair), 所以从参考2下载到 Android 2.1 的

Compatibility Definition, 大体阅读一下， 它定义了一些需求：

数据： 必须实现一种无线连接， 速率达到 200Kbit/Sec

Camera: 至少 2M pixels

重力加速: 必须有， 3维， >50Hz

指南针： 必须有， 3纬， >10Hz

GPS: 必须有

内存： 至少 92M （不包括专用内容）

Nand: /data 分区至少 290M

性能： 启动时间： 浏览器 < 1300ms

MMS/SMS < 700ms

AlarmClock < 650ms

第二次启动一个应用的时间不能超过第一次启动时间。

CTS 测试： 必须通过最新的 CTS

升级： 必须有一种办法可以升级全系统。 可以为：

OTA

USB

SD 卡

看来 Android 是在不断往高端方向走。 不过想想也正常，今天的高端就是明天的低端！

Quick Start¶

参考2 的 User Manual 似乎是针对 1.6 的， 其中提到 CTS 是单独下载的一个包。

而参考1 则说从 source code 中编译而来。

先按照参考1简单运行一下。

1） 获取 2.1 代码， 并先做一个基本的编译（不知是否需要）

2） 编译 cts:

cd ~/mydroid

. build/evnsetup.sh

make cts

3) 启动 emulator (或者 device, 不过可能需要按照 User Manual 设置一下）

4） 将 ~/mydroid/out/host/linux-x86/bin 加到路径

5) adb start-server

6） cts 

进入 cts 交互环境， 可以敲入 help 看各种命令：cts_host > help

这里是quick start,所以不详解。

7） 在 shell 下直接以非交互模式运行一下：

$ cts start --plan Signature 

该测试用例比较少，发现两分钟可以运行通过。 像 Android 测试方案就比较耗时间了。

参考¶

1. 某大牛的 Blog 文章

http://bitbar.com/blog/44/using-androids-compatibility-test-suite

2. Android 官方论坛:

http://source.android.com/compatibility/downloads.html

http://blog.csdn.net/zjujoe/article/details/5633147

Android CTS 测试研究之二

分类： Android Testing2010-06-01 20:3412032人阅读评论(48)收藏举报

Android CTS 测试研究之二 

作者： 宋立新 

Email ： zjujoe@yahoo.com 

前言 

继续较深入了解 CTS 的细节 

先研究一下具体用法 

命令行下敲 cts 进入命令行 , 

先看一下帮助 

Help 一下 

cts_host > help 

Usage: command options 

Avaiable commands and options: 

Host: 

help: show this message 

exit: exit cts command line 

Plan: 

ls --plan: list available plans 

ls --plan plan_name: list contents of the plan with specified name 

add --plan plan_name: add a new plan with specified name 

add --derivedplan plan_name -s/--session session_id -r/--result result_type: derive a plan from the given session 

rm --plan plan_name/all: remove a plan or all plans from repository 

start --plan test_plan_name: run a test plan 

start --plan test_plan_name -d/--device device_ID: run a test plan using the specified device 

start --plan test_plan_name -t/--test test_name: run a specific test 

start --plan test_plan_name -p/--package java_package_name: run a specific java package 

start --plan test_plan_name -t/--test test_name -d/--device device_ID: run a specific test using the specified device 

start --plan test_plan_name -p/--package java_package_name -d/--device device_ID: run a specific java package using the specified device 

Package: 

ls -p/--package: list available packages 

ls -p/--package package_name: list contents of the package with specified name 

add -p/--package root: add packages from root to repository 

rm -p/--package package_name/all: remove a package or all packages from repository 

Result: 

ls -r/--result: list all result of sessions 

ls -r/--result -s/--session session_id: list detail case result of a specified session 

ls -r/--result [pass/fail/notExecuted/timeout] -s/--session session_id: list detail cases of a specified session by the specified result. 

History: 

history/h: list all commands in command history 

history/h count: list the latest count records in command history 

history/h -e num: run the command designated by 'num' in command history 

Device: 

ls -d/--device: list available devices 

列出所有的 plan 

cts_host > ls --plan

List of plans (8 in total): 

CTS 

Signature 

AppSecurity 

Performance 

RefApp 

Java 

VM 

Android 

查看某 plan 的内容 

cts_host > ls --plan Android 

Packages of plan Android (29 in total): 

================================= 

android.apidemos.cts 

android.accessibilityservice 

android.accounts 

android.app 

android.bluetooth 

android.content 

android.database 

android.dpi 

android.dpi2 

android.example 

android.gesture 

android.graphics 

android.hardware 

android.jni 

android.location 

android.media 

android.net 

android.os 

android.permission2 

android.permission 

android.provider 

android.speech 

android.telephony 

android.text 

android.util 

android.view 

android.webkit 

android.widget 

android.tests.appsecurity 

添加一个新的 plan 

cts_host > add --plan marvell 

[Choose package] SignatureTest: select[Y], reject[n], or choose suite in it[m]? [Y/n/m] Y 

Invalid input. Please chose 'y', 'n', or 'm' (default is 'y') 

[Choose package] SignatureTest: select[Y], reject[n], or choose suite in it[m]? [Y/n/m] y 

[Choose package] android.accessibilityservice: select[Y], reject[n], or choose suite in it[m]? [Y/n/m] y 

[Choose package] android.accounts: select[Y], reject[n], or choose suite in it[m]? [Y/n/m] y 

[Choose package] android.apidemos.cts: select[Y], reject[n], or choose suite in it[m]? [Y/n/m] 

[Choose package] android.app: select[Y], reject[n], or choose suite in it[m]? [Y/n/m] y 

。。 

[Choose package] android.widget: select[Y], reject[n], or choose suite in it[m]? [Y/n/m] 

cts_host > ls --plan marvell 

The following package(s) contained in plan marvell have been removed: 

SignatureTest 

Packages of plan marvell (55 in total): 

================================= 

android.accessibilityservice 

android.accounts 

android.apidemos.cts 

android.app 

。。 

android.widget 

删除一个 plan 

cts_host > rm --plan marvell 

执行一个 plan 

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) 

junit.framework.AssertionFailedError: App Took too long to startup: 715 650 at android.performance5.cts.AppStartup.testStartup(AppStartup.java:67) 

at android.performance5.cts.AppStartup.testStartup(AppStartup.java:67) 

at java.lang.reflect.Method.invokeNative(Native Method) 

at android.test.InstrumentationTestCase.runMethod(InstrumentationTestCase.java:205) 

at android.test.InstrumentationTestCase.runTest(InstrumentationTestCase.java:195) 

at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:169) 

at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:154) 

at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:430) 

at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1447) 

at android.performance5.cts.AppStartup.testStartup(AppStartup.java:67) 

at java.lang.reflect.Method.invokeNative(Native Method) 

at android.test.InstrumentationTestCase.runMethod(InstrumentationTestCase.java:205) 

at android.test.InstrumentationTestCase.runTest(InstrumentationTestCase.java:195) 

at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:169) 

at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:154) 

at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:430) 

at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1447) 

at android.app.Instrumentation.checkStartActivityResult(Instrumentation.java:1404) 

at android.app.Instrumentation.execStartActivity(Instrumentation.java:1378) 

at android.app.ApplicationContext.startActivity(ApplicationContext.java:555) 

at android.performance.cts.MultiAppStartupTest.launchActivity(MultiAppStartupTest.java:52) 

at android.performance.cts.MultiAppStartupTest.testMultipleApps(MultiAppStartupTest.java:) 

at java.lang.reflect.Method.invokeNative(Native Method) 

at android.test.InstrumentationTestCase.runMethod(InstrumentationTestCase.java:205) 

at android.test.InstrumentationTestCase.runTest(InstrumentationTestCase.java:195) 

at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:169) 

at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:154) 

at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:430) 

at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1447) 

Test summary: pass=2 fail=2 timeOut=1 notExecuted=0 Total=5 

Time: 635.927s 

查看有多少个包 

cts_host > ls -p 

Available packages (56 in total): 

android.util 

android.hardware 

。。 

android.core.tests.luni.net 

android.jni 

android.core.vm-tests 

查看某个包 

cts_host > ls -p android.net 

Test suites (3 in total): 

android.net.cts 

android.net.wifi.cts 

android.net.http.cts 

查看测试结果 

cts_host > ls -r 

List of all results: 

Session Test result Start time End time Test plan name 

Pass Fail Timeout NotExecuted 

1 2 2 1 0 2010.06.01 16:18:03 2010.06.01 16:28:39 Performance 

2 1 0 0 0 2010.06.01 16:39:38 2010.06.01 16:41:33 Signature 

研究 cts 生成文件 

cts 脚本文件位于： ~/mydroid/out/host/linux-x86/bin ，它是一个 100 行不到的脚本，最终执行： 

java -Xmx512M 

-cp ./../framework/ddmlib.jar:./../framework/junit.jar:./../framework/hosttestlib.jar:./../framework/cts.jar:./cts.jar 

-DHOST_CONFIG=./../cts/android-cts/repository/host_config.xml 

com.android.cts.TestHost 

可见， CTS 的 Java 主程序为： com.android.cts.TestHost ，同时使用了配置文件： host_config.xml. 

两个 cts.jar: ./out/host/linux-x86/cts/android-cts/tools/cts.jar ./out/host/linux-x86/framework/cts.jar 相同。 

cts 使用的目录则为： ~/mydroid/out/host/linux-x86/cts 

文件列表 1 

songlixin @zjujoe-desktop:~/mydroid/out/host/linux-x86/cts$ tree -L 3 

. 

├── all_cts_core_files_stamp 

├── all_cts_files_stamp 

├── android-cts 

│ ├── docs 

│ ├── repository 

│ │ ├── host_config.xml 

│ │ ├── log_2010.06.01_16.02.21_.txt 

│ │ ├── log_2010.06.01_16.12.22_.txt 

│ │ ├── log_2010.06.01_16.38.30_.txt 

│ │ ├── log_2010.06.01_16.59.50_.txt 

│ │ ├── plans 

│ │ ├── results 

│ │ └── testcases 

│ └── tools 

│ ├── cts.jar 

│ ├── hosttestlib.jar 

│ ├── junit.jar 

│ └── startcts 

├── android-cts.zip 

└── temp 

└── description.xml 

我们关心的主要是 repository 目录。 

文件列表 2 

songlixin @zjujoe-desktop:~/mydroid/out/host/linux-x86/cts$ tree android-cts/repository/ 

android-cts/repository/ 

├── host_config.xml 

├── plans 

│ ├── Android.xml 

│ ├── AppSecurity.xml 

│ ├── CTS.xml 

│ ├── Java.xml 

│ ├── Performance.xml 

│ ├── RefApp.xml 

│ ├── Signature.xml 

│ └── VM.xml 

├── results 

│ ├── 2010.06.01_16.18.03 

│ │ ├── cts_result.css 

│ │ ├── cts_result.xsl 

│ │ ├──  

│ │ ├──  

│ │ └── testResult.xml 

│ ├── 2010.06.01_16.18.03.zip 

│ ├── 2010.06.01_16.39.38 

│ │ ├── cts_result.css 

│ │ ├── cts_result.xsl 

│ │ ├──  

│ │ ├──  

│ │ └── testResult.xml 

│ ├── 2010.06.01_16.39.38.zip 

│ ├── cts_result.css 

│ ├── cts_result.xsl 

│ ├──  

│ └──  

└── testcases 

├── android.core.tests.annotation.apk 

├── android.core.tests.annotation.xml 

├── android.core.tests.archive.apk 

。。。。。。。。。 

├── CtsWidgetTestCases.xml 

├── SignatureTest.apk 

├── SignatureTest.xml 

└── TestDeviceSetup.apk 

5 directories, 156 files 

可见 plans 目录下为以 xml 格式定义的测试方案 

results 目录为 测试结果。 

testcases 目录则为一个个测试用例包 

host_config.xml 为配置文件 

研究 cts 源文件 

从根目录开始 

Cts 的 source 包位于 android 根目录下： 

songlixin @zjujoe-desktop:~/mydroid/cts$ tree -L 2 

. 

├── Android.mk 

├── tests 

│ ├── accessibilityservice 

│ ├── AndroidManifest.xml 

│ ├── Android.mk 

│ ├── ApiDemosReferenceTest 

│ ├── appsecurity-tests 

│ ├── assets 

│ ├── config_demo 

│ ├── core 

│ ├── ProcessTest 

│ ├── res 

│ ├── SignatureTest 

│ ├── src 

│ ├── tests 

│ └── vm-tests 

└── tools 

├── Android.mk 

├── annotation-helper 

├── cts-reference-app-lib 

├── dasm 

├── device-setup 

├── dex-tools 

├── dx-tests 

├── host 

├── signature-tools 

├── spec-progress 

├── test-progress 

├── test-progress-new 

├── utils 

└── vm-tests 

根目录下的 make file 非常简单： 

songlixin @zjujoe-desktop:~/mydroid/cts$ cat Android.mk 

include $(call all-subdir-makefiles) 

看来主要内容在两个子目录下。 

子目录 1 ： tools 

根目录下的 Android.mk 与其父目录相同。 

各子目录代表不同的工具，比如 dasm 编译后的位置是： ./out/host/linux-x86/bin/dasm 

这里就不仔细分析这些工具了。 

子目录 2 ： tests 

看一下根目录下的 Android.mk: 

LOCAL_PATH:= $(call my-dir) 

include $(CLEAR_VARS) 

LOCAL_MODULE_TAGS := tests 

LOCAL_SRC_FILES := $(call all-java-files-under, src)/ 

$(call all-java-files-under, core/runner/src)/ 

src/android/app/cts/ISecondary.aidl/ 

src/android/os/cts/IEmptyService.aidl 

LOCAL_JAVA_LIBRARIES := android.test.runner 

# Resource unit tests use a private locale and some densities 

LOCAL_AAPT_FLAGS = -c xx_YY -c cs -c 32dpi -c 240dpi -c 160dpi 

LOCAL_PACKAGE_NAME := CtsTestStubs 

include $(BUILD_PACKAGE) 

# Build the test APK using its own makefile, and any other CTS-related packages 

include $(call all-makefiles-under,$(LOCAL_PATH)) 

所有 src 及 core/runner/src 下的 java 文件被编译成： 

./out/host/linux-x86/cts/android-cts/repository/testcases/CtsTestStubs.apk 

剩下的就是很多子目录以及子目录的子目录会被编译成 *.apk 

Tests 目录下每个子目录包括一个 test suite. 

songlixin @zjujoe-desktop:~/mydroid/cts/tests/tests$ tree -L 1 

. 

├── accessibilityservice 

├── accounts 

├── Android.mk 

。。 

├── webkit 

└── widget 

Core 目录下每个子目录包含一个 test suite, 但是他们的代码在其他地方 

songlixin @zjujoe-desktop:~/mydroid/cts/tests/core$ tree -L 2 

. 

├── Android.mk 

├── annotation 

│ ├── AndroidManifest.xml 

│ └── Android.mk 

├── archive 

│ ├── AndroidManifest.xml 

│ └── Android.mk 

。。 

├── text 

│ ├── AndroidManifest.xml 

│ └── Android.mk 

├── xml 

│ ├── AndroidManifest.xml 

│ └── Android.mk 

└── xnet 

├── AndroidManifest.xml 

└── Android.mk 

appsecurity-tests/test-apps 目录下每个子目录包括一个 test case. 都特别简单 . 

songlixin @zjujoe-desktop:~/mydroid/cts/tests/appsecurity-tests/test-apps$ tree -L 1 

. 

├── Android.mk 

├── AppAccessData 

├── AppWithData 

├── InstrumentationAppDiffCert 

├── PermissionDeclareApp 

├── SharedUidInstall 

├── SharedUidInstallDiffCert 

├── SimpleAppInstall 

├── SimpleAppInstallDiffCert 

├── TargetInstrumentationApp 

└── UsePermissionDiffCert 

总结 

Cts 其实就是基于 instrumentation test, Test case 有很多类型，不同的实现方式。 对我们来说，需要： 

1 ） 能够执行现有的 test case 

2 ） 能够模仿 api demo test case 写一些比较简单的： 

可以参考： http://www.netmite.com/ / 

android/mydroid/cupcake/development/pdk/docs/instrumentation_testing.html

http://blog.csdn.net/zjujoe/article/details/50461

Android CTS 测试研究之三 

作者： 宋立新 

Email ： zjujoe@yahoo.com 

前言 

前面都是研究 CTS 面上的东西， 这两天认真学习了一下 Android Instrumentation Test 的相关内容，深切体会到其强大的功能！（ UI 控制，生命周期控制，伪环境对象提供等等）， 回过头来，我们再来看看 CTS 的细节内容。 

和前面的内容区分开，我们从具体测试用例的角度来看。 

首先选择文档中经常提起的 apidemo 作为研究对象。 

例子一： apidemo 

从 test plan 开始研究 

~/mydroid/out/host/linux-x86/cts/android-cts/repository/plans$ cat CTS.xml 

。。 

可见，某个 test plan 只需要包括一个到具体测试用例的 uri 申明即可。 

该 uri 的定义在 test cases 子目录下： 

~/mydroid/out/host/linux-x86/cts/android-cts/repository/testcases$ cat ApiDemosReferenceTest.xml 

可见 , CTS 在 Android 的 Instrumentation Test 上又包了一层。该 xml 文件的格式说明没有找到，只能先望文生义了。 

照字面理解，它要测试 ApiDemo, 测试的代码是 ApiDemoReferenceTest, 使用的 Test runner 是： android.test.InstrumentationTestRunner. ( 其它的 test runner 还有： android.test.InstrumentationCtsTestRunner, android.test.InstrumentationCoreTestRunner) 

该 Test 一共只有一个 test: testNumberOfItemsInListView 

以下是相关文件： 

songlixin@zjujoe-desktop:~/mydroid/out/host/linux-x86/cts/android-cts/repository/testcases$ ls -l ApiDemo* 

-rw-r--r-- 1 songlixin songlixin 2106161 2010-06-16 09:38 ApiDemos.apk 

-rw-r--r-- 1 songlixin songlixin 5526 2010-06-16 09:38 ApiDemosReferenceTest.apk 

-rw-r--r-- 1 songlixin songlixin 657 2010-06-16 09:38 ApiDemosReferenceTest.xml 

现在看看这些位于 out 目录下的文件是如何生成的。 

再看源码树 

根据参考， 要在 cts 中添加一个 test package, 必须将其加入： build/core/tasks/cts.mk. 

查看一下，果然 , 其中包含： 

ApiDemos / 

ApiDemosReferenceTest / 

ApiDemos 位于： 

~/mydroid/development/samples/ApiDemos$ tree -L 2 

. 

├── AndroidManifest.xml 

├── Android.mk 

├── assets 

│ ├── fonts 

│ └── read_asset.txt 

├── _index.html 

├── res 

│ ├── anim 

│ ├── drawable 

。。 

│ ├── layout 

│ ├── menu 

│ ├── raw 

│ ├── values 

。。 

│ └── xml 

├── src 

│ └── com 

└── tests 

├── AndroidManifest.xml 

├── Android.mk 

├── build.properties 

└── src 

其中， make file 中包含 tests tag: 

LOCAL_MODULE_TAGS := samples tests 

ApiDemosReferenceTest 位于： 

~/mydroid/cts/tests/ApiDemosReferenceTest$ tree 

. 

├── AndroidManifest.xml 

├── Android.mk 

└── src 

└── android 

└── apidemos 

└── cts 

├── AllTests.java 

└── ApiDemosTest.java 

其 make file 没有包含 tests tag, 但是父目录的 Android.mk 中包含了。并且它使用所有子目录的源码。 

两个疑问 

1） ApiDemosReferenceTest.xml 是从哪里来的？ 

猜测： 从 /mydroid/cts/tests/ApiDemosReferenceTest 生成 

2） ApiDemosReferenceTest 中提供了两个 testcase, 而 ApiDemosReferenceTest.xml 只用了一个？ 

从代码上看， ~/mydroid/cts/tools/utilsbuildCts.py 是用来生成 test description 以及 test plan 的。它在 ~/mydroid/build/core/tasks/cts.mk 中被调用。 

例子二： CtsExample 

CTS test plan 中有： 

这对应： 

~/mydroid/out/host/linux-x86/cts/android-cts/repository/testcases$ ls -l CtsExampleTestCases.* 

-rw-r--r-- 1 songlixin songlixin 3294 2010-06-16 10:58 CtsExampleTestCases.apk 

-rw-r--r-- 1 songlixin songlixin 1257 2010-06-16 10:59 CtsExampleTestCases.xml 

看它的 xml 文件： 

Test {@link Example#blort}.

Test {@link Example#zorch}.

其中包含了两个 test case. 

我们再看 build/core/tasks/cts.mk ： 

CtsExampleTestCases / 

该 package 位于： 

~/mydroid/cts/tests/tests/example$ tree 

. 

├── AndroidManifest.xml 

├── Android.mk 

└── src 

└── android 

└── example 

├── cts 

│ ├── ExampleSecondaryTest.java 

│ └── ExampleTest.java 

└── Example.java 

该 package 的特殊之处在于它的测试代码以及被测试代码都在同一个包内。 

两个 TestCase 都是从 TestCase 继承，因为它不需要更复杂的功能。 

可以发现， 相比较 ApiDemo 而言，这是一个更典型的 CTS 测试的例子。如果您想写自己的 cts 测试用例，不凡模仿它。更进一步说， cts/tes/tests 下的那些例子更适合我们用来参考。比如： performance 目录下的 MultiAppStartupTest, 继承了 InstrumentationTestCase. 也是一个很好的例子。 

另外，还发现每个例子其包的最后一段总是 cts, 不知是不是硬性要求。这也可以说明 CTS 是基于 instrumentation test, 但是又不等同。 

疑问

AndroidManifest.xml 中定义的 package name 为: com.andoid.cts.example

Example 类属于：

package android.example;

public class Example 

ExampleTest 类属于：

package android.example.cts;

public class ExampleTest extends TestCase 

非常奇怪！

单个运行 CTS 测试用例

安装

~/mydroid/out/host/linux-x86/cts/android-cts/repository/testcases$ adb install CtsPerformanceTestCases.apk 

70 KB/s (4518 bytes in 0.062s)

    pkg: /data/local/tmp/CtsPerformanceTestCases.apk

Success

查看一下已经安装的 instrumentation

~/mydroid/out/host/linux-x86/cts/android-cts/repository/testcases$ adb shell pm list instrumentation

instrumentation:com.android.cts.performance/android.test.InstrumentationTestRunner (target=com.android.calculator2)

instrumentation:com.android.example.spinner.test/android.test.InstrumentationTestRunner (target=com.android.example.spinner)

instrumentation:com.example.android.apis/.app.LocalSampleInstrumentation (target=com.example.android.apis)

instrumentation:com.example.helloandroid.test/android.test.InstrumentationTestRunner (target=com.example.helloandroid)

运行(失败)

:~/mydroid/out/host/linux-x86/cts/android-cts/repository/testcases$ adb shell am instrument -w -r com.android.cts.performance/android.test.InstrumentationTestRunner

INSTRUMENTATION_STATUS: id=InstrumentationTestRunner

INSTRUMENTATION_STATUS: current=1

INSTRUMENTATION_STATUS: class=android.performance.cts.MultiAppStartupTest

INSTRUMENTATION_STATUS: stream=

android.performance.cts.MultiAppStartupTest:

INSTRUMENTATION_STATUS: numtests=1

INSTRUMENTATION_STATUS: test=testMultipleApps

INSTRUMENTATION_STATUS_CODE: 1

INSTRUMENTATION_STATUS: id=InstrumentationTestRunner

INSTRUMENTATION_STATUS: current=1

INSTRUMENTATION_STATUS: class=android.performance.cts.MultiAppStartupTest

INSTRUMENTATION_STATUS: stream=

Error in testMultipleApps:

android.content.ActivityNotFoundException: Unable to find explicit activity class {com.android.calendar/com.android.calendar.LaunchActivity}; have you declared this activity in your AndroidManifest.xml?

    at android.app.Instrumentation.checkStartActivityResult(Instrumentation.java:1404)

    at android.app.Instrumentation.execStartActivity(Instrumentation.java:1378)

    at android.app.ApplicationContext.startActivity(ApplicationContext.java:555)

    at android.performance.cts.MultiAppStartupTest.launchActivity(MultiAppStartupTest.java:52)

    at android.performance.cts.MultiAppStartupTest.testMultipleApps(MultiAppStartupTest.java:)

    at java.lang.reflect.Method.invokeNative(Native Method)

    at android.test.InstrumentationTestCase.runMethod(InstrumentationTestCase.java:205)

    at android.test.InstrumentationTestCase.runTest(InstrumentationTestCase.java:195)

    at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:169)

    at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:154)

    at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:430)

    at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1447)

INSTRUMENTATION_STATUS: numtests=1

INSTRUMENTATION_STATUS: stack=android.content.ActivityNotFoundException: Unable to find explicit activity class {com.android.calendar/com.android.calendar.LaunchActivity}; have you declared this activity in your AndroidManifest.xml?

    at android.app.Instrumentation.checkStartActivityResult(Instrumentation.java:1404)

    at android.app.Instrumentation.execStartActivity(Instrumentation.java:1378)

    at android.app.ApplicationContext.startActivity(ApplicationContext.java:555)

    at android.performance.cts.MultiAppStartupTest.launchActivity(MultiAppStartupTest.java:52)

    at android.performance.cts.MultiAppStartupTest.testMultipleApps(MultiAppStartupTest.java:)

    at java.lang.reflect.Method.invokeNative(Native Method)

    at android.test.InstrumentationTestCase.runMethod(InstrumentationTestCase.java:205)

    at android.test.InstrumentationTestCase.runTest(InstrumentationTestCase.java:195)

    at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:169)

    at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:154)

    at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:430)

    at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1447)

INSTRUMENTATION_STATUS: test=testMultipleApps

INSTRUMENTATION_STATUS_CODE: -1

INSTRUMENTATION_RESULT: stream=

Test results for InstrumentationTestRunner=.E

Time: 6.729

FAILURES!!!

Tests run: 1, Failures: 0, Errors: 1

INSTRUMENTATION_CODE: -1

songlixin@zjujoe-desktop:~/mydroid/out/host/linux-x86/cts/android-cts/repository/testcases$

修改

出错信息说是找不到：calendar

修改代码，使其不启动 calendar:

//launchActivity("com.android.calendar", "LaunchActivity", true);

//Thread.sleep(ACTIVITY_STARTUP_WAIT_TIME);

重新编译: make cts

重新安装

重新安装用：adb install -r CtsPerformanceTestCases.apk

运行（成功）

~/mydroid/out/host/linux-x86/cts/android-cts/repository/testcases$

adb shell am instrument -w -r com.android.cts.performance/android.test.InstrumentationTestRunner

INSTRUMENTATION_STATUS: id=InstrumentationTestRunner

INSTRUMENTATION_STATUS: current=1

INSTRUMENTATION_STATUS: class=android.performance.cts.MultiAppStartupTest

INSTRUMENTATION_STATUS: stream=

android.performance.cts.MultiAppStartupTest:

INSTRUMENTATION_STATUS: numtests=1

INSTRUMENTATION_STATUS: test=testMultipleApps

INSTRUMENTATION_STATUS_CODE: 1

INSTRUMENTATION_STATUS: id=InstrumentationTestRunner

INSTRUMENTATION_STATUS: current=1

INSTRUMENTATION_STATUS: class=android.performance.cts.MultiAppStartupTest

INSTRUMENTATION_STATUS: stream=.

INSTRUMENTATION_STATUS: numtests=1

INSTRUMENTATION_STATUS: test=testMultipleApps

INSTRUMENTATION_STATUS_CODE: 0

INSTRUMENTATION_RESULT: stream=

Test results for InstrumentationTestRunner=.

Time: 7.3

OK (1 test)

总结 

至此，我们大体知道如何运行 cts, 配置 cts, 扩充 cts, 下一步就看具体实践了！ 

参考链接里有如何添加一个 cts 测试、修改 test plan 的信息，所以本文就没有重复。 

http://blog.csdn.net/zjujoe/article/details/5673469

关于 Android 下的自动化测试

作者： 宋立新 

Email ： zjujoe@yahoo.com 

前言： 

现在 Android 开发非常红火， Java 环境下敏捷开发是不二选择。 而敏捷开发都是测试驱动。 所以，最近研究了一下 Android 下的各种自动化测试手段。本文重点在于面上的比较而非点上的细节。时间比较短，所以很可能理解很不充分。 

测试手段 1 ： CTS 

CTS 原来只对 OHA 联盟开放。 最近 Google 把它 Release 出来了。 似乎做过一些裁剪 , 比如针对 Java 虚拟机的测试，似乎被删除了，但我们一般用不着这么高深的。 

针对每个版本，比如 2.1, 2.2, Goolge 发布了一个兼容性规范，而 CTS 测试就是用来确保某手机或者模拟器符合该兼容性规范。 

CTS 测试基于 Android instrumentation 测试， 其又基于 JUnit 测试。 说白了， CTS 就是一堆单元测试用例。 这也是 Java 语言的擅长部分。 

在 2.1 模拟器上试验了一下， 有少数没有通过。 

目前 CTS 主要包括功能方面的测试，有少数的性能方面的测试。 性能测试未来会越来越多。 

总的来说， CTS 跟 WM 的 LTK 测试还是弱了一些， 毕竟还年轻。 它只包括自动化测试，目的主要是保证 API 的兼容性。由于基于单元测试， CTS 本身不能用于测试多应用交互的情况。 

对我们的帮助： 

1） 应用程序的开发者可以开发出自己应用的单元测试，并将其加入 CTS 测试集。 

2） 设备制造商可以通过周期性运行 CTS 测试，确保没有对 Android 伤筋动骨。 

测试手段 2 ： Monkey 

猴子测试本身非常简单，就是模拟用户的按键输入，触摸屏输入，手势输入等。 看手机多长时间会出异常。 

可以设置让 Monkey 只测试某个应用，从而辅助应用程序的开发。 

对我们的帮助： 

1） 应用程序的开发者可以测试自己应用的鲁棒性。 

2） 设备制造商可以使用猴子对自己的测试施行压力测试。看设备能坚持多久。 

测试手段 3: ASE 

ASE 意思为 Android 脚本环境， 即我们可以通过脚本（比如 Python ）调用 Android 的功能，从而定制一些测试。比如打电话，发短信，浏览网页，等。 

个人觉得这对复现某些偶发故障非常有帮忙。 

目前 ASE 还处于它的成长期，希望它不断成熟，为开发者提供更多便利。 

测试手段 4: 其它 

可以写一个 Android 应用程序，命令行脚本等， 在其他方法不能实现时，就只能用这些方法了。 

总结 

一方面我们要充分利用 Android 提供的现成测试，密切关注其进展，另一方面，我们要学习好 java/Python 编程，必要时，自己开发自己的测试用例。 

作为模块开发者，一定要写自己的单元测试，一方面可以保证自己的代码没有缺陷，另一方面，也为系统级测试提供素材。 

当然，自动化测试关键还在于意识，创意比实现更重要。 

http://blog.csdn.net/zjujoe/article/details/51477

关于 Android 下的自动化测试之二

作者： 宋立新

Email：zjujoe@yahoo.com

前言：

研究了一个多月 Android 自动化测试，也大体知道了各种测试手段，这里总结一下。也是对前面（之一）的补充。前面的专题已经说得够多，这里只是些总结性的文字。

测试手段1： CTS

用来确保某设备符合 Android 兼容性规范。原来想扩充它，不是正道。

测试手段2： Monkey

1） 应用程序的开发者可以测试自己应用的鲁棒性。

2） 设备制造商可以使用猴子对自己的测试施行压力测试。看设备能坚持多久。

猴子测试即可以针对全局，也可以正对某个局部（某个 Category, package等等）。

执行简单，效果明显。

测试手段3: ASE

ASE 意思为 Android 脚本环境， 即我们可以通过脚本（比如 Python）调用 Android 的功能，从而定制一些测试。比如打电话，发短信，浏览网页，等。

我们可以扩充它的API（Java 部分）, 并用python 脚本调用这些 API, 从而实现丰富的测试功能。

用于API 部分可以访问到Android全部API, python又能灵活部署测试，所以 ASE 的扩展性非常好。

测试手段4: Robotium

该工具用于黑盒的自动化测试。可以在有源码或者只有APK的情况下对目标应用进行测试。

Robotimu 提供了模仿用户操作行为的API，比如在某个控件上点击，输入 Text 等等。

测试手段5： 单元测试

Android 本身带有很多单元测试例子，我们可以按需要模仿它们，针对某个应用进行单元测试。

注意 Android 的Instrument机制功能非常强大，可以测试 UI.

总结

对于 CTS/Monkey, 我们不需要开发，只要执行测试就可以了。

对于 ASE, 我们可以扩充它的现有API(Java), 用Python调用这些API实现丰富的测试功能。

Robotium 模仿普通用户行为，可以试着把一些原来由测试工程师做的测试变成Robotium自动化实现。

http://blog.csdn.net/zjujoe/article/details/56324