背景
目前Android端已完成了相應的框架搭建，并實際落地產出了，由于Android使用的是Unittest+HtmlTestRunner產出報告，需要增加新功能的話需要改動到底層框架，所以目前在負責的iOS端打算采用Pytest+Allure方式來進行，優(yōu)點是更好的插件支持，報告也會更好看（裝逼）點
PS：Android端自動化運行相比iOS自動化確實會穩(wěn)定很多
一 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 在創(chuàng)建工程時，會默認使用 XCTest，并且默認創(chuàng)建了 Unit Test（單元測試）和 UI Test（界面測試）兩個 Target，其中 Unit Test 主要用于測試代碼的大部分基本功能，比如絕大多數 Model 的類和方法測試，業(yè)務邏輯測試，網絡接口調用測試等等。
UI Test 一般會考慮到用戶的交互流程，模擬用戶的交互操作，利用 XCTest 的 UI 記錄特性來獲取界面上的一些列視圖元素和操作事件，然后在測試方法中觸發(fā)事件。
所以這是一個可以提供各個層次的測試的框架，比如單元測試，自動化測試，性能測試等
XCTest參考資料
3.KIF
KIF 是 Keep It Functional 項目的縮寫，是一款 iOS app 功能性測試框架，來自 Square，該測試框架只支持 iOS。
所有測試使用 Objective-C 語言編寫，對測試人員來講，需要熟練的掌握 Objective-C 語言 ， 對蘋果開發(fā)者來說非常容易上手，更是一款開發(fā)者廣為推薦的測試工具。
KIF 使用未公開的 Apple API（私有 API），這對于測試目的而言是安全的，基于第三方 iOS UI 的單元測試框架，所以可以做項目的單元測試，也可以做 UI 集成測試。但缺點是運行較慢。
KIF參考資料
4.Frank
Frank 是 iOS 開發(fā)環(huán)境下一款實現自動測試的工具，Xcode 環(huán)境下開發(fā)完成后，通過 Frank 實現結構化的測試用例，其底層語言為 Ruby，作為一款開源的 iOS 測試工具，在國外已經有廣泛的應用。
但是國內相關資料卻比較少。其最大的優(yōu)點是允許我們用熟悉的自然語言實現實際的操作邏輯。
它提供了針對 iOS 平臺的功能測試能力，可以模擬用戶的操作對應用程序進行黑盒測試，并且使用 Cucumber 編寫測試用例，使測試用例如同自然語言一樣描述功能需求，讓測試以“可執(zhí)行的文檔”的形式成為業(yè)務客戶與交付團隊之間的橋梁。
- 優(yōu)點
測試場景是在 Cucumber 的幫助下，用可理解的英語句子寫的，還有活躍的社區(qū)支持，以及不斷擴大中的庫。
- 缺點
對手勢的支持有限，所以在設備上運行測試有點難。
5.Calabash-iOS
Calabash 是一個適用于 iOS 和 Android 開發(fā)者的跨平臺 app 測試框架，可用來測試屏幕截圖、手勢和實際功能代碼。
Calabash 開源免費并支持 Cucumber 語言，Cucumber 能讓你用自然的英語語言表述 app 的行為，實現 BDD（Behavior Driven Development，行為驅動開發(fā)）。
而 Calabash-iOS 就是一個基于 Calabash 的 iOS 的功能、自動化測試框架。
- 優(yōu)點：
有大型社區(qū)支持；
列表項簡單，類似英語表述的測試語句支持在屏幕上的所有動作，如滑動，縮放，旋轉，敲擊等。
- 缺點：
測試步驟失敗后，將跳過所有的后續(xù)步驟，這可能會導致錯過更嚴重的產品問題。
測試耗費時間，因為它總是默認先安裝 app，需要 Calabash 框架安裝在 iOS 的 ipa
文件中， 因此測試人員必須要有 iOS 的 app 源碼。
除了 Ruby，對其他語言不友好
Calabash參考資料
6.Appium
Appium 是一個開源的、跨平臺的自動化測試工具，支持 iOS、Android 和 FirefoxOS 平臺。
通過 Appium，開發(fā)者無需重新編譯 app 或者做任何調整，就可以測試移動應用，可以使測試代碼訪問后端 API 和數據庫。
它是通過驅動蘋果的 UIAutomation 框架來實現的 iOS 平臺支持,底層使用的是WEBDriverAgent來進行驅動
開發(fā)者可以使用 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用例編寫其實是最優(yōu)選擇，但是由于本人對Object-C不熟悉，學習一門語言只用于做iOS自動化相關成本較大，所以綜合考量決定在Appium和Airtest之間做對比
Appium做自動化測試的都應該熟悉，Airtest作為網易開源的項目也是很不錯的，那么接下來看下兩者有何區(qū)別
二 Appium與Airtest的iOS自動化測試對比
| 對比項 | Appium | Airtest |
|---|---|---|
| 安裝配置 | 中等:需要前置的一些依賴環(huán)境和填寫啟動的參數 | 簡單 IDE可直連 |
| 語言支持 | 涵蓋主流大部分語言 | python為主 |
| 上手難易 | 中等 | 容易 |
| 市場占有率 | TOP1 | 逐漸增加 |
| 支持平臺 | Android，iOS，H5 | Android，iOS，H5 |
| 集成框架 | UiAutomator、UiAutomation框架 | Poco元素識別、Airtest圖像識別 |
| 多設備并行 | 支持 | 支持 |
| 相關資料 | 多 | 較少 |
| 社區(qū)支持與維護 | 有專門的社區(qū)支持維護，交流討論較多 | 有Q群進行交流 |
| 后續(xù)升級 | 有保證 | 取決于網易團隊后續(xù)維護 |
| 測試報告 | HtmlTestRunner、Allure | 有自己帶的報告模板 |
| CI持續(xù)集成 | 支持 | 支持 |
| 元素定位 | 部分頁面無法獲取元素 | 個人感覺元素定位不好用 |
| 執(zhí)行效率 | 文本定位較快，其余定位較慢 | 文本定位較快，其余定位較慢 |
| 穩(wěn)定性 | 一般，主要取決于WDA | 一般，主要取決于WDA |
| 編寫效率 | 取決于對Appium-Api的熟悉程度 | 取決于對Airtest和PocoUI的Api熟悉程度 |
| 適用場景 | 適用于自研，原生的App應用 | 多用于快速構建圖形腳本和游戲自動化 |
對比結論：
1.關于執(zhí)行效率上，Appium與Airtest相差不大，主要還是通過元素的文本方式進行定位，脫離了文本想對元素進行定位速度都比較慢
2.關于代碼編寫效率上，本人使用Appium會好于Airtest（由于Android項目），Airtest的Api是新的，與appium的有所不同，對Api的熟悉需要一定過程，前期可能會較慢，后期熟練了會較快，Airtest對api的封裝會更多一些，初始用者需要自己對Appium的Api進行封裝
3.關于穩(wěn)定性，Appium-wda和iOS-tagent都是基于facebook-wda（facebook未維護了，appium團隊對其進行改造有在維護，airtest目前也有在改造維護中）進行封裝改造的，試用時穩(wěn)定性差不多，暫未出現掉線情況，iOS-tagent據說簡化了內部的一些邏輯調用，不過總體體驗下來差不多，對于高版本的iOS，Airtest官方好像還是推薦Appium的wda
4.關于適用場景，Appium主要是通過元素定位來進行自動化運行，適用于原生App下沒有特殊強調對某種類型的app會更好用，屬于兼容性較強的場景使用性，Airtest由于背靠網易，所以在場景使用方面更受游戲公司的自動化運行，尤其是他的圖像識別點擊，能夠更好的識別游戲自動化中的場景，不過Airtest也可以通過PocoUI進行元素點擊，涉及圖形多的，如游戲類的可以使用Airtest
5.對于特定場景的元素定位，部分App流下，Appium與Airtest均無法獲取到其中的元素信息，從而導致無法對該部分內容進行校驗，Appium每次切換頁面需要手動刷新頁面
Airtest可以實時顯示界面，Airtest的連接方式相對于Appium會稍簡單
6.關于后續(xù)版本維護方面，Appium目前社區(qū)維護穩(wěn)定，幾天一更新，Airtest目前看最新的維護時間是在3個月前，相比之下Appium的維護工作會更好
7.關于多設備并行，Appium與Airtest都可以運行多設備，目前我這都是根據Tidevice啟動多個wda服務開啟多個端口號進行，使用情況差不多
8.相對于其他方面的比較基本都差不多
由于公司的App是原生+H5相關的，對Appium的使用也比較了解，兩者區(qū)別不是很大的情況下，還是選擇使用Appium做iOS自動化測試
三 Appium驅動原理
驅動原理
XCUITest是蘋果開發(fā)的一個做IOS自動化測試的框架，需要了解些Swift等iOS編程知識
WebDriverAgent是Facebook開發(fā)的一個iOS自動化測試工具，先來看下面的這張原理圖：
WDA在Client創(chuàng)建了一個Server，在手機端安裝了一個叫作WebDriverAgentRunner 的一個應用；這個應用會接收來自 Server 的指令，并連接底層的XCTest.framwork，讓 XCTest.framwork 調用蘋果API來操作手機進行自動化
而appium是把WebDriverAgentRunner 給集成進去了，因此實現了appium的跨平臺能力
通過上圖我們了解到 Appium 很粗暴的把整個 WebDriverAgent 直接集成到自己的項目里，然后通信機制就走 WebDriverAgent，Appium 其實就提供了一個 Client 端的作用。所以 iOS 9.3 系統之后自動化測試核心是 WebDriverAgent，Appium 就提供了一個 Client 端來寫腳本和發(fā)送指令。
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 出品:文章來源：http://www.zghlxwxcb.cn/news/detail-487780.html
- 實現了一個 server，通過 server 可以遠程控制 iOS 設備：啟動應用、關閉應用、點擊、滾動等操作；
- 通過連接 framework 調用蘋果的 API 執(zhí)行動作；
- 支持多個設備同時進行自動化；
- Appium、Macaca 已經集成。
- 但是 WebDriverAgent僅僅只提供了一個 server（和 inspect 進行元素定位），并沒有像Appium 一樣提供 java 或 python 的 Client 端去寫腳本，腳本執(zhí)行的時候發(fā)送指令給server，然后去運行。WebDriverAgent 要求你自己去實現 Client 端，即拿 Java/ Python 的WebDriver 庫進行封裝，然后發(fā)送指令。所以 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能夠發(fā)送http請求給server，那么的話client用什么語言來實現都是可以的，這就是appium及webdriver如何做到支持多語言的；
Appium優(yōu)點
- 開源
- 跨架構: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自動化測試】第二章：環(huán)境搭建文章來源地址http://www.zghlxwxcb.cn/news/detail-487780.html
到了這里，關于【iOS自動化測試】第一章：方案調研的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！
