第2章 走進iOS

2.1 引言

測試觀介紹完后，正式進入iOS特色測試篇，本節就iOS平臺的基礎知識進行講解，而iOS平臺的移動終端包括iPhone、iPad、iTouch，本章將以iPhone為主要介紹對象，iPad、iTouch與iPhone基本一致，不再贅述。

2.2 iOS平臺的興起

隨著科技和移動互聯網技術的進步，智能移動硬件設備的迅猛發展，曾經輝煌的諾基亞神話已經不在，取而代之的是一個龐大的蘋果帝國。蘋果公司原稱蘋果電腦公司，由史蒂夫·喬布斯、史蒂夫·沃茲尼克、羅納德·韋恩等于1976年創立，最初是一家開發和銷售個人計算機的公司。2007年推出第一代iPhone并改名為蘋果公司后開始將重心轉移到消費電子領域。

從2007年蘋果公司發布的第一代iPhone手機，到2016年發布的iPhone 7，蘋果公司已經發布了iTouch、iPhone、Apple Watch和iPad等一系列高端智能移動設備。在全世界范圍內掀起了一股蘋果熱，一夜之間涌現了無數瘋狂的果粉，尤其是蘋果手機，雖然價格不菲，依然有無數人為了搶購到最新的iPhone不惜徹夜排隊。這些移動設備究竟有哪些獨特的優勢使其如此風靡呢？

要說風靡的原因，當然不排除部分用戶的虛榮心，但是歸根結底還是蘋果公司用自己的產品品質征服了廣大用戶。蘋果的制作工藝要求之高，幾乎達到了苛刻的程度，其軟硬件互相配合，實現了硬件性能最優化。對質量的高要求使得在Android系統上飽受詬病的散熱和電量兩大問題都沒有在iPhone上出現。當然，讓iPhone成為眾人吹捧的最根本原因還在于其搭載的iOS操作系統。首先，iOS是一個相對非常封閉的系統，避免了黑客利用源代碼的漏洞鉆空子，這就大大提升了系統的安全性。其次，iPhone嚴格的內存管理機制使其在長時間運行后依然能保持流暢的體驗和超高的穩定性。除此之外，iOS平臺的App上架前都要經過蘋果公司嚴苛的審核，這就從根本上保障了App的質量。蘋果的產品質量、蘋果的賬號體系和蘋果自有的應用平臺共同組成了一個蘋果生態圈，又進一步鞏固和擴大了其用戶數量。

目前，iOS已成為移動互聯網主導的系統之一，搭載iOS的硬件設備更是成為用戶追捧的對象，在未來的發展過程中，移動互聯網產品將融入生活的每一個角落，不僅是手機產品，很多可穿戴設備也都離不開移動互聯網產品，可見未來iOS系統的市場之大也是非常值得期待的。只有提升開發和測試水平，保證產品的質量，才能夠確保搭上iOS未來更深入發展的這趟列車。

2.3 iOS平臺的特殊性

iOS平臺作為一種獨立的操作系統平臺，有很多其他平臺所沒有的特性。

2.3.1 證書

我們在找工作時，需要向用人單位出示學校頒發的畢業證書，同理，要想我們開發的應用能夠在iOS設備上安裝啟動，就需要向iOS設備提供由蘋果公司頒發的證書，證明我們的應用是經過蘋果公司官方認證的。iOS設備在啟動App前，會先驗證證書是否合法，這個過程被固化在了iOS系統中，除非手機越獄，否則都要經歷這個過程。

