Appium自动化框架简介

Appium

• Appium简介
• Appium结构流程
• Appium工作原理
• Appium架构分析

---

Appium简介

Appium遵循的原则：

1.使用自动化来测试一个app，但是不需要重新编译它
2.写自动化case，不需要学习特定的语言
3.一个自动化框架不需要重复造轮子
4.一个自动化框架需要开源，在精神和实践上实现开源

appium扩展了webdriver的协议，没有自己重新去实现一套。

这样的好处是以前的webdriver
api能够直接被继承过来，以前的webdriver各种语言的binding都可以拿来就用，省去了为每种语言开发一个client的工作量。

appium选择了client-server的设计模式。

只要client能够发送http请求给server，那么的话client用什么语言来实现都是可以的，这就是appium及webdriver如何做到支持多语言的；

Appium 是一个用Node.js编写的HTTP server，它创建、并管理多个 WebDriver sessions 来和不同平台交互。开始一个测试后，就会在被测设备（手机）上启动一个 server ，监听来自 Appium server的指令。

移动端自动化框架、跨平台、多语言、不需要修改编译应用。

Appium结构流程

第一条：采用底层驱动商提供的自动化框架。

IOS:苹果的UIAutomation
Android 4.2+:谷歌的 UiAutomator
Android 2.3+:谷歌的Instrumentation（已被selendroid取

第二条：采用底层驱动商提供统一API，就是WebDriver API。

WebDriver(也称Selenium WebDriver)其实是一个C/S架构的协议，叫做JSON Wire Protocol。通过这个协议，用任何语言写成的客户端都可以发送HTTP请求给服务器。这就意味着你可以自由选择你想要使用的测试框架和执行器，也可以将任何包含HTTP客户端的库文件加入到你的代码中。换句话说，Appium的WebDriver不是一个技术上的测试框架，而是一个自动化库。

第三条：因为WebDriver是一个非常成熟的网页协议且已经正在起草W3C的标准。

不需要再创造其他东西呢？相反，我们在WebDriver的基础上，扩展了一些适合移动端自动化协议的API。

Appium工作原理

工作原理图：

在Android端，appium基于WebDriver协议，利用Bootstrap.jar，最后通过调⽤用UiAutomator的命令，实现App的自动化测试UiAutomator测试框架是Android SDK自带的App UI自动化测试Java库。另外由于UiAutomator对H5的支持有限，appium引入了chromedriver以及safaridriver等来实现基于H5的自动化。

appium 在android端工作流

1、client端也就是我们 test script是我们的webdriver测试脚本。
2、中间是起的Appium的服务，Appium在服务端起了一个Server（4723端口），跟selenium Webdriver测试框架类似， Appium⽀持标准的WebDriver JSONWireProtocol。在这里提供它提供了一套REST的接口,Appium Server接收web driver
client标准rest请求，解析请求内容，调⽤用对应的框架响应操作。
3、appium server会把请求转发给中间件Bootstrap.jar 它是用java写的，安装在手机上.Bootstrap监听4724端口并接收appium的命令，最终通过调⽤用UiAutomator的命令来实现。
4、最后Bootstrap将执行的结果返回给appium server。
5、appium server再将结果返回给 appium client。

Appium架构分析

Client/Server Architecture

appium的核心其实是一个暴露了一系列REST API的server。
这个server的功能其实很简单：监听一个端口，然后接收由client发送来的command。翻译这些command，把这些command转成移动设备可以理解的形式发送给移动设备，然后移动设备执行完这些command后把执行结果返回给appium
server，appium server再把执行结果返回给client。

在这里client其实就是发起command的设备，一般来说就是我们代码执行的机器，执行appium测试代码的机器。狭义点理解，可以把client理解成是代码，这些代码可以是java/ruby/python/js的，只要它实现了webdriver标准协议就可以。
这样的设计思想带来了一些好处：
1，可以带来多语言的支持；
2，可以把server放在任意机器上，哪怕是云服务器都可以；（是的，appium和webdriver天生适合云测试）

Session

session就是一个会话，在webdriver/appium，你的所有工作永远都是在session
start后才可以进行的。一般来说，通过POST /session这个URL，然后传入Desired
Capabilities就可以开启session了。 开启session后，会返回一个全局唯一的session
id，以后几乎所有的请求都必须带上这个session id，因为这个seesion id代表了你所打开的浏览器或者是移动设备的模拟器。
进一步思考一下，由于session id是全局唯一，那么在同一台机器上启动多个session就变成了可能，这也就是selenium
gird所依赖的具体理论根据。

Desired Capabilities

Desired
Capabilities携带了一些配置信息。从本质上讲，这个东东是key-value形式的对象。你可以理解成是java里的map，python里的字典，ruby里的hash以及js里的json对象。实际上Desired Capabilities在传输时就是json对象。 Desired
Capabilities最重要的作用是告诉server本次测试的上下文。这次是要进行浏览器测试还是移动端测试？如果是移动端测试的话是测试android还是ios，如果测试android的话那么我们要测试哪个app Appium Server 这就是每次我们在命令行用appium命令打开的东西。

Appium Clients

由于原生的webdriver api是为web端设计的，因此在移动端用起来会有点不伦不类。appium官方提供了一套appium
client，涵盖多种语言ruby/java/python，在我看来ruby
client是实现最好的。在测试的时候，一般要使用这些client库去替换原生的webdriver库。这实际上不是替换，算是client对原生webdriver进行了一些移动端的扩展，加入了一些方便的方法，比如swipe之类，appium
client让我们可以更方便的写出可读性更好的测试用例。

Bootstrap介绍：

下面一部分就是蓝色的就是bootstrap所在的位置，可以看到它是运行在我们的安卓目标测试机器端的，它会监听4724端口获得命令然后pass给UiAutomator来做处理。

Bootstrap是Appium运行在安卓目标测试机器上的一个UiAutomator测试脚本，该脚本的唯一一个测试方法所做的事情是在目标机器开启一个socket服务器来把一个session中Appium从PC端过来的命令发送给UiAutomator来执行处理。

这个定义说明了bootstrap在appium和uiautomator中究竟处于一个什么样的角色：
首先，它是一个uiautomator的测试脚本，它的入口类Bootstrap继承于UiAutomatorTestCase，所以UiAututomator可以正常运行它，它也可以正常的使用uiautomator的方法，这个就是appium的命令可以转换成uiautomator的命令的关键
其次，它是一个socket服务器，它专门监听4724端口过来的appium的连接和命令数据，并把appium的命令转换成uiautomator的命令来让uiautomator进行处理最后，它处理的是appium从pc端过来的命令，而非一个文件。