Appium这个听起来既生疏也熟悉的自动化测试工具,比起原生的UiAutomator可能是异常的不起眼,可是却是有自身独当一面的能力,可以完成许多高难度作业,完成UiAutomator不可能完成的一些任务,可以说appium丰富了UiAutomator的功能,使UiAutomator可以完成更多的任务。
Appium到底有哪些优势会让我们优先选择它去做ui自动化呢?
首先来看一下appium相比较于UiAutomator有哪些优势:
目前很多手机app都是混合型,同时具有native页面和webview页面,而UiAutomator是不能直接操 作混合型app中的webview页面。
Appium不仅可以在android平台上使用,还可以在ios上进行自动化,这样使得自动化脚本复用成为了可能。
Appium不会受到语言方面的限制,绝大多数语言均可以驱动appium进行自动化测试,给测试人员提供了更多的选择。
既然有这么多的好处,那他跟UiAutomator到底有哪些联系,运行流程又是怎样?
Appium的加载过程如上图。
1)调用Android adb完成基本的系统操作;
2)向Android上部署bootstrap.jar;
3)Bootstrap.jar Forward Android的端口到PC机器上;
4)Pc上监听端口接收请求,使用webdriver协议;
5)分析命令并通过forward的端口发给bootstrap.jar;
6)Bootstrap.jar接收请求并把命令发给uiautomator;
7)Uiautomator执行命令。
在执行自动化命令时,首先通过appium client(各种语言均有对应的client)将命令发送至appium 服务器,appium服务器会将解析到的结果发送至手机。Bootstrap收到来自服务器发来的请求去驱动UiAutomator执行命令(appium在IOS测试里是基于apple自身工具automation)。
Appium环境的搭建比较繁琐,其中有很多的细节,处理不好会影响到后续用例的编写,稳妥搭建环境可以事半功倍。
官网 https://nodejs.org/en/download/
appium的使用需要node.js支持,下载最新版node.js,双击安装后通过命令行node -v如果输出版本信息则说明已安装成功。
这里需要注意的是确保sdk版本在level 17以上,且需要配置环境变量。
安装地址:https://bitbucket.org/appium/appium.app/downloads/ 。
我本地安装的是1.4.16,相对比较稳定的一个版本,安装好后,需要配置环境变量,把node_modules的.bin目录放到系统的Path路径里,之后命令行输入appium-doctor检查是否安装成功。
打开appium客户端界面:
可以看到这就是appium server,右上角可以启动服务器,点击android的图标可以配置自动化的一些信息,包括待测app的位置,在测试前是否需要清空数据,配置待测手机的android版本信息等。
设置项可以配置服务器使用的端口信息,配置好后,启动服务器,信息就会在主界面上进行打印。
到这里,环境的搭建基本上就完成了,下面会结合java用例来说,会用到一些jar也要提前下载。接下来我们的appium需要用到监控来处理一些异常情况,同时通过监控类可以打印自己想要的内容,这部分也是需要环境的支持,不多说,直接上图。
其中java—client和client-combine还有selenium的jar用户支持appium客户端和appium服务器之间的交互,其余各jar的作用在于监听appium的信息时,会用到spring框架的东西。导入以上的jar就可以下面的工作了,实现用例。
通常情况下,手管web页面改动不是很多,页面元素较稳定,但是经常会对调用接口等做部分修改,每周都会在特定时间发布,由于没有h5测试人力,因此客户端测试人员每有改动就需要验证客户端内嵌webview页面是否可以正常点击及使用,而且通常情况下这些页面需要手机管家的登陆态,因此一定需要人工在手机管家内测试这些页面,而这类测试消耗较多测试人力,测试方法简单,较适合自动化测试。
Appium是一款非常适合混合型app自动化测试的工具,在app和webview之间快速切换,因此这里采用了appium来对手管页面进行测试。
测试一共分为三个部分,构造appium所需配置,执行自动化操作,对操作进行监听。
首先是构造AppiumDriver所需配置
用例的实现需要使用到JUNIT,首先需要在testcase前将需要的参数配置好,新建一个AppiumDriver实例,在DesiredCapabilities中把所需参数配置好。
首先需要设置platformName,deviceName平台和设备名称,这个可以根据需要自行设置,另外服务器客户端会配置这些内容,且会优先生效。
设置包名和activity名称,可通过adb命令获取对应的信息。
设置输入法,如果不设置是无法输入中文内容的,这条命令执行后,相当于你的手机替换为appium输入法。
最后,实现appiumdriver,新建url与本地的端口4723进行通信。
配置好driver内容,就可以开始用例的编写了,对于webview的测试,网上给出的方式是:开启待测应用的debug选项,然后将用例所处环境有native转换为webview模式,之后可以用h5页面中的控件对应的name对控件进行操作。转换成程序语言:
获取你的手机的所有webview信息然后找到你所测app的webview并设置。
然而上述方法有两个缺陷可能导致你无法获取webview,首先,绝大多数应用是不会开启webview的debug模式,第二,切换webview的情况会受到网络状态的影响,如果是内部代理的网络则会导致你无法操作chromedriver,切换至webview模式时会无法将命令传入导致超时,因此这种方式并未对其进行实现。
偶然间看到有人说android 6.0以上系统,无需切换webview模式就可以测试app中的webview,通过appium打开webview后,使用UiAutoviewver可以看到,webview中各控件可以像普通app中的控件一样可以捕捉到其控件信息。这里有一个技巧,需要你通过appium自动化打开webview的页面才能够获取控件信息,如果是手动打开,则页面是一个整体的view。
后面执行用例就要简单很多了,基本上都是捕获控件,然后对控件进行操作,这里我们选择了findElement方法,参数为控件的信息,通过By方法可以获取到名称resourceid等,原理同UiAutomator。
上述用例,通过打开手机管家,在app内打开反馈h5页面,并进行反馈和提交。 反馈操作,最后返回到h5的主页,通过assert判断返回去的页面的某元素是否存在,从而判断整个流程的正确性。常用的ui自动化测试工具在app和webview切换时会遇到无法测试webview的情况(例如有些情况下登录态是webview界面,则会导致无法进行后续的app自动化操作),而appium很好的解决了这一问题,能够快速在两种状态下切换并完成UI自动化测试。appium中查找控件的方法是findElements,可以通过class,name,desc,resourse-id进行查找,具体方法可以查阅appium api文档。
执行完上述操作,基本上就可以执行所有webview自动化需求了,不过这里你需要一些监听接口来插入日志,或是加入一些异常情况的判断,所以在实现了driver这个对象后。
通过上述方法,可以为用例加入监听,监听类继承自AppiumWebDriverEventListener。
看一下监听类中的方法,有形如下图的各种方法。
BeforeFindBy就是在findElement前是会首先执行这个方法,该方法会将控件信息和driver信息传递进来,在执行用例前可以进行一些打印日志,捕获异常和截图的操作,而afterFindBy则相反,是在执行完对应操作后进行监听。监听类可以获取到当前的driver信息,如上图,arg2是从用例中传递过来的driver,通过执行driver对应的方法可以操作页面元素,arg0为用例中findElement的参数,通过该参数可以确定用例执行位置,并打印出对应信息方便定位问题。
对于自动化用例执行过程中的异常(包括弹框等),因为appium服务器是单个线程执行,如果不想使用if else来监听控件信息来执行特殊操作,也可以结合uiWatcher进行异常情况的处理。
经过上述操作后,一条Hybrid混合应用的测试用例就完成了,开发对接口的改动,可以一键自动化操作完成对app内h5页面的自动化测试,通过该方法可以克服需要管家登陆态的情况,可以同时测试native页面和webview页面,减少开发人员和测试人员间的沟通成本和测试人力成本,快速验证改动点是否成功。
Appium目前是一种比较先进的测试工具,可以覆盖到UiAutomator所涉及的各个方面,还能完成webview的自动化测试,但是部署环境较复杂,而且出现很多的异常情况很难去定位到问题,同时网上资料也比较匮乏,导致其普及范围不是很广,希望这篇文章可以帮助需要用到appium工具的同学,快速越过搭建环境这一关,快速投入到混合型App的自动化测试当中。
关注微信公众号腾讯移动品质中心TMQ,获取更多测试干货!