做Android 系统/应用开发怎么可以不懂自动化测试
接触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<T extends 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为我们提供方便的自动化测试机制，还有什么理由说不需要。
