Android CTS 总结
2011-03-09 10:22
127 查看
CTS
是什么?
资料:
CDD
、
CTS
官网、
android-cts-manual-r4
;
CTS
是什么我就不多费话了,看上面官方的说法就行了。不过有一点需要明确,你的设备只有满足
CDD
的规定并且通过
CTS
,才有可能获得
Android
的商标和享受
Android Market
的权限。这里有可能指的是需要你自己去向
google
申请的,不是说兼容了,这些东西就自然而然有了。
怎么用:
资料:
android-cts-manual-r4
、宋立新
_Android CTS
测试研究;
安装与配置:
下载或自己编译;修改
startcts
中
SDK_ROOT
;在板子或
emulator
上装一个
apk
;设置
setting
;
各种命令的用法:
注意:
start --plan –p
以及
start --plan –t
的用法,
-t
要指定一个具体的测试方法
方法1:一般使用的方法
$
./start
cts
注意如果用手机设备调试,用
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
只运行某个用例包中的某个用例
方法
2
:遇到问题时方便调试的方法
$ adb install out/target/product/xxxx/data/app/SginatureTest.apk
安装某个用例包
$ adb shell pm list instrumentation pm
用于管理
package
,看当前机器安装了什么用例
$ adb shell am instrument -w android.tests.sigtest/.InstrumentationRunner am
用于管理
activity
运行某一用例
$
adb shell am instrument -e class
android.app.cts.AlertDialogTest#testAlertDialog -w
com.android.cts.app/android.test/InstrumentationCtsTestRunner
单独运行一个小
case
如果在一个时间很长的
plan
(如
Android
)中,某处错了,而错误信息又不全,需要单独跑一个小
case
,用
-e
指明
class
明就可以节约很多时间
用完后结果的分析:
结果在
repository/results
中,放在一个文件夹里,名字是你测试开始的时间。
分析的方法有两种:
1
、可以直接从
Failure Details
找原因;(个人感觉应该难度较大)
2
、结合源代码以及
Failure Details
的信息找原因
第二种方法牵扯到找测试源代码
的问题,这就要对
CTS
源码目录以及相应生成物的命名有一定的了解。
了解
CTS
这个工程:
资料:宋立新同学的
Android CTS
测试研究二、
android build system
、
CTS
源码、
makefile
以及
shell
基本知识
了解
Linux
工程最好的入手点,就是从它的编译系统入手。
这个涉及到
Linux
的
makefile
以及
android
的编译系统的基本知识,具体内容还是挺多的,不过看懂了
android
编译系统,以后看其他
Android
工程应该都会得心应手。
在
android CTS
上增加自己的
test package
资料:
CTS
命令的用法、
Erin Yueh
的两篇文章
有两种方法:
1
、完美利用自带命令(已验证)
2
、用
Erin Yueh
的方法
用这个方法的前提也是要彻底弄懂
CTS
的内部结构,不然也只能照猫画虎
如何写
test case
资料:
JUnit
、
SDK/docs
下面的五篇文章、android open source官网/porting/Instrumentation Testing
这又是另外一门学问了
这个
test case
可以涉及各个层次,
Android
平台相关的测试的写法可以参考官方的那五篇文章,如何运行可参考上面资料三,其他的可能会涉及到
JUnit
以及其他一些知识,目前还没实地考察。
接下来要弄明白的
1
、
android
的编译系统(学习下
makefile
以及
shell
基本知识)
2
、
CTS
这个工程(看看测试包
XML
生成器的假设成不成立,能不能提取出来)
3
、众多层次
test case
的写法
是什么?
资料:
CDD
、
CTS
官网、
android-cts-manual-r4
;
CTS
是什么我就不多费话了,看上面官方的说法就行了。不过有一点需要明确,你的设备只有满足
CDD
的规定并且通过
CTS
,才有可能获得
Android
的商标和享受
Android Market
的权限。这里有可能指的是需要你自己去向
申请的,不是说兼容了,这些东西就自然而然有了。
怎么用:
资料:
android-cts-manual-r4
、宋立新
_Android CTS
测试研究;
安装与配置:
下载或自己编译;修改
startcts
中
SDK_ROOT
;在板子或
emulator
上装一个
apk
;设置
setting
;
各种命令的用法:
注意:
start --plan –p
以及
start --plan –t
的用法,
-t
要指定一个具体的测试方法
方法1:一般使用的方法
$
./start
cts
注意如果用手机设备调试,用
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
只运行某个用例包中的某个用例
方法
2
:遇到问题时方便调试的方法
$ adb install out/target/product/xxxx/data/app/SginatureTest.apk
安装某个用例包
$ adb shell pm list instrumentation pm
用于管理
package
,看当前机器安装了什么用例
$ adb shell am instrument -w android.tests.sigtest/.InstrumentationRunner am
用于管理
activity
运行某一用例
$
adb shell am instrument -e class
android.app.cts.AlertDialogTest#testAlertDialog -w
com.android.cts.app/android.test/InstrumentationCtsTestRunner
单独运行一个小
case
如果在一个时间很长的
plan
(如
Android
)中,某处错了,而错误信息又不全,需要单独跑一个小
case
,用
-e
指明
class
明就可以节约很多时间
用完后结果的分析:
结果在
repository/results
中,放在一个文件夹里,名字是你测试开始的时间。
分析的方法有两种:
1
、可以直接从
Failure Details
找原因;(个人感觉应该难度较大)
2
、结合源代码以及
Failure Details
的信息找原因
第二种方法牵扯到找测试源代码
的问题,这就要对
CTS
源码目录以及相应生成物的命名有一定的了解。
了解
CTS
这个工程:
资料:宋立新同学的
Android CTS
测试研究二、
android build system
、
CTS
源码、
makefile
以及
shell
基本知识
了解
Linux
工程最好的入手点,就是从它的编译系统入手。
这个涉及到
Linux
的
makefile
以及
android
的编译系统的基本知识,具体内容还是挺多的,不过看懂了
android
编译系统,以后看其他
Android
工程应该都会得心应手。
在
android CTS
上增加自己的
test package
资料:
CTS
命令的用法、
Erin Yueh
的两篇文章
有两种方法:
1
、完美利用自带命令(已验证)
2
、用
Erin Yueh
的方法
用这个方法的前提也是要彻底弄懂
CTS
的内部结构,不然也只能照猫画虎
如何写
test case
资料:
JUnit
、
SDK/docs
下面的五篇文章、android open source官网/porting/Instrumentation Testing
这又是另外一门学问了
这个
test case
可以涉及各个层次,
Android
平台相关的测试的写法可以参考官方的那五篇文章,如何运行可参考上面资料三,其他的可能会涉及到
JUnit
以及其他一些知识,目前还没实地考察。
接下来要弄明白的
1
、
android
的编译系统(学习下
makefile
以及
shell
基本知识)
2
、
CTS
这个工程(看看测试包
XML
生成器的假设成不成立,能不能提取出来)
3
、众多层次
test case
的写法
相关文章推荐
- Android CTS 测试总结【转】
- Android CTS測试Fail项改动总结(四)
- Android CTS 测试总结【转】
- Android CTS 测试总结
- Android CTS 测试总结
- Android CTS 总结
- Android CTS 测试总结
- Android CTS 测试总结【转】
- Android CTS 总结
- android CTS测试之TV智能电视总结笔记
- Android CTS 测试总结
- Android CTS测试Fail项修改总结(四)
- Android CTS测试Fail项修改总结(四)
- Android CTS 测试总结
- Android CTS 测试总结【转】
- Android 5.1 CTS测试中部分问题总结
- android4.1.2 CTS测试总结
- Android 7.0 R2 CTS总结