Appium原理小結
Api接口調用selenium的接口，Android底層用android的instrumentation(API2.3+ 通過綁定另外一個獨立的selendroid項目來實現的)、uiautomator接口(API4.2+)，iOS底層用ios的uiautomation接口。
Client/ServerArchitecture
Appium server是用Node.js寫的，安裝node.js可以直接用npm命令或dmg，server端功能：監聽一個端口，接收client發送來的command，翻譯這些命令，把這些command轉成移動設備可以理解的形式發送給移動設備，然後移動設備執行完command後把執行結果返回給appium server，appium再把執行結果返回給client。
Client其實就是發起command的設備，一般來說就是執行代碼的機器，執行appium測試代碼的機器，可以把client理解成代碼，這些代碼可以是Java、Python、ruby、js，只要實現了webdriver標準協議就可以。
跨語言：只要支持selenium webdriver api和這種語言相關的client libraries就可以。Server放在任意機器上，哪怕是雲服務器都可以(appium和webdriver天生適合雲測試)。
Session
session就是一個會話，在webdriver/appium，你的所有工作永遠都是在session start後纔可以進行的。一般來說，通過POST /session這個URL，然後傳入Desired Capabilities就可以開啓session了。
開啓session後，會返回一個全局唯一的sessionid，以後幾乎所有的請求都必須帶上這個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？ server的這些疑問Desired Capabilities都必須給予解答，否則server不買賬，自然就無法完成移動app或者是瀏覽器的啓動。
Appium Clients
原生的webdriver api是爲web端設計的，appium官方提供了一套appium client，爲不同的語言的開發者可以測試自己的app，測試的時候，一般要使用這些client庫去替換原生的webdriver庫。算是client對原生webdriver進行了一些移動端的擴展。
appium0.18.x到appium1.x 的改變
1.新的客戶端庫
appium客戶端庫取代原來的webdriver客戶端庫
from appium import webdriver取代fromselenium import webdriver
2.新的capabilities選項
不再使用device、version，使用platformName、platformVersion、deviceName、automationName(“Selendroid”如果是api2.3以上要選擇，默認可以不填)，udid(ios要指定設備標示)。
之前的app這項capability保留不變，但該項現在專門用在非browser類型的app上面，要測試Safari或Chrome瀏覽器應用，要使用標準的browserName，app和browserName都是專用的選項。
同時我們也用駱駝命名法重新統一命名了我們的Appium Server的capabilities。比如說原來的app-package和app-wait-activity將改成appPackage和appWaitActivity。當然，鑑於我們能自動檢測到Android應用的包和activity，所以你可以大多時候忽略掉這些選項了。
3. 我們把以下的控件查找器策略給移除掉了：
name
tag name
我們現在引入了accessibility_id這個策略來取代原來name所做的事情（譯者注：也就是說原來的AppiumDriver.findElementByName將會被現在的AppiumDriver.findElementByAccessibilityId取代）。當中細節將會根據你使用的Appium客戶端（譯者注：客戶端語言）而有所不同。
新的class name將會取代原來的tag name（譯者注：也就說原來的findElementByTagName將會被想在的findElementByClassName取代），所以如果你要根據一個控件的UI類型來查找出該控件，請使用class name這個控件查找器。
注意class name和xpath策略的變化：你現在需要使用FQCN來描述你的控件。也就是說如果你由一個xpath選擇子如下所述：
//table/cell/button
那麼現在要改爲（譯者注：也就是說原來的findElementByXpath(""//TextView[contains(@text,'Addnote')]"")將需要改成findElementByXpath("//android.widget.TextView[contains(@text,'Addnote')]")：
//UIATableView/UIATableCell/UIAButton(如此類推：button現在就要寫成android.widget.Button)
同時我們也添加了如下的控件定位器策略（譯者注：也就是說入Andoid增加了AppiumDriver.findElementByUiAutomator）：
iosuiautomation
androiduiautomator
請根據你使用的客戶端（根據不同語言）庫來確定如何使用新的控件定位器策略。
4.使用XML取代JSON
取得當前窗口的源碼（譯者注：也就是AppiumDriver.getPageSource函數）返回的格式將從原來的JSON改成XML。所以如果你之前的代碼有依賴分析控件源碼的地方必須做相應的更新。
5. 混合應用通過context而非window進行支持
如今Appium支持（跟切換上下文這個概念）更加概念一致的的“context”。爲了取得所有可用的上下文或者你的應用特有的上下文，請使用如下方式:
# python driver.contexts current = driver.context
請使用如下方式進行切換：
# python driver.switch_to.context("WEBVIEW")
6. execute_script("mobile:xxx")將銷聲匿跡
所有”mobile：”相關的方法講都會被剔除掉，並且被Appium客戶端庫的原生方法給替代掉。例如原來的driver.execute("mobile:lock",[5])將會被現在的driver.lock(5)所取代（這裏lock這個功能已經成爲了原生的客戶方法了）。當然，具體的調用方法將會根據你所使用的不同的客戶端庫而有所不同了。
需要特別聲明的是，手勢操作相關的方法將會被新的TouchAction/MultiAction API所替代，把這些手勢操作集合在一起將會使得你的手勢操作相關的自動化更強大和通俗易懂。更詳細的TouchAction/MultiAction的使用請查看你的的Appium客戶端。
參考網址：
官網介紹：http://appium.io/slate/en/master/?python#appium
大神blog：http://blog.csdn.net/zhubaitian/article/details/39753945