要想開發iOS應用，首先要成為蘋果公司認證的開發者（雖然Xcode 7之后可以用個人非付費Apple ID進行真機調試，但是不適合團隊開發和正式提交AppStore發布，因此非付費Apple ID沒有算作開發者賬號來進行介紹）。開發者賬號有四種不同的類型，分別是個人賬號、公司賬號、企業賬號和教育賬號。其中個人賬號和公司賬號為99美元/年，企業賬號是299美元/年，教育賬號是0美元/年。我們在開發和測試iOS應用的時候，不能一直在模擬器上進行，總是要在真機上進行調試和驗證，通過非AppStore渠道安裝的應用，如果想要安裝到設備上，就要將這些應用導出為iOS可識別的ipa格式安裝包，在導出安裝包時，最重要的一個因素就是包所使用的證書，即包的簽名方式。剛剛提到的兩種不同金額的開發者賬號可以申請的證書類型也是不同的。蘋果的證書體系非常煩瑣復雜，這里不再贅述，先簡單列舉一個表2-1說明一下與發布有關的證書。

下面詳細介紹這三個在iOS項目中經常見到的證書類型。

AppStore方式：可以提交AppStore發布的最終極版本，但是只能通過AppStore下載安裝。三種開發者賬號均可以申請該簽名方式。

Adhoc方式：允許設備不通過AppStore下載而直接安裝，然而，對于Adhoc方式發布的App或者在真機調試時，蘋果公司會由一個文件來限制可安裝的設備列表，里面是iOS設備的UDID（設備標識），每個設備只有一個獨一無二的UDID，只有在文件中添加了UDID的設備，才允許安裝Adhoc的包，每個開發者賬號在繳費周期內只允許100臺設備添加到文件中，也就是最多只有100臺設備可以安裝Adhoc簽名的包。同樣，三種開發者賬號均可以申請該簽名方式。

In House方式：又稱企業簽名方式，可以不通過AppStore下載，也不限制安裝的設備數。這種簽名方式只有企業賬號可以申請。雖然不限制安裝的設備數，但是蘋果公司嚴禁企業簽名的包流入用戶手中，只允許公司內部小范圍內安裝體驗，一旦發現有違規，就會做永久下架處理。所以iOS平臺沒有可供大量用戶提前體驗的灰度渠道。

本節只簡單介紹蘋果公司的賬號和證書體系，以及對App開發和測試帶來的影響，對于其中涉及的具體實現細節和一些加密算法沒有做重點說明，網上相關的資料很多，感興趣的讀者可以自行查閱。

2.3.2 越獄

前面介紹的是開發或者安裝App所必須有的證書。但是，如果iPhone手機本身越獄了，那么就不存在任何證書問題。每一個iPhone或者iPad用戶，應該都聽過越獄這個詞。越獄就是獲取iOS設備的Root權限，打破手機原版系統的限制，用戶可以自由安裝各種插件、訪問和獲取系統文件，從而更便捷地控制手機。

iOS系統與Android系統最大的區別就是對用戶權限的限制。Android系統是完全開放用戶權限的，用戶可以訪問甚至修改系統文件，可以從各種渠道下載應用；而iOS系統則要封閉許多，用戶的權限非常低，無法訪問系統文件，應用只能從蘋果認證的AppStore中下載。iOS系統的封閉性會讓剛使用iPhone和iPad的用戶很不習慣，因此會有很多用戶選擇越獄。

越獄有什么優點？越獄后可以獲得更高的系統權限，可以自己修改和管理系統文件，可以安裝需要高系統權限的應用，例如瀏覽器插件、藍牙傳輸文件等功能；越獄后既可以安裝AppStore提供的免費應用，也可以免費安裝破解版的收費的應用；越獄后可以隨意更換主題、圖標等，讓手機更有個性。

越獄的這些優點同樣可以為測試所用。如測試性能用到的遠程連接工具openssh、用于錄屏的display recorder，以及啟動App和抓取數據包等操作要用到的命令行工具等，都只有在越獄設備上才可以安裝。

2.3.3 灰度

