前文：根據(jù)Martin Fowler 的測(cè)試?yán)碚?，測(cè)試應(yīng)該遵循如下測(cè)試金字塔組合，測(cè)試金字塔最底層是單元測(cè)試，然后是集成測(cè)試，繼而是面向應(yīng)用程序服務(wù)層的中間層測(cè)試，最高層是面向用戶的業(yè)務(wù)邏輯測(cè)試。
iOS的測(cè)試分為兩塊：UI測(cè)試和Unit測(cè)試，因Unit測(cè)試先定義行為，然后定義測(cè)試用例，接著再編寫代碼。?實(shí)踐中發(fā)現(xiàn)，通常沒有那么多時(shí)間來先定義行為，需要 去投入很大一塊精力去進(jìn)行單元測(cè)試，無法有效構(gòu)建一個(gè)合理的單元測(cè)試環(huán)境。
（一）Unit測(cè)試
1，經(jīng)驗(yàn)困境反倒更難以解決，且教程不多，新手入手難度較大。
2， 在 iOS常常會(huì)需要測(cè)試異步方法的正確性。我們常常會(huì)用到 ‘做異步等待。太依賴嚴(yán)重于當(dāng)前環(huán)境。
3， 編寫單元測(cè)試會(huì)增加程序員工作量。單元測(cè)試跟生產(chǎn)代碼是一樣的，并不會(huì)應(yīng)為是用來測(cè)試的就有所不同，開發(fā)人員同樣要面對(duì)測(cè)試代碼的編寫、維護(hù)等工作，也同樣要面對(duì)避免重復(fù)代碼等一系列問題，能否寫出好的測(cè)試代碼還是取決于開發(fā)人員的設(shè)計(jì)和編碼能力。
?對(duì)思想上的學(xué)習(xí)挑戰(zhàn)較大，并不能，單一模仿代碼實(shí)現(xiàn)類的完整測(cè)試，需要站立于模塊的基礎(chǔ)進(jìn)行行為的定義，來測(cè)試代碼流程
（二）UI測(cè)試：
目前只能進(jìn)行一些簡(jiǎn)單的測(cè)試，且測(cè)試的過程還需要人工干預(yù)
一,基于KIF：
KIF的全稱是Keep it functional。它是一個(gè)建立在XCTest的UI測(cè)試框架，通過accessibility來定位具體的控件，再利用私有的API來操作UI。由于是建立在XCTest上的，所以你可以完美的借助XCode的測(cè)試相關(guān)工具（包括命令行腳本），能幫助我們?nèi)ツM用戶輸入來測(cè)試。
KIF繼承自XCTest測(cè)試框架，可直接使用私有API對(duì)UI界面進(jìn)行操作，支持UIWebView的測(cè)試。
KIF利用Accessibiility來做界面測(cè)試的基本原理，需要注意的是，由于KIF基于Accessibility，因此我們?cè)诔跏蓟丶r(shí)，不管是代碼還是InterfaceBuilder，都要記得對(duì)需要測(cè)試的控件設(shè)置AccessibilityLabel和AccessibilityTrait
使用語(yǔ)言：Object C & Swift, 在iOS 10之后，無正式版的lib和App
KIF 優(yōu)勢(shì)
1，測(cè)試時(shí)直接獲取到UIView：KIF在測(cè)試過程中，是直接獲取到應(yīng)用程序，可以直接取得UIView等控件，因此各種屬性可以直接判斷；而 XCTest就顯得很不方便，它并沒有直接取得應(yīng)用程序，而是在現(xiàn)有的視圖上取得XCUIElement，該類和UIView有很大差別，基本上UIView的屬性我們無法判斷。
2，XCTest原則上每個(gè)UI測(cè)試都要重新啟動(dòng)一遍應(yīng)用，這樣的耗時(shí)是驚人的，而KIF則不用。文檔、教程比較多：KIF從2011年推出至今，網(wǎng)上已有大量的教程和問答，可能很方便找到解決方案，而XCode UI Test則不同，推出不久，相關(guān)資料還不是很多。
1、KIF搭建,配置Target項(xiàng)目參數(shù)；
2、安裝KIF第三方框架；
3、用例編寫與組織：accessibility 屬性設(shè)置；用例常用操作接口，分? 為交互操作和測(cè)試用例操作，系統(tǒng)功能完整性的實(shí)現(xiàn)；
?4、用例的運(yùn)行獨(dú)立和 retry 機(jī)制；
KIF自動(dòng)化的持續(xù)集成：
持續(xù)集成是一個(gè)自動(dòng)化的周期性的集成測(cè)試過程，從檢出代碼、編譯構(gòu)建、運(yùn)行測(cè)試、結(jié)果記錄、測(cè)試統(tǒng)計(jì)等都是自動(dòng)完成的，無需人工干預(yù)。UI 測(cè)試目標(biāo)是覆蓋最核心的代碼，盡可能去掉依賴，讓不穩(wěn)定因子降到最低；持續(xù)集成最大的好處在于能夠盡早高效發(fā)現(xiàn)問題，降低解決問題的成本。
借助Jenkins ，完成基于KIF 的 UI 自動(dòng)化持續(xù)集成搭建，Jenkins 以Job 為單位運(yùn)行項(xiàng)目；是一套開源的持續(xù)集成工具，需要自己在服務(wù)器（iOS項(xiàng)目只能是MacOS）先部署好，然后可以對(duì)接項(xiàng)目的Git倉(cāng)庫(kù)地址，配置一些定時(shí)／事件觸發(fā)的任務(wù)，通過腳本來編譯、測(cè)試、打包。
KIF的集成較易上手，需要學(xué)習(xí)測(cè)試類的使用，比如獲取不同控件元素的方式等，易學(xué)習(xí)；
Jenkins環(huán)境配置的要求+使用學(xué)習(xí)，因涉及到領(lǐng)域的跨界，需要Java基礎(chǔ)，java語(yǔ)法上好上手，做到熟練需要循序漸進(jìn)；配置簡(jiǎn)單，直接集成到XCode上，不需要安裝多余的包。 像用戶一樣測(cè)試，測(cè)試代碼模仿用戶操作，代碼很簡(jiǎn)單；自動(dòng)集成XCode5以上的測(cè)試工具，在XCode上使用就像使用蘋果原生的測(cè)試框架一樣，支持XCode的各種測(cè)試工具。
大公司使用者: 美團(tuán)，騰訊均有使用
簡(jiǎn)介：使用Ruby語(yǔ)言，開源內(nèi)嵌Server型，通過注入Server到APP使用API，通過Server對(duì)外通信完成UI操作。支持CI持續(xù)集成，不支持UIWebView,要求測(cè)試時(shí)在應(yīng)用程序內(nèi)部編譯。
安裝過程：
1，安裝frank-cucumber；
命令：sudo gem install frank-cucumber
2，在你的項(xiàng)目下設(shè)置frank以及執(zhí)行下面的命令；
命令: frank setup
3，編譯frank
命令：frank build
4，啟動(dòng)模擬器
命令：frank launch
Frank，這意味著對(duì)源代碼的改變是強(qiáng)制性的。
測(cè)試場(chǎng)景是在Cucumber的幫助下，用可理解的英語(yǔ)句子寫的。強(qiáng)大的Symbiote實(shí)時(shí)檢查工具。 活躍的社區(qū)支持。 不斷擴(kuò)大中的庫(kù)
缺點(diǎn)：對(duì)手勢(shì)的支持有限。 在設(shè)備上運(yùn)行測(cè)試有點(diǎn)難。 修改配置文件需要在實(shí)際設(shè)備上運(yùn)行。 記錄功能不可用；
需要ruby的基礎(chǔ)，操作方式為使用Cucumber和JSON組合命令，將命令發(fā)送到在本地應(yīng)用程序內(nèi)部運(yùn)行的服務(wù)器上，并利用UISpec運(yùn)行命令。需要學(xué)習(xí)ruby語(yǔ)言，跨界性較大。近兩年的學(xué)習(xí)資料較少
Appium是一個(gè)開源的、跨平臺(tái)的自動(dòng)化測(cè)試工具，支持IOS、Android和FirefoxOS平臺(tái)。
appium?采用Client - Server的測(cè)試框架，的核心就是一個(gè)遵守REST設(shè)計(jì)風(fēng)格的web服務(wù)器，它接受客戶端的連接，接收客戶端的命令，在手機(jī)設(shè)備上執(zhí)行命令，然后通過HTTP的響應(yīng)收集命令執(zhí)行的結(jié)果。
App相當(dāng)于一個(gè)Server，測(cè)試代碼相當(dāng)于Client，通過發(fā)送JSON來操作APP，測(cè)試語(yǔ)言可以是任意的，可以使測(cè)試代碼訪問后端API和數(shù)據(jù)庫(kù)。它是通過驅(qū)動(dòng)iOS的UIAutomation和Android的UiAutomator框架來實(shí)現(xiàn)的雙平臺(tái)支持，同時(shí)綁定了Selenium WebDriver用于老的Android平臺(tái)測(cè)試。
基于WebDriver JSON wire protocol對(duì)實(shí)際的UI操作庫(kù)進(jìn)行了封裝，并且暴露出RESTFUL的接口。然后測(cè)試代碼通過HTTP請(qǐng)求的方式，來進(jìn)行實(shí)際的測(cè)試。其中，實(shí)際驅(qū)動(dòng)UI的框架根據(jù)系統(tǒng)版本有所不同；在安裝Appium之前，為了確保Appium的相關(guān)依賴已經(jīng)準(zhǔn)備就緒，可以使用Appium-doctor來進(jìn)行驗(yàn)證。
安裝過程：操作簡(jiǎn)易。
跨平臺(tái)，同時(shí)支持iOS、Android、H5，且盡量能保持接口統(tǒng)一，減少開發(fā)維護(hù)成本；
開發(fā)者可以使用WebDriver兼容的任何語(yǔ)言編寫測(cè)試腳本，如Ruby，C#，Java， JS，OC， PHP，Python，Perl和Clojure 語(yǔ)言。
不需要重新編譯應(yīng)用（APP）或者任何方式修改它就可以進(jìn)入測(cè)試行為；
測(cè)試腳本獨(dú)立與源代碼和測(cè)試框架；
Appium社區(qū)更活躍、有可能納入Selenium-WebDriver體系，從而成為事實(shí)上的移動(dòng)應(yīng)用測(cè)試標(biāo)準(zhǔn)；
Appium在不同平臺(tái)中使用了標(biāo)準(zhǔn)的自動(dòng)化APIs，所以在跨平臺(tái)時(shí)，不需要重新編譯或者修改自己的應(yīng)用；
采用Appium時(shí)，無需對(duì)被測(cè)應(yīng)用做任何修改，也無需嵌入任何東西；
Appium對(duì)iOS和Android的原生自動(dòng)化測(cè)試框架進(jìn)行了封裝，并提供了統(tǒng)一的API，減少了自動(dòng)化測(cè)試代碼的維護(hù)工作量；
Appium采用Client-Server的架構(gòu)設(shè)計(jì)，并采用標(biāo)準(zhǔn)的HTTP通信協(xié)議；Server端負(fù)責(zé)與iOS/Android原生測(cè)試框架交互，無需測(cè)試人員關(guān)注細(xì)節(jié)實(shí)現(xiàn)；Client端基本上可以采用任意主流編程語(yǔ)言編寫測(cè)試用例，減少了學(xué)習(xí)成本。
缺點(diǎn)：自定義控件支持不好；WebView的支持不好
對(duì)于appium的工具的使用學(xué)習(xí)，和任選一門腳本語(yǔ)言的學(xué)習(xí)成本，
因支持的腳本語(yǔ)言比較廣泛， 用戶量大，文檔豐富。較易上手。支持多種腳本語(yǔ)言，不會(huì)將測(cè)試人員限制在某種特定語(yǔ)言或者框架上，門檻低。
四、UI測(cè)試框架EarlGrey
EarlGrey是Google推出iOS功能性UI測(cè)試框架，其所提供的主要特性：強(qiáng)大的內(nèi)建同步機(jī)制，測(cè)試會(huì)在與UI進(jìn)行交互前自動(dòng)等待動(dòng)畫、網(wǎng)絡(luò)請(qǐng)求等事件。
可見性檢測(cè)：所有的交互都發(fā)生在用戶可以看到的元素上。
靈活的設(shè)計(jì)：用于確定元素選擇、交互、斷言與同步的組件在設(shè)計(jì)上就是可擴(kuò)展的。
EarlGrey是個(gè)原生iOS UI自動(dòng)化測(cè)試框架，EarlGrey與XCTest框架協(xié)同工作，并且集成到了Xcode的Test
Navigator中，這樣你就可以直接在Xcode中或是在命令行中（使用xcodebuild）運(yùn)行測(cè)試了。
對(duì)于EarlGrey，我們強(qiáng)烈推薦CocoaPods作為入門的最佳方式，并保持EarlGrey版本同步到最新版本。（官網(wǎng)原話）
1、EarlGrey是個(gè)原生iOS UI自動(dòng)化測(cè)試框架，可以幫助你編寫出更加清晰、簡(jiǎn)明的測(cè)試。
2、借助于EarlGrey框架，你可以使用增強(qiáng)的同步特性。
3、EarlGrey會(huì)自動(dòng)與UI、網(wǎng)絡(luò)請(qǐng)求及各種查詢保持同步，同時(shí)在必要的情況下，你還可以手工實(shí)現(xiàn)自定義的定時(shí)器。
4、EarlGrey的同步特性可以確保在執(zhí)行動(dòng)作前，UI會(huì)處于一種穩(wěn)定的狀態(tài)。這極大地增強(qiáng)了測(cè)試穩(wěn)定性，使得測(cè)試變得高度可重復(fù)。
5、EarlGrey與XCTest框架協(xié)同工作，并且集成到了Xcode的Test
Navigator中，這樣你就可以直接在Xcode中或是在命令行中（使用xcodebuild）運(yùn)行測(cè)試了。
6、適配環(huán)境 < (更新macOS Sierra + Xcode 8.1 + iOS 10.0.2：無法使用)
與KIF的對(duì)比：
EarlGrey寫法多樣，操作靈活；KIF比較簡(jiǎn)單，適合快速開發(fā)
EarlGrey支持同步；KIF需要手動(dòng)等待：由于EarlGrey采用了同步機(jī)制，所以保證了下一個(gè)操作的執(zhí)行；對(duì)需要等待的操作，KIF需要手動(dòng)添加等待事件，
EarlGrey建議使用AccessibiltyIdentifier；KIF使用AccessiblityLable：
兩個(gè)框架都是利用Accessibility來找元素，EarlGrey中建議使用AccessibiltyIdentifier，而KIF中大部分的API只支持AccessiblityLable，所以如果使用的是KIF，就只能去修改控件的AccessiblityLable。
EarlGrey支持拍照，可以存在任何地方；KIF失敗自動(dòng)拍照，只能存在固定地方。不過需要事先指定存儲(chǔ)路徑。
需要學(xué)習(xí)測(cè)試用例的編寫，以及內(nèi)建同步機(jī)制等的實(shí)現(xiàn)思想；
因太靈活，編碼上，沒有固定的套路；
參考專業(yè)人士的描述，其自動(dòng)化測(cè)試的功能更智能，但國(guó)內(nèi)的關(guān)于EarlGrey學(xué)習(xí)資料較少，又寫法多樣，在零基礎(chǔ)的使用上，并不能很好的保證自己的編碼是一個(gè)可復(fù)制的，具有偶然性。
UI測(cè)試優(yōu)先推薦KIF，如果需要兼顧安卓測(cè)試，或者測(cè)試人員對(duì)OC/Swift很陌生，可以采用appium；就目前搜索有關(guān)于自動(dòng)化測(cè)試的眾多資料顯示，KIF和appiunm的資料較全面，且相對(duì)來說，易模仿易復(fù)制；KIF的使用，更多涉及到iOS原生代碼思想的學(xué)習(xí)和編碼實(shí)現(xiàn)，以及Jenkins工具的上手；對(duì)于appiunm，因其跨平臺(tái)，對(duì)三端均支持自動(dòng)化測(cè)試，如果兼顧不同平臺(tái)的測(cè)試，建議首先，同時(shí)因?yàn)橹С帜_本語(yǔ)言較多，因Python的易上手，有不少資料顯示，選擇appium與Python的結(jié)合。對(duì)于Google推出的EarlGrey框架，功能相對(duì)是最好的，因搜索顯示，資料較少，在后期的具體實(shí)現(xiàn)上，對(duì)于未可預(yù)測(cè)的問題的解決效率上，會(huì)略有挑戰(zhàn)。因Frank在2014年較為流行，最近的測(cè)試框架并不在推薦范圍內(nèi)。
