Appium自动化框架简介
一、Appium简介
1、Appium遵循的原则：
1.使用自动化来测试app，但是不需要重新编译它
2.写自动化case，不需要学习特定的语言
3.一个自动化框架不需要重复造轮子
4.一个自动化框架需要开源，在精神和实践上实现开源
2、Appium扩展了webdriver的协议，没有自己重新去实现一套
这样的好处是以前的webdriver api能够直接被继承过来，以前的webdriver各种语言的binding都可以拿来就用，省去了为每种语言开发一个client的工作量。
3、Appium选择了client-server的设计模式
只要client能够发送http请求给server，那么的话client用什么语言来实现都是可以的，这就是appium及webdriver如何做到支持多语言的。
4、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端过来的命令，而非一个文件。
五、Appium 框架的功能
（1）支持iOS、Android，可在多台机器上并行App 自动化，测试机型适配。
（2）代码实现关键字驱动：
测试集：关联Excel 测试用例和脚本配置。
测试数据：Excel 存储输入数据、控件元素、测试结果。
测试脚本：由Java 和TestNG 编写，分层结构有case、log、config、report 以及data 等。
（3）自动测试用例执行：
从功能测试用例中抽取需重复执行的、主要的功能进行用例覆盖。
支持用例failed（失败）时自动截屏。
failed（失败）用例自动重复执行数遍。
（4）持续集成环境Jenkins，定时自动构建和执行测试任务。
测试结果报告展示，自动邮件展示。
网友评论