背景

目前Android端已完成了相應的框架搭建，并實際落地產出了，由于Android使用的是Unittest+HtmlTestRunner產出報告，需要增加新功能的話需要改動到底層框架，所以目前在負責的iOS端打算采用Pytest+Allure方式來進行，優點是更好的插件支持，報告也會更好看（裝逼）點

PS：Android端自動化運行相比iOS自動化確實會穩定很多

一 iOS自動化框架及工具介紹

1.UIAutomation
UIAutomation 是蘋果提供的 UI 自動化測試框架，使用 JavaScript 編寫。

基于 UIAutomation 有擴展型的工具框架和驅動型的框架。擴展型框架以 JavaScript 擴展庫方法提供了很多好用 js 工具，注入式的框架通常會提供一些 Lib 或者是 Framework，要求測試人員在待測應用的代碼工程中導入這些內容，框架可以通過他們完成對 app 的驅動。

驅動型 UI Automation 在自動化測試底層使用了 UI Automation 庫，通過 TCP 通信的方式驅動 UI Automation 來完成自動化測試，通過這種方式，編輯腳本的語言不再局限于 JavaScript。這個工具在 iOS UI 自動化測試中使用非常廣泛

2.XCTest
XCTest 是蘋果在 iOS 7 和 Xcode5 引入的一個簡單而強大的測試框架，集成在 Xcode 中，用來編寫測試代碼。它提供了各個層次的測試。

XCTest 測試編寫起來非常簡單，并且遵循 xUnit 風格。

Xcode 在創建工程時，會默認使用 XCTest，并且默認創建了 Unit Test（單元測試）和 UI Test（界面測試）兩個 Target，其中 Unit Test 主要用于測試代碼的大部分基本功能，比如絕大多數 Model 的類和方法測試，業務邏輯測試，網絡接口調用測試等等。

UI Test 一般會考慮到用戶的交互流程，模擬用戶的交互操作，利用 XCTest 的 UI 記錄特性來獲取界面上的一些列視圖元素和操作事件，然后在測試方法中觸發事件。

所以這是一個可以提供各個層次的測試的框架，比如單元測試，自動化測試，性能測試等
XCTest參考資料

3.KIF
KIF 是 Keep It Functional 項目的縮寫，是一款 iOS app 功能性測試框架，來自 Square，該測試框架只支持 iOS。

所有測試使用 Objective-C 語言編寫，對測試人員來講，需要熟練的掌握 Objective-C 語言 ， 對蘋果開發者來說非常容易上手，更是一款開發者廣為推薦的測試工具。

KIF 使用未公開的 Apple API（私有 API），這對于測試目的而言是安全的，基于第三方 iOS UI 的單元測試框架，所以可以做項目的單元測試，也可以做 UI 集成測試。但缺點是運行較慢。

KIF參考資料

4.Frank

Frank 是 iOS 開發環境下一款實現自動測試的工具，Xcode 環境下開發完成后，通過 Frank 實現結構化的測試用例，其底層語言為 Ruby，作為一款開源的 iOS 測試工具，在國外已經有廣泛的應用。

但是國內相關資料卻比較少。其最大的優點是允許我們用熟悉的自然語言實現實際的操作邏輯。

它提供了針對 iOS 平臺的功能測試能力，可以模擬用戶的操作對應用程序進行黑盒測試，并且使用 Cucumber 編寫測試用例，使測試用例如同自然語言一樣描述功能需求，讓測試以“可執行的文檔”的形式成為業務客戶與交付團隊之間的橋梁。

• 優點

測試場景是在 Cucumber 的幫助下，用可理解的英語句子寫的，還有活躍的社區支持，以及不斷擴大中的庫。

• 缺點

對手勢的支持有限，所以在設備上運行測試有點難。

5.Calabash-iOS
Calabash 是一個適用于 iOS 和 Android 開發者的跨平臺 app 測試框架，可用來測試屏幕截圖、手勢和實際功能代碼。

Calabash 開源免費并支持 Cucumber 語言，Cucumber 能讓你用自然的英語語言表述 app 的行為，實現 BDD（Behavior Driven Development，行為驅動開發）。

而 Calabash-iOS 就是一個基于 Calabash 的 iOS 的功能、自動化測試框架。

• 優點：

有大型社區支持；
列表項簡單，類似英語表述的測試語句支持在屏幕上的所有動作，如滑動，縮放，旋轉，敲擊等。

• 缺點：

測試步驟失敗后，將跳過所有的后續步驟，這可能會導致錯過更嚴重的產品問題。
測試耗費時間，因為它總是默認先安裝 app，需要 Calabash 框架安裝在 iOS 的 ipa
文件中， 因此測試人員必須要有 iOS 的 app 源碼。

除了 Ruby，對其他語言不友好

Calabash參考資料

6.Appium
Appium 是一個開源的、跨平臺的自動化測試工具，支持 iOS、Android 和 FirefoxOS 平臺。

通過 Appium，開發者無需重新編譯 app 或者做任何調整，就可以測試移動應用，可以使測試代碼訪問后端 API 和數據庫。

