一、認知ios自動化測試及框架：

通常，我們會選擇那些業務穩定，需要頻繁測試的部分來編寫自動化測試腳本，其余的采用人工測試，人工測試仍然是iOS App開發中不可缺少的一部分。

測試種類

從是否接觸源代碼的角度來分類：測試分為黑盒和白盒（灰盒就是黑盒白盒結合，這里不做討論）。

白盒測試的時候，測試人員是可以直接接觸待測試App的源代碼的。白盒測試更多的是單元測試，測試人員針對各個單元進行各種可能的輸入分析，然后測試其輸出。白盒測試的測試代碼通常由iOS開發編寫。

黑盒測試。黑盒測試的時候，測試人員不需要接觸源代碼。是從App層面對其行為以及UI的正確性進行驗證，黑盒測試由iOS測試完成。

而iOS測試通常只有以下兩個層次：

Unit，單元測試，保證每一個類能夠正常工作

UI，UI測試，也叫做集成測試，從業務層的角度保證各個業務可以正常工作。

框架選擇

啰里八嗦講的這么多，自動化測試的效率怎么樣，關鍵還是在測試框架上。那么，如何選擇測試框架呢？框架可以分為兩大類：XCode內置的和三方庫。

選擇框架的時候有幾個方面要考慮：

測試代碼編寫的成本

是否可調式

框架的穩定性

測試報告（截圖，代碼覆蓋率，…）

WebView的支持（很多App都用到了H5）

自定義控件的測試

是否需要源代碼

能否需要連著電腦

是否支持CI（持續集成）...

我們首先來看看XCode內置的框架：XCTest。
XCTest又可以分為兩部分：Unit Test和UI Test，分別對應單元測試和UI測試。有一些三方的測試庫也是基于XCTest框架的，這個在后文會講到。由于是Apple官方提供的，所以這個框架會不斷完善。
二、框架選擇：

按照iOS自動化測試框架的實現原理來劃分，iOS自動化測試框架大致可以分為兩個大類4種類型：

UI Automation系

擴展型UI Automation
驅動型UI Automation

非 UI Automation系

私有API型
注入編譯型

1、UI Automation

UI Automation是Apple官方提供的UI自動化測試的解決方法，雖然直接使用非常不爽，但是還不得不說。雖然不好用，但是作為一些工具的底層實現還是需要了解的。官方教程和相關API文檔可以方便查閱

（1）擴展型UI Automation

TuneupJs是最早的iOS自動化測試工具，以JavaScript擴展庫方法提供了很多好用js工具，最重要的是提供了超簡潔的單元測試框架和持續繼承解決方案。

ynm3k是筆者維護的iOS自動化測試框架，借鑒或者說抄襲了很多TuneUpJs的想法，在其基礎上加入了UI控件定位的很多方法，讓測試腳本更加簡單便捷。當然之后還有后續的維護計劃，過了變態的996以后會開始實施。

如果你偏愛這種類型的測試框架，我真心的推薦ynm3k。因為TuneUpJS已經不維護了，ynm3k還會做一些好玩的功能。最關鍵的是我覺得ynm3k的UI控件定位識別功能真的很棒。（老王賣瓜了這么長時間還請大家見諒）

（2）驅動型UI Automation

驅動型UI Automation 在自動化測試底層使用了UI Automation庫，通過TCP通信的方式驅動UI Automation來完成自動化測試。通過這種方式，編輯腳本的語言不在局限于JavaScript，理論上講可以是任何一種語言。所以有了iOSDriver和Appium.

iOSDriver和Appium還兼容了WebDriver的Json Wire Protocol協議，意味著你可以寫WebDriver腳本來完成iOS自動化測試。當然在手機端的一些操作和Web端是不同的，iOSDriver和Appium都擴展了相關的功能。iOSDriver選擇了多加入Java語言Jar包的方式支持，而Appium則選擇了通過WebDriver注入JavaScript的方式支持。iOSDriver的實現方式決定了只能使用Java語言編輯腳本，而Appium則支持更多的語言。

當然讓我真正選擇Appium的原因是因為Appium更加輕便易用一些。如果你不經常玩Java，使用iOSDriver的時候一定會在環境設置方面卡很長的時間。

2、非 UI Automation系

（1）私有API型

直接使用私有API對UI界面進行操作是最簡潔有效的自動化測試方式。私有API結合iOS單元測試框架OCUnit的組合完全非常棒，至少對iOS開發工程師來說。在這種類型的測試框架中，KIF是必須介紹的。原因很簡單，Google在使用。對于那些對Google無理由崇拜的人們，趕緊用起來吧。

筆者關注了KIF一段時間，起初1.0版本的時候，真心的不好用。當然工具的維護者也意識到了這個方面的問題，推出了KIF的2.0版本，更新了很多的API。在2.0版本時，還不錯。如果想做純UI界面操作的話，不推薦使用KIF。

（2）注入編譯型

注入編譯型是指在編譯時注入一個Server到App內部，通過Server對外通信完成UI操作指令的執行。其中最著名的代表為Frank和Calabash. 它們還是BDD測試框架的杰出代表。維護大單位都是全球知名的敏捷咨詢公司。喜歡cucumber和ruby的人可以考慮。

三、iOS自動化-- 常用iOS命令：

iOS命令：
獲取設備的的UDID

idevice_id --list # 顯示當前所連接設備的 udid
instruments -s devices # 列出所有設備，包括真機、模擬器、mac
ideviceinfo 可以在返回的數據中找到 udid
idevice_id -l

安裝某個app

ideviceinstaller -i apppath 安裝apppath下的app
ideviceinstaller -u [udid] -i [xxx.ipa] # xxx.ipa 為應用在本地的路徑

卸載應用

ideviceinstaller -u [udid] -U [bundleId]

查看設備已安裝的應用

ideviceinstaller -u [udid] -l # 查看設備安裝的第三方應用
ideviceinstaller -u [udid] -l -o list_user # 同上，查看設備安裝的第三方應用
ideviceinstaller -u [udid] -l -o list_system # 查看設備安裝的系統應用
ideviceinstaller -u [udid] -l -o list_all # 查看設備安裝的所有應用

獲取設備信息

ideviceinfo -u [udid] # 獲取設備信息
ideviceinfo -u [udid] -k DeviceName # 獲取設備名稱 同命令 idevicename
idevicename # 同上
ideviceinfo -u [udid] -k ProductVersion # 獲取設備版本 10.3.3
ideviceinfo -u [udid] -k ProductType # 獲取設備類型 iPhone 8，1
ideviceinfo -u [udid] -k ProductName # 獲取設備系統名稱

其他系統文件信息

ideviceinfo # 獲取設備所有信息
idevicesyslog # 獲取設備日志
idevicecrashreport -e test # 獲取設備 crashlog，test 是文件夾需新建
idevicediagnostics # 管理設備狀態 - 重啟、關機、睡眠等

ios-deploy 常用命令

ios-deploy -c # 查看當前鏈接的設備
ios-deploy --[xxx.app] # 安裝APP
ios-deploy --id [udid] --uninstall_only --bundle_id [bundleId] # 卸載應用
ios-deploy --id [udid] --list_bundle_id # 查看所有應用
ios-deploy --id [udid] --exists --bundle_id # 查看應用是否安裝

列舉設備安裝的應用：

ideviceinstaller -l則可以列出手機上所有的用戶安裝的app

運行某個app

idevicedebug run 'APP_BUNDLE_ID'可以直接launch某個app，當然，這個app必須是你通過development證書build到手機上的才行。

獲取手機的設備版本：

Ideviceinfo -k ProductVersion

獲取手機的設備名：

ideviceinfo -k ProductType

截圖：

idevicescreenshot

錄像：

xrecord --quicktime --list
xrecord --quicktime --name="iPhone" --out="/Users/blah/video/iphone.mp4" --force

手機關機：idevicediagnostics shutdown # shutdown device
重啟手機：idevicediagnostics restart # restart device
休眠(熄屏滅屏): idevicediagnostics sleep # 類似于斷開adb . (disconnects from host)
四、IOS自動化App測試——安裝app指令

IOS自動化運行

1） 安裝iOS測試包相關命令

① 安裝iOS測試包

