Appium的入門使用

ps：有沒有人和我同樣以爲Appium官方文檔寫的很爛的， 這官方文檔，還不如不少人寫的博客詳細，並且對於初學的入門者實在是不夠友好，
官網:https://github.com/appium/java-client

移動測試神器：帶你玩轉Appium

移動測試神器：帶你玩轉Appium

以移動應用的自動化測試爲主題，介紹目前主流的移動應用自動化測試框架 Appium。Appium 是一個開源的自動化測試框架，支持 iOS 和 Android 上 Web App、Native App 和 Hybrid App 的自動化測試。

因爲基於 Appium 的移動應用環境搭建相對複雜，雖然網上也有很多教程，可是知識點都比較零碎，並且大多都是基於早期版本的示例，因此我會使用最新版本的 Appium Desktop 1.6.2 和 Appium Server 1.8.1 來展開今天的內容：

• 首先，我會展現如何在 Mac 環境下一步一步地搭建 Appium 測試環境；
• 接下來，我以 iOS 爲例，實際開發兩個測試用例，一個是 Native App 的測試用例，另外一個是 Web App 的測試用例（由於 Hybird App 的測試用例實際上是相似的，Native App 的殼，Web App 的內容，因此就再也不單獨舉例子了）；
• 而後，我會在 iOS 的模擬器上實際執行這兩個測試用例（之因此選擇 iOS 模擬器，而不用 iOS 真機作例子，是由於 iOS 真機的測試須要用到 Apple 開發者帳號，還須要對被測應用進行簽名等，會在環境搭建過程當中引入不少額外步驟，而這些步驟對於講解 Appium 並無直接的關係）；
• 最後，當你已經經過實際使用對 Appium 造成感性認識後，我再來簡單介紹一下 Appium 的內部原理，讓你作到知其然知其因此然。

移動應用的自動化測試需求

在開始設計測試用例前，咱們首先須要明確要開發的這兩個自動化測試用例的具體測試需求。

1. Native App 的測試用例，被測 App 我選用了 Appium 官方的示例 App，被測 App 的源代碼能夠經過「https://github.com/appium/ios-test-app」 下載，而後在 Xcode 中編譯打包成 TestApp.app。
   具體的測試需求是輸入兩個數字，而後點擊「Compute Sum」驗證兩個數字相加後的結果是否正確。
2. Web App 的測試用例，具體需求是在 iPhone 上打開 Safari 瀏覽器，訪問 Appium 的官方主頁「http://appium.io」，而後驗證主頁的標題是不是「Appium: Mobile App Automation Made Awesome」。

圖 1 Native App 和 Web App 的 GUI 界面示例

接下來，我將從最初的環境搭建開始，和你來一塊兒開發 iOS 上的 Native App 和 Web App 的測試用例。首先咱們看一下 iOS 的環境搭建，若是你以前沒有接觸過這部份內容，你能夠跟着個人步驟一步一步來作；而若是你已經比較熟悉 Xcode 的話，能夠跳過這部份內容，直接從「Appium 環境搭建」部分看起。

iOS 環境搭建

在正式搭建 Appium 環境前，咱們先來搭建 iOS 開發環境：

• 首先，下載安裝 Xcode；
• 而後，在 Xcode 中下載 iOS 的模擬器；
• 接着，使用 Xcode 編譯打包被測試 App；
• 最後，在 iOS 的模擬器中嘗試手工執行這兩個測試用例。

在 iOS 模擬器中，手動執行測試用例的具體操做步驟以下：

1. 啓動 Xcode，導入 ios-test-app 下的 TestApp.xcodeproj 項目。
2. 在 Xcode 中，打開「Preferences」中的「Components」，完成 iOS 10.0 Simulator 的下載。
3. 在 Xcode 的「General」頁面，將 TestApp 的「Deployment Target」設置爲 10.0，而且將「Devices」設置爲「iPhone」，如圖 2 所示。

圖 2 TestApp 的 General 配置

1. 在 Xcode 中編譯運行 TestApp，以後系統會自動啓動 iPhone 模擬器，自動完成 TestApp 的安裝，並在 iPhone 模擬器中自動啓動 TestApp。
2. 在 TestApp 中手動執行自定義的加法測試用例。
3. 退出 TestApp，而後打開 Safari 瀏覽器，在 Safari 中執行訪問 Appium 官方主頁的測試用例。

