測試策略

自動化測試可以透過多種方式提升應用程式品質。舉例來說，這項工具可協助您執行驗證、偵測回歸情形，以及驗證相容性。良好的測試策略可讓您利用自動化測試，著重在「開發人員工作效率」這項重要優點。

如果團隊使用系統化的方法進行測試，並與基礎架構增強功能搭配使用，團隊的工作效率更高。這樣就能及時針對程式碼的行為提供意見回饋。良好的測試策略應具備下列功能：

• 盡早找出問題。
• 執行速度快。
• 針對需要修正的問題提供明確指示。

本頁面可協助您決定要導入哪種類型的測試、在何處執行測試，以及測試頻率。

測試金字塔

您可以依大小分類現代應用程式中的測試。小型測試只會著重於一小部分的程式碼，因此速度快且可靠。大型測試範圍廣泛，需要更複雜的設定，且難以維護。不過，大型測試有較擬真度*，而且可以一次發現更多問題。

*忠實度：指的是測試執行階段環境與實際工作環境的相似程度。

大多數應用程式都應包含許多小型測試，而大型測試則相對較少。每個類別的測試分佈應形成一個金字塔，其中有數量較多的小型測試形成基礎，而形成小費的大型測試數量較少。

盡可能降低錯誤成本

良好的測試策略能提高開發人員的工作效率，同時盡可能降低發現錯誤的成本。

以下舉例說明可能效率不彰的策略。這裡的按照大小區分的測試數量不會整理為金字塔。端對端測試太多，元件 UI 測試太少：

這表示在合併前執行的測試太少。如果有錯誤，可能要等到每晚或每週執行端對端測試時，才能偵測到。

請務必考量這種做法對識別和修正錯誤的成本有何影響，以及為何應將測試作業調整成規模較小且更頻繁的測試：

• 單元測試偵測到錯誤時，通常只需幾分鐘就能修正，因此成本較低。
• 端對端測試可能需要幾天的時間才會發現相同的錯誤。這可能會吸引多位團隊成員，降低整體工作效率並可能延遲發布版本。這個錯誤的成本較高。

儘管如此，測試策略的成效不如完全沒有策略來得好。如果錯誤在實際工作環境中生效，修正作業需要很長的時間才能傳送至使用者的裝置 (有時需要數週)，因此意見回饋循環時間最長，也最昂貴。

可擴充的測試策略

測試金字塔通常分為 3 種類別：

• 單元測試
• 整合測試
• 端對端測試。

不過，這些概念並沒有明確的定義，因此團隊可能會以不同方式定義類別，例如使用 5 個層級：

• 單元測試會在主機上執行，並驗證單一功能性邏輯單元，且不依附於 Android 架構。
  • 範例：驗證數學函式中是否有誤差 1 的錯誤。
• 元件測試會獨立驗證模組或元件的功能或外觀，不受系統中的其他元件影響。與單元測試不同，元件測試的表面積延伸至個別方法和類別之上的較高抽象層。
  • 範例：自訂按鈕的螢幕截圖測試
• 功能測試會驗證兩個以上獨立元件或模組的互動方式。功能測試規模較大且較複雜，通常會在功能層級運作。
  • 範例：UI 行為測試，可驗證畫面中的狀態管理
• 應用程式測試會以可部署的二進位檔形式，驗證整個應用程式的功能。這些是大型整合測試，使用可偵錯的二進位檔 (例如可包含測試鉤子的開發人員版本) 做為測試系統。
  • 範例：UI 行為測試，用於驗證折疊式裝置的設定變更、本地化和無障礙功能測試
• 候選版本測試可驗證發布子版本的功能。這類測試與應用程式測試類似，差別在於應用程式二進位檔會經過壓縮和最佳化。這些是大型的端對端整合測試，可在最接近實際工作環境的環境中執行，但不會向公開使用者帳戶或公開後端公開應用程式。
  • 範例：關鍵使用者歷程、效能測試

