最常用於測試的參數是範圍 (有時稱為「大小」)。
範圍是相對於可測試的單元。專注於單一單元的測試稱為單元測試，而同時測試多個單元的測試則稱為整合測試。大部分的測試也可以排列在測試金字塔中。
測試作者可視情況自行定義測試單位。舉例來說，在物件導向程式設計中，單位通常是類別。在本文件中，以及在 Fuchsia 中，除非另有說明，否則經常會提到測試中的單位是元件。
編寫 Fuchsia 測試時，請務必熟悉測試原則和編寫測試的最佳做法。
測試範圍
不同範圍的測試可互補彼此的優缺點。妥善搭配各種測試，就能建立出色的測試計畫，讓開發人員安心進行變更，並快速有效地找出實際的錯誤。
在考慮要撰寫哪些類型的測試，以及每個類型的測試數量時，請將測試設想為金字塔的排列方式：
許多軟體測試出版品都建議採用 70% 單元測試、20% 整合測試和 10% 系統測試的組合。基於以下原因，Fuchsia 建議您將資源投入整合測試，而非其他類型的測試：
- Fuchsia 強調軟體的元件化。Fuchsia 上的應用程式和系統通常會大量使用元件之間的邊界。因此，建議您測試這些邊界。
- Fuchsia 的元件架構可讓您在測試中重複使用實際元件，有時甚至可以輕鬆做到這點，進而降低開發整合測試的成本。
- Fuchsia 的測試執行階段為整合測試提供與單元測試相同程度的隔離，可讓整合測試更加可靠。
- 元件之間的通訊速度比直接方法呼叫慢上許多，但仍相當快速。整合測試通常不會比單元測試執行得慢，至少不會讓開發人員察覺。
- Fuchsia 上已有許多整合測試可做為實用範例。
如要進一步瞭解 Fuchsia 中測試金字塔的各種測試，請參閱以下資源：
還有一些專門的測試不在測試金字塔範圍內。詳情請參閱「專門測試」。
另請參閱：
單元測試
在 Fuchsia 上，在單一元件中完整定義的測試稱為單元測試。
單元測試可在隔離的 這可避免測試取得非預期的功能、受到測試預期範圍以外的系統狀態影響，以及影響在同一裝置上並行或依序執行的其他測試。
單元測試會透過直接在測試主體中呼叫程式碼來控制。舉例來說，audio_effects_example_test.cc 會在可載入的模組中執行程式碼，實作音效效果並驗證程式碼是否運作。
在健全的測試金字塔中，單元測試是測試的廣泛基礎，因為單元測試可提供最高程度的隔離，且是速度最快的測試，進而產生非常可靠且實用的正面信號 (測試通過) 和負面信號 (測試失敗，且有可採取行動的錯誤，表示實際缺失)。單元測試也會產生最實用的測試涵蓋率資訊，並享有其他額外好處，例如與消毒器搭配執行時。因此，任何可透過單元測試滿足的測試需求，都應透過單元測試滿足。
如果只有測試套件的內容會影響測試通過或失敗，則稱為密封的單元測試。
另請參閱：
整合測試
在 Fuchsia 上，跨越多個元件且在單一測試套件中提供的測試稱為整合測試。
在健全的測試金字塔中，整合測試是繼單元測試後最常見的測試類型。Fuchsia 上的整合測試通常很快，但不如單元測試那麼快。在 Fuchsia 上執行的整合測試與單元測試一樣，會與系統其他部分的外部效果隔離。整合測試的定義和驅動方式比單元測試複雜。因此，如果單元測試無法滿足任何測試需求，但整合測試可以滿足，則應使用整合測試。
與其他平台相比，整合測試在 Fuchsia 上扮演著更重要的角色。這是因為 Fuchsia 鼓勵軟體開發人員將程式碼分解為多個元件，以符合平台的安全性和可更新性目標，然後提供穩健的元件間通訊機制，例如管道和 FIDL。
在整合測試中，系統會建立一個與單元測試類似的 realm，但會在該領域中布建多個元件，並彼此互動。測試由測試領域中的其中一個元件驅動，該元件也會決定測試是否通過或失敗，並提供其他診斷資訊。舉例來說，字型伺服器整合測試會測試字型解析器元件，該元件會將 fuchsia.pkg.FontResolver FIDL 通訊協定公開為通訊協定功能，然後透過在其與用戶端的契約中叫用方法，以及驗證預期的回應和狀態轉換，驗證該元件。
整合測試由測試驅動程式庫控制。測試驅動程式庫會設定一或多個測試元件、執行測試，並觀察結果，例如使用支援的介面和其他合約查詢這些元件的狀態。
在測試領域中，標準在測試領域中，能力轉送通常會用作依附元件插入的機制。舉例來說，如果測試中的元件依附於由測試範圍以外的其他元件提供的能力，則可針對不同的元件 (「測試雙重」) 或實際元件的個別例項進行測試，這些例項會在測試領域中獨立執行。
如果只有測試套件的內容會影響測試通過或失敗，則稱為密封整合測試。
另請參閱：
- 複雜的拓樸和整合測試：如何以靜態方式定義包含多個元件和路由功能的測試領域。
- Realm 建構工具：整合測試輔助程式庫，可在個別測試案例中執行時建構測試 Realm 和模擬元件。
系統測試
在 Fuchsia 上，如果測試範圍不限於單一套件的內容，以及其中包含的一或多個元件，則稱為系統測試。這類測試的範圍並未以元件或套件嚴格定義，且可能涵蓋在特定設定中建構的整個系統。
系統測試有時也稱為關鍵使用者旅程 (CUJ) 測試或端對端 (E2E) 測試。有些人可能會說，如果測試範圍比單一 Fuchsia 裝置更廣泛，例如針對遠端伺服器進行測試，或是在特定 Wi-Fi 存取點或其他已連結的硬體上進行測試，這類測試就是 E2E 測試。
在健全的測試金字塔中，系統測試是金字塔的狹窄尖端，表示系統測試的數量少於其他範圍的測試。系統測試通常比單元測試和整合測試慢得多，因為它會運作更多程式碼，且有更多依附元件，其中許多是隱含定義，而非明確陳述。系統測試無法提供內在的隔離程度，且會受到更多副作用或非預期的干擾，因此通常不如其他類型的測試可靠。由於系統測試執行的程式碼範圍未定義，Fuchsia 的 CI/CQ 不會收集 E2E 測試的測試涵蓋率 (收集涵蓋率會產生不穩定或不穩定的結果)。由於類似原因，消毒工具不支援 E2E 設定。因此，如果單元測試或整合測試無法獲得邊際效益，您就應編寫系統測試。
額外測試
Fuchsia 提供多種專門測試：
核心測試
由於涉及的特殊需求和限制，因此測試核心時必須特別留意。核心測試涵蓋核心的表面：系統呼叫、核心機制 (例如句柄權限或信號傳送物件)、vDSO ABI 和使用者空間引導程序，以及任何重要的實作詳細資料。
大多數的核心測試會在使用者空間中執行，並從外部測試核心 API。這些稱為「核心使用者模式測試」。舉例來說，TimersTest 會測試核心的計時器 API。這些測試比一般測試更難編寫：只支援特定程式設計語言、測試之間的隔離邊界較弱、無法平行執行測試、必須重新啟動和重新鋪排才能更新測試，以及適用其他限制。透過這些權衡，測試就能減少對執行階段環境的假設，也就是說，即使沒有元件架構或進階網路功能，也能執行測試，前提是使用最基本的建構設定 (bringup 建構)。這些測試已內建於
您可以執行這些測試，讓沒有其他程式在使用者模式下執行，這有助於隔離核心錯誤。
某些核心行為無法從外部測試，因此我們會使用編譯至核心映像檔並在核心空間執行的程式碼進行測試。這些測試的編寫和疑難排解作業更加困難，但可提供對核心內部最完整的存取權，即使使用者空間的引導程序發生故障，也能執行這些測試。有時這項操作對於測試來說是必要的。舉例來說，timer_tests.cc 會測試計時器期限，但如果只從使用者空間執行核心 API，就無法準確測試，因為核心會保留一些slack，以便合併從使用者空間設定的計時器。
相容性測試
相容性測試 (有時也稱為相容性測試) 會將正確性的概念擴展至符合特定規格，並隨著時間的推移而遵循該規格。相容性測試會以特定合約條款表示，並可針對該合約的多個實作項目執行，確保任何實作項目皆相容。
例如：
- Fuchsia 相容性測試 (CTF) 是用來驗證 Fuchsia 系統介面的測試。CTF 測試可針對不同的 Fuchsia 版本執行，確保這些版本維持相容性，或偵測重大變更。隨著時間推移，CTF 測試將涵蓋 Fuchsia SDK 的完整介面。
- FIDL 會使用特定的二進位格式 (或線路格式)，對透過管道在元件之間交換的 FIDL 訊息進行編碼。許多語言 (例如 C、C++、Rust、Dart 和 Go) 都提供 FIDL 用戶端和伺服器端繫結和程式庫。FIDL 相容性測試和黃金 FIDL (GIDL) 測試可確保不同實作項目具有二進位相容性，因此無論開發人員選擇哪種程式設計語言，用戶端和伺服器都能正確且一致地互相通訊。
- Fuchsia Inspect 會使用特定的二進位格式來編碼診斷資訊。檢查工具提供多種語言，且基礎的二進位格式可能會隨著時間改變。檢查驗證工具測試：確保所有讀取器/寫入器實作之間的二進位相容性。
效能測試
效能測試會執行特定工作負載 (例如綜合基準或 CUJ)，並評估效能指標，例如完成時間或測試期間的資源使用情形。
效能測試可能會確保達到特定門檻 (例如以 60 FPS 的一致速率算繪影格)，或是只收集效能資訊並以結果呈現。
例如：
- 您可以在端對端效能測試目錄中找到許多效能測試和效能測試公用程式。這些測試涵蓋多種目標，例如核心啟動時間、觸控輸入延遲時間、Flutter 算繪效能，以及效能敏感程式的各種微型基準測試。
- CPU 效能監控可提供 CPU 效能計數器，用於高頻率低負載效能測試。
- Perfcompare 是一個架構，可比較特定變更前後特定基準的結果。這項指標可用於評估效能改善或回歸情形。
- FIDL 基準測試針對 FIDL 產生的程式碼提供各種大小的基準測試。
- 網路堆疊基準測試會使用熱門程式的微基準測試，測試網路堆疊的效能。
壓力和耐久性測試
壓力測試會以異常高負載的方式運作系統，但在系統合約中，這類情況是預期的。其目的是展示系統對壓力的復原力，或找出只有在壓力下才會發生的錯誤。
在壓力測試中，測試系統會與測試工作負載元件隔離。測試工作負載元件可以執行任何操作，包括在未導致測試系統中斷的情況下發生當機。
舉例來說，minfs 壓力測試會重複執行許多 MinFS 分區作業。這項測試可驗證作業是否成功、結果是否符合預期，以及 MinFS 是否會當機或顯示錯誤 (例如檔案系統損毀)。
有意讓系統長時間運作的測試是一種壓力測試，稱為壽命測試。在耐久性測試中，時間範圍是系統負載或壓力的內在因素。舉例來說，如果系統成功完成 10,000 次使用者歷程，就是壓力測試；如果系統在 20 小時內循環執行相同的使用者歷程，且持續正常運作並回應，就是耐久性測試。
另請參閱：
模糊測試
Fuzzer 是一種程式，會嘗試與測試中的程式碼產生有效互動，進而導致錯誤狀態 (例如當機)。模糊測試是由偽隨機行為引導，有時也會透過檢測 (尋找涵蓋新程式碼路徑的輸入內容) 或其他資訊策略 (例如預先產生的字典或機器學習) 進行。
經驗證明，模糊測試器可以找出獨特且嚴重程度高的錯誤。舉例來說，即使 reader_fuzzer.cc 已接受大量測試和消毒程序，但在 Inspect 讀取器程式碼中仍發現會導致執行階段當機的錯誤。
另請參閱：