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