Appium运行原理

Appium通信原理:

5564331e64d92884f808e2e.webp

Appium通信原理:Client端发送自动化指令给Appium server,Appium Server接收到client发送的指令后,转换为移动端能够识别的指令,然后发送给移动端设备,并对移动端设备进行操作。

运行原理如下:

①客户端运行脚本的时候,调用任何的appiumAPI,都会向Appium Server端post一条HTTP请求,请求内容就是根据webdriver wire protocol协议规定的一条JSON格式的数据;

②当开启appium服务器的同时就开启了监听端口,Appium Server端接收到请求后,解析出JSON数据并发送到手机端;

③手机端上已经由BootStrap.jar(iOS为BootStrip.js)开启的socket服务器监听相应的端口,BootStrap.jar在appium每个session第一次访问手机端的时候会自动安装;

④手机端接收到对应的请求后,通过BootStrap.jar翻译成UIAutomator能执行的命令,然后通过UIAutomator处理并操作APP完成测试。

Client端:

一般来说就是运行代码的机器,即我们是用Java语言编写的代码,也可以用其他Selenium支持Python,ruby,C#等语言来编写,Appium提供的Appium-client API是Appium通过扩展Selenium的Webdriver协议而来的,我们编写代码的时只要实现Webdriver标准协议即可。

Appium Server:

Appium Server功能是监听接口,接收client端发送的command,然后将command转为移动端能够识别的command,然后发送给移动设备进行操作,再等待移动设备返回来的操作结果,将操作结果发送给client端。 Appium server是可以放在client端,也可以放在云端。 Appium server 默认的端口号是4723,用于Appium server监听client端的发送来的请求。

Android设备

Android端,Appium基于Webdriver协议,利用Bootstrap.jar,最后通过调用UIautomatior命令,实现APP的自动化测试(Android4.2以前的版本是用Instrumentation框架,通过绑定另外一个独立的selendroid项目来实现),Android4.2以后的版本是用UIautomator)。UIAutomator测试框架是Android SDK自带的APP UI自动化测试Java库,另外UIAutomator对H5支持有限,Appium引入了Chromedriver以及Safaridriver来实现H5的自动化。

在Android设备的工作过程:

  1. Appium server将监听到的4723端口的指令,转发给中间件Bootstrap.jar,Bootstrap.jar是用Java编写的,安装在Android手机上;
  2. Bootstrap监听4724端口并接收Appium server的指令;
  3. Bootstrap再通过调用UIautomator的命令来实现具体的command操作。
  4. 最后Bootstrap将执行的结果返回给Appium server。

appium的整体架构是C/S模式,整体流程(返回顺序为逆向):

脚本请求 ——> 4723端口appium server ——> 解析参数给PC端4724端口 ——> 发送给设备4724端口 ——> 通过设备4724端口发给bootstrap.jar ——> Bootstrap.jar把命令发给uiautomator

appium工作流程

1、脚本请求 ——> 4723端口appium server :

首先我们要开启appium服务,即Appium server,默认监听4723端口。4723端口专门和脚本打交道,基于WebDriver协议。webdriver是按照server – client的经典设计模式设计的,作用就是启动基于WebDriver Wire协议的appium服务,接下来脚本与appium server的通信实际上是一个HTTP request请求给appium server,在请求的body中,会以WebDriver Wire协议规定的JSON格式的字符串来告诉appium服务我们希望设备接下来做什么事情。

appium中的Json wire protocol继承自selenium的webdriver wire protocol,并进行了扩展,使得Json wire protocol能够控制不同的移动设备的行为。

上面说到的是脚本请求对设备进行操作,但前提是,我们要对谁进行操作测试呢?这里就引入一个新名词:desired Capabilities。了解了上述之后,再去看脚本怎么将desired Capabilities传递给appium server就明白多了,脚本通过Json Wire Protocol协议以json格式发送测试设备信息给server端,测试设备信息被携带在Desired Capabilities中,这个东西实质上是一个key-value形式的对象,Desired Capabilities最重要的作用是告诉server本次测试的上下文。这次是要进行浏览器测试还是移动端测试?如果是移动端测试的话是android还是ios?如果android的话我们要测试哪个app?server的这些疑问Desired Capabilities都必须给予解答,否则server不买账,针对我们现在所说的安卓,它带来的影响就是无法完成app的启动。

那么,将测试设备信息告知之后,是不是就可以开始进行测试了呢?答案是:NO。这里又要引入一个名词:session。session就是一个会话,在webdriver/appium,你的所有工作永远都是在session start后才可以进行的。client 创建1个session,在该session中通过http向appium server发送请求,appium server解析请求,完成相应操作并返回response。

session

Session在计算机中,尤其是在网络应用中,称为“会话控制”。Session 对象存储特定用户会话所需的属性及配置信息,对应到这里其实就是desired Capabilities中的配置信息参数。脚本通过POST /session这个URL,然后传入Desired Capabilities就可以开启session了,由于这是第一次请求创建session,所有并没有一个已创建的session id所以appium server会调用android driver(appium升级到2.0.0后,原有的AppiumDriver函数变成抽象函数了,需更改为AndroidDriver)为client生成一个session并且生成一个与此session相关联的session id,这个 session id将被在本次响应中返回给客户端保存,当下次脚本发出操作请求时就会自带session id为唯一标识,代表所打开的设备,Appium server会按照此session id把这个session检索出来使用,脚本向appium server发送的请求即是存在于创建的session中的。

Session 的作用就是它在appium服务上保持设备的状态信息,供在任何时间进行访问,在多次的操作行为中,存储在 Session对象中的配置信息将不会丢失,而是在整个用户会话中一直存在下去,整个测试进程中设备与程序的联系不会断开,也不需要每次都发送带配置信息的请求,程序都知道对哪个设备进行测试操作。当测试结束后,需关闭webdriver,driver.quit()会关闭所有关联窗口和session,并且也会把进程也关闭

2、解析参数给PC端4724端口 ——> 发送给设备4724端口 ——> 通过设备4724端口发给bootstrap.jar ——> Bootstrap.jar把命令发给uiautomator:

创建session成功之前,就已将bootstrap.jar放入手机中,并开启设备上的基于appium bootstrap的socket服务,绑定本机和boostrap通信的端口号4724用于和Android设备通讯,默认监听4724端口,等待client的连接。

Appium server将脚本的请求解析后给到4724端口,通过设备的4724端口转发解析后的请求, 此时,对于socket服务来说,appium server就充当了client的角色,appium server通过4724端口主动去请求设备上的socket服务,即向socket服务发送请求,即bootstrap.jar,Bootstrap.jar再把Appium的命令转换成uiautomator的命令来让uiautomator进行处理。有请求就有返回,socket接收到请求后会做出响应,原路返回给脚本,然后脚本再进行下一次的请求。

参考资料

上一篇 下一篇

评论 | 0条评论