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？ server的這些疑問Desired Capabilities都必須給予解答，否則server不買賬，自然就無法完成移動app或者是瀏覽器的啟動。
具體例子如下：
For example, we might set the
platformNamecapability toiOSto tell Appium that we want an iOS session, rather than an Android one. Or we might set thesafariAllowPopupscapability totruein order to ensure that, during a Safari automation session, we’re allowed to use JavaScript to open up new windows. See the capabilities doc for the complete list of capabilities available for Appium
Appium Server
這就是每次我們在命令行用appium命令打開的東西。
Appium Clients
由於原生的webdriver api是為web端設計的，因此在移動端用起來會有點不倫不類。appium官方提供了一套appium client，涵蓋多種語言ruby/java/python，在我看來ruby client是實現最好的。在測試的時候，一般要使用這些client庫去替換原生的webdriver庫。這實際上不是替換，算是client對原生webdriver進行了一些移動端的擴展，加入了一些方便的方法，比如swipe之類，appium client讓我們可以更方便的寫出可讀性更好的測試用例。
Appium.app, Appium.exe
appium server的GUI版本，前者用在osx上，后者是windows上。可視化、不需要裝node，可以看app的UI結構是這個東東的賣點。
下一講，appium的安裝
本文版權歸乙醇所有，歡迎轉載，但請注明作者與出處，嚴禁用於任何商業用途