我們希望在代碼改動發生的時候就做到盡早發現代碼改動帶來的問題,所以使用 “Poll SCM” 在當代碼倉庫有新的 pull request 的時候觸發相應 Job 完成構建,Job 的執行結果作為這個 pull request 能否合入的衡量指標之一;同時為支持客戶端支持 daily build ,Job 使用 "Build periodically" 在每天 daily build 打包前完成一次自動構建。
Job 需要支持命令行構建才能實現持續集成,如上一部分提到,我們可以借助 xcodebuild/xctool 實現單命令行構建。同時為了衡量 Job 的執行結果,我們需要在 Job 執行完成后生成相應的測試報告和代碼覆蓋率報告,使用 xcodebuild/xctool 這樣的命令行工具,只需要配置相關的參數即可獲取相應的 XML 測試報告文件。
Jenkins 中 JUnit Plugin 插件可以將 XML 形式的測試報告轉化成一種隨時間推移的測試結果圖表,向我們展示測試的結果和測試的穩定性; Cobertura plugin 插件可以將 XML 形式的覆蓋率文件轉化成一種隨時間推移的代碼覆蓋率圖表。如下圖是 Job 中測試報告的代碼覆蓋率和測試結果的示例,通過下面的圖表,我們可以清晰地看到測試是否通過,檢查代碼的測試覆蓋范圍,并對比歷史的測試結果和代碼覆蓋率來推斷和定位問題。
我們的測試用例覆蓋了第一次安裝啟動的操作。在初期,這個用例經常失敗。經過排查發現,持續集成系統中的模擬器設備重置操作并沒有覆蓋所有的設備,UI 測試 Job 運行時,Job 選擇的模擬器設備上可能遺留了其他 Job 構建的相同的 app 產物,導致我們的 Job 構建產物并不是第一次安裝啟動。所以在腳本中我們遍歷所有模擬器設備,將其進行重置。
(2)鍵盤敲擊延遲我們的測試用例在輸入框輸入文字時,經常出現輸入不全而導致失敗的問題。比如在輸入框中輸入 'beijing' ,失敗后提示:Failed to get text in field; instead, it was 'beiji' 。經過排查,發現持續集成系統中的機器性能有高有低,在低性能機器中更容易發生此問題,再研究 KIF 框架源碼發現,KIF 默認設置的鍵盤敲擊時延為一個常數,對于低性能機器來說這個敲擊時延較短,容易漏掉輸入,所以我們在 KIFTypist.m 源碼文件中適當增加 (NSTimeInterval) keystrokeDelay 的時長來避免輸入不全的問題。
原文轉自:https://zhuanlan.zhihu.com/p/22283843