它是通過驅動蘋果的 UIAutomation 框架來實現的 iOS 平臺支持,底層使用的是WEBDriverAgent來進行驅動

開發者可以使用 WebDriver 兼容的任何語言編寫測試腳本，如 Ruby，C#，Java， JS，OC， PHP，Python，Perl 和 Clojure 語言。

今日主角：Appium

7.AirTest
Airtest是由網易游戲推出的UI自動化測試解決方案，是一個跨平臺的、 基于圖像識別的UI自動化測試框架，適用于游戲和App，支持平臺有Windows、Android和iOS。并且提供了基于UI控件識別的Poco框架，目前也支持Android原生、iOS原生、Unity3D、cocos2dx、UE4和Egret等平臺。為了讓測試人員更好上手，網易還貼心地提供了AirtestIDE工具，內置了Airtest和Poco的相關插件功能，能夠使用它快速簡單地編寫 Airtest 和 Poco 代碼

相比于Appium，POCOUI最大的亮點是其內部集成了自研的圖像識別進行點擊，代碼編寫的語法會更為精煉
PocoUi 參考資料

結合以上7種方案，如果能使用Object-C進行XCTest用例編寫其實是最優選擇，但是由于本人對Object-C不熟悉，學習一門語言只用于做iOS自動化相關成本較大，所以綜合考量決定在Appium和Airtest之間做對比
Appium做自動化測試的都應該熟悉，Airtest作為網易開源的項目也是很不錯的，那么接下來看下兩者有何區別

二 Appium與Airtest的iOS自動化測試對比

對比項AppiumAirtest

安裝配置	中等:需要前置的一些依賴環境和填寫啟動的參數	簡單 IDE可直連
語言支持	涵蓋主流大部分語言	python為主
上手難易	中等	容易
市場占有率	TOP1	逐漸增加
支持平臺	Android，iOS，H5	Android，iOS，H5
集成框架	UiAutomator、UiAutomation框架	Poco元素識別、Airtest圖像識別
多設備并行	支持	支持
相關資料	多	較少
社區支持與維護	有專門的社區支持維護，交流討論較多	有Q群進行交流
后續升級	有保證	取決于網易團隊后續維護
測試報告	HtmlTestRunner、Allure	有自己帶的報告模板
CI持續集成	支持	支持
元素定位	部分頁面無法獲取元素	個人感覺元素定位不好用
執行效率	文本定位較快，其余定位較慢	文本定位較快，其余定位較慢
穩定性	一般，主要取決于WDA	一般，主要取決于WDA
編寫效率	取決于對Appium-Api的熟悉程度	取決于對Airtest和PocoUI的Api熟悉程度
適用場景	適用于自研，原生的App應用	多用于快速構建圖形腳本和游戲自動化

對比結論：

1.關于執行效率上，Appium與Airtest相差不大，主要還是通過元素的文本方式進行定位，脫離了文本想對元素進行定位速度都比較慢

2.關于代碼編寫效率上，本人使用Appium會好于Airtest（由于Android項目），Airtest的Api是新的，與appium的有所不同，對Api的熟悉需要一定過程，前期可能會較慢，后期熟練了會較快，Airtest對api的封裝會更多一些，初始用者需要自己對Appium的Api進行封裝

3.關于穩定性，Appium-wda和iOS-tagent都是基于facebook-wda（facebook未維護了，appium團隊對其進行改造有在維護，airtest目前也有在改造維護中）進行封裝改造的，試用時穩定性差不多，暫未出現掉線情況，iOS-tagent據說簡化了內部的一些邏輯調用，不過總體體驗下來差不多，對于高版本的iOS，Airtest官方好像還是推薦Appium的wda

4.關于適用場景，Appium主要是通過元素定位來進行自動化運行，適用于原生App下沒有特殊強調對某種類型的app會更好用，屬于兼容性較強的場景使用性，Airtest由于背靠網易，所以在場景使用方面更受游戲公司的自動化運行，尤其是他的圖像識別點擊，能夠更好的識別游戲自動化中的場景，不過Airtest也可以通過PocoUI進行元素點擊，涉及圖形多的，如游戲類的可以使用Airtest

5.對于特定場景的元素定位，部分App流下，Appium與Airtest均無法獲取到其中的元素信息，從而導致無法對該部分內容進行校驗，Appium每次切換頁面需要手動刷新頁面
Airtest可以實時顯示界面，Airtest的連接方式相對于Appium會稍簡單

6.關于后續版本維護方面，Appium目前社區維護穩定，幾天一更新，Airtest目前看最新的維護時間是在3個月前，相比之下Appium的維護工作會更好

7.關于多設備并行，Appium與Airtest都可以運行多設備，目前我這都是根據Tidevice啟動多個wda服務開啟多個端口號進行，使用情況差不多

8.相對于其他方面的比較基本都差不多

由于公司的App是原生+H5相關的，對Appium的使用也比較了解，兩者區別不是很大的情況下，還是選擇使用Appium做iOS自動化測試

三 Appium驅動原理

驅動原理