至此，你已經搭建好了 iOS 開發環境，而且成功編譯打包了 TestApp。接下來，咱們再一塊兒來搭建 Appium 測試環境，並嘗試在 Appium 中開發上述的兩個測試用例。

Appium 測試環境搭建

經過 Appium 的官方網站下載並安裝最新版本的 Appium，截止本文寫做的時間，最新版本是 Appium-1.6.2.dmg。

須要注意的是，早期版本和網上不少教程都建議用命令行的形式啓動 Appium Server，但在這裏我是想強調的是，你徹底能夠經過界面啓動（在 Launchpad 中找到 Appium 的圖標，點擊便可啓動），並且新版本的 Appium 也推薦這個啓動方式。經過界面啓動，是目前最簡單直接的方式。

而後，你須要用命令行「npm install -g appium-doctor」安裝 Appium 的環境診斷工具 appium-doctor，用於檢查 Appium 所依賴的相關環境變量以及其餘安裝包是否都已經配置好了。若是尚未，就須要逐個安裝，並根據 appium-doctor 的提示配置環境變量。

這裏，Appium 最主要的依賴項主要有：Java、Node.js、Xcode、Carthage、Android SDK、adb 等。若是你全部的環境依賴都正常配置的話，你就會看到 appium-doctor 返回這樣一個截圖，如圖 3 所示。

圖 3 正常配置環境依賴後，appium-doctor 返回的截圖

按照上面的步驟，配置好 Appium 的環境依賴後，就能夠繼續啓動 Appium Server 了。

Appium Inspector 的使用

爲了後續測試用例的順利執行，咱們能夠先來熟悉一下 Appium Inspector 的使用。Appium Inspector 主要是用來協助對界面元素進行定位的工具。

首先，咱們來看看如何使用 Appium Inspector 啓動 iPhone 的模擬器，並在模擬器上運行 TestApp，以及如何經過 Inspector 定位 TestApp 界面上的元素（瞭解元素的定位是後續開發自動化腳本的基礎）。具體的操做過程以下。

1. 經過 Appium Server 的「Start Inspector Session」按鈕，進入 Session 配置界面。

圖 4 點擊「Start Inspector Session」按鈕打開 Session 配置界面

1. 在 Session 配置界面完成必要參數的配置。這裏你須要根據選用的移動設備操做系統、模擬器 / 真機等具體狀況來完成參數配置工做。須要配置的參數主要包括：platformName、platformVersion、DeviceName、automationName 和 app。
   其中，automationName，指自動化測試框架的名稱，這裏採用了 XCUITest；app 指被測 Native App 的安裝包路徑，這裏使用以前 Xcode 打包生成的 TestApp.app，這樣啓動模擬器時，就會自動把 TestApp.app 安裝到模擬器中。
   其餘參數的配置很是簡單，我就再也不一一展開了。

圖 5 Session 配置界面

1. 完成配置後，點擊 Session 界面的「Start Session」按鈕，啓動 iPhone 模擬器，並在 iPhone 模擬器中啓動 TestApp，同時還會打開 Inspector 窗口。如圖 6 所示。

圖 6 啓動 Session 後的 Inspector 窗口

1. 在 Inspector 窗口，咱們能夠利用「Select Elements」功能，經過點擊元素顯示 Native App 上的元素定位信息。如圖 7 所示。

圖 7 「Select Elements」功能示例

1. 在 Inspector 窗口，能夠經過「Recording」功能生成不一樣語言的自動化腳本。好比在啓用了「Recording」功能後，點擊「Compute Sum」按鈕，就會生成如圖 8 所示的自動化腳本片斷。

圖 8 「Recording」功能示例

瞭解瞭如何經過 Inspector 獲取元素定位信息的方法以後，咱們就來正式開發基於 Appium 的第一個 Web App 和第一個 Native App 的測試用例。

基於 Appium 開發你的第一個 Native App 的測試用例

第一步，創建一個空的 Maven 項目，而後在 POM 文件中加入如圖 9 所示的依賴。

在這個案例裏面，咱們會使用 TestNG 組織測試用例，因此代碼的第 14 行加入了 TestNG 的依賴。

第 19 行的 java-client 是關鍵，java-client 的做用是利用 Java 代碼將測試用例中的操做步驟發送給 Appium Server，而後由 Appium Server 自動完成這些操做。

