概要
Android目前的测试工具相较于4.0之前的版本变化很大. 令人欣喜的是Android的测试工具被重新整理分类. 针对不同的测试目的, 分别有了不同的测试解决方案:
- 针对非UI单元测试的Instrument.
- 针对单应用UI测试的Espresso
- 针对多应用UI测试的Uiautomator
其中, Uiautomator在跨进程调用, 黑盒测试领域有着非常好的便利性, 特别是平台黑盒测试领域, 应该是Android上目前比较理想的原生自动化工具了.
不过, 相较于早起版本, 近期的Uiautomator变化比较大, 总的来说变的更好用, 功能更全面了.
基于较高版本的Junit
- 基于较高版本的Junit使得测试更加灵活, 用例的属性会得到突出
- 通过annotation标注用例, 用例名字可以更加自由的定制了.
- 通过加入listener的方式进行扩展, 比如: 加入失败截图等
统一了Runner
早期的Uiautomator是以ant组织的jar包程序, 由内置的Uiautomator命令启动.
而最新的Support Library使用AndroidJUnitRunner 统一了各种用例的执行. 带来的好处是无论是单元测试还是UI测试, 都可以使用统一的runner. 在这之前, Uiautomator的用例是通过Uiautomator命令来支持的. 当然, 现在Uiautomator也依然好用.
命令行的限制
由于新版的Uiautomator用例是APK的附属品. 早期Uiautomator中使用的各种系统命令也需要获取一定的权限才可以正常运行. 比较普遍的如, 获取SurfaceFlinger权限, Dump权限, 读取Logcat的权限等等, 需要添加到Apk的manifest文件.
同时, 笔者实验时, 发现以前应用内部可以通过命令行调用Uiautomator, 似乎现在变得不可行.
需要注意的是, 以前通过命令行来实现的测试手段, 在新版的Uiautomator下,会有更好的解决方案. 比如, 之前通过dumpsys windows命令来取得当前的顶层Activity名字. 在新版的Uiautomator上, 借助context可以轻松取得task栈, 进而得到顶层Activity的名字.
成本考量
- 需要将原有基于命令行的功能函数重写, 改用Android的API来实现
- 用例的基类从UiAutomatorTestCase可以迁移到Instrument的Case类
- 建立Android工程, Manifest中添加各种需要的权限
总结
从官方的推荐来看, 针对单应用测试, 在可以得到代码的前提下, 最理想的是Espresso, 同时, 为了兼顾个别跨应用的用例, 可以辅以Uiautomator.
而针对非白盒的情况, Uiautomator仍然是首选. 同时, 编译jar包上传到测试机运行的方式仍然支持.
从长远观点来看, 迁移到新的Uiautomator方式会获得更多的灵活性.
