随着移動終端的普及，手機應用越來越多，也越來越重要。而作為測試的我們也要與時俱進，努力學習手機App的相關測試，前一段時間我們介紹了Robotium手機自動化測試架構，從本章開始，我們介紹另一個手機自動化測試架構Appium。那究竟什麼是Appium呢？我們引用Appium官網的介紹如下：
英文官網：http://appium.io/introduction.html?lang=zh
1.1 Appium 簡介
Appium是一個開源的自動化測試工具，其支援iOS和安卓平台上的原生的，基于移動浏覽器的，混合的應用。
原生應用：僅使用iOS和安卓标準SDK編寫的應用
基于移動浏覽器的應用：用移動平台的浏覽器通路的應用（Appium支援IOS上的Safari和安卓上的Chrome或内嵌的“浏覽器”應用）
混合應用：把基于一個WebView實作的所有功能包裝成一個應用的應用，WebView是一個可以和網頁各種元素互動的原生控件（譯者注：因為所有的移動平台都會有浏覽器，是以基于浏覽器封裝起來的應用就可以輕易做到跨平台了）。Phonegap這些項目可以很友善的把那些基于web技術實作的功能打封裝成一個混合應用。
重要的是，Appium是跨平台的：它允許你采用同一套API在不同的平台（iOS,Android）上編寫測試代碼。這就讓測試套件在iOS和Android平台上實作代碼複用成為可能。
至于有關Appium跨平台支援和測試自動化子產品化的具體意義，請參考platform support doc.
1.2 Appium 理念
Appium是基于以下的四個理念設計來滿足移動平台測試自動化的要求的：
（1）您不應該因為需要自動化測試您的應用而不得不以任何形式去重新編譯或者修改你的app。
（2）您不應該把自己固定在一門特定的語言和一個特定的架構上去實作和運作你的測試。
（3）當說到測試自動化APIs的時候，一個移動測試架構不應該做“重新發明***”的事情。
（4）一個移動測試自動化架構應該是開源的，無論是在精神上，實際上，還是名義上！
1.3 Appium 設計
那麼Appium項目的架構是如何滿足這些理念的要求的呢？為了實作第#1個要求，我們在背後使用的是移動平台供應商（譯者注:iOS的UIAutomation和Android的Instrumentation及UIAutomator)提供的标準自動化測試架構。這樣一來，我們就不需要往你的app裡面編譯進去任何的Appium相關的或第三方代碼或架構。這就意味着“你測試的是你将要釋出的那一個應用”。我們使用的移動平台供應商提供的架構如下：
Ø IOS: 蘋果公司的 UIAutomation。
Ø Android 4.2+: Google公司的 UiAutomator。
Ø Android 2.3+: Google公司的 Instrumentation. (Instrumentation 的支援是通過綁定另外一個獨立的Selendroid項目來實作的)。
為了實作第#2個要求，我們的做法是把不同的移動平台供應商的自動化測試架構進行一次更高層次的封裝，做成一套統一的API暴露出來，也就是我們要說的WebDriver API了。WebDriver（也叫做“Selenium WebDriver”）指定使用了一套用戶端-伺服器端協定（也就是JSON Wire Protocol),基于這一套協定，用戶端無論是用什麼語言編寫的都能夠通過HTTP請求恰當的發送到伺服器。事實上現在已經存在有使用不同流行語言編寫的用戶端了。這也就意味着您可以随便使用任何你喜歡的測試執行過程管理平台和測試架構，因為你使用到的Appium用戶端的庫僅僅是一個HTTP用戶端而已，你可以用任何你喜歡的方式把它嵌入到你的代碼裡面去。換一個說法就是，Appium&WebDriver用戶端實際上并不是真正的”測試架構“，而是"自動化測試庫”，你可以借助它們按照你自己喜歡的方式來搭建管理你的測試環境。
我們使用同樣的方法實作了第#3個要求：鑒于WebDriver事實上已經是網絡浏覽器自動化測試的标準，并且已經立為W3C的工作草案，那麼我們有什麼必要針對移動裝置再重建立立一套标準呢？沒有必要！我們隻需要擴充相應的WebDriver API來友善移動平台測試自動化的使用就行了。
至于第#4點就不言而喻了--你現在在讀這篇文章這些内容就是因為Appium是開源的。
1.4 Appium 概念
1.4.1用戶端/伺服器端架構
Appium的核心是一個暴露了REST API的網絡伺服器。它接收用戶端過來的連接配接，監聽（用戶端過來的）指令，在移動裝置上運作指令，然後把代表指令運作結果的HTTP響應包發送回用戶端。
我們使用用戶端/伺服器段的架構事實上為我們打開了很多可能性：我們可以在任何支援http 用戶端API的語言上面實作我們的測試代碼，當然使用我們提供的”Apppiu用戶端庫“會更加友善高效。我們可以把伺服器端放在跟我們的測試運作機器完全不一樣機器上。我們可以低頭安心編寫測試用例然後依賴遠端的雲服務平台如“Sauce Labs”來接收和翻譯我們的測試指令。
1.4.2會話
自動化往往都是在一個擁有會話的上下文中進行的。用戶端往伺服器端發起一次會話的方式根據具體不同的庫而會有所不同，但相同的是它們最終都會發送一個包含所謂的“desired capabilities"JSON對象的Post/session的請求到伺服器端。這樣伺服器端就會開啟一個自動化會話并把會話ID發送回用戶端以便往後的持續的指令傳遞。
1.4.3 Desired Capabilities（不好翻譯，是以當成專用術語不翻譯算了）
Desired Capabilities是由用戶端發送給Appium伺服器端的用來告訴伺服器去啟動哪種我們想要的會話的一套鍵值對集合。當中也有一些鍵值對是用來在自動化的過程中修改伺服器端的行為方式的。
比如，我們可以把鍵為platformName的capability的值設定成iOS來告訴伺服器我們想要開啟的是一個iOS的會話，而非Anddroid的會話。或者我們可以把鍵為safariAllowPopups 的capability的值設定成true來確定在Safari自動化會話的過程中，我們可以使用JavaScript來彈出一個新視窗。要檢視Appium支援的完整的capabilities清單，請檢視capabilities doc。
1.4.4 Appium 伺服器
Appium是一個由Node.js編寫的伺服器。可以通過源碼或NPM進行編譯和安裝。
1.4.5 Appium 用戶端
存在很多對WebDriver協定進行擴充的Appium用戶端庫（針對以下語言的庫：Java，Python，PHP,JavaScript，以及C#).當使用Appium的時候，相對正常的（譯者注：沒有擴充的）WebDriver庫，我相信你更會選擇使用這些擴充後的庫。你可以在這裡檢視所有的庫。
1.4.6 Appium.app, Appium.exe
這些Appium伺服器的GUI封裝版是可以下載下傳的。事實上這些在配置appium伺服器可運作環境時已經和其他東西一起打包安裝了的，是以你并不需要擔心要用Node再去下載下傳安裝。當中有一個Inspector也會一起安裝，你可以用它來檢視你的app的結構，這樣你就可以在它的協助下很友善的編寫測試腳本了。
開始
恭喜！你現在已經裝備好足夠的知識來開始使用Appium了，何不去getting started doc擷取更加詳細的需求描述和建議呢？
1.5 本章小結
本章我們引用了Appium官網的介紹來作為我們這個教程的開始，先讓大家對這個架構有一定的了解，然後在接下來的章節，我們将詳細講解如果利用這個測試架構來編寫我們的自動化測試用例。而語言上我們采用python，當然也可以使用java。我們先介紹python+appium,如果大家有需求，我們後期會介紹java+appium，希望對大家的學習有所幫助。