Android自动化测试可行性途径分析

 

测试手段1： CTS 

用来确保某设备符合Android兼容性规范。

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  

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

[鲁棒是Robust的音译，也就是健壮和强壮的意思。 
鲁棒性（robustness）就是系统的健壮性。它是在异常和危险情况下系统生存的关键。比如说，计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下，能否不死机、不崩溃，就是该软件的鲁棒性。所谓“鲁棒性”，是指控制系统在一定（结构，大小）的参数摄动下，维持某些性能的特性。根据对性能的不同定义，可分为稳定鲁棒性和性能鲁棒性。以闭环系统的鲁棒性作为目标设计得到的固定控制器称为鲁棒控制器。 ]

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

Monkey测试即可以针对全局，也可以正对某个局部（某个 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自动化实现。