Android自动化工具的选型对比

[摘要:先容 现在针对android主动化的框架或道对象实的是八门五花。有monkeyrunner、robotium、UiAutomator,appium,CTS等。全部的主动化照样须要从现实的项目动身。 MonkeyRunner ]

介绍

目前针对于android自动化的框架或者说工具真的是五花八门。有monkeyrunner、robotium、UiAutomator,appium,CTS等。所有的自动化还是需要从实际的项目出发。

MonkeyRunner

MonkeyRunner是Android SDK提供的测试工具,严格意义上来说MonkeyRunner其实是一个Api工具包。使用python语言进行编写测试用例,它的点击,输入,拖拽等实际上是通过调用monkey来进行实现的。而应用的安装,卸载以及设备的重启则是通过adb进行实现的。

缺点:

  1. 基于坐标的操作,实现的脚本难以维护
  2. 通过截图对比的方式进行验证,方式单一

Instrumentation

在UiAutomator出来之前,Instrumentation是最流行的android自动化框架,目前大多数的工具也都是基于Instrumentation进行二次封装实现的,如Robotium,淘宝的Athrun。Instrumentation通过将主程序以及被测程序放在同一个进程中来实现对被测程序进行模拟按键按下,屏幕点击等操作。它是直接使用android api进行操作。我们可以把Instrumentation看成一个类似Activity或者Service并且不带界面的组件,在程序运行期间监控你的主程序。

缺点:

  1. 由于Instrumentation的实现原理:要将主程序以及被测程序放在同一个进程中。所以就要求我们要对被测程序的apk进行重签名的操作。这一点对于我们测试整机系统来说是十分不便的。
  2. 由于android禁止了第三方的进程访问另外的进程,所以这就限制Instrumentation进行跨app操作的能力。

UiAutomator

UiAutomator同样是Android提供的自动化测试框架,基本上支持所有的Android事件操作,UiAutomator它运行的JUnit测试用例是有特殊权限的,这意味着测试用例可以跨越不同的进程。它还提供了五种不同的类给开发人员使用:

com.android.uiautomator.core.UiCollection;
com.android.uiautomator.core.UiDevice;
com.android.uiautomator.core.UiObject;
com.android.uiautomator.core.UiScrollable;
com.android.uiautomator.core.UiSelector

缺点:

  1. 编译运行较为麻烦,且不易于调试。UiAutomator需要将编译后的jar包推送到手机上后,通过手机的 uiautomator 的shell脚本才能运行。
  2. UiAutomator 只能工作于API 16或更高级别的Android设备上 。
  3. 不支持webview。也就是说它只能够支持Native APP的测试,对于Hybird App、WebApp就显得很无力了。

Adb-For-Test

Adb-For-Test是github上的一个开源项目,通过项目名字就可以知道,实际上所有的操作都是通过adb进行操作的。只是说作者在这上面对adb的操作做了一整套的封装。并且它也是需要依赖到UiAutoamtor的,它通过uiautomator dump /data/local/tmp/uidump.xml 命令将当前界面的树状结构,通过脚本传入的参数定位到元素的坐标,最后通过adb input 命令进行点击等操作。相较于UiAutoamtor变得更加的灵活了。

缺点:

  1. 仍然存在UiAutomator的缺点,只是说在API 16 以下的设备,Adb-For-Test仍然能够运行只是说只能通过坐标点击的方式了。
  2. 此工具的定位更多在于使用其他测试工具时集成它,类似于解决Robotium的跨进程的问题。

Appium

Appium是近来比较热门的一个开源框架了,并且社区 Testerhome 也相当的活跃,经常有一些大牛在上面分享一些经验。Appium支持iOS ,Android 的测试。对于 Android 4.1以前的版本使用的是 Selendroid,同样是基于instrumentation的框架,4.1以后的版本使用的UiAutomator,并且它同时能够支持webview的测试,解决了UiAutomator的缺陷。iOS 通过Apple官方的UiAutomation进行实现。另外appium支持多种语言使用。

这里还是需要重点介绍下Appium,因为我个人还是比较推崇它的,也使用它比较多。appium目前能够结合一些单元的测试框架如 Java的 Junit。python unittest 等进行 一些检查点的测试。这个是编写自动化测试用例最关键的一点。 另外还能够支持结合ReportNg生成测试报告。如图:

这里写图片描述

这里写图片描述

缺点:基于C/S的架构,需要安装Nodejs以及Appium的Server,相较于其他工具还是比较 “重”

总结

PS:

其实以上的介绍还有一些工具没有提及 如 Monkey , Espresso , Calabash , mokeyTalk
Monkey: 主要是用在压力测试以及稳定性测试上,在功能测试的作用上它还是有点相形见绌,不过后续会考虑在做app的深度遍历时加入monkey。
Calabash:同样能够支持Android以及iOS,采用Ruby来进行脚本编写, 基于Robotium框架,所以还是免不了Instrumentation的问题
MonkeyTalk:需要在源代码进行“插桩” 。
所以均未在这次自动化的考虑中。

出于后续其他项目自动化的开展,目前比较推荐的是使用Appium,当然如果只是一个android apk 的话 robotium也是一个备选的方案。



赞 (0) 评论 分享 ()