Appium Python 二：理论概念理解

简介

Appium 是一个开源的自动化测试工具，支持 iOS 平台和 Android 平台上的原生应用，web 应用和混合应用。

“移动原生应用”是指那些用 iOS 或者 Android SDK 写的应用。

“移动 web 应用”是指使用移动浏览器访问的应用（Appium 支持 iOS 上的 Safari 和 Android 上的 Chrome）。

“混合应用”是指原生代码封装网页视图——原生代码和 web 内容交互。

Appium可以在模拟器以及真机上运行测试。

支持的平台有：IOS、Android、Windows、FirefoxOS。

理念

你无需为了自动化，而重新编译或者修改你的应用。（这里只需要一个编译好的APK文件即可）
你不必局限于某种语言或者框架来写和运行测试脚本。（支持多种语言，比如Python、Java、Ruby等等；Appium是一个自动化库，所以我们可以随意采用框架而不受限制）
一个移动自动化的框架不应该在接口上重复造轮子。（Appium扩充了浏览器的WebDriver协议，并添加了移动自动化相关的API方法）
无论是精神上，还是名义上，都必须开源。（Appium是开源的）

Appium 服务端以及客户端

Appium 服务端：就是安装 Appium的地方。可以从Appium的设置中看到默认地址是“http://127.0.0.1:4723/wd/hub”。

Appium 客户端：就是运行脚本的地方。这里脚本可能采用Java编写，也可能采用Python编写。Appium 客户端有很多语言库，比如 Java, Ruby, Python, PHP, JavaScript 和 C#。

我们写脚本时，会定义“driver = webdriver.Remote('http://localhost:4723/wd/hub', desired_caps)”，这里的第一个参数其实就是告诉客户端连接到哪个服务端。

Appium的核心就是一个web服务器，它提供了一套 REST 的接口。

当我们在Appium客户端编写好脚本之后，执行，会建立客户端到服务端的连接，Appium服务端监听到命令，会在移动设备上执行这些命令，然后将执行结果放到HTTP响应中返回给客户端。

下面是在Appium服务端打印出来的日志，执行的是“driver.find_element_by_name("1")”语句：

POST /wd/hub/session/xxxxxxxxxxxxxxxxxxxxxxxx/element {"value":"","sessionId":"xxxxxxxxxxxxxxxxxxxxxxxx","using":"name"}

> warn: [DEPRECATED] The name locator strategy has been deprecated and will be removed.  Please use the accessibility id locator strategy instead.

> info: [debug] Waiting up to 0ms for condition

> info: [debug] Pushing command to appium work queue: ["find",{"strategy":"name","selector":"","context":"","multiple":false}]

> info: [debug] [BOOTSTRAP] [debug] Got data from client: {"cmd":"action","action":"find","params":{"strategy":"name","selector":"","context":"","multiple":false}}

> info: [debug] [BOOTSTRAP] [debug] Got command of type ACTION

> info: [debug] [BOOTSTRAP] [debug] Got command action: find

> info: [debug] [BOOTSTRAP] [debug] Finding 1 using NAME with the contextId:  multiple: false

> info: [debug] [BOOTSTRAP] [debug] Using: UiSelector[DESCRIPTION=1, INSTANCE=0]

> info: [debug] [BOOTSTRAP] [debug] Using: UiSelector[TEXT=1, INSTANCE=0]

> info: [debug] [BOOTSTRAP] [debug] Returning result: {"value":{"ELEMENT":""},"status":0}

> info: [debug] Responding to client with success: {"status":0,"value":{"ELEMENT":""},"sessionId":"xxxxxxxxxxxxxxxxxxxxxxxx"}

这种服务端/客户端的架构，有很多好处。比如我在机器A上安装了Appium，然后我可以在机器B、机器C上编写脚本并执行，当然编写的脚本还可以采用不同的脚本语言。

Session

自动化始终围绕一个session进行。

客户端初始化一个seesion（会话）来与服务端交互，不同的语言有不同的实现方式，但是他们最终都是发送为一个POST请求给服务端，请求中包含一个JSON对象，被称作“desired capabilities”。此时，服务端就会开启一个自动化的 session，同时返回一个 session ID，session ID将会被客户端用来发送后续的命令。

下面是在Appium服务端打印出来的日志，反映的是客户端开始执行代码到服务端返回sessionID的过程：

> info: --> POST /wd/hub/session {"desiredCapabilities":{"platformName":"Android","appPackage":"com.android.calculator2","deviceName":"Android Emulator","platformVersion":"4.2.2","appActivity":".Calculator"}}

.........

> info: [debug] Creating new appium session xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

> info: Starting android appium

...........

> info: [debug] Appium session started with sessionId xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx