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