$ ios-deploy --id [設備udid] --bundle [ipa路徑]

例：

ios-deploy --id 315214497a82c001d0cac7541ddfaac3288c05b2 --bundle /data/uitest/UmeAutomationTestAndroid/res/app/ios/UmetripFree.ipa

ios-deploy --id 2d262872589c8272c7eaddb89bd9da750f170952 --bundle /data/uitest/UmeAutomationTestAndroid/res/app/ios/UmetripFree.ipa

② 查看當前設備udid

$ idevice_id -l

③ 查看當前設備信息

$ instruments -s devices
五、搭建IOS自動化測試環境-Appium

一、安裝Homebrew工具
1、簡介

Homebrew官網http://brew.sh/index_zh-cn.html

Homebrew是神馬

linux系統有個讓人蛋疼的通病，軟件包依賴，好在當前主流的兩大發行版本都自帶了解決方案，Red ha有yum，Ubuntu有apt-get

神馬，你用mac os，不好意Mac os木有類似的東東，淚奔中幾經折騰總算找到了第三方支持：Homebrew，Homebrew簡稱brew，是Mac OSX上的軟件包管理工具，能在Mac中方便的安裝軟件或者卸載軟件，可以說Homebrew就是mac下的apt-get、yum神器

2、Homebrew安裝

