Appium工作原理

一、Appium工作原理

 

1、Appium启动的时候，会创建一个http\\127.0.0.1:4723\wd\hub服务端（中转站）
2、4723端口接收client(也就是测试脚本)发来的请求，解析对应的请求
3、appium server把对应的请求发给bootstrap.jar，它是用java写的，安装在手机上的，在手机上监听4724端口，最终调用UiAutomator命令来实现操作
4、执行的结果由bootstrap返回给appium server  ，appium server再把结果返回给client
之前，Appium通过appium-android-bootstrap实现与UIAutomator v1的交互

现在大部分都使用UiAutomator2 ，针对Google推出的 UIAutomator V2，UiAutomator2修复了v1中遇到的大多数问题，最重要的是实现了与Android系统更新的分离

ps. 我们都知道appium只有在uiautomator2下可以实现对toast的识别，那是因为Google新增了AccessibilityService服务，重写该服务可以实现对Notification和Toast内容的捕捉

uiautomator2原理：
将automationName设置为uiautomator2，appium会调用appium-uiautomator2-driver,同时将uiautomator2 server的两个apk安装到测试设备上，
io.appium.uiautomator2.server.apk，执行handlers
io.appium.uiautomator2.server.test.apk，只有一个test，用于启动server

 

AppiumServlet ，管理请求的路由，将driver发过来的请求转发给对应Handler.
Handler，调用UiAutomator V2去执行指定操作，操作的结果经AppiumResponse统一封装
AppiumResponse，操作结果返回给appium-uiautomator2-driver，再将结果返给客户端

IOS工作原理

appium IOS封装了Apple的Instruments框架，主要用了Instrument里面的UI Automation，然后在设备中注入bootstrap.js进行监听

1、appium 启动server(监听4723端口)，用于和脚本通信，
2、收到请求后，server调用instruments.js启动一个socket server,同事分离出一个子进程运行instruments.app，讲bootstrap.js注入device，用于和外界交互
3、bootstrap.js把执行的结果返回给appium server

Appium从1.6.0 开始支持XCUItest框架， 
XCUITest是IOS官方维护的一个自动化测试框架，在iOS 10/xcode8 苹果完全去掉了以前的 UIAutomation 的技术支持，所以现在，要进行IOS的app自动化，只能使用XCUITest。

appium使用的模块是appium-xcuitest-driver，其中引用的Facebook提供的WDA方案来驱动iOS的测试，WDA编译应用在真机中必须配置development team和provisioning profil
 

二、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工作过程

1、appium是C/S模式的，分为appium-server和appium-client；
2、appium是基于webdriver协议，添加了对移动设备自动化api的扩展，所以具有和webdriver一样的特性，比如多语言支持；
3、webdriver是基于http协议的，第一次连接会建立一个session回话，并通过post请求发送一个json告知服务端相关测试信息；
4、对于Android来说，4.2以后是基于UiAutomator框架实现查找注入事件的
5、appium服务端是node.js编写的HTTP服务器，将现有的优秀的框架进⾏了集成

二、初步认识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测试脚本，该脚本的唯一一个所做的事情是在目标机器开启一个socket服务器来把一个session中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端过来的命令，而非一个文件。

从源代码中能够看到：

这个类是继承UiAutomatorTestCase的，这样它就能被UIAutomator作为测试用例类来运行了。而UiAutomatorTestCase类是继承自 Junit TestCase （Junit），可以直接使用它的一些方法和Junit单元测试框架中的Assert断言机制。
Bootstrap创建一个socketserver并监听4724端口，通过该端口可以与Appium服务端进行通信。
通过循环监听获取Appium服务端发送过来的指令，就可以进行相应的处理了。
 

package io.appium.android.bootstrap;  
import io.appium.android.bootstrap.exceptions.SocketServerException;  
import com.android.uiautomator.testrunner.UiAutomatorTestCase;  
/** 
 * The Bootstrap class runs the socket server. uiautomator开发的脚本，可以直接在pc端启动 
 */  
public class Bootstrap extends UiAutomatorTestCase {   
  public void testRunServer() {  
    SocketServer server;  
        try {  
          // 启动socket服务器，监听4724端口。  
          server = new SocketServer(4724);  
          server.listenForever();  
        } catch (final SocketServerException e) {  
          Logger.error(e.getError());  
          System.exit(1);  
        }  
      }  
    } 
 

四、所使用的技术

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这个地址就可以

九、 Appium客户端与Appium服务端之间的指令信息传递示例
1.点击“Start Server”(Host,Port保持默认即可)，启动Appium服务端

2.Appium服务端启动之后，会自动跳转到服务端控制台。

3.执行Appium客户端脚本，即可在服务端控制台看到对应日志，下图中截取了Appium服务端的部分日志。

现将示例中所有指令相关的日志筛选出来。通过以下的日志可以看出，每一个指令都有对应的Http请求与响应：
【–> POST】是Appium客户端向Appium服务端发送的请求，后面是指令转换成的json格式数据。
【<-- POST】是以HTTP响应的方式返回执行结果，状态码【200】表示成功。
具体示例：

person_center =driver.find_element_by_id(“content_rb_mine”) # 获取“个人中心”元素
[HTTP] --> POST /wd/hub/session/5e720862-8c45-450b-a115-d86dfd436bbe/element
[HTTP] {“using”:“id”,“value”:“content_rb_mine”}
[HTTP] <-- POST /wd/hub/session/5e720862-8c45-450b-a115-d86dfd436bbe/element 200 1251 ms - 137