iOS系統下的持續集成實踐(3)

　　在構建完測試版本之后要準備進行內測版本的構建工作，這個時候需要再將環境切換至線上環境;

　　這種由于項目中提供的環境切換方式不統一導致的問題需要在后面和開發形成統一的共識，以減少切換腳本的多樣性，形成同一個腳本來進行修改，減少維護問題;

　　應用安裝到iPhone上需要的是一個ipa包，因此需要將構建出來的正式版本打包成ipa包，然后提供給內測下載服務器，而Xcode Plugin提供了打ipa包的功能，Xcode Plugin制作ipa的方式是通過xrun命令行來進行的，打包ipa的配置如下：

　　在制作ipa包的過程中需要提供mobileprovision文件和簽名證書(注意提供給內測使用的ipa需要的是企業級證書，因此注意檢查工程的配置或者提供shell腳本修改project的配置);

　　關于單元測試：

　　在上面的部分其實少了一部分就是關于單元測試的內容，iOS提供了一個單元測試的框架SenTestingKit，通過這個框架可以對iOS進行單元測試，而Xcode Plugin允許在每次構建的時候執行單元測試，因此就可以通過Build來及時的把問題反饋給開發，也更便于開發定位問題原因;

　　那為何在本地的整個持續集成中沒有這部分的內容呢?關于這個問題的考慮是這樣的，本地這邊客戶端對于業務的封裝是通過提供一系列的Service實現，這些Service構成了客戶端業務的SDK，負責實現客戶端主要的業務邏輯，但是目前這些Service比較“薄”，基本都是對與后端的http請求，然后將對應的結果包裝成為對象返回調用方，因此這部分的測試可以通過對于后端提供的http接口的測試來覆蓋，因此在這里缺少了對于單元測試的描述。

　　關于自動化驗證：

　　在進行這些所有工作之前其實第一個想到的是自動化，希望可以通過自動化來對主要功能進行驗證，減少成本;于是就對目前的自動化框架進行了調研，參考了其他團隊的方式，最終選擇了使用athrun來作為本地的自動化測試框架;

　　Athrun對于iOS自動化提供了底層的支持，而業務線需要根據具體的情況去搭建上層的結構，就好比搭積木，底層的積木塊提供了出來，搭成房子還是搭成汽車就是上層的事情了;

　　分析了一下iOS客戶端的特點，一般來說客戶端的界面不是很多，一個基礎的業務操作基本都在一個界面中就可以完成，很少會出現跨越多個界面進行操作的基礎業務操作，其次就是客戶端每個界面上需要輸入的數據都不會很多，因此也不太需要提供專門的數據層來對測試數據進行支持;針對以上的特點對于業務的自動化測試腳本進行了分層，由上至下分為了四層：

　　<!--[if !supportLists]-->1) <!--[endif]-->第一層是測試用例集層，該層負責整合測試用例集，物理的對于測試用例進行劃分，按照一定的邏輯將測試用例整合起來;

　　<!--[if !supportLists]-->2) <!--[endif]-->第二層是測試用例層，該層提供了實際的測試用例腳本，測試用例由業務操作組合起來，形成各自的業務場景;

　　<!--[if !supportLists]-->3) <!--[endif]-->第三層是業務流層，該層提供了對于客戶端應用的業務操作的封裝，為測試用例層提供可復用的操作;

　　<!--[if !supportLists]-->4) <!--[endif]-->第四層是元素層，該層提供了操作界面元素的接口，這部分完全由athrun來提供;

　　代碼的組織結構如下：

　　測試用例由業務流的操作組合而成，同時添加必要的驗證，測試用例的結構如下所示：

　　而這些業務流的初始化與清理工作完全由每個應用的測試用例基類來進行處理，測試用例基類的寫法如下：

　　隨著自動化測試的開展和新的項目開展，新的問題也一個個的出現了，這些問題包括：

　　<!--[if !supportLists]-->1) <!--[endif]-->開始的時候沒有使用jenkins，同時由于機器的IP地址沒有辦法固定下來，因此沒有辦法得到需要的測試報告，于是提供了一套機制來生成測試報告，測試報告的生成結果如下：

　　后來使用jenkins來進行持續集成，該測試報告生成方式被拋棄;

　　<!--[if !supportLists]-->2) <!--[endif]-->電影票客戶端數據每天都需要更新，如此數據準備的操作需要放到自動化中來解決，于是提供數據準備和數據清理工作，提供@DataPrepare和@DataClear來進行數據準備和數據清理的配置;

　　<!--[if !supportLists]-->3) <!--[endif]-->測試環境有時候不太穩定，一些測試用例在第二次運行的時候就可以通過，問了解決這個問題提供了@Rerun標簽來對失敗的測試用例進行再次執行進行配置，允許設置重復執行的次數;

　　<!--[if !supportLists]-->4) <!--[endif]-->后來環境就更惡劣了，已經不是靠重復執行就可以解決的，同時也希望當測試環境有問題的時候就不要運行測試用例，為了解決這個問題提供了@CheckEnv標簽來檢查環境;

　　這些部分的特點都是與業務基本上沒有相關性，因此在這里的做法是將這部分獨立提成一個工程，該工程為各個業務的自動化腳本提供支持，同時在這個工程中處理了運行自動化腳本時的內存泄露和異常退出時再次運行無法啟動app的問題;

原文轉自：http://www.anti-gravitydesign.com