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端過來的命令，而非一個文件。