appium介绍和工作原理

导读

Appium这个听起来既生疏也熟悉的自动化测试工具，比起原生的UiAutomator可能是异常的不起眼，可是却是有自身独当一面的能力，可以完成许多高难度作业，完成UiAutomator不可能完成的一些任务，可以说appium丰富了UiAutomator的功能，使UiAutomator可以完成更多的任务。

Appium到底有哪些优势会让我们优先选择它去做ui自动化呢？

一、 appium的优势

首先来看一下appium相比较于UiAutomator有哪些优势：

1、支持webview、hybrid、native App自动化

目前很多手机app都是混合型，同时具有native页面和webview页面，而UiAutomator是不能直接操 作混合型app中的webview页面。

2、跨平台

Appium不仅可以在android平台上使用，还可以在ios上进行自动化，这样使得自动化脚本复用成为了可能。

3、支持多种语言（Java、Python、Ruby、C#等）

Appium不会受到语言方面的限制，绝大多数语言均可以驱动appium进行自动化测试，给测试人员提供了更多的选择。

既然有这么多的好处，那他跟UiAutomator到底有哪些联系，运行流程又是怎样？

二、appium运行流程

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）。

实现用例

通常情况下，手管web页面改动不是很多，页面元素较稳定，但是经常会对调用接口等做部分修改，每周都会在特定时间发布，由于没有h5测试人力，因此客户端测试人员每有改动就需要验证客户端内嵌webview页面是否可以正常点击及使用，而且通常情况下这些页面需要手机管家的登陆态，因此一定需要人工在手机管家内测试这些页面，而这类测试消耗较多测试人力，测试方法简单，较适合自动化测试。

Appium是一款非常适合混合型app自动化测试的工具，在app和webview之间快速切换，因此这里采用了appium来对手管页面进行测试。

测试一共分为三个部分，构造appium所需配置，执行自动化操作，对操作进行监听。

混合型app的自动化测试

配置好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文档。

3、监听自动化动作

执行完上述操作，基本上就可以执行所有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的自动化测试当中。

参考了：https://www.tinymind.net.cn/articles/002d3b11206805d

第二个介绍

一、Appium加载的过程图解

Appium的原理

WebDriver script：我们的测试脚本（java or python）

Appium：

　　会首先开启一个监听4723端口的server，接收测试脚本发送过来的对应请求，再将对应的请求发送给中间件Bootstrap.jar（注意这里的请求不是整个脚本文件，而是对应的命令请求，比如：点击一个元素就是一条请求）

Bootstrap.jar：

　　监听4724端口由appium发送过来的相关请求，并且将请求转换成UiAutomator可以识别的命令发给UiAutomator进行处理

二、初步认识appium工作过程

1.appium是c/s模式的 
2.appium是基于webdriver协议添加对移动设备自动化api扩展而成的，所以具有和webdriver一样的特性，比如多语言支持 
3.webdriver是基于http协议的，第一连接会建立一个session会话，并通过post发送一个json告知服务端相关测试信息 
4.对于android来说，4.2以后是基于uiautomator框架实现查找注入事件的，4.2以前则是instrumentation框架的，并封装成一个叫Selendroid提供服务 
5.客户端只需要发送http请求实现通讯，意味着客户端就是多语言支持的 
6.appium服务端是node.js写的，所以你安装的时候无论哪个平台都是先装node，然后npm install -g appium安装(翻墙墙)

三、bootstrap介绍

1）Bootstrap作用：

Bootstrap是Appium在初始化的时候推送到安卓手机上的一个UiAutomator测试脚本，该脚本的唯一一个测试方法所做的事情是在手机端开启一个SocketServer（通信模块），用来监听Appium从PC端过来的命令发送给UiAutomator来执行处理。

它会监听4724端口获得命令然后pass给UiAutomator来做处理。

2）Bootstrap在appium中扮演的角色：

首先，Bootstrap是uiautomator的测试脚本，它的入口类bootstrap继承于UiautomatorTestCase，所以Uiautomator可以正常运行它，它也可以正常使用uiautomator的方法，这个就是appium的命令可以转换成uiautomator命令的关键；

其次，bootstrap是一个socket服务器，专门监听4724端口过来的appium的连接和命令数据，并把appium的命令转换成uiautomator的命令来让uiautomator进行处理；

最后，bootstrap处理的是从pc端过来的命令，而非一个文件。

四、所使用的技术

Android上使用了instrumentation和uiautomator两套技术

iOS使用uiautomation

同时还支持firefox, 并可扩展其他平台

默认开启4723端口接受webdriver请求 ，4723是appium服务的，专门和脚本打交道；

默认开启4724用于和Android设备通讯

五、Capabilities

Capabilities是由客户端发送给Appium服务器端的用来告诉服务器去启动哪种我们想要的会话的一套键值对集合。当中也有一些键值对是用来在自动化的过程中修改服务器端的行为方式。

六、自我理解的工作原理

Appium启动时会创建一个http：127.0.0.1:4723/wd/hub服务端（相当于一个中转站），脚本会告诉服务器我要做什么，服务端再去跟设备打交道，服务端完成了脚本交给他的任务之后

服务端和设备如何通讯？

服务端和设备默认使用4724端口进行通讯的，底层调用uiautomator工具，在测试的时候服务端会给设备扔一个jar包就是appiumbootstrap.jar，会启动这个包，启动之后会在手机上创建一个socket服务，暴露的就是4724的端口；相对于socket服务来说，appium服务端又是一个客户端；

服务端的4724可以修改，设备上的不可以；服务端收到脚本传递过来的命令之后，通过电脑上的4724端口，想设备上的4724端口发送指令，appiumbootstrap.jar收到指令后回去完成点击，滑动其他的操作，完成之后再通过服务给服务端一个相应。服务端收到之后再去相应脚本

服务端和脚本如何通讯？

通过接口来访问，意味着服务端和脚本可以不在一起，只要能访问到127.0.0.1:4723这个地址就可以

参考：https://www.cnblogs.com/hyhyhy/articles/10830685.html

https://www.jianshu.com/p/5d11299f674b(可以再看一下这个)