Appium Python 二：理論概念理解

簡介

Appium 是一個開源的自動化測試工具，支持 iOS 平臺和 Android 平臺上的原生應用，web 應用和混合應用。

「移動原生應用」是指那些用 iOS 或者 Android SDK 寫的應用。

「移動 web 應用」是指使用移動瀏覽器訪問的應用（Appium 支持 iOS 上的 Safari 和 Android 上的 Chrome）。

「混合應用」是指原生代碼封裝網頁視圖——原生代碼和 web 內容交互。

Appium能夠在模擬器以及真機上運行測試。

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

理念

1. 你無需爲了自動化，而從新編譯或者修改你的應用。 （這裏只須要一個編譯好的APK文件便可）
2. 你沒必要侷限於某種語言或者框架來寫和運行測試腳本。 （支持多種語言，好比Python、Java、Ruby等等；Appium是一個自動化庫，因此咱們能夠隨意採用框架而不受限制）
3. 一個移動自動化的框架不該該在接口上重複造輪子。 （Appium擴充了 瀏覽器的WebDriver協議，並添加了移動自動化相關的API方法）
4. 不管是精神上，仍是名義上，都必須開源。（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":"1","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":"1","context":"","multiple":false}]
> info: [debug] [BOOTSTRAP] [debug] Got data from client: {"cmd":"action","action":"find","params":{"strategy":"name","selector":"1","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":"1"},"status":0}
> info: [debug] Responding to client with success: {"status":0,"value":{"ELEMENT":"1"},"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