Homebrew的安裝非常簡單，打開終端復制、粘貼以下命令，回車，搞定(請放心使用，原汁原味的官方安裝方法搬運）

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

ps:不知道為什么執行這個命令有時會返回400，估計可能被墻了，過幾分鐘重試下一般就ok了，有圖有真相

3、Homebrew使用

Homebrew使用沒啥好說的了，常用的

搜索軟件：brew search 軟件名，如brew search wget

安裝軟件：brew install 軟件名，如brew install wget

卸載軟件：brew remove 軟件名，如brew remove wget

二、安裝libimobiledevice開源包（IOS開發的另類神器）
1、簡介

libimobiledevice又稱libiphone，是一個開源包，可以讓Linux支持連接iPhone/iPod Touch等iOS設備。由于蘋果官方并不支持Linux系統，但是Linux上的高手絕對不能忍受因為要連接iOS設備就換用操作系統這個事兒。因此就有人逆向出iOS設備與Windows/Mac Host接口的通訊協議，最終成就了橫跨三大桌面平臺的非官方版本USB接口library。經常用Linux系統的人一定對libimobiledevice不陌生，但是許多Windows和Mac用戶也許就不知道了。事實上，它同iTools一樣，都是可以替代iTunes，進行iOS設備管理的工具。因為源碼是開放的，可以自行編譯，所以對很多開發者而言可以說更為實用

參考：http://www.jianshu.com/p/6423610d3293

2、安裝

指令：brew install libimobiledevice –HEAD

三、安裝carthage
1、簡介

Carthage的目標是用最簡單的方式來管理Cocoa第三方框架

參考https://www.cnblogs.com/wendingding/p/5959322.html

Carthage 是用來解決 xcode project 依賴的，大家可能知道cocoapod，那你就把 Carthage 理解成和 cocoapod 一樣的東西就可以了，可以通過brew install carthage安裝。

2、安裝

指令：brew install carthage

四、安裝nodejs
1、簡介

簡單的說 Node.js 就是運行在服務端的 JavaScript。

Node.js 是一個基于Chrome JavaScript 運行時建立的一個平臺。

Node.js是一個事件驅動I/O服務端JavaScript環境，基于Google的V8引擎，V8引擎執行Javascript的速度非常快，性能非常好。

2、安裝

按照官方的地址https://nodejs.org/en/download/。 下載.pkg文件安裝

五、安裝cnpm
1、簡介

npm（node package manager）是nodejs的包管理器，用于node插件管理（包括安裝、卸載、管理依賴等）

2、安裝

cnpm(由于某種原因,直接用npm下載安裝會有好多網絡問題，安裝淘寶的cnpm要比npm好用)https://npm.taobao.org/

指令：npm install -g cnpm --registry=https://registry.npm.taobao.org

出現權限問題：在指令前加sudo

公司內網非常慢，建議用手機流量，巨快= =

六、安裝ios-deploy
1、簡介

ios-deploy是一個使用命令行安裝ios app到連接的設備的工具，原理是根據os x命令行工程調用系統底層函數，獲取連接的設備、查詢/安裝/卸載app。類似的工具有Fruitstrap，ideviceinstaller、node-ios-device等

2、安裝

指令：cnpm install -g ios-deploy

（公司內網同樣不行T_T）

七、安裝xcpretty
1、簡介

用于對xcodebuild的輸出進行格式化。并包含輸出report功能。

2、安裝

指令：cnpm install xcpretty

八、安裝appium
1、安裝appium1.6.3(到發帖為止，最新版本是1.6.3，要其他版本的跟上版本號就行了)這一步驟若出現安裝jDK彈出框忽略就好

cnpm install -g appium@1.6.3

2、檢驗：輸入命令：appium

九、appium-doctor
會提示裝下面的xcode comment line tools

如出現這些問題后面解決（ANDROID_HOME要用安桌sdk）

十、安裝appium-xcuitest-driver依賴
1、進入WebDriverAgent安裝目錄，運行bootstrap

cd /usr/local/lib/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent （如果WebDriverAgent 所在路徑和此不同，請自行查找）

mkdir -p Resources/WebDriverAgent.bundle sh ./Scripts/bootstrap.sh

在運行sh ./Scripts/bootstrap.sh很可能會有因為咱們大中華局域網而網絡連接失敗。方法就是去App store下載了一個VPN代理軟件，我下了一個評分最多且免費的，的確很好用。我就不說軟件名稱了。
再次運行sh ./Scripts/bootstrap.sh 無報錯就OK了

安裝Xcode及Xcode Command Line Tools
--安裝Xcode-最好用app store直接下載-----------------------------------------------------------

檢測是否安裝好Xcode

$ xcode-select -p

顯示這樣說明安裝好

/Applications/Xcode.app/Contents/Developer

如果沒有裝好，安裝方法：

Xcode不同版本可以在以下網頁下載，需要登陸apple帳戶:

https://developer.apple.com/downloads/

--安裝Xcode Command Line Tools---

1.調出安裝窗口

$ xcode-select --install

2.點擊 Install 安裝

Click “Install” to download and install Xcode Command Line Tools.

用Xcode打開WebDriverAgent，并且編譯

編譯WebDriverAgentLib

編譯WebDriverAgentRunner

六、使用Appium進行iOS的真機自動化測試

安裝類庫

Homebrew

如果沒有安裝過Homebrew,先安裝[ homebrew ]

npm

如果沒有安裝npm,請移步[ node.js和npm安裝 ]

安裝依賴庫

brew install libimobiledevice --HEAD
sudo npm install -g ios-deploy --unsafe-perm=true

如果執行sudo npm install -g ios-deploy --unsafe-perm=true報錯，執行sudo xcode-select --switch/Applications/Xcode.app/Contents/Developer/

如果沒有安裝 libimobiledevice，會導致Appium無法連接到iOS的設備，所以必須要安裝，如果要在iOS10+的系統上使用appium，則需要安裝ios-deploy

appium-doctor 安裝

npm install appium-doctor -g

安裝后執行appium-doctor –ios指令，可以查看與iOS相關配置是否完整，下圖是全部配置都成功,如果出現有一項不正確在執行一次就可以，或者直接跳過

appium-doctor –ios

更新Appium中的WebDriverAgent

到WebDriverAgent下載最新版本的WebDriverAgent
cd 進入下載后的WebDriverAgent文件
執行 ./Scripts/bootstrap.sh
直接用Xcode打開WebDriverAgent.xcodepro文件
配置WebDriverAgentLib和WebDriverAgentRunner的證書

連接并選擇自己的iOS設備，然后按Cmd+U，或是點擊Product->Test
運行成功時，在Xcode控制臺應該可以打印出一個Ip地址和端口號
在網址上輸入http://192.168.2.101:8100/status，如果網頁顯示了一些json格式的數據，說明運行成功。

進入到Appium中的WebDriverAgent目錄，目錄路徑如下/Applications/Appium.app/Contents/Resources/app/node_modules/appium/node_modules/appium-xcuitest-driver/
將自己下載并編譯后的WebDriverAgent替換Appium原有的WebDriverAgent

---

在Appium-Desktop下載傳送門中下載最新版本的Appium-Desktop

運行Appium-Desktop

開啟start server

點擊start new session并且在Desired Capabilities 中輸入相關的參數后點擊Start Session

運行成功后，會彈出一個控制界面，在該界面中可以控制手機上正在運行的程序

利用Appium-Python-Client進行iOS的自動化測試

安裝python

brew install python

下載python-client
git clonehttps://github.com/appium/python-client.git
cd python-client
python setup.py install

在git上下載測試文件appiumSimpleDemo

開始自動化測試

打開下載后的appiumSimpleDemo文件，打開appiumSimpleDemo.xcodepro程序,配置下TARGET的簽名

在appiumSimpleDemo的根目錄執行編譯指令，編譯出一個app文件xcodebuild -sdk iphoneos -target appiumSimpleDemo -configuration Release，編譯成功后app文件的地址會打印在命令行中

配置python文件

打開appiumSimpleDemo中的appiumSimpleDemo.py文件,將，修改setup中的幾個參數，將app的路徑，設備的相關信息修改成當前連接設備的信息。

如果執行appiumSimpleDemo.py報錯File"/usr/local/Cellar/python@2/2.7.15/Frameworks/Python.framework/Versions請升級python版本，如果你是iOS開發人員，請謹慎，升級python有可能是Xcode無法打包參考文稿

七、Mac端-Appium桌面版-iOS真機自動化測試

1. 啟動appium，版本 1.13.0

2.點擊紅框里的，Edit Configurations。

3.配置一下ANDROID_HOME，JAVA_HOME

我的是這樣的，如果你的沒有下載，就先去下載（Android sdk）（JAVA）：

ANDROID_HOME：/Users/yingying.zou/Library/Android/sdk

JAVA_HOME：/Library/Java/JavaVirtualMachines/jdk-12.0.1.jdk/Contents/Home

4.Start Server(Restart Now)

{
"platformName": "ios",
"deviceName": "xxxiPhone", （蘋果手機設置-通用-關于本機，可查看名稱）
"platformVersion": "12.1.4", （蘋果手機設置-通用-關于本機，可查看版本）
"udid": "xxxxxxxxxxxxxxxxxx", （蘋果手機連蘋果電腦，iTunes里查看手機的摘要，能找到，右鍵復制，不會的話百度一下你就知道）
"bundleId": "com.xxxxxxxxxxxx" (用xcode打開工程，能找到，或者你直接問iOS開發人員)
"xcodeOrgId": "C2xxxxxxxx", (十位字符的組織ID,是蘋果開發證書的組織單位，appium可以通過十位組織單位ID找到相應的
組織,如果是連接真機測試APP的話，必須要設置組織參數。注意: 連接真機時，測試app的打包
簽名證書必須要與xcodeOrgId里的一致，否則會報證書錯誤，錯誤代碼是65。)
"xcodeSigningId": "iPhone Developer" (固定的)
}
這個填好了可以Save As一下，下次直接打開就可以了。

5.Start Session，手機上會自動裝一個webdriverapp的應用，然后才會啟動要測試的app。（要測試的app提前在手機上存在著～）

到這一步了，隨便點點逛逛，可以通過這個操控手機，看看日志了，有一點激動，雖然還有好多不明所以
下一步，要學習用python寫測試腳本了～加了個油～

八、XCTest認識

本Markdown編輯器使用StackEdit修改而來，用它寫博客，將會帶來全新的體驗哦：

Markdown和擴展Markdown簡潔的語法
代碼塊高亮
圖片鏈接和圖片上傳
LaTex數學公式
UML序列圖和流程圖
離線寫博客
導入導出Markdown文件
豐富的快捷鍵
快捷鍵
加粗 Ctrl + B
斜體 Ctrl + I
引用 Ctrl + Q
插入鏈接 Ctrl + L
插入代碼 Ctrl + K
插入圖片 Ctrl + G
提升標題 Ctrl + H
有序列表 Ctrl + O
無序列表 Ctrl + U
橫線 Ctrl + R
撤銷 Ctrl + Z
重做 Ctrl + Y
Markdown及擴展
Markdown 是一種輕量級標記語言，它允許人們使用易讀易寫的純文本格式編寫文檔，然后轉換成格式豐富的HTML頁面。 —— [ 維基百科 ]

使用簡單的符號標識不同的標題，將某些文字標記為粗體或者斜體，創建一個鏈接等，詳細語法參考幫助？。

本編輯器支持 Markdown Extra , 　擴展了很多好用的功能。具體請參考Github.

表格
Markdown　Extra　表格語法：

可以使用冒號來定義對齊方式：

定義列表
Markdown　Extra　定義列表語法：
項目１
項目２
定義 A
定義 B
項目３
定義 C
定義 D

定義D內容

代碼塊
代碼塊語法遵循標準markdown代碼，例如：

腳注

生成一個腳注1.

目錄
用 [TOC]來生成目錄：

數學公式

更多LaTex語法請參考 這兒.

UML 圖:
可以渲染序列圖：

或者流程圖：

關于 序列圖 語法，參考 這兒,
關于 流程圖 語法，參考 這兒.
離線寫博客
即使用戶在沒有網絡的情況下，也可以通過本編輯器離線寫博客（直接在曾經使用過的瀏覽器中輸入write.blog.csdn.net/mdeditor即可。Markdown編輯器使用瀏覽器離線存儲將內容保存在本地。

用戶寫博客的過程中，內容實時保存在瀏覽器緩存中，在用戶關閉瀏覽器或者其它異常情況下，內容不會丟失。用戶再次打開瀏覽器時，會顯示上次用戶正在編輯的沒有發表的內容。

博客發表后，本地緩存將被刪除。　

用戶可以選擇 把正在寫的博客保存到服務器草稿箱，即使換瀏覽器或者清除緩存，內容也不會丟失。

注意：雖然瀏覽器存儲大部分時候都比較可靠，但為了您的數據安全，在聯網后，請務必及時發表或者保存到服務器草稿箱。

瀏覽器兼容
目前，本編輯器對Chrome瀏覽器支持最為完整。建議大家使用較新版本的Chrome。
IE９以下不支持
IE９，１０，１１存在以下問題
不支持離線功能
IE9不支持文件導入導出
IE10不支持拖拽文件導入

九、UIAutomation---IOS自動化測試的工具

xcode中自帶的Instuments工具可以用來進行APP的自動化測試, 以及用于進行內存泄露, 文件讀寫操作等的性能分析.

第一部分: 熟悉Instruments的UIAutomation.

首先, 選取xcode->Open Developer Tool->Instruments打開Instruments工具, 然后在左上角可以選取設備及被測APP(如下圖):

在這里, 我選取了iPhone 5s的一個模擬濃ky"/kf/ware/vc/" target="_blank" class="keylink">vcsINLUvLDWrsewseDQtLXE0ru49rzytaW1xNaquvXI1bGoQVBQLjwvcD4KPHA+uNW/qsq8vdO0pVVJQXV0b21hdGlvbrXEu7AsIL2o0unRodTxwrzWxr3Fsb61xLe9yr3AtMrsz6S4w7mkvt+1xMq508MuIMjnz8LNvLXEtdeyv7XEyP249rC0xaW31rHwyseypbfFLCDCvNbGLCDNo9a5LjwvcD4KPHA+PGltZyBzcmM9"/uploadfile/Collfiles/20141229/20141229084253128.png" alt="">

點擊中間的紅色按鈕開始錄制, 錄制過程中, 代碼框中會實時更新自動化腳本, 點擊停止后, 就錄制成功了一段自動化測試腳本了. 然后可以點擊左邊執行即可看到iPhone 5s模擬器中的執行結果了, 跟錄制的動作是一致的.

可以看出, 使用UIAutomation對IOS的APP進行自動化測試, 使用的是JavaScript語言.
以上的target, app是建立特定的執行環境, 然后通過app.mainWindow()獲取APP的UIWindow.

也可以通過var navBar = app.navigationBar()來獲取APP的導航欄navigationBar.

使用target.logElementTree()可以建立APP的層級結構樹(類似于Android自動化中的getHierarchyView()方法). 一個簡單的結構如下:

第二部分: 控件的獲取及操作

獲取UI控件的方法也非常簡便:

其他控件的獲取都是類似的方法, 如buttons(), images(), webViews().
對控件的操作如下:

導航欄navigationBar與tabBar的獲取及操作如下:

打印調試log的方式如下:

第三部分: 自定義自動化腳本
熟悉了基本的UIAutomation相關的規則之后, 我們就可以來編寫自定義的自動化腳本了.

在這里, 我簡單的取出tableView上的所有cell, 并依次點擊該cell, 然后跳轉至每個cell的詳細界面, 最后返回.
log欄里, 會呈現所有的執行結果, 分析起來也是非常方便的.

怎么樣, 使用起來是不是蠻簡單的. 但是, 在這里, 只是簡單總結了Instruments中UIAutomation的基本用法, 真正精髓的東西還要自己去慢慢琢磨.

所有的技術都是易學難精, 大家加油.

十、【iOS小白教程】開始測試：單元測試與UI測試

單元測試適合測試用戶交互行為無法覆蓋的代碼，和小而完整的代碼。UI 測試更適合測試大范圍的功能集合。

一、單元測試

iOS 單元測試和 UI 測試快速入門：非常適合小白的入門教程，code
iOS測試各個斷言用法：工具而已

用 Xcode 進行單元測試

創建一個單元測試 Target

Xcode 的測試導航器提供了一種最簡單的進行測試的方法；你可以用它創建一個測試 target 并在你的 app 中進行測試。

打開 BullsEye 項目，按下 command+5 打開它的測試導航器。

點擊左下角的 + 按鈕，然后從菜單中選擇 New Unit Test Target…：

使用默認的 BullsEyeTests 作為名字。當導航器中顯示出測試 bundle 時，點擊并在編輯器中打開它。如果 BullsEyeTests 沒有自動顯示，點擊其它導航器，然后返回測試導航器。

模板代碼中，import 了 XCTest，并定義了一個 XCTestCase 的繼承類 BullsEyeTests，并聲明了 setup()、tearDown() 和 示例測試方法。

有三種運行這個測試類的方法：

ProductTest 或者 Command-U。這實際上會運行所有測試類。
點擊測試導航器中的箭頭按鈕。
點擊中縫上的鉆石圖標。

你還可以點擊某個測試方法上的鉆石按鈕單獨測試這個方法，鉆石按鈕在導航器和中縫上都有。

測試不同的運行測試方法，看看它們會運行多長時間，以及運行起來的樣子。示例測試不會執行任何動作，因此它們的運行是十分快速的！

如果所有測試通過，鉆石會變綠并顯示一個對勾。點擊 testPerformanceExample() 底部的灰色鉆石，打開 Performance Result：

你用不著 testPerformanceExample() 方法，請刪除它。

用 XCTAssert 測試模型

首先，用 XCTAssert 測試 BullsEye 的模型中的一個核心功能：一個 BullsEyeGame 對象能夠正確計算出一局游戲的得分嗎？

在 BullsEyeTests.swift 中，在 import 語句下面添加：

@testable import BullsEye

1

這樣單元測試就可以訪問 BullsEye 中的類和方法了。

在 BullsEyeTests 類頭部加入一個屬性：

var gameUnderTest: BullsEyeGame!

1

在 setup() 方法中創建一個新的 BullsEyeGame 對象，位于 super 方法調用之后：

gameUnderTest = BullsEyeGame()
gameUnderTest.startNewGame()

1
2

這會用類的級別創建出一個 SUT（被測系統）對象，因此這個測試類中的所有測試都能夠訪問 SUT 對象的屬性和方法。

這里，你也調用了游戲的 startNewGame 方法，這會創建一個 targetValue。你會有很多測試都要使用 targetValue，以測試游戲中計算的得分是否正確。

別忘了在 tearDown() 方法中釋放你的 SUT 對象，在調用 super 方法之前：

gameUnderTest = nil

1

注意：在 setup() 中創建 SUT，在 tearDown() 中釋放 SUT 是一種好的做法，能夠保證每次測試都以干凈的狀態開始。更多討論，請閱讀 Jon Reid 的這篇帖子。

準備編寫你的第一個測試了！

將 testExample() 方法修改為:

// 用 XCTAssert 測試模型
func testScoreIsComputed() {
  // 1. given
  let guess = gameUnderTest.targetValue + 5

  // 2. when
  _ = gameUnderTest.check(guess: guess)

  // 3. then
  XCTAssertEqual(gameUnderTest.scoreRound, 95, "Score computed from guess is wrong")
}

1
2
3
4
5
6
7
8
9
10
11

測試方法的名字總是以 test 開頭，后面加上一個對測試內容的描述。

將測試方法分成 given、when 和 then 三個部分是一種好的做法：

在 given 節，應該給出要計算的值：在這里，我們給出了一個猜測數，你可以指定它和 targetValue 相差多少。
在 when 節，執行要測試的代碼，調用 gameUnderTest.check(_:)方法。
在 then 節，將結果和你期望的值進行斷言（這里，gameUnderTest.scoreRound 應該是 100-5），如果測試失敗，打印指定的消息。

點擊中縫上或者測試導航器上的鉆石圖標。App 會編譯并運行，鉆石圖標會變成綠色的對勾！

注意：要查看完整 XCTestAssertions 列表，Command+左鍵，點擊 XCTAssertEqual，將跳到 XCTestAssertions.h，或者通過閱讀蘋果的 Assertions Listed by Category。

注意：Given-When-Then 結構源自 BDD(行為驅動開發)，是一個對客戶端友好的、更少專業術語的叫法。另外也可以叫做 Arrange-Act-Assert 和 Assemble-Activate-Assert。

在測試中進行 debug

在 BullsEyeGame 中認為制造了一個 bug，你可以試試怎么找出它。將 testScoreIsComputed 修改為 testScoreIsComputedWhenGuessGTTarget，然后復制、粘貼，將它復制為另外一個方法 testScoreIsComputedWhenGuessLTTarget。

在這個方法中，在 given 節，讓 targetValue - 5，而其它地方不變：

func testScoreIsComputedWhenGuessLTTarget() {
  // 1. given
  let guess = gameUnderTest.targetValue - 5

  // 2. when
  _ = gameUnderTest.check(guess: guess)

  // 3. then
  XCTAssertEqual(gameUnderTest.scoreRound, 95, "Score computed from guess is wrong")
}

1
2
3
4
5
6
7
8
9
10

猜的數和正確的數仍然相差 5，因此得分仍然應該是 95。

在斷點導航器中，添加一個 Test Failure 斷點，這樣，當測試方法斷言失敗時，測試會停止。

運行測試，它會在 XCTAssertEqual 這行停止，同時報告測試失敗。

查看 debug 控制臺中的 gameUnderTest 和 guess 值：

guess 變量是 targetValue - 5，但 scoreRound 是 105，而不是 95！

接下來，用正常的調試方法進行調試：分別在 when 節的代碼上設置一個斷點，在 BullsEyeGame.swift 的 check(_:) 方法的聲明 difference 變量處設置一個斷點。再次運行測試，跳到 let difference 語句處，觀察 difference 變量的值:

問題是： difference 是負值，因此 score 變成了 100 – (-5); 解決辦法是在 difference 上取絕對值。在 check(_:) 方法中，反注釋正確的代碼，刪掉錯誤的代碼。

清除兩個斷點，再次運行測試確保測試通過。

用 XCTestExpectation 測試異步操作

現在我們學習了如何測試模型，如何對測試失敗的情況進行 debug，接下來介紹用 XCTestExpectation 來測試網絡操作。

打開 HalfTunes 項目：它使用 URLSession 來查詢 iTunes API，下載歌曲小樣。假設你想用 AlamoFire 來進行網絡請求。為了證明一切正常，你應該為網絡請求編寫測試，并在修改代碼之前進行測試。

URLSession 方法是異步的：它們會立即返回，但并不會終止運行直到未來某個時候。要測試異步方法，需要用 XCTestExpectation 以確保測試會等待異步操作完成。

異步測試通常是慢的，因此要和其它較快的單元測試分開來。

點 + 按鈕，選擇 New Unit Test Target… ，取名為 HalfTunesSlowTests。在 import 語句中，導入 HalfTunes：

@testable import HalfTunes

1

這個類中的測試方法會使用默認的 session 來向蘋果服務器發送請求，因此聲明一個 sessionUnderTest 對象，在 setup() 方法中實例化而在 tearDown() 中釋放這個對象。

var sessionUnderTest: URLSession!

override func setUp() {
  super.setUp()
  sessionUnderTest = URLSession(configuration: URLSessionConfiguration.default)
}

override func tearDown() {
  sessionUnderTest = nil
  super.tearDown()
}

1
2
3
4
5
6
7
8
9
10
11

將 testExample() 方法修改為異步測試方法：

// 異步測試: 成功塊，失敗慢
func testValidCallToiTunesGetsHTTPStatusCode200() {
  // given
  let url = URL(string: "https://itunes.apple.com/search?media=music&entity=song&term=abba")
  // 1
  let promise = expectation(description: "Status code: 200")

  // when
  let dataTask = sessionUnderTest.dataTask(with: url!) { data, response, error in
    // then
    if let error = error {
      XCTFail("Error: (error.localizedDescription)")
      return
    } else if let statusCode = (response as? HTTPURLResponse)?.statusCode {
      if statusCode == 200 {
        // 2
        promise.fulfill()
      } else {
        XCTFail("Status code: (statusCode)")
      }
    }
  }
  dataTask.resume()
  // 3
  waitForExpectations(timeout: 5, handler: nil)
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

這個方法檢查 iTunes 返回狀態碼是否為 200。大部分代碼和你在 App 中的寫法一樣，除了這幾行：

expectation(_:) 返回一個 XCTestExpectation 對象，這個對象保存了一個承諾（promise)，又稱作期望(expectation)或未來(future)。參數 description 用于描述你預期的行為。
為了和描述一致，你可以在異步方法的成功回調塊中調用 promise.fullfill()。
waitForExpections(:_handler:) 保持測試方法的運行，直到所有的 expectation 被 fullfill 或者到達指定超時時間，這兩個條件任何一個都行。

運行測試。如果已連接網絡，當模擬器中 app 啟動之后，測試很快就會通過，

更快的失敗

失敗是痛苦的，但它不一定會發生。那么如何才能快速模擬測試失敗的方法？這樣我們才可以節省時間用于浪費到 Facebook 上？:]

