Android cts介绍

来源：互联网发布：温州淘宝技术培训编辑：程序博客网时间：2024/06/15 05:31

Android cts介绍

1 cts编译使用

1.1编译生成CTS:

cd~/workspace/exdroid/android2.3.4;

makects;

1.2启动设备

emulator@android-sdk-2.3 -show-kernel

1.3启动CTS

cd android2.3.4/out/host/linux-x86/bin#

./cts; ( droid CTS version 2.3_r2Device(emulator-5554) connected)

1.4.基本操作

1.4.1 help

exit 退出CTS测试

1.4.2测试计划

CTS以“测试计划”为单元进行测试，即使只测试一个软件包，也要首先将其置于某个计划中

ls --plan；列出全部已有计划

ls --planplan_name;列出指定plan_name中软件包

1.4.3添加计划

如果要创建新的计划，使用如下步骤：

add --plan plan_name; (plan_name不可与已有计划名冲突）

手动选择需要测试的软件包，CTS会自动搜索所有已安装的软件包供用户选择是否加入测试计划：

'y' --加入测试计划；‘n'--拒绝；‘m'--选择合适的包（如果存在）使用上述方式可完成将需要测试的包加入新的测试计划。

1.4.4启动测试

start --plan plan_name;启动指定plan_name的测试计划；

start --plan plan_name -p package_name;启动测试计划中的指定的软件包；

如果不清楚某计划中具体有哪些包，可用命令：

ls -plan plane_name;

1.4.5删除计划

测试完成后，可删除计划

rm --plan plan_name/all;

1.4.6测试结果

产生异常，测试计划自动终止；

若成功，以“pass“标记；

若异常，以“fail“标记；

查看详细测试报告：

ls -r/--result;

筛选某种标志的测试报告：

ls -r/--result [pass/fail/notExecuted/timeout] -s/--sessionsession_id

1.4.7其他辅助命令

ls -p/--package；查看平台所有软件包

ls -p/--package package_name; 指定软件包

rm -p/--package package_name/all；移除

2 编译CTS生成文件

cts脚本文件位于：/android/out/host/linux-x86/bin，它是一个 100行不到的脚本，最终执行：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使用到目录为：/android/out/host/linux-x86/cts

*2.1文件cts***

root@fe:~/net/workspace/exdroid/android2.3.4/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_2011.08.23_20.00.30_.txt

│ │ ├──log_2011.08.26_17.44.11_.txt

│ │ ├──log_2011.08.26_17.45.03_.txt

│ │ ├──log_2011.08.29_08.53.30_.txt

│ │ ├──log_2011.08.29_09.08.54_.txt

│ │ ├──log_2011.08.29_13.42.39_.txt

│ │ ├── plans

│ │ ├── results

│ │ └── testcases

│ └── tools

│ ├── cts.jar

│ ├── CtsTestAnnotationsHostLib.jar

│ ├── ddmlib-prebuilt.jar

│ ├── hosttestlib.jar

│ ├── junit.jar

│ └── startcts

├──android-cts.zip

└──temp

└── description.xml

我们最关心到所repository目录

2.2文件目录repository

root@fe:~/net/workspace/exdroid/android2.3.4/out/host/linux-x86/cts/android-cts/repository#tree

├──host_config.xml

├──log_2011.08.23_20.00.30_.txt

├──log_2011.08.26_17.44.11_.txt

├──log_2011.08.26_17.45.03_.txt

├──log_2011.08.29_08.53.30_.txt

├──log_2011.08.29_09.08.54_.txt

├──log_2011.08.29_13.42.39_.txt

├──plans

│ ├──Android.xml

│ ├──AppSecurity.xml

│ ├──CTS.xml

│ ├──Java.xml

│ ├──Performance.xml

│ ├──RefApp.xml

│ ├──Signature.xml

│ └── VM.xml

├──results

│ ├──2011.08.26_17.46.55

│ │ ├── cts_result.css

│ │ ├── cts_result.xsl

│ │ ├── logo.gif

│ │ ├──newrule-green.png

│ │ ├── snap1.png

│ │ └── testResult.xml

│ ├──2011.08.26_17.46.55.zip

│ ├──2011.08.29_09.12.59

│ │ ├── cts_result.css

│ │ ├── cts_result.xsl

│ │ ├── logo.gif

│ │ ├──newrule-green.png

│ │ └── testResult.xml

│ ├──2011.08.29_09.12.59.zip

│ ├──cts_result.css

│ ├──cts_result.xsl

│ ├──logo.gif

│ └──newrule-green.png

└──testcases

├── android.core.tests.dom.apk

├── android.core.tests.dom.xml

├── android.core.tests.luni.io.apk

├── android.core.tests.luni.io.xml

├── android.core.tests.luni.lang.apk

├── android.core.tests.luni.lang.xml

├── android.core.tests.luni.net.apk

├── android.core.tests.luni.net.xml

├── android.core.tests.luni.util.apk

........................

├── CtsWebkitTestCases.apk

├── CtsWebkitTestCases.xml

├── CtsWidgetTestCases.apk

├── CtsWidgetTestCases.xml

├── SignatureTest.apk

├── SignatureTest.xml

└── TestDeviceSetup.apk

可以看出： plans目录下为以xml格式定义到测试方案

results目录为测试结果

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

host_config.xml为配置文件

3 cts源文件

3.1 从根目录开始

root@fe:~/net/workspace/exdroid/android2.3.4/cts# tree -L2

├──Android.mk

├──apps

│ ├──Android.mk

│ └──CtsVerifier

├──CleanSpec.mk

├──CtsHostLibraryList.mk

├──CtsTestCaseList.mk

├──CtsTestCoverage.mk

├──development

│ └── ide

├──libs

│ ├──Android.mk

│ ├──annotation

│ ├── json

│ └──vogar-expect

├──tests

│ ├──accessibilityservice

│ ├──AndroidManifest.xml

│ ├──Android.mk

│ ├──ApiDemosReferenceTest

│ ├──appsecurity-tests

│ ├── assets

│ ├──config_demo

│ ├── core

│ ├──expectations

│ ├──ProcessTest

│ ├── res

│ ├──SignatureTest

│ ├── src

│ ├── tests

│ └──vm-test

└──tools

├── Android.mk

├── annotation-helper

├── cts-api-coverage

├── cts-reference-app-lib

├── dasm

├── device-setup

├── dex-tools

├── dx-tests

├── host

├── signature-tools

├── spec-progress

├── test-progress

├── test-progress-new

├── tradefed-host

├── utils

└── vm-tests

3.1.1Android.mk

cat Andorid.mk

include $(call all-subdir-makefiles)

3.1.2子目录：tools

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

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

3.1.3子目录：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 -c160dpi
LOCAL_PACKAGE_NAME := CtsTestStubs
include $(BUILD_PACKAGE)
# Build the test APK using its own makefile, and any otherCTS-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

3.1.3.1 test目录下每个子目录包括一个test case

root@fe:~/net/workspace/exdroid/android2.3.4/cts/tests/tests#tree -L 1

├──accessibilityservice

├──accounts

├──Android.mk

├──app

...............

├──webkit

└──widget

3.1.3.2core目录下每个子目录包括一个testsuite

root@fe:~/net/workspace/exdroid/android2.3.4/cts/tests/core#tree -L 2

├──Android.mk

├──ctscore.mk

├──dom

│ ├──AndroidManifest.xml

│ └──Android.mk

├──luni-io

│ ├──AndroidManifest.xml

│ └──Android.mk

├──luni-lang

│ ├──AndroidManifest.xml

│ └──Android.mk

├──luni-net

│ ├──AndroidManifest.xml

│ └──Android.mk

├──luni-util

│ ├──AndroidManifest.xml

│ └──Android.mk

├──runner

│ ├──AndroidManifest.xml

│ ├──Android.mk

│ └── src

└──xml

├── AndroidManifest.xml

└── Android.mk

3.1.3.3appsecurity-tests/test-apps

目录下每个子目录包括一个 test case. 都特别简单

root@fe:~/net/workspace/exdroid/android2.3.4/cts/tests/appsecurity-tests/test-apps#tree -L 1

├──Android.mk

├──AppAccessData

├──AppWithData

├──InstrumentationAppDiffCert

├──PermissionDeclareApp

├──SharedUidInstall

├──SharedUidInstallDiffCert

├──SimpleAppInstall

├──SimpleAppInstallDiffCert

├──TargetInstrumentationApp

3.2 小结

Cts其实就是基于instrumentationtest, Test case有很多类型，不同的实现方式。

4 CTS 的细节内容

4.1apidemo测试用例

4.1.1从test plan开始

  /android2.3.4/out/host/linux-x86/cts/android-cts/repository/plans$cat CTS.xml
<?xml version="1.0"encoding="UTF-8"?>
<TestPlan version="1.0">
<Entryuri="android.apidemos.cts"/>
  <Entryuri="android.accessibilityservice"/>
   ....
<Entryuri="android.core.vm-tests"/>
<Entryuri="android.tests.appsecurity"/>
</TestPlan>
可见，某个 test plan只需要包括一个到具体测试用例的uri申明即可。

该 uri的定义在 testcases 子目录下：

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

<?xml version="1.0"encoding="UTF-8"?>
<TestPackage AndroidFramework="Android 1.0"apkToTestName="ApiDemos" 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">
  <TestSuitename="android">
<TestSuitename="apidemos">
   <TestSuitename="cts">
     <TestCasename="ApiDemosTest">
     <Testname="testNumberOfItemsInListView"/>
     </TestCase>
   </TestSuite>
</TestSuite>
  </TestSuite>
</TestPackage>

可见 , CTS在 Android的 InstrumentationTest 上又包了一层

照字面理解，它要测试 ApiDemo,测试的代码是ApiDemoReferenceTest,使用的Testrunner 是：android.test.InstrumentationTestRunner. (其它的testrunner还有：android.test.InstrumentationCtsTestRunner,android.test.InstrumentationCoreTestRunner)
Test 一共只有一个test:testNumberOfItemsInListView
以下是相关文件：

~/android2.3.4/out/host/linux-x86/cts/android-cts/repository/testcases$ls -l ApiDemo*
-rw-r--r-- 1  ApiDemos.apk
-rw-r--r-- 1  ApiDemosReferenceTest.apk
-rw-r--r--1   ApiDemosReferenceTest.xml
现在看看这些位于out目录下的文件是如何生成的。

再看源码树
根据参考，要在 cts中添加一个 testpackage, 必须将其加入：build/core/tasks/cts.mk.

4.2CtsExample

/android2.3.4/out/host/linux-x86/cts/android-cts/repository/plans$cat CTS.xml

里面有：

<Entryuri="android.example"/>

这对应：
/android/out/host/linux-x86/cts/android-cts/repository/testcases$ls -l CtsExampleTestCases.*
-rw-r--r-- 1 CtsExampleTestCases.apk
-rw-r--r-- 1 CtsExampleTestCases.xml
看看 CtsExampleTestCases.xml：

<?xml version="1.0"encoding="UTF-8"?><TestPackageAndroidFramework="Android 1.0"appNameSpace="com.android.cts.example"appPackageName="android.example" name="CtsExampleTestCases"runner="android.test.InstrumentationTestRunner"version="1.0">

<TestSuitename="android">

<TestSuitename="example">

<TestSuitename="cts">

<TestCasename="ExampleSecondaryTest">

<Testname="testZorch">

<Description> Test{@linkExample#zorch}</Description>

</Test>

</TestCase>

<TestCasename="ExampleTest">

<Testname="testBlort">

<Description> Test{@linkExample#blort} </Description>

</Test>

</TestCase>

</TestSuite>

其中包含两个testcase

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

该包位于：

root@fe:~/net/workspace/exdroid/android2.3.4/cts/tests/tests/example#tree

├──AndroidManifest.xml

├──Android.mk

└──src

└── android

└── example

├── cts

│ ├──ExampleSecondaryTest.java

│ └──ExampleTest.java

└── Example.java

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

可以发现，相比较ApiDemos而言，这是一个更典型到CTS测试例子

另外，还发现每个例子其包的最后一段总是cts,不知是不是硬性要求。这也可以说明CTS是基于instrumentationtest,但是又不等同。
疑问
AndroidManifest.xml 中定义的 packagename为:com.andoid.cts.example
Example 类属于：
package android.example;
public class Example
ExampleTest 类属于：
package android.example.cts;
public class ExampleTest extends TestCase
非常奇怪！

5 CTS框架

5.1 CTS框架图

Android <wbr>cts介绍

5.2 CTS运行流程

5.2.1CTS程序入口

当执行/android2.3.4/out/host/linux-x86/bin下的CTS脚本时，最后执行：com.android.cts.TestHost，可以发现，CTS的入口是TestHost。

5.2.2HostLock.lock

为了保证一个CTS只控制一台测试设备，需要对当前测试的设备经行枷锁

Android <wbr>cts介绍

5.2.3初始化并管理目标设备：DeviceManager

Exdroid 测试系统 CTS测试原理9.jpg

5.2.4 启动控制输入功能：ConsoleUi

5.2.5 解析输入指令：CommandParser

CommandParser cp = CommandParser.parse("start-plan test_plan")

cp.getAction() will get "start "

cp.getValue("-plan") will get "test_plan"

5.2.6 启动命令执行： ConsoleUi.startUi()

Xdroid 测试系统 CTS测试原理12.jpg

5.2.7 转到当前测试中：TestSession

负责执行一个具体的测试计划并初始化：

n 获取设备

n 获取测试包

5.2.8 管理寄宿设备：TestDevice

n 安装/卸载测试包APK

n 转到设备的shell命令之中，执行测试命令

5.3主要类功能

l TestHost

描述：测试总入口main

功能：负责寄宿设备的连接、提供组织管理测试会话

l ConsoleUi

描述：提供UI交互接口

功能：接受并转化解析用户命令、开始执行一个计划、移除一个计划、添加一个测试包

l TestSession

描述：一个具体测试计划的运行时会话,

功能：负责执行一个计划并初始化跟清理工作

l SessionObserver

功能：当一个会话结束时发布广播并通知监听者

l TestSessionLog

保存一个测试计划的信息，默认保存在XML文件中

l TestDevice

描述：管理寄宿设备

功能：安装/卸载测试包、在寄宿设备上执行命令、从标准输出里获取命令反馈信息

l DeviceObserver

功能：广播测试包安装/卸载进行的状态

l DeviceManager

功能：初始化并管理目标设备

l AndroidDebugBridge

描述：ADB控制类

功能：负责与所有类型设备的通信，包括模拟器

5.4 往CTS中添加Camera TestCase

Ø 找到cts目录下面的CtsTestCaseList.mk文件，把Camera测试包名

CameraTests添加到里面。

Ø 重新编译：make cts，在anddroid2.3.4/out/host/linux-x86/cts/android-cts/repository/testcases目录下面会生产CameraTests.apk

Ø 在testcases目录下面创建CameraTests.xml文件

Android <wbr>cts介绍

appNameSpace:表示测试用例命名空间

appPackageName:表示应用程序测试包

name:表示此测试包的配置信息文件名

runner:表示运行此测试用例的入口

targetNameSpace:表示测试对象的命名空间