目前 Appium 支持多種編程語言，每種語言都有本身的 client，好比這裏使用 Java 語言，因此引入了 java-client；若是你使用 Python 語言，那麼就須要引用 python-client。

圖 9 POM 文件加入 TestNG 和 java-client 的依賴

第二步，建立一個類，並命名爲「iOS_NativeApp_DemoTest」，而後按照如圖 10 所示的代碼實現這個 class。

注意，這裏的代碼是真實的可執行 Java 代碼，你能夠直接拿去使用。

圖 10 Native App 測試用例實例

• 代碼第 21 行的 @BeforeTest，第 38 行的 @AfterTest，以及第 44 行的 @Test，都是利用了 TestNG 的 annotation 對函數進行標註。
  標有 @Test 的函數是真正的測試主體，全部測試相關的步驟都放在這個函數中；
  標有 @ BeforeTest 的函數會在 @Test 函數以前執行測試的相關準備工做，圖中的代碼用這個函數完成了 DesiredCapabilities 的設置，並用該 Capabilities 構造了 iosdriver；
  標有 @ AfterTest 的函數在 @Test 函數執行結束後執行，主要用於環境的清理和收尾，圖示的代碼用這個函數完成了 iosdriver 的退出操做。
• 代碼的第 24-33 行構造了 DesiredCapabilities 對象，並對 APPIUM_VERSION、PLATFORM_VERSION、PLATFORM_NAME、AUTOMATION_NAME、DEVICE_NAME 和 APP 等參數進行了設置。其中 APP 的值是被測 Native App 安裝包的絕對路徑。
• 代碼的第 46-58 行是測試用例的主體部分，主要分爲三部分：
  第 47-50 行經過 iosdriver 的 findElementByAccessibilityId 方法定義了頁面上的四個元素，分別是輸入參數框 A、輸入參數框 B、計算按鈕和加法結果顯示框。代碼中具體的 AccessibilityId 能夠經過 Inspector 獲取。
  第 53-55 行經過自定義元素的操做執行加法運算。
  第 58 行經過斷言方法 assertEquals 驗證加法運算的結果。

第三步，爲了運行這個 TestNG 的測試用例，咱們須要再添加一個 testng.xml 文件， 具體內容如圖 11 所示。

圖 11 testng.xml 文件示例

第四步，在保證 Appium Server 已經啓動的狀況下，就能夠運行 testng.xml 執行測試了。 測試開始後，首先會自動啓動基於 iOS 10.0 的 iPhone 7 模擬器，而後依次自動完成 WebDriverAgent（WDA）和被測 Native App 的安裝。

WDA 是由 Facebook 開源的支持 iOS 自動化的代理工具，其底層經過 XCUItest 實現自動化。

接着，就會自動運行被測 Native App，並根據 @Test 函數中定義的步驟完成自動化測試的步驟和驗證。

到此，咱們的第一個基於 Appium 的 Native App 自動化測試用例就設計完了。

基於 Appium 開發你的第一個 Web App 的測試用例

有了 Native App 測試用例的設計基礎，再來實現一個基於 Appium 的 Web App 自動化測試用例就簡單得多了。

第一步，在上述的 Maven 項目中再建立一個類，並命名爲「iOS_WebApp_DemoTest」，而後按照如圖 12 所示的代碼實現這個類。

圖 12 Web App 測試用例實例

代碼的總體結構和上述 Native App 測試用例的徹底一致，只有一個地方須要特別注意：代碼的第 29 行，因爲 Web App 是基於瀏覽器的測試，因此這裏不須要指定 App 這個參數，而是直接用 BROWSER_NAME 指定瀏覽器的名字便可。

對於測試用例的主體部分，也就是代碼的第 45-47 行就比較簡單了，首先打開 Safari 瀏覽器並訪問「http://appium.io/」，接着用斷言方法 assertEquals 驗證頁面的 Title 是否是「Appium: Mobile App Automation Made Awesome.」。其中，實際頁面的 Title，能夠經過 mobiledriver 的 getTitle 方法得到。

第二步，在 testng.xml 中添加這個 Web App 的測試用例，而後咱們就能夠在 Appium Server 已經啓動的狀況下執行這個測試用例了。

