測試策略

自動化測試有助於從多方面提升應用程式品質。舉例來說，這有助於執行驗證、找出回歸問題，以及驗證相容性。良好的測試策略可讓您善用自動化測試，專注於一項重要優勢：提升開發人員生產力。

團隊採用系統化測試方法，並搭配基礎架構強化功能，可大幅提升生產力。這樣做可及時提供程式碼行為的意見回饋。理想的測試策略應符合下列條件：

• 盡早發現問題。
• 執行速度快。
• 清楚指出需要修正的項目。

本頁面將協助您決定要導入的測試類型、執行測試的位置和頻率。

測試金字塔

您可以在現代應用程式中依大小分類測試。小型測試只會著重於一小段程式碼，因此速度快且可靠。大型測試的範圍很廣，需要較為複雜的設定，因此難以維護。不過，大型測試的準確度較高*，一次就能發現更多問題。

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

大多數應用程式應進行許多小型測試，大型測試則相對較少。各類別的測試分配應形成金字塔，數量較多的小型測試構成底部，數量較少的大型測試則構成頂端。

將錯誤的成本降至最低

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

舉例來說，以下策略可能效率不彰。在此，測試數量並未依大小排列成金字塔。有太多大型端對端測試，但元件 UI 測試太少：

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

請務必考量這對找出及修正錯誤的成本有何影響，以及為何應將測試工作重心放在較小且更頻繁的測試：

• 如果單元測試發現錯誤，通常幾分鐘內就能修正，因此成本很低。
• 端對端測試可能需要數天才能發現相同錯誤。這可能會吸引多位團隊成員，降低整體生產力，並可能延遲發布。這個錯誤的成本較高。

不過，低效率的測試策略仍勝過完全沒有策略。 如果錯誤進入正式版，修正檔需要很長時間才能在使用者裝置上發布 (有時甚至需要數週)，因此意見回饋循環最長，成本也最高。

可擴充的測試策略

傳統上，測試金字塔分為 3 類：

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

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

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

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

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

決定測試類別

一般來說，您應考慮金字塔最底層，因為這層可為團隊提供適當程度的回饋。

舉例來說，請考慮如何測試這項功能的實作項目：登入流程的 UI。請根據要測試的項目，選擇不同類別：

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

在某些情況下，某項內容屬於哪個類別可能較為主觀。測試升級或降級的原因可能不只一個，例如基礎架構成本、不穩定性，以及測試時間過長。

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

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

測試基礎架構

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

您可以依範圍將測試分類，定義何時何地要執行哪些測試。舉例來說，如果採用 5 層模型：

類別	環境 (地點)	觸發條件 (時間)
單位	[Local][4]	每個提交
構成要素	地區性	每個提交
功能	本機和模擬器	合併前，也就是合併或提交變更前
帶入個人需求	本機、模擬器、1 支手機、1 支折疊式手機	合併後，在合併或提交變更後
候選版本	8 支手機、1 支折疊式手機、1 部平板電腦	發布前

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

當測試次數影響生產力時，這些規則可能會隨時間變更。 舉例來說，如果將測試移至每晚的節奏，您可能會縮短 CI 建構和測試時間，但同時也可能延長意見回饋迴路。