可以修改你的代碼，以便模擬異步操作失敗的情況，將 URL 中 itunes 刪除最后的 s:

let url = URL(string: "https://itune.apple.com/search?media=music&entity=song&term=abba")

1

運行測試：如果失敗，app 會在超時時間之后才返回！這是因為它的 expectation 是請求成功，我們也只有在成功時才調用 promise.fullfil()。因此當操作失敗時，測試要結束必須等超時時間過去。

你可以修改 expectation，讓測試失敗得更快一點：

我們不要去等待請求成功了，而是去等待異步方法完成塊被回調的時候。這會在 app 收到響應之后立即發生——無論服務器返回的是 OK 還是錯誤，expectation 都會 fulfill。這樣，無論請求是否成功，你都能檢測到。

我們創建一個新的測試方法來進行測試。首先，將修改過的 url 恢復原樣，然后新建一個測試方法：

// 異步測試: 讓失敗更快
func testCallToiTunesCompletes() {
  // given
  let url = URL(string: "https://itune.apple.com/search?media=music&entity=song&term=abba")
  // 1
  let promise = expectation(description: "Completion handler invoked")
  var statusCode: Int?
  var responseError: Error?

  // when
  let dataTask = sessionUnderTest.dataTask(with: url!) { data, response, error in
    statusCode = (response as? HTTPURLResponse)?.statusCode
    responseError = error
    // 2
    promise.fulfill()
  }
  dataTask.resume()
  // 3
  waitForExpectations(timeout: 5, handler: nil)

  // then
  XCTAssertNil(responseError)
  XCTAssertEqual(statusCode, 200)
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

關鍵的一點是，在完成回調中，簡單地 fulfill 這個 expectation，這個過程會很快。如果請求失敗，斷言就會失敗。

運行測試，現在失敗的時間只需要一秒，這次的失敗是真的因為請求失敗，而不是因為超時。

恢復 url，再次進行測試，請求仍然是成功的。

模擬對象和交互

異步測試讓你在編寫調用異步 API 時更能保證輸入的正確。你可能還想測試一下用 URLSession 獲取數據，或者是更新 Userdefaults 或 CloudKit 數據庫的代碼是否正確。

大部分 App 會和系統或庫對象打交道——你無法控制這些對象——和這些對象交互時測試會變慢和不可重現，這違背了 FIRST 原則的其中兩條。但是，你可以通過從存根獲取數據或者寫入模擬對象寫入來模擬這種交互。

當你的代碼需要依賴系統或庫對象時可以使用偽造手段——創建一個模擬的對象代替并將之注入到你的代碼中。Jon Reid 的“依賴注入”一文介紹了幾種方法。

模擬從存根獲取數據

在這個測試方法中，你會測試 app 的 updateSearchResults(_:) 方法是否能夠解析從 session 中下載的數據，通過檢查 searchResults.cout 是否正確的方式。這個 SUT 是 view controller，你將用存根和已經下載好的數據來模仿 session。

點擊 +，選擇 New Unit Test Target…，取名為 HalfTunesFakeTest。在 import 語句中導入 HalfTunes：

@testable import HalfTunes

1

聲明這個 SUT，在 setup() 方法中構建，在 tearDown() 方法中釋放：

var controllerUnderTest: SearchViewController!

override func setUp() {
  super.setUp()
  controllerUnderTest = UIStoryboard(name: "Main", 
      bundle: nil).instantiateInitialViewController() as! SearchViewController!
}

override func tearDown() {
  controllerUnderTest = nil
  super.tearDown()
}

1
2
3
4
5
6
7
8
9
10
11
12

注意：SUT 是這個 view contoller，因為 HalfTunes 有一個很大的問題——所有的工作都是在 SearchViewController.swift 中進行的。將網絡代碼遷移到一個獨立的模塊中能夠解決這個問題，并能使測試更容易進行。

然后，你需要一些測試的 JSON 數據，這些數據將通過偽造的 session 來提供給測試方法。只需要幾個數據就可以了，你可以在 URL 字符串中用 &limit=3 來限制結果集：

https://itunes.apple.com/search?media=music&entity=song&term=abba&limit=3

1

將這個 URL 復制到瀏覽器中。將結果下載到一個 1.txt 之類的文件中。打開它，檢查它的 JSON 格式，然后重命名為 abbaData.json，然后將它拖到 HalfTunesFakeTests 的文件組中。

HalfTunes 項目中有一個 DHURLSessionMock.swift 文件。它定義了一個簡單的協議 DHURLSession，包含了用 URL 或者 URLRequest 來創建 data taks 的方法。還有實現了這個協議的 URLSessionMock 類，它的初始化方法允許你用指定的數據、response 和 error 來創建一個偽造的 URLSession。

構造模擬數據和 response，然后創建一個偽造的 seesion 對象，就在 setup() 方法中創建完 SUT 對象后面：

let testBundle = Bundle(for: type(of: self))
let path = testBundle.path(forResource: "abbaData", ofType: "json")
let data = try? Data(contentsOf: URL(fileURLWithPath: path!), options: .alwaysMapped)

let url = URL(string: "https://itunes.apple.com/search?media=music&entity=song&term=abba")
let urlResponse = HTTPURLResponse(url: url!, statusCode: 200, httpVersion: nil, headerFields: nil)

let sessionMock = URLSessionMock(data: data, response: urlResponse, error: nil)

1
2
3
4
5
6
7
8

在 setup() 最后，將這個偽造的 session 注入到 app 的屬性中：

controllerUnderTest.defaultSession = sessionMock

1

注意：你也可以直接在測試方法中使用這個偽造的 session，但我們想演示依賴注入，這樣你就可以通過 view controller 的 defaultSession 屬性來測試 SUT 的方法.

接下來準備編寫測試方法，調用 updateSearchResults(_:) 方法來解析模擬數據。將 testExample() 方法替換為：

// 用 DHURLSession 協議和模擬數據偽造 URLSession
func test_UpdateSearchResults_ParsesData() {
  // given
  let promise = expectation(description: "Status code: 200")

  // when
  XCTAssertEqual(controllerUnderTest?.searchResults.count, 0, "searchResults should be empty before the data task runs")
  let url = URL(string: "https://itunes.apple.com/search?media=music&entity=song&term=abba")
  let dataTask = controllerUnderTest?.defaultSession.dataTask(with: url!) {
    data, response, error in
    // 如果 HTTP 請求成功，調用 updateSearchResults(_:) 方法，它會將數據解析成 Tracks 對象
    if let error = error {
      print(error.localizedDescription)
    } else if let httpResponse = response as? HTTPURLResponse {
      if httpResponse.statusCode == 200 {
        promise.fulfill()
        self.controllerUnderTest?.updateSearchResults(data)
      }
    }
  }
  dataTask?.resume()
  waitForExpectations(timeout: 5, handler: nil)

  // then
  XCTAssertEqual(controllerUnderTest?.searchResults.count, 3, "Didn't parse 3 items from fake response")
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

我們仍然要編寫異步測試的代碼，因為存根是也模擬了異步方法。

當 data task 還沒有執行，斷言 searchResults 為空是成立的——即斷言為 true，因為在 setup() 方法中我們創建的是一個全新的 SUT。

模擬數據中包含了 3 個 Track 對象，因此我們斷言 view controller 的 searchResults 數組中包含了 3 個對象。

運行測試。很快就通過測試，因為根本就沒有使用網絡連接！

模擬寫入 mock 對象

上一個測試使用了 stub (存根)來從偽造對象中獲取數據。接下來，你將用一個偽造對象來測試向 UserDefaults 進行寫入的代碼是否正確。

再次打開 BullsEye 項目。這個 App 有兩種游戲方式：用戶可以拖動 slider 來猜數字，也可以通過 slider 的位置來猜數字。右下角的 segmented 控件可以切換游戲方式，并將 gameStyle 保存到 UserDefaults。

這個測試將檢查 app 是否正確地保存了 gameStyle 到 UserDefaults 里。

在測試導航器中，點擊 New Unit Test Target… ，取名為 BullsEyeMockTests。在 import 語句下添加：

@testable import BullsEye

class MockUserDefaults: UserDefaults {
  var gameStyleChanged = 0
  override func set(_ value: Int, forKey defaultName: String) {
    if defaultName == "gameStyle" {
      gameStyleChanged += 1
    }
  }
}

1
2
3
4
5
6
7
8
9
10

MockUserDefaults 重寫了 set(_:forKey:) 方法，用于增加 gameStyleChanged 的值。通常你可能認為應當使用 Bool 變量，但使用 Int 能帶來更多的好處——例如，在你的測試中你可以檢查這個方法是否真的被調用過一次。

在 BullsEyeMockTests 中聲明 SULT 和 MockUserDefaults 對象：

var controllerUnderTest: ViewController!
var mockUserDefaults: MockUserDefaults!

1
2

在 setup() 方法中，創建 SUT 和偽造對象，然后將偽造對象注入到 SUT 的屬性中：

controllerUnderTest = UIStoryboard(name: "Main", bundle: nil).instantiateInitialViewController() as! ViewController!
mockUserDefaults = MockUserDefaults(suiteName: "testing")!
controllerUnderTest.defaults = mockUserDefaults

1
2
3

在 tearDown() 中釋放 SUT 和偽造對象：

controllerUnderTest = nil
mockUserDefaults = nil

1
2

將 testExample() 替換為：

// 模擬和 UserDefaults 的交互
func testGameStyleCanBeChanged() {
  // given
  let segmentedControl = UISegmentedControl()

  // when
  XCTAssertEqual(mockUserDefaults.gameStyleChanged, 0, "gameStyleChanged should be 0 before sendActions")
  segmentedControl.addTarget(controllerUnderTest, 
      action: #selector(ViewController.chooseGameStyle(_:)), for: .valueChanged)
  segmentedControl.sendActions(for: .valueChanged)

  // then
  XCTAssertEqual(mockUserDefaults.gameStyleChanged, 1, "gameStyle user default wasn't changed")
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14

在測試方法“點擊” segmented 控件之前，when 斷言中，gameStyleChanged 的值應當是 0。在 then 斷言中也是 true，因為 set(:forkey) 方法真的被調用了 1 次。

運行測試，測試通過。

XCode 的 UI 測試

從 Xcode 7 開始引入了 UI 測試，允許你通過記錄 UI 上的交互來創建 UI 測試。UI 測試通過查詢來找到 app 的 UI 對象，同步事件，然后將事件發送給這些對象。這個 API 允許你檢索 UI 對象的屬性和狀態，并和預期值進行比對。

在 BullsEye 項目的測試導航器中，添加一個新的 UI Test Target。在 Target to be Tested 勾上 BullsEye，名稱保持默認的 BullsEyeUITests。

在 BullsEyeUITest 類中添加一個屬性：

var app: XCUIApplication!

1

在 setup() 方法，將 XCUIApplication().launch() 一句替換為:

app = XCUIApplication()
app.launch()

1
2

將 testExample() 方法名修改為 testGameStyleSwitch()。

在 testGameStyleSwitch() 中新起一行，然后在底部的編輯器窗口中，點擊紅色的 Record 按鈕。

當模擬器中 App 一打開，點擊游戲方式切換的 segmented 控件的 Slide 按鈕和頂部標簽。然后點擊 Xcode 中的 Record 按鈕，停止錄制。

在 testGameStyleSwitch() 方法中會添加三行代碼:

let app = XCUIApplication()
app.buttons["Slide"].tap()
app.staticTexts["Get as close as you can to: "].tap()

1
2
3

如果還有其它語句，請刪除。

第一行代碼完全和 setup() 方法中的代碼重復了，同時你也不需要真的點擊動作，因此可以刪除第一行和其它兩句的 .tap()。點開[“slide”]旁邊的下拉菜單，選擇 segsegmentedControls.buttons[“Slide”]。

這樣就變成了：

app.segmentedControls.buttons["Slide"]
app.staticTexts["Get as close as you can to: "]

1
2

然后開始編寫 given 節：

// given
let slideButton = app.segmentedControls.buttons["Slide"]
let typeButton = app.segmentedControls.buttons["Type"]
let slideLabel = app.staticTexts["Get as close as you can to: "]
let typeLabel = app.staticTexts["Guess where the slider is: "]

1
2
3
4
5

現在你已經獲得兩個按鈕和兩個頂部標簽的引用，繼續添加：

// then
if slideButton.isSelected {
  XCTAssertTrue(slideLabel.exists)
  XCTAssertFalse(typeLabel.exists)

  typeButton.tap()
  XCTAssertTrue(typeLabel.exists)
  XCTAssertFalse(slideLabel.exists)
} else if typeButton.isSelected {
  XCTAssertTrue(typeLabel.exists)
  XCTAssertFalse(slideLabel.exists)

  slideButton.tap()
  XCTAssertTrue(slideLabel.exists)
  XCTAssertFalse(typeLabel.exists)
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

這是為了測試當任何一個按鈕被選中或點擊時，對應的標簽是否存在。運行測試，斷言應當成立。

性能測試

根據蘋果文檔描述：性能測試將一段代碼執行十遍，計算出平均執行時間和標準偏差。平均值用于和基線值進行比較，以衡量是否測試通過。

編寫性能測試十分簡單：將需要測試的代碼放進 measure() 方法的閉包中。

要實際體驗一把，可以打開 HalfTunes 項目，將 HalfTunesFakeTests 的 testPerformanceExample() 方法替換為：

// 性能測試 
func test_StartDownload_Performance() {
  let track = Track(name: "Waterloo", artist: "ABBA", 
      previewUrl: "http://a821.phobos.apple.com/us/r30/Music/d7/ba/ce/mzm.vsyjlsff.aac.p.m4a")
  measure {
    self.controllerUnderTest?.startDownload(track)
  }
}

1
2
3
4
5
6
7
8

運行測試，點擊 measure() 方法閉包結束 } 旁邊的圖標，查看統計結果。

點擊 Set Baseline，再次運行測試，查看結果——結果可能比基線要好或差。 Edit 按鈕允許你修改基線以查看新的報告。

基線是根據設備配置來保存的，因此你可以在不同設備上進行同一個測試，每種設備會根據其配置的處理器速度、內存而擁有不同的基線。

當你對 App 進行修改之后，都會對測試性能造成影響，請重新運行性能測試，查看時需要參照基線進行。

代碼覆蓋

代碼覆蓋工具會報告 App 代碼有多少經過了測試，你也可以知道那一部分代碼還沒有經過測試。

注意：在代碼覆蓋選項打開的情況下，可以運行性能測試嗎？根據蘋果文檔中描述：代碼覆蓋率統計會導致性能下降……它以線型方式影響代碼的執行，因此當同樣是在打開的情況下，一次性能測試的結果和另外一次性能測試的結果仍然是有可比性的。但是，如果要在測試中進行嚴謹的性能計算，你應當考慮是否要開啟代碼覆蓋。

要打開代碼覆蓋，編輯 scheme 中的 Test，然后勾選 Code Coverage 選項：

運行全部測試（command+U)，打開報告導航器（command+8)。選擇 By Time，選擇列表中第一個，然后選擇 Coverage 欄：

點擊倒三角，查看 SearchViewController.swift 的函數列表：

將鼠標放到 updateSearchResults(:) 旁邊的藍色覆蓋率統計條上，可以看到覆蓋率為 71.88%。

點擊這個函數的箭頭按鈕，打開源文件，找到該函數。將鼠標靠近右邊縫的覆蓋率標注上，代碼會被分成不同顏色的部分，紅色或者綠色：

股概率標注顯示了一個測試“擊中”了代碼多少次，沒有被調用過的代碼會用紅色標注。你可能猜到了，for 循環被執行了 3 次，而錯誤路徑一次都沒執行。為了提高這個函數的覆蓋率，你應該復制 abbaData.json，修改內容使它產生錯誤——比如，將“results”修改為“result”，從而導致這句：print(“Results key not found in dictionary”)被調用。

100% 的覆蓋率

要追求 100% 的覆蓋率有多難？你可以用谷歌搜一下 100% unit test coverage，你會發現有許多贊成和反對的意見，以及關于對 100% 股概率的定義的爭論。反對的一方認為至少有 10-15% 的覆蓋率是毫無意義的。贊成的一方認為最后的 10-15% 是最重要的，因為它們很難被測試出來。再搜一下 “hard to unit test bad design”，你會發現一種比較有說服力的說法，不能測試的代碼表明存在深層次的設計問題。進一步的思考表明，測試驅動開發才是正理。

結束

你擁有了幾個幫助你編寫測試的良好工具。我希望本教程能夠在你測試任何事情的時候充滿自信。

在這里瞎子完整項目的zip 文檔。

要學習更多內容，請參考如下資源：

現在你是自己編寫測試的，更進一步是自動化：持續集成和持續分發。首先是蘋果的關于 Xcode 服務器和 xcodebuild 的官方文檔Automating the Test Process，維基百科關于持續分發，圖來自于ThoughtWorks。
TDD in Swift Playgrounds利用 XCTestObservationCenter 在 playground 中運行 XCTestCase 單元測試。你可以在 playground 中開發和測試項目代碼，然后將它們轉換到 app 中。
CMD+U Conference的Watch Apps: How Do We Test Them?，使用 PivotalCoreKit 來測試 watchOS apps。
如果你的 App 還未編寫過任何測試，你可以參考 Michael Feathers 的Working Effectively with Legacy Code，因為沒有測試過的代碼是遺留問題。
Jon Reid 的 Quality Coding 的示例 App app 是一個學習測試驅動開發的好去處。

十一、IOS自動化之KIF框架實踐

KIF的全稱是Keep it functional。它是一個建立在XCTest的UI測試框架，通過accessibility來定位具體的控件，再利用私有的API來操作UI。由于是建立在XCTest上的，所以你可以完美的借助XCode的測試相關工具。

一， 測試環境搭建
KIF框架依賴工程源碼進行測試的，所以要能從開發處拿到被測試工程的源碼，然后在搭建相應的測試環境。
1，命令行安裝pod：
sudo gem install cocoapods
2，修改或創建工程的pod文件 ：Podfile，如下所示：

# platform :ios, '9.0'
target 'TenMinDemo' do
# Uncomment the next line if you're using Swift or would like to use dynamic frameworks
# use_frameworks!

# Pods for CYXText
pod 'AFNetworking', '~> 3.0'
pod "SDWebImage"
pod "MJExtension"
pod "MJRefresh"
pod 'SVProgressHUD'
pod 'ReactiveObjC'

end

target 'TenMinDemoTests' do
use_frameworks!
pod 'KIF', '~> 3.5.1'
end
其中如下一段內容為新添加的：
target 'TenMinDemoTests' do //測試工程名
use_frameworks!
pod 'KIF', '~> 3.5.1'
end
3,執行安裝命令：
pod install
安裝相應的內容。
4，在現有工程中添加Target實現
選擇File→New→Target…菜單項, 從中選擇iOS→Other中的Cocoa Touch Unit Testing Bundle模板.如下圖所示：

單擊下一步，進行相應的設置頁：

5，設置測試工程相關項：

（1） Product Name:KIF測試工程名，可以自由命名，最好是測試工程名+”Tests”。
（2）Organization Name, Organization identifier, Bundle identifier,根據需要自行全名即可。
（3）Language:編碼語言，有Objective-C和Swift,默認選擇OC.
（4）Project和Target to be Tested:為對應的要測試的工程名，一定要保證是正確的。
（5）單擊“Finish”創建完成。
（6）工程創建完成，如下所示：

生成TenMinDemoTests工程，同時生成TenMinDemoTests.m文件和info.plist文件。
在Products文件夾中生成“TenMinDemoTests.xctest”文件。
TenMinDemoTests.m文件內容如下：
// TenMinDemoTestsB.m
// TenMinDemoTestsB
//
// Created by GrowingIO on 2018/5/30.
// Copyright ? 2018年 SXF. All rights reserved.
//
#import <XCTest/XCTest.h>
@interface TenMinDemoTests : XCTestCase
@end
@implementation TenMinDemoTests
- (void)setUp {
[super setUp];
// Put setup code here. This method is called before the invocation of each test method in the class.
}

- (void)tearDown {
// Put teardown code here. This method is called after the invocation of each test method in the class.
[super tearDown];
}

- (void)testExample {
// This is an example of a functional test case.
// Use XCTAssert and related functions to verify your tests produce the correct results.
}
- (void)testPerformanceExample {
// This is an example of a performance test case.
[self measureBlock:^{
// Put the code you want to measure the time of here.
}];
}
@end
各個函數相互作用及執行順序如下圖所示：

二， 測試用例編寫
KIF和其他測試框架類似，通過OC編寫代碼實現我們的測試步驟，進而去檢測操作完成的結果。下面我們以一個簡單而完整的用例來說明一下測試用例如何編寫：
1，手工用例步驟介紹：
（1）我從網上下載的一個Demo,工程名為TenMinDemo,選擇其中的一個功能，登錄：打開app,選擇“博文”項
（2）輸入用戶名：dingdone和密碼：123456，單擊“登錄”按鈕，登錄成功。
（3）檢測是否進入到了列表頁。
2，代碼測試用例如下：
//LoginTests.m
//
// LoginTest.m
// TenMinDemoTests
//
// Created by GrowingIO on 2018/5/31.
// Copyright ? 2018年 SXF. All rights reserved.
//

#import "LoginTest.h"

@implementation LoginTest
- (void)setUp {
// Put setup code here. This method is called before the invocation of each test method in the class.
}
- (void)tearDown {
// Put teardown code here. This method is called after the invocation of each test method in the class.

}
- (void)testLogin {
//單擊“博文”
[tester tapViewWithAccessibilityLabel:@"博文"];
//輸出用戶名和密碼
[tester clearTextFromViewWithAccessibilityLabel:@"usename"];
[tester enterText:@"dingdone
" intoViewWithAccessibilityLabel:@"usename"];
[tester clearTextFromViewWithAccessibilityLabel:@"password"];
[tester enterText:@"123456
" intoViewWithAccessibilityLabel:@"password"];
//等待1秒
[tester waitForTimeInterval:1];
//單擊登錄按鈕
[tester tapViewWithAccessibilityLabel:@"login"];
[tester waitForTimeInterval:5];
//獲取列表頁view
UITableView *utable=[tester waitForViewWithAccessibilityLabel:@"tableView"];
//獲取tableview第二行
NSIndexPath *index = [NSIndexPath indexPathForRow:1 inSection:0];
UITableViewCell *utvc=[tester waitForCellAtIndexPath:index inTableView:utable];
if (@available(iOS 11.0, *)) {
//判斷第二行的內容是否符合預期
//NSLog(@"Cell Content:%@",utvc.textLabel.text);
XCTAssertEqualObjects(utvc.textLabel.text, @"第2行");
} else {
// Fallback on earlier versions
}
}
@end
上面的代碼添加了詳細的注釋，內容也比較簡單，就不逐步介紹了。注意：KIF是基于XCText的，基本的判斷語句都是XCTest的。
3，KIF API簡介
KIF API相關的介紹挺多，只是不太全面，下面我介紹幾個不錯的網站：
（1）KIF API的中文翻譯https://www.jianshu.com/p/87bbbb798926，
感覺好像不太全；
（2）官網上的源碼及其介紹：https://github.com/kif-framework/KIF.
（3） KIFUITestActor Doc：http://cocoadocs.org/docsets/KIF/3.2.1/Classes/KIFUITestActor.html，這個網站內容比較全面，只是英文的，不FQ能不能打開還不清楚。
很多新的技術都有一個特點，就是相關的文檔非常少，這也沒有辦法；可是換個想法來看，如果相關技術文檔到處都是，這項技術學了也沒有什么優勢了。

三，測試用例集及命令行執行
目前KIF一個Kiftestcase類就相當于一個測試用例集，我們可以簡單地利用類的方式來組織測試用例，類中的每個以test****開頭的函數均是一個測試用例。當然基于KIF開源的特性，我們可以開發其他的用例集管理方式或是工具，如下圖所示：

（圖片來源于：https://tech.meituan.com/iOS-UITest-KIF.html）
任何自動化測試最終的歸宿都是CI(持續化集成)，當然我們的KIF自動化也需要做持續化集成。而在做持續化集成前，需要調研如何通過命令行來執行測試用例？
（1）將項目設置成shared
從product->Scheme->manage schemes,查看項目是否是shared,如果不是，則選中后面的復選框將其共享。

（2）借助于xctool來執行測試用例
Xctool源碼地址：https://github.com/facebook/xctool，可以去查看一下如何安裝和使用：https://blog.csdn.net/jeikerxiao/article/details/51669451
而運行我們的示例代碼應該是：
xctool -workspace XXX.xcworkspace –schem XXYYY run-tests XXXtests:測試用例集 -sdk "iphonesimulator11.3"
同時可以通過-only來指定運行某個用例
(a)運行單個測試用例
xctool -workspace TenMinDemo.xcworkspace -scheme TenMinDemo run-tests -only TenMinDemoTests:LoginTest/testlogin -sdk "iphonesimulator11.3"
(b)運行一個測試用例集
xctool -workspace TenMinDemo.xcworkspace -scheme TenMinDemo run-tests TenMinDemoTests:LoginTest -sdk "iphonesimulator11.3"

四，生成測試報告
xctool的reporter選項可以生成不同形式的測試報告：
pretty: (默認) 一個文字化的輸出器，使用 ANSI 顏色和 unicode 符號來進行美化輸出。
plain: 類似 pretty, 不過沒有顏色和 Unicode。
phabricator: 把構建/測試的結果輸出為 JSON 數組，它可以被 Phabricator 的代碼評審工具讀取。
junit: 把測試結果輸出成和 JUnit/xUnit 兼容的 XML 文件。
json-stream: 一個由構建/測試事件組成的 JSON 字典流，每行一個（示例輸出）。
json-compilation-database: 輸出構建事件的 JSON Compilation Database ，它可以用于基于 Clang Tooling 的工具，例如 OCLint.
而我們通常使用xml格式測試報告，一則做持續化集成的時候，Jenkins可以直接這個報告；二則我們可以借助于ant將期轉換成 html的報告：
1,生成junit報告：
xctool -workspace TenMinDemo.xcworkspace -scheme TenMinDemo run-tests TenMinDemoTests:LoginTest -sdk "iphonesimulator11.3" -reporter junit:/Users/growingio/Documents/report.xml
2，轉換測試報告xml成html
由于xctool輸出的報告中含有中間輸出信息，所以不能直接轉換，需要先處理一下，去掉無用的信息。或是先將報告轉化成json格式，然后再提取出合適的信息，生成xml文件。這個方法需要另外寫腳本轉換一下。
生成報告的步驟如下：
（1）安裝ant
（2）優化xctool生成的xml，把中間輸出信息去掉
（3）創建builld.xml文件
<project name="TestNG_WORKSPACE" default="junit-report" basedir=".">
<!-- Sets the property variables to point to respective directories -->
<property name="junit-xml-dir" value="${basedir}/junitreports"/> //junit報告文件的路徑
<property name="report-dir" value="${basedir}/html-report" /> //生成html生成報告的位置
<!-- Ant target to generate html report -->
<target name="junit-report">
<!-- Delete and recreate the html report directories -->
<delete dir="${report-dir}" failοnerrοr="false"/>
<mkdir dir="${report-dir}" />
<mkdir dir="${report-dir}/Junit" />
<!-- Ant task to generate the html report.
todir - Directory to generate the output reports
fileset - Directory to look for the junit xml reports.
report - defines the type of format to be generated.
Here we are using "noframes" which generates a single html report.
-->
<junitreport todir="${report-dir}/Junit">
<fileset dir="${junit-xml-dir}">
<include name="**/*.xml" />
</fileset>
<report format="noframes" todir="${report-dir}/Junit" /> //format:"frames",還左邊框的報告，“noframes”,無邊框的報告
</junitreport>
</target>
</project>
（4）將juntreport.xml的路徑設置好，同時將build.xml給保存到相應的位置，然后在build.xml的路徑下執行命令：ant,則會生成如下格式的html報告

五，持續化集成
持續化集成的核心思想就是借助于Jenkins的任務調度功能，將自動化測試用例放到Git/Svn上，然后配置相應的代碼庫地址，執行腳本命令等。根據不同的觸發條件，完成自動運行的機制。其中還要根據需要進行相關的配置等等，網上相應的步驟比較多，在此就不詳細介紹了，可以參考一下：“基于 KIF 的 iOS UI 自動化測試和持續集成（https://tech.meituan.com/iOS-UITest-KIF.html）”
在做持續化集成的時候，一定要考慮到因為環境原因，網絡原因等造成的非正常失敗的情況，故要加上用例失敗重跑機制。
Commands如下所示：
xctool -workspace TenMinDemo.xcworkspace -scheme TenMinDemo run-tests TenMinDemoTests:LoginTest -sdk "iphonesimulator11.3" -reporter junit:/Users/growingio/Documents/report.xml
array=( TimerTests HistoryTests )
for data in ${array[@]}
do
xctool -workspace TenMinDemo.xcworkspace -scheme TenMinDemo run-tests -only TenMinDemoTests:${data} -sdk "iphonesimulator11.3" -reporter junit:/Users/growingio/Documents/report.xml
done

六，總結
最近在公司以KIF框架做了一些IOS自動化測試相關的東西，中間磕磕碰碰的遇到了不少問題，也查了資料進行了解答。現在就整個項目的實現過程給總結一下，以方便知識的總結和記錄，也有利于后來者進行快速入門。
由于經驗有限，難免會存在不足之處，后續會不斷更新和完善。

總結

以上是生活随笔為你收集整理的IOS自动化测试框架搭建及测试流程介绍（满满的干货）的全部內容，希望文章能夠幫你解決所遇到的問題。

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