iOS 自動化測試：最佳實踐和頂級框架
介紹
iOS 自動化測試涉及測試僅適用於 iOS 裝置的應用程式。通常，測試應用程式需要測試人員瞭解應用程式的目的、技術要求和效能指標，以比較預期行為與實際行為。iOS 系列是一個封閉環境，僅被許可在 Apple 裝置上執行。這使得在整個裝置範圍內測試應用程式變得更容易，而不是可以部署到更大範圍的裝置中的 Android 應用程式。
想要為您的團隊找到合適的自動化測試框架？我們能幫你。
iOS 應用程式需要手動和使用自動化指令碼進行測試。儘管經過深思熟慮的設計，但在任何應用程式中，錯誤都是不可避免的。無論是在 iOS 還是 Android 平臺上，iOS 自動化測試都與測試任何應用程式一樣重要。質量保證活動必須從應用程式生命週期的一開始就執行。在 iOS 應用中，由於裝置是已知的，並且作業系統更新有周密的計劃，因此在這些裝置上進行測試更方便。iOS 應用程式的自動化測試有很多好處。執行自動化測試指令碼有助於節省時間和精力，因為它允許一個測試在多個裝置上並行執行。
iOS自動化測試是如何實現的？
iOS 應用程式不僅需要測試其功能，還需要測試其 UI/UX 設計。測試用例必須應用於各種 iDevices - viz、iPhone、iPad、iPad mini、iPad Pro、Apple Watch、Apple TV、iMac（各種螢幕尺寸）、iPod Touch、Macbooks 等 - 以確保 UI/ UX 正在各種解析度的裝置上按預期實施。除了在將部署應用程式的裝置陣列上進行測試之外，作為測試人員，您還需要從各個角度測試應用程式。其他一些必不可少的測試型別包括單元測試、功能測試、視覺化 UI 測試以及端到端測試。讓我們花點時間來看看每種型別的測試：
-
單元測試
單元測試通常由開發人員自己進行。執行單元測試以確認任何特定部分的原始碼是否按照要求獨立執行。此測試是在開發人員將其工作合併到應用程式的原始碼後開發的一段程式碼上單獨完成的。執行單元測試最常見的框架是 Apple 的 XCTest，它在 XCode 開發環境中可用，它也提供 iOS 自動化測試功能。 -
功能測試
在不瞭解原始碼的情況下徹底測試所有功能的過程稱為功能測試。在 iOS 裝置上，我們需要了解觸覺功能，例如軟觸控、3D 觸控、敲擊、搖晃和旋轉等。 在各種相容裝置上對 iOS 應用程式進行功能測試時需要考慮這些輸入.這些測試用例可以手動編寫，然後自動寫入自動化測試指令碼，以便可以在應用程式的每個版本釋出中測試功能，也可以作為迴歸測試的一部分。KIF (Keep It Functional)、XCode UI Test、EarlGrey 和 Calabash 是 Apple 支援的一些用於功能測試的 iOS 自動化測試工具。我們將在文章中進一步瞭解這些工具。 -
UI/UX 測試
iOS 測試中最重要的部分之一是使用者介面和體驗。執行以下操作時，應用程式的使用者介面必須按預期執行。我們可以將 UI 測試的不同方面分類為：
輸入：輸入包括軟觸控、滾動、長觸控/3D 觸控和按鈕。這些輸入中的每一個都將執行需要仔細測試的特定功能。螢幕上的按鈕的大小、位置、顏色和字型可能不同。
螢幕：必須在其相容裝置上測試應用程式的螢幕方向。螢幕 UI 測試還必須包括根據裝置的螢幕解析度變化和適應性。
軟鍵盤：隱藏或使用包含表情符號和符號選項卡的鍵盤的選項對於包含和測試很重要。
硬鍵：一些應用程式還與物理按鈕相關聯，例如電源、主頁和音量按鈕。這些硬鍵在 UI/UX 測試中發揮著重要作用，因為它們為使用者提供了可訪問性和舒適度。
列表：與安卓系統不同，iOS 處理彈出視窗的方式不同。在 iOS 應用程式中，需要選擇選項而不是彈出視窗時會顯示列表。
測試iOSUI/UX與測試 Android 應用程式中的UI/UX有很大不同。由於 Apple 的封閉生態系統，其裝置的行為和期望是有限的，這使得測試過程可預測。
可以通過使用 XCUITest 來為 iOS 應用程式自動進行 UI/UX 測試，XCUITest 直接嵌入 Xcode 和 IDE 環境中，並且僅限於 Objective C 或 Swift 語言，或者利用 Appium 自動化框架允許靈活地使用程式語言和其他工具您認為適合您的 iOS 自動化測試。 -
迴歸和端到端測試
iOS 應用程式經歷了多次更改、錯誤修復和版本釋出。在應用程式的整個生命週期中，引入到應用程式的更改可能會影響應用程式的現有功能。出於這個原因，測試人員必須執行迴歸測試，以確保現有功能按預期工作，儘管進行了更改。必須在應用程式的每個版本釋出期間執行迴歸測試。一般來說，由於這些測試場景的重複性，QA 團隊更願意自動化這些測試場景。自動化它們可以節省 QA 團隊、時間和精力，使他們能夠專注於編寫和自動化測試用例，以應對將成為下一版本回歸測試套件一部分的新更改。
另一方面，我們有端到端的測試，從頭到尾對應用程式堆疊進行完整的測試。在這裡，我們模擬了從前端 UI/UX 到後端伺服器功能和其他網路相關方面的整個使用者體驗。它是整合測試的一部分，我們可以在其中測試所有功能是否如預期的那樣相互協同工作。在此類情況下，如果在實際裝置或所有相容裝置上進行測試不可行，則使用模擬器來自動化端到端測試場景。但是，最佳做法是在真實裝置上執行迴歸和端到端測試，因為它提高了測試的信心，就好像裝置在使用者手中一樣。通過利用上面提到的 iOS 自動化測試框架（稍後將討論），
iOS自動化測試面臨的挑戰
在開發 iOS 應用程式時，釋出時間緊迫並不少見。這讓 QA 團隊有更少的時間來整合應用程式執行的眾多功能或建立新的測試指令碼。
隨著人臉 ID 和指紋認證方法的引入，大多數測試用例的自動化變得更加困難。在這種情況下，人工干預被認為是必要的。需要專業知識的動態運營商網路條件和相關後臺流程的環境自動化可能很困難。
自動化 iOS 應用程式測試面臨的其他一些挑戰包括由於時間不足而對測試程式碼進行故障排除和除錯。缺乏足夠的移動測試實驗室也很困難。
最重要的是，與為 Web 應用程式提供的各種框架和解決方案相比，用於 iOS 自動化測試和一般移動應用程式測試的自動化框架解決方案是最少的。
iOS 測試最佳實踐
模擬器/模擬器上的真實裝置：
在 UI/UX 測試方面，我們需要在所有相容裝置上測試應用程式，但在所有裝置上執行測試可能會非常昂貴。這是模擬器或模擬器發揮作用的地方。除了成本之外，還有一步一步除錯應用程式的問題，這在使用真實裝置進行測試時並不容易發現。
相反，使用真實裝置進行測試的處理速度可能比使用模擬器/模擬器工作要快。可靠性在這裡也起著重要作用。與模擬器/模擬器相比，真實裝置可能更可靠，因為模擬各種使用者互動可能很乏味。
儘管模擬器和模擬器很容易啟動，但它們無法完全捕捉裝置電池或儲存電量低或流量被呼叫或通知中斷的情況。在這種情況下，使用真實裝置進行手動測試會更令人滿意。此外，如上所述，在執行迴歸和端到端測試以儘可能接近地模擬使用者的操作時，真實裝置更可取。
豐富的報告和溝通：
在應用程式測試方面，為每個步驟或操作擷取螢幕截圖或記錄螢幕對於除錯和理解應用程式的實際行為至關重要。在 iOS 裝置上，可以通過在舊裝置上同時按下電源和主頁按鈕並在最新裝置上按下電源和音量增大按鈕來手動擷取螢幕截圖。錄屏，我們可以使用QuickTime來錄製iOS裝置的螢幕，前提是它使用避雷線連線到Mac機。一些工具提供自動截圖和螢幕錄製，例如 fastlane，它使用 XCUITest 進行截圖。此外，還有一些iOS自動化測試框架可以在您的自動化和測試工作期間提供豐富的報告和通訊。
崩潰和控制檯日誌：
崩潰日誌用於瞭解應用程式失敗時的根本原因。在這種情況下，您需要捕獲崩潰日誌。可以採取以下步驟來捕獲崩潰日誌：
-
將 iOS 裝置與 Mac 機（iMac 或 Macbook）連線。
-
按住 Option (⌥) 鍵開啟選單欄。
-
在選單下，導航到 Library/Logs/CrashReporter/MobileDevice
-
您將在此處找到 iOS 裝置的名稱。單擊資料夾。
-
您可以在此處找到以您的 AUT（被測應用程式）的名稱開頭的日誌。
另一方面，控制檯日誌顯示 iOS 裝置上 AUT（被測應用程式）的完整資訊。要檢視控制檯日誌，您需要使用 iTools 應用程式。下載應用程式後，將裝置連線到執行 iTools 應用程式的系統，然後單擊工具箱圖示。最後一步是單擊顯示控制檯日誌的實時日誌按鈕。
iOS 自動化測試框架中的 SetUp 和 TearDown 方法：
在XCTest、Appium等一些框架中，我們可以根據自己的測試需求使用SetUp和TearDown方法自定義測試用例的狀態。
setUp()：此方法可用於在執行特定測試方法之前設定每個測試用例的初始狀態。
tearDown()：這個方法可以用於在每個測試用例或測試方法完成後進行清理。
這些方法對於使用一些常見測試框架來避免由於快取導致的測試失敗的有效 iOS 自動化測試至關重要。
頂級 iOS 自動化框架
-
Appium
由開創性的 Web 應用程式自動化框架 Selenium 建立，Appium 是移動應用程式自動化框架。由於在同一個家族中，Appium 使用相同的 Selenium WebDriver 和 HTTP 協議流程來自動化移動應用程式，包括 iOS 應用程式。它是一個開源平臺，不受程式語言的限制，您可以使用大多數常用語言測試應用程式，例如 Java、C#、Python、Ruby 等。此外，Appium 可以與幫助促進移動應用程式自動化所需的任何其他框架或工具。因此，Appium 提供了一種靈活的方式來設定您認為合適的測試需求。
Appium 的主要優勢之一是它適用於任何型別的移動應用程式，包括 Web、本機和混合應用程式，這意味著我們可以在 iOS 和 Android 裝置上使用相同的 Appium 程式碼。 -
XCTest/XCUITest
XCTest 是 Apple 的官方測試框架，用於執行單元測試。XCUITest 是一個 UI 測試框架，它構建在 XCTest 框架之上，幷包括輔助 UI 測試的補充類，例如 UIAccessibility。這兩個框架都可以用 Objective C 或 Swift 編寫。由於它是 iOS 裝置原生的，它不需要任何支援軟體或包來在 AUT（被測應用程式）上執行測試。
XCTest/XCUITest 比 iOS 應用程式的其他自動化框架更快。XCTest 不需要額外的抽象 API 層，因此是輕量級的。如果您決定使用 XCTest 作為自動化框架，則 XCode 測試記錄器是另一種選擇。使用測試記錄器，可以更輕鬆地執行 UI 測試場景，因為我們可以記錄和回放執行的 UI 測試 -
EarlGrey
Google 提出了自己的、開源的、靈活的內部 UI 測試框架，名為 EarlGrey。它具有獨特的優勢，例如： -
與 UI、網路請求和執行緒的同步功能。
-
類似使用者的互動是可以執行滑動和點選的應用程式級觸控事件。
-
可見性檢查在執行測試指令碼之前檢查元素是否可見。
-
Calabash
Calabash 也是一個開源框架，可以在 iOS 和 Android 平臺上進行測試。要在 Calabash 中自動化測試用例，測試用例必須用 Cucumber 編寫。Cucumber 是一種行為驅動開發框架，它使用 Gherkin 語言以“Given, When, Then”格式編寫測試場景，使業務分析師和利益相關者更容易理解測試場景，而無需要求他們具備任何技術編碼知識。Calabash 可以與本機和混合應用程式互動。它包含各種有益的功能，例如螢幕截圖記錄功能和手勢。 -
Detox
Detox 是一款專門用於端到端、UI 自動化測試需求的工具。它支援 JavaScript，旨在作為一個更容易學習的灰盒測試框架。排毒的一些優點是： -
它通過監視 UI 中的非同步元素來幫助減少應用程式的脆弱性。它像在生產中一樣執行測試用例。
-
如前所述，Detox 是一種灰盒測試工具，可以從移動應用程式訪問原始碼，因此它比 XCTest/XCUITest 之外的其他第三方 iOS 自動化框架更快
-
它在持續整合管道中執行。
-
OCMock
該框架用於在 iOS AUT 中建立存根物件。它可以通過靜態庫實現來開發 iOS 應用程式或作為用於 OS X 開發的框架。其優勢包括：
-
它使用 Objective-C，因此大多數 iOS 應用程式開發人員也可以開發測試用例。
-
它也是一個開源框架。
-
通過向單元測試新增模擬物件，它很容易使用。
-
KIF (Keep It Functional)
像大多數 iOS 自動化測試框架一樣，KIF 是一個開源工具。它是一個 iOS 原生應用程式，開發人員需要將 KIF 框架新增到專案中。下面列出了 KIF 的一些主要優點： -
語法易於理解和直觀。
-
它使用目標 C。
-
在 CI 管道的命令列上執行良好。
-
它可以毫不費力地與 XCode 工作流程整合。
-
它不需要任何外部依賴項，許多其他測試框架都這樣做。
結論
在 iOS 應用程式上執行 iOS 自動化測試既有趣又具有挑戰性。如上所述，要跟上已經取代古老的 PIN 和密碼身份驗證方法的先進技術（例如面容 ID 和指紋身份驗證）可能會很費勁。這並不容易，考慮到定期發生的有時間限制的 OS 版本升級，但幸運的是，這些升級是精心策劃的。
總而言之，對於開發和 QA 團隊來說，提出最佳實踐以準備好應對可能出現的任何挑戰至關重要。瞭解何時使用模擬器/模擬器以及何時需要對真實裝置進行測試非常重要。我們需要利用螢幕捕獲和記錄工具以及崩潰和控制檯日誌來跟蹤測試用例的步驟並瞭解可能出現的潛在 UI 問題，以便及時修復它們。
既然我們已經討論了測試 iOS 應用程式的概述，很明顯，為您的專案團隊選擇正確的自動化框架、正確的補充工具和方法以及測試裝置（模擬器/模擬器/存根）對於成功測試至關重要應用程式。根據您團隊的技能組合，選擇最佳框架來測試您的 iOS 應用程式。