接触Andorid有几个月了,一直认为做系统,应用开发根本不需要懂Android自动化测试之道,认为那都是测试人员需要掌握的东西,我们只要懂开发,只要读懂系统,根据客户的需求可以做相应的更改就可以了,只要熟悉了API,写出的应用可以实现某功能就可以了。其实不是的。
举个例子说,我们伟大的客户,疯狂地更换硬件配置,那么我们的驱动就跟着来回换,相关功能的c实现也要换,上层java对应稍作修改,碰上腻歪点的客户提出腻歪的需求,那么只有Good Luck了……幸运的整完了,好使了。Google及时发布Android的高版本,客户要跟风要升级,这时候突然发现,自己修改的系统相对于原生Android并非只是优化和添加XX功能,4个字:伤筋动骨。这个时候,完美升级几乎等于重写。避免这个悲剧的发生其实很简单,就是在完成开发任务之后,用cts测试一下符合不符合Android兼容性规范。倘若全部pass那么OK谢天谢地欢天喜地,若有fail项(不影响系统编译和相关功能实现,只是不符合兼容性规范),就要及时查看相关文件可以不可以修改,将其实现回归到Android正道。如若实在困难 ,就要提前和客户打好招呼,避免日后被他们扔回来,自己不好收拾。
Android自动化测试不单单只是cts,还有Monkey,ASE,Robotium,Instrumentationd ......都是非常实用的工具。比如应用中的UI测试,单个Activity测试,Instrumentationd就是最大的功臣。
android.test为我们提供了些什么?
举个例子来夸夸 ActivityInstrumentationTestCase2 <Textends Activity >
通过getActivity()可以轻松的获得activity,肆意使用其中的方法,回避了无法实例化对象使用不了某类的方法的问题。在get之前,
setActivityIntent(Intent)
and/or
setActivityInitialTouchMode(boolean)
, provide custom setup values to your Activity 。
我最近时间在接触camera这块,解决了几个bug,测了一下cts,意外的发现cts中,camera 的hardware test这块原来不符合兼容规范的fail项,全部都pass了。所以顿时很悔恨,为什么开始不先针对cts的结果来找bug出口,这个目标就锁定的很快,解决的效率会提高一倍。
简单说一下cts吧
$ make cts //android源码编译好后,在编译cts
解压上一步生成的android-cts.zip 然后就可以进行测试了。详细的操作搜一下资料,网上相关资源很多。
CTS测试会自动生成相应的测试包,该包位于如下目录:
android-cts/repository/results
每个测试包中包含了如下文件;
cts_result.css
cts_result.xsl
logo.gif
newrule-green.png
testResult.xml
该包的测试情况都在 testResult.xml 文件中,通过查看该文件可以知道,那些是和 Android兼容的
还有一点,特别需要注意,随着android版本的更新,cts也在不断更新。
如果你够好奇,可以试一试,同一系统的同一设备,用从r1到r5不同版本的cts都来测试一遍,会有意外的收获!
不懂测试,就不要说自己是优秀的开发人员。尤其,Android为我们提供方便的自动化测试机制,还有什么理由说不需要。