XCUITest是蘋果開發的一個做IOS自動化測試的框架，需要了解些Swift等iOS編程知識
WebDriverAgent是Facebook開發的一個iOS自動化測試工具，先來看下面的這張原理圖：

WDA在Client創建了一個Server，在手機端安裝了一個叫作WebDriverAgentRunner 的一個應用；這個應用會接收來自 Server 的指令，并連接底層的XCTest.framwork，讓 XCTest.framwork 調用蘋果API來操作手機進行自動化

而appium是把WebDriverAgentRunner 給集成進去了，因此實現了appium的跨平臺能力

通過上圖我們了解到 Appium 很粗暴的把整個 WebDriverAgent 直接集成到自己的項目里，然后通信機制就走 WebDriverAgent，Appium 其實就提供了一個 Client 端的作用。所以 iOS 9.3 系統之后自動化測試核心是 WebDriverAgent，Appium 就提供了一個 Client 端來寫腳本和發送指令。

Appium 自動化架構模式可以用一個抽象的架構表示，如下圖所示：

從圖中可以看出：

Client 端是 Appium 之前本身提供的；

Server 端是：WebDriverAgent 和 Instruments；（ Appium 直接把 WebDriverAgent 整個集成進來，Instruments 是為了支持 iOS 9.3 之前的系統）

之前 Server 是和 bootstrap.jar 通信，這里 WebDriverAgent提供了WebDriverAgentRunner （類似 jar 的功能），WebDriverAgent與之通信；

WebDriverAgentRunner 是一個應用，Client 和 server 運行了之后，WebDriverAgentRunner 會被裝到手機上，這個應用會接收來自 Server 的指令，并連接底層的framwork，并告訴XCTest.framwork操作手機進行自動化

關于WebDriverAgent

FaceBook 出品:

實現了一個 server，通過 server 可以遠程控制 iOS 設備：啟動應用、關閉應用、點擊、滾動等操作；

通過連接 framework 調用蘋果的 API 執行動作；

支持多個設備同時進行自動化；

Appium、Macaca 已經集成。

但是 WebDriverAgent僅僅只提供了一個 server（和 inspect 進行元素定位），并沒有像Appium 一樣提供 java 或 python 的 Client 端去寫腳本，腳本執行的時候發送指令給server，然后去運行。WebDriverAgent 要求你自己去實現 Client 端，即拿 Java/ Python 的WebDriver 庫進行封裝，然后發送指令。所以 WebDriverAgent 其實就類似于 Appium server，就只是一個server。

Appium簡介

Appium原理

• Appium是一個開源、跨平臺的測試框架，可以用來測試原生及混合的移動端應用。Appium支持IOS、Android及FirefoxOS平臺。Appium使用WebDriver的jsonwire協議，來驅動Apple系統的UIAutomation庫、Android系統的UIAutomator框架。Appium對IOS系統的支持得益于Dan Cuellar’s對于IOS自動化的研究。Appium也集成了Selendroid，來支持老android版本。
• Appium支持Selenium WebDriver支持的所有語言，如java、Object-C、JavaScript、Php Python、Ruby、C#、Clojure，或者Perl語言，更可以使用Selenium WebDriver的Api。Appium支持任何一種測試框架。如果只使用Apple的UIAutomation，我們只能用javascript來編寫測試用例，而且只能用Instruction來運行測試用例。同樣，如果只使用Google的UIAutomation，我們就只能用java來編寫測試用例。Appium實現了真正的跨平臺自動化測試。
• appium選擇了client-server的設計模式。只要client能夠發送http請求給server，那么的話client用什么語言來實現都是可以的，這就是appium及webdriver如何做到支持多語言的；

Appium優點

開源

跨架構:Native App、Hybird App、Web App

跨設備:Android、iOS、Firefox OS

不依賴源碼

使用任何 WebDriver 兼容的語言來編寫測試用例。比如 Java， Objective-C， JavaScript with
Node.js (in both callback and yield-based flavours)， PHP， Python，
Ruby， C#， Clojure， 或者 Perl.

不需要重新編譯APP

支持IOS手機錄制視頻

Appium理念

• 你無需為了自動化，而重新編譯或者修改你的應用。
• 你不必局限于某種語言或者框架來寫和運行測試腳本。
• 一個移動自動化的框架不應該在接口上重復造輪子。（移動自動化的接口應該統一）
• 無論是精神上，還是名義上，都必須開源。

Appium 在 iOS 下工具的變革

• iOS 9 之前一直以 instruments 下的 UIAutomation為驅動底層技術（弊端由于 instruments
  的限制，單臺 mac 只能對應單臺設備）；
• iOS 9.3 時代推出 XCUITest 工具，用以替代 UIAutomation；
• iOS 10 時代蘋果直接廢棄了 UIAutomation、Facebook 推出 WebDriverAgent（實現的 server
  能夠支持單臺 mac 對應多個設備）；
• Appium 在iOS 9.3 后全面采用 WebDriverAgent 的方案。

下一章內容：

【iOS自動化測試】第二章：環境搭建

總結

以上是生活随笔為你收集整理的【iOS自动化测试】第一章：方案调研的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。