這項分類會考量擬真度、時間、範圍和隔離層級。您可以在多個層級中設定不同類型的測試。舉例來說，應用程式測試層可包含行為、螢幕截圖和效能測試。

	範圍	網路存取權	執行	版本類型	生命週期
單位	具備最低依附元件的單一方法或類別。	否	地區性	可偵錯	合併前
構成要素	模組或元件層級 多個課程一起	否	本機 Robolectric 模擬器	可偵錯	合併前
功能	特徵層級 與其他團隊擁有的元件整合	模擬	本機 Robolectric 模擬器 裝置	可偵錯	預先合併
帶入個人需求	應用程式層級 與其他團隊擁有的功能和/或服務整合	模擬 測試伺服器 正式版伺服器	模擬器 裝置	可偵錯	合併前 合併後
候選版	應用程式層級 與其他團隊擁有的功能和/或服務整合	正式版伺服器	模擬器 裝置	壓縮過的發布子版本	合併後 預先發布

決定測試類別

一般來說，您應考慮使用金字塔最底層的資料，為團隊提供適當層級的意見回饋。

舉例來說，請考慮如何測試這項功能的實作方式：登入流程的 UI。視您需要測試的項目而定，您可以選擇不同的類別：

測試主體	說明要測試的內容	測試類別	測試類型範例
表單驗證器邏輯	這個類別會根據規則運算式驗證電子郵件地址，並檢查是否已輸入密碼欄位。它沒有依附元件。	單元測試	本機 JVM 單元測試
登入表單 UI 行為	表單中含有按鈕，只有在表單通過驗證後才能啟用	元件測試	在 Robolectric 上執行的 UI 行為測試
登入表單 UI 外觀	符合使用者體驗規格的表單	元件測試	Compose 預覽螢幕截圖測試
與驗證管理工具整合	將憑證傳送至驗證管理員，並接收可能包含不同錯誤的回應。	功能測試	使用假資料進行 JVM 測試
登入對話方塊	按下登入按鈕時，畫面上會顯示登入表單。	應用程式測試	在 Robolectric 上執行的 UI 行為測試
關鍵使用者歷程：登入	使用測試帳戶針對測試伺服器的完整登入流程	候選版	在裝置上執行的端對端 Compose UI 行為測試

在某些情況下，某項內容是否屬於某個類別可能會因人而異。測試排名上升或下降可能還有其他原因，例如基礎架構成本、不穩定性和測試時間過長。

請注意，測試類別不會決定測試類型，而且並非所有功能都必須在每個類別中進行測試。

手動測試也可以加入測試策略。通常，QA 團隊會執行候選版本測試，但也可以參與其他階段。例如，在沒有指令碼的情況下，探索性測試功能中的錯誤。

測試基礎架構

測試策略必須搭配基礎架構和工具，才能協助開發人員持續執行測試，並強制執行規則，確保所有測試都能通過。

您可以依範圍分類測試，藉此定義執行測試的時間和位置。以 5 層模型為例：

類別	環境 (where)	觸發條件 (何時)
單位	[Local][4]	每次修訂版本
構成要素	地區性	每個修訂版本
功能	本機和模擬器	合併或提交變更之前
帶入個人需求	本機、模擬器、1 部手機、1 部折疊式手機	合併或提交變更後
候選版	8 款不同手機、1 款折疊式手機、1 款平板電腦	發布前

• 單元和元件測試會在持續整合系統中針對每個新的提交執行，但只針對受影響的模組。
• 在合併或提交變更之前，會先執行所有單元、元件和功能測試。
• 應用程式測試會在合併後執行。
• Release Candidate 測試會在手機、摺疊式裝置和平板電腦上每晚執行。
• 在發布前，「候選」測試會在大量裝置上執行。

當測試次數影響工作效率時，這些規則可能會隨時間變更。舉例來說，如果您將測試移至每晚的週期，雖然可以縮短 CI 建構和測試時間，但也可能延長回饋循環。