產品在正式發布之前，都會發布一個Beta灰度版本，也就是對所有用戶公開的測試版本，又稱公測。因為開發者和測試人員的時間和精力有限，總是沒有辦法涵蓋所有用戶所處的網絡條件和用戶操作場景，所以會提前放出一個經過測試的、功能完整、性能相對穩定的灰度版本，讓用戶幫忙驗證是否在不同的場景下還會遇到問題。我們總是希望有大規模不同使用習慣的灰度用戶能夠使用我們的Beta版本，以提供更多的反饋，幫助我們發現未知的缺陷，不斷優化和提升產品質量。可以說，灰度版本是軟件生命周期的必經階段。然而，由于蘋果公司規定，iOS平臺軟件的正式版本必須通過蘋果官方應用商店AppStore才能發布，而用于內部開發和調試的版本也受到簽名和設備的限制，不能隨意推送給用戶。于是iOS應用的灰度渠道只能寄希望于越獄用戶，通常采用91助手越獄版向越獄用戶進行推送。

隨著時間的推移，人們已經適應了iOS簡潔、友好的交互界面，而且免費的iOS應用越來越多，加上越獄可能帶來的系統穩定性下降和硬件損傷等風險，因此，選擇將設備越獄的蘋果用戶越來越少，灰度渠道的用戶也越來越少。在iOS 8上，蘋果提供了一種新的灰度渠道，將TestFlight整合進了iTunes Connect，開發人員可以通過電子郵件邀請用戶通過TestFlight下載應用一起來參與測試。這個渠道看起來沒什么問題，實際上最大的問題就是TestFlight的活躍用戶太少。要用TestFlight來發布灰度版本，有以下幾個條件。

（1）開發者自己收集總數不超過2000個的郵箱賬號提交TestFlight。

（2）提交的App版本要審核三天（這已經比AppStore審核快了N倍）。

（3）用戶需要下載TestFlight客戶端到手機，登錄自己的Apple ID并填寫郵件里的邀請碼。

（4）一個邀請碼只能在一個Apple ID使用。

（5）第二次發布體驗版的時候，用戶需要手工去TestFlight里點擊更新。

實際上我們遇到的問題還有以下幾方面。

（1）通過各種論壇收集的用戶郵箱賬號提交后，有三分之一的用戶收不到邀請碼。

（2）剩下三分之二的用戶里又有二分之一的用戶不會去下載灰度體驗版本。

（3）僅剩的下載了體驗版本的用戶使用不活躍，也沒有什么反饋提交。

（4）反饋的信息不足，聯系用戶困難，基本聯系不上，復現問題的概率很低。

最后我們采用了企鵝眾測（tesly.qq.com）作為灰度發布的主要渠道，企鵝眾測又稱Tesly，主要是通過建立iOS測試軍團的方式將測試任務發布給普通用戶，用戶獲取任務后進行測試并提交反饋獲取積分獎勵。通過這種方式可以有效調起TestFlight上灰度版本的下載和體驗率，獲取項目組需要的質量信息。

然而，盡管有了這些途徑，相比Android平臺一款應用動輒幾萬甚至幾十萬的灰度用戶量，iOS應用的灰度用戶杯水車薪，甚至沒有灰度，這就給測試人員帶來了更大的挑戰。產品沒有經過批量用戶的檢驗就要直接接受蘋果的審核，審核通過后才能正式上架推送給正式用戶。用戶對正式版本的忍耐度普遍沒有對公測版本的高，一旦集中爆發某個問題，可能就會給用戶帶來質量極差的感知，導致用戶大量流失。

2.3.4 AppStore審核

AppStore是蘋果公司提供給開發者發布和用戶下載的應用平臺。如前文提到，為了給發布者營造一個公正、良性的發布環境，給用戶提供安全、可靠的應用，蘋果公司制定了一套嚴格的審核規范，每個提交AppStore的應用都會經過蘋果公司在技術、內容和設計規范等一系列多重規范的審核。詳情見蘋果AppStore審查官方指南：https://developer.Apple.com/APP-store/review/guidelines/。

