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