這個測試用例，首先會自動啓動基於 iOS 10.0 的 iPhone 7 模擬器，而後自動打開 Safari 瀏覽器並訪問 Appium 的官方網站。執行完成後的界面以下圖 13 所示。

圖 13 測試用例執行完成的界面

進行到這裏，咱們基於 Appium 開發的第一個 Web App 的自動化測試用例，也就開發完成了。

通過前面 Appium 環境搭建，以及兩個測試用例的設計，相信你已經對 Appium 有了一個感性的認識了。那麼，Appium 的實現原理又是怎樣的呢？理解了 Appium 的使用原理，能夠幫助你更好地使用這個工具，設計更加「有的放矢」的測試用例。

Appium 的實現原理

Appium 做爲目前主流的移動應用自動化測試框架，具備極強的靈活性，主要體如今如下 5 個方面：

• 測試用例的實現支持多種編程語言，好比 Java、Ruby、Python 等；
• Appium Server 支持多平臺，既有基於 Mac 的版本，也有基於 Windows 的版本；
• 支持 Web App、Native App 和 Hybird App 三大類移動應用的測試；
• 既支持 iOS，也支持 Android；
• 既支持真機，也支持模擬器。

實際應用中，你能夠根據項目狀況靈活組合完成移動應用的自動化測試。好比，用 Java 寫 iOS 上的 Native App 的測試用例，測試用例跑在 Mac 平臺的 iPhone 虛擬機上；或者，用 Python 寫 Android 上的 Web App 的測試用例，測試用例經過 Windows 平臺跑在 Android 的真機上。

這樣的組合還有不少不少。那你有沒有想過，Appium 爲何能夠作到如此強大的靈活性呢？這就要從 Appium 的基本原理講起了。

要真正理解 Appium 的內部原理，你能夠把 Appium 分紅三大部分，分別是 Appium Client、Appium Server 和設備端。這三部分的關係如圖 14 所示。

圖 14 Appium 內部原理

咱們先來看看處於中間位置的 Appium Server。

Appium Server 有 Mac 和 Windows 版本，也就是說 Appium Server 能夠運行在 Mac 或者 Windows 電腦上。本質上，Appium Server 是一個 Node.js 應用，接受來自 Appium Client 的請求，解析後經過 WebDriver 協議和設備端上的代理打交道。

• 若是是 iOS，Appium Server 會把操做請求發送給 WebDriverAgent（簡稱 WDA），而後 WDA 再基於 XCUITest 完成 iOS 模擬器或者真機上的自動化操做；
• 若是是 Android，Appium Server 會把操做請求發送給 appium-UIautomator2-server，而後 appium-UIautomator2-server 再基於 UIAutomator V2 完成 Android 模擬器或者真機上的自動化操做。

Appium Client 其實就是測試代碼，使用對應語言的 Client 將基於 JSON Wire 協議的操做指令發給 Appium Server。

總體來講，Appium 的內部原理能夠總結爲：Appium 屬於 C/S 架構，Appium Client 經過多語言支持的第三方庫向 Appium Server 發起請求，基於 Node.js 的 Appium Server 會接受 Appium Client 發來的請求，接着和 iOS 或者 Android 平臺上的代理工具打交道，代理工具在運行過程當中不斷接收請求，並根據 WebDriver 協議解析出要執行的操做，最後調用 iOS 或者 Android 平臺上的原生測試框架完成測試。

總結

目前網絡上，Appium 工具使用相關的資料都比較零散，爲此我以最新版本的 Appium Desktop 1.6.2 和 Appium Server 1.8.1 爲例，手把手地帶你搭建了 iOS 環境，以及 Appium 測試環境，並介紹瞭如何經過 Appium Inspector 來定位頁面元素。

搭建好了測試環境後，分別針對 Native App 和 Web App 這兩類移動應用，基於 Appium 實現了兩個測試用例，這也是我在這個專欄裏面，爲你實現的第一個移動應用的測試用例。雖然測試需求比較簡單，可是你也能夠從中體會到移動應用測試用例設計的思想、方法。

最後，介紹了 Appium 的實現原理：它屬於 C/S 架構，Appium Client 經過第三方庫向 Appium Server 發起請求，Appium Server 接受請求，而後和移動平臺上的代理工具打交道，代理工具在運行過程當中不斷接收來自 Appium Server 的請求，並解析出要執行的操做，最後調用移動平臺原生的測試框架完成測試操做。