前言
　　iOS 開發從 2010 年開始在國內不斷地升溫，開發和測試相關的問題不絕于耳。iOS 測試主要涉及哪些內容？又有哪些挑戰呢？帶著疑問我們開始第一個大問題的討論。
　　iOS 測試的范圍和可能遇到的挑戰
　　iOS 測試范圍
　　一般來說，每一個 iOS 應用的背后都會有一些后臺服務。后臺服務會給 iOS 應用提供豐富的數據和精彩的內容，后臺服務的測試必須要包含在 iOS 測試中。當然，本文主要討論一些 iOS 測試領域的內容，后臺服務的測試在此直接掠過。因此，下文提到的 iOS 測試主要指在 iOS 移動端需要做的測試。
　　iOS 測試需要著重從以下 5 個方面入手：
　　功能測試
　　性能測試
　　穩定性測試
　　兼容性測試
　　電量測試
　　當然，還可能有一些測試類型沒有被歸納進來，這里是從 iOS 測試共性上來歸納的測試類型，還有一些 iOS 應用需要格外注意以下安全性的問題等。
　　功能測試一般會花費測試工程師 7 成以上的精力，每一個新功能點，都需要自己的驗證。老版本功能點也要進行嚴格的回歸。稍有疏忽可能會造成遺漏。當然，功能測試方面不光需要細心，也有很多技巧和經驗，之后的內容會進行重點闡述。
　　性能測試的范圍可大可小，很多公司把穩定性、電量等內容都會算作性能測試的范圍。當然，怎么劃分都是合理的。本文中的性能測試特指 CPU、內存和 I/O 三項指標。CPU 的過度占用說明應用程序存在著一些潛在風險和優化空間，CPU 的過度使用也會損耗大量的電量。內存的持續上漲，說明程序可能存在一定的內存泄露，并且 iOS 系統會對應用內存進行嚴格的限制，一旦超出限制，程序會被系統殺死。I/O 的合理性也需要在測試中觀察，頻繁的 I/O 會導致程序變卡變慢，用戶體驗非常不好，嚴重的甚至會致使用戶失去耐心，造成用戶流失。
　　穩定性測試是檢驗應用程序長期穩定的運行能力。程序頻繁地異常退出非常影響用戶體驗，次數過多會導致用戶無法使用 iOS 應用，這時，用戶可能會刪除應用。一般的穩定性測試會通過一些邊界值和非常規的操作，來驗證應用程序的問題性。穩定性測試也需要探索，因為有時穩定性測試的通過，也不能說明應用程序足夠穩定。
　　兼容性測試又被稱為適配測試，主要由硬件兼容性測試、軟件兼容性測試和數據兼容性測試組成。兼容性測試的目的是要確保應用程序可以在所支持的系統平臺上正常運行，而兼容性測試 iOS 設備的多樣化使得兼容性測試更加地重要。
　　隨著 iOS 設備的硬件不斷更新和用戶越來越多地依賴移動設備，iOS 設備的電量逐漸成為用戶非常關心的問題。如果 iOS 應用由于某些缺陷造成了設備電量的迅速下降，用戶會毫不猶豫刪改應用。由此，電量測試顯得愈發重要。
　　iOS 測試可能遇到的挑戰
　　如果你是一位經驗豐富的測試工程師，但是還沒有接觸過移動應用相關的測試，可能會有這樣的疑問。從 iOS 測試范圍來看，并沒有什么新的測試類型，之前所有的測試也都會做很多的功能測試，關注性能測試、穩定性測試、兼容性測試等，還會遇到什么挑戰？雖然從測試類型上并沒有引入新的測試類型，但是 iOS 相關的特點決定了，iOS 測試的工作量將會是之前軟件測試工作量的好幾倍。具體可能會遇到以下一些挑戰：
　　和時間賽跑。iOS 絕大部分應用只能通過 App Store 發布。所以，開發商都會盡量頻繁地發布自己的應用，并盡可能獲取更多的用戶。每次發布前的測試都不會有特別充分的時間進行特別詳細的測試。所以，iOS 測試工作者必須在測試之前進行分析和選擇，找重點和容易發生錯誤的地方測試。
　　網絡情況異常復雜。在測試一個需要網絡數據的 iOS 應用時，網絡狀態對應用影響非常大，而且網絡狀態還非常多。從網絡數據接入點來劃分可以分為：Wi-Fi 和手機網絡。從網速來進行區分可以分為：弱網絡和強網絡。在這些網絡情況下，程序可能使用不同的網絡策略。弱網絡如果處理不好，會直接影響到用戶感受。如果需要播放一段視頻或音頻文件時，是否需要提示用戶注意一下流量費用等。
　　紛亂復雜的用戶場景。iOS 應用的開發者，完全沒有辦法控制用戶什么時候打開應用，是橫屏還是豎屏使用。更沒有辦法知道，在應用正在被使用時，用戶是否需要接聽一個電話呼入或瀏覽一下短消息；更不會了解到用戶這時是很悠閑地開啟了 iOS 應用還是很急切地打開應用需求幫助。在以上這些復雜的場景中，怎么能保證用戶體驗？而 iOS 應用的功能正常等也都需要測試來論證。
　　非統一化的運行環境。iOS 應用可以運行在 iPhone 上，也可以運行在 iPad 或 iPod 上。雖然 iOS 的用戶有著很好的更新系統的習慣，但依然不能保證 iOS 運行在統一的 ROM 下。兼容性測試的挑戰非常大。
　　發布前的測試
　　針對以上 iOS 測試的一些挑戰，和過去 iOS 測試領域的實踐與總結。我們更傾向于把一個測試過程分為：發布前的場內測試和發布后的用戶測試或用戶反饋。之后的內容主要會圍繞發布前測試和發布后測試兩大部分進行詳細的闡述。
　　功能測試方法闡述
　　在每次發布前的測試，功能測試都是主要的測試內容。測試工程師不但要仔細驗證新功能點的功能是否正常，還要關心之前的老版本功能點是否正常。功能測試雖然工作量很大，但如果有一份比較詳細準確的測試用例作為指導，工作會變得有條不紊一些。所以，本文將詳細闡述一下測試用例的設計方法。
　　傳統測試用例方法
　　傳統的測試用例方法，無非是等價類、邊界值、因果圖分析法和正交分解法等幾大方法。一般測試工程師都會對這幾種方法純熟使用，在此不多贅述。一個功能點，可以根據以上幾個方法產生出正常的功能測試點和異常的功能測試點。但是，移動端有一些特點決定了，傳統的測試用例設計法是不夠用的。比如：測試“大眾點評”App 的“附近的餐廳”功能。隨著位置的變化，看到的餐廳數據可能完全不一樣。再比如，一段音頻的播放功能測試，可能會受到耳機插拔、電話呼入、別的音頻播放等場景的影響，表現出來的結果也完全不一樣。iOS 應用還有很多這樣的場景，所以測試用例設計方法也需要更新一下了。
　　探索式測試方法
　　探索式測試方法是由 Google 測試專家 James A. Whittaker 發明，并為此撰寫了一本《 探索式軟件測試》書籍來詳細介紹其中的一些方法。過去的幾年，國內的測試領域也對該方法有過一些實踐和討論。重要成果是好友高翔所著的《 探索式測試實踐之路》和好友徐毅主持翻譯的《 探索吧！深入理解探索式軟件測試》。
　　在學習探索式測試方法的時候，一定不能著急實踐，應該找本書認真的看，并且做一些學習筆記。當對探索式測試有一個全面的認識以后才可以進行實踐。探索式測試方法分為：全局探索式測試方法和基于場景的混合式探索測試方法。全局探索式測試方法會分為 6 大類測試類型和 23 種測試方法。更加詳細的可以參看下圖。


　　
　　圖 1. 全局探索式測試方法

　　全局探索是用來設計所有的測試點該怎么測試的，但測試點不應該是獨立的，而需要組合才能完成一個完整的功能測試。通過基于場景的混合式測試方法，將之前的功能點混合到一起；趫鼍暗幕旌鲜綔y試方法一些大體的路徑分支可以參看下圖。


　　
　　圖 2. 基于場景的混合式測試方法

　　有經驗的測試工程師會說，這么多組合功能怎么可能測試完成了。是的，測試根本無法完成，探索式測試還強調給測試工程師足夠的自由，哪些需要進行測試，哪些功能不需要進行測試都由測試工程師決定。測試工程師應該測試用例的運行情況來決定具體運行什么樣子的測試用例。當然，探索式測試在國內不太被接受的點也在于給測試工程師太多的自由，團隊中別的成員角色會質疑。
　　我個人認為，探索式測試可以在局部的地方使用，這個局部包含局部的功能點，也包括極個別團隊的測試工程師。很多漏測都是因為想不到有某種場景或某種情況，而探索式測試能幫助我們想到更多的測試場景。