蘋果審核，是iOS應用從業者又一個不得不說的痛，絕大多數公司都有過產品被拒的經歷，可以說是一言不合就會被蘋果以各種理由拒絕。蘋果審核時間一般需要一周左右，一旦被拒，修復后再提交，前后兩次就要耗費兩周，如果多次被拒，就很可能成為蘋果的重點審查對象，審核周期無法保證，這無疑嚴重影響了產品的正常發布進度。每位iOS平臺相關的從業者都應該系統理解蘋果審核的規則，盡量規避這些情況的發生，保證產品的正常發布周期。

作為一名測試人員，既要盡可能挖掘產品隱藏的缺陷，保證產品的質量，還要根據AppStore審核規范協助項目組對App進行提交前的驗收，減少不必要的錯誤，降低審核被拒的風險，為App順利上線把好最后一道關。

根據蘋果AppStore審查官方指南，同時結合之前曾經出現過的審核被拒的案例，我們建立了一套上線前的checklist，每次版本提交AppStore之前，項目組的不同角色分工合作，對提交材料進行驗收，驗收合格后正式提交蘋果審核。

驗收對象按照模塊可以劃分為三部分：應用的ipa包、應用說明資源、應用內容和功能。

應用的ipa包驗收主要是對info.plist中的配置文件、私有API、第三方SDK庫、文件大小、是否有Crash上報，以及64位和32位等內容是否符合蘋果要求進行檢查。

應用說明資源驗收主要是對應用的介紹和用以輔助說明的圖片、視頻等進行檢查，確保內容真實，規格屬性符合蘋果要求。

應用內容和功能是蘋果審核最為嚴格的部分，通常蘋果公司的審核人員會安裝應用體驗功能，稍有問題就可能會被拒絕，這也是在經過迭代、集成和回歸測試后，在上線前仍要走查功能的原因。

除此之外，由于蘋果公司的審核團隊是在美國，因此在上線前驗收還要關注是否兼容IPv6網絡，美國VPN網絡下是否能正常連接等，避免在這些場景下出現問題而被拒。

2.3.5 自動化測試工具

iOS平臺還有一個特性是自動化測試工具比較少。說起Android的UI自動化工具，人們總可以說出很多現成的自動化框架來，如UIAutomator、Cabalash、Appium、Robtium等。雖然各個框架都有自己的優缺點，有不同的適用場景，但是現有的框架基本可以滿足自動化測試的需求。即使有特殊的要求，因為Android系統是開源的，完全開放用戶權限，測試人員也可以根據實際需要進行二次封裝開發就可以輕易實現。

在iOS平臺上就沒有這么方便了，雖然iOS平臺的自動化工具有UITest、XCTest、KIF、Cabalsh、Appium等，但是距離運用到每日迭代持續集成還有很長的距離。

（1）框架穩定性不高。當用例數目比較少、運行時間較短時，現有的自動化框架基本沒有問題，但是隨著用例數的增多，框架可能要連續運行多個小時，這時大部分框架就會暴露出穩定性不高的問題，頻繁出現閃退，只能重新啟動項目，增加了人為干預的時間。目前只有XCTest在這方面比較有優勢，這會在第5章進行詳細講解。

（2）無法獲取底層接口。由于iOS系統的封閉性，導致無法獲取系統root權限和系統狀態等，這就無法對文件進行操作，也沒辦法根據系統輔助判斷運行結果，給自動化的運行帶來了難處。

（3）無自動分析運行結果的日志系統。腳本運行不是目的，最重要的是要看到運行結果，對異常情況能夠快速定位問題。框架自身的日志系統需要人工去逐一排查用例運行結果，不能滿足用戶結合自動化腳本分步驟展示日志的需求，這就延長了自動化運行后確認結果的時間，增加了新人的學習成本。這個問題通過對框架的二次開發和封裝解決，會在第6章介紹。

2.4 小結

iOS平臺獨特的系統特性直接影響著測試的方式和內容，因此，了解iOS基礎知識十分必要。本章主要介紹了iOS的平臺基礎知識，為后續章節講述iOS特色測試鋪墊背景知識。任何想了解iOS平臺的讀者都要深刻銘記本章的內容。