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