測試是應用程式開發流程中不可或缺的一環。您通常會在模擬器或裝置上執行應用程式，手動驗證程式碼是否能正常運作。不過，手動測試相當耗時、容易出錯，而且在各種螢幕和裝置上執行的應用程式通常無法管理。手動測試的問題通常是因為開發時使用單一裝置。因此，在其他板型規格的裝置上可能會發生未察覺的錯誤。
如要找出不同視窗和螢幕大小的迴歸問題，請實作自動化測試，驗證不同板型規格的應用程式行為和外觀是否一致。自動化測試可及早找出問題，降低影響使用者體驗的問題風險。
要測試哪些項目？
開發不同螢幕和視窗大小的 UI 時，請特別留意以下兩個方面：
- 元件和版面配置在不同大小的視窗中，視覺屬性有何不同
- 如何在設定變更後保留狀態
視覺屬性
無論您是否為不同視窗大小自訂 UI，都應確認 UI 是否正確顯示。請考量精簡、中等和展開的寬度和高度。如要瞭解建議的中斷點，請參閱「視窗大小類別」。
此外，當大小限制拉長時，應用程式可能無法如預期顯示設計系統中的某些元件。
如果應用程式針對不同視窗大小提供自動調整式版面配置，則應進行自動化測試，以防回歸。舉例來說，在手機上固定邊距可能會導致平板電腦上的版面配置不一致。建立 UI 測試，以驗證版面配置和元件的行為，或建構螢幕截圖測試，以便視覺化驗證版面配置。
狀態還原
在平板電腦等裝置上執行的應用程式，其旋轉和調整大小的頻率遠高於手機上的應用程式。此外，折疊式裝置還會引進新的顯示功能，例如折疊和展開，這類功能可觸發設定變更。在發生這些設定變更時，應用程式必須能夠還原狀態。接著，您也需要編寫測試，確認應用程式是否正確還原狀態。
首先，請測試應用程式在發生設定變更時不會當機。確保應用程式中的每個 UI 都能處理旋轉、調整大小或折疊的任何組合。由於設定變更預設為重新建立活動，因此某些當機情形是基於假設活動持續性而發生。
測試設定變更的方式有很多種，但在大多數情況下，有兩種測試方式：
- 在 Compose 中，使用
StateRestorationTester以有效率的方式模擬設定變更，而無須重新啟動活動。詳情請參閱下文。 - 在任何 UI 測試 (例如 Espresso 或 Compose) 中，呼叫
Activity.recreate()模擬設定變更。
您通常不需要使用不同的裝置來測試狀態還原來回應設定變更。這是因為所有重新建立活動的設定變更，都會有類似的執行結果。不過，某些設定變更可能會在特定裝置上觸發不同的狀態還原機制。
舉例來說，當使用者在開啟的折疊式裝置上查看清單/詳細資料 UI，然後折疊裝置並切換至封面螢幕時，UI 通常會切換至詳細資料頁面。自動化測試應涵蓋有關 UI 狀態還原作業的內容，包括導覽狀態。
如要測試裝置從一個螢幕轉到其他螢幕，或進入多視窗模式時會發生的設定變更，可以採用多個選項：
- 使用任何裝置，在測試期間調整螢幕大小。在大多數情況下，這會觸發您需要驗證的所有狀態還原機制。不過，這項測試不適用於偵測折疊式裝置特定姿態的邏輯，因為姿態變更不會觸發設定變更。
- 使用支援您要測試的功能的裝置或模擬器，觸發相關設定變更。舉例來說，您可以使用 Espresso 裝置控制摺疊式裝置或平板電腦，從摺疊式裝置改為橫向開啟的平板。請參閱用來測試不同螢幕大小的程式庫和工具中 Espresso 裝置一節的範例。
不同螢幕和視窗大小的測試類型
針對每個用途使用適當類型，確認不同板型規格的測試都能正常運作：
UI 行為測試會啟動應用程式 UI 的部分內容，例如活動的顯示畫面。這些測試會驗證特定元素是否存在或具有特定屬性。測試可能會選擇性執行模擬的使用者動作。如要使用檢視區塊，請使用 Espresso。Jetpack Compose 有自己的測試 API。UI 行為測試可以檢測或本機。設備測試會在裝置或模擬器上執行，本機 UI 測試則是在 JVM 上的 Robolectric 上執行。
使用 UI 行為測試，驗證應用程式導覽功能的實作方式是否正確。這些測試會執行點擊和滑動等動作。UI 行為測試也會檢查特定元素或屬性的存在情形。詳情請參閱「自動化 UI 測試」。
螢幕截圖測試會擷取 UI 或元件的螢幕截圖，並將圖片與先前核准的螢幕截圖進行比較。單張螢幕截圖可以涵蓋大量元素及其視覺屬性，因此是防範迴歸的有效方法。您可以在 JVM 或裝置上執行螢幕截圖測試。您可以使用多種螢幕截圖測試架構。詳情請參閱「螢幕截圖測試」。
最後，您可能需要單元測試來測試邏輯單元功能，其行為會因裝置類型或視窗大小而有不同，但單元測試在這個領域中較不常見。
後續步驟
如要進一步瞭解如何實作本文中的檢查，請參閱程式庫和工具。