測試時最常考慮的參數是範圍 (有時稱為「大小」)。
範圍相對於可測試單位。著重於單一這類單元的測試稱為單元測試，而將數個單元一起練習的測試稱為整合測試。大部分測試也可以在測試金字塔中安排。
單元是由測試作者的觀點任意定義。舉例來說，在物件導向程式設計中，單位通常是類別。在本文件 (通常在 Fuchsia 上) 中，常會提到受測試的單元 (除非另有說明)。
編寫 Fuchsia 的測試時，您可能會想熟悉有關編寫測試的測試原則和最佳做法。
測試範圍
執行不同範圍的測試可互補彼此的優點和缺點。一流的測試可以製定出完善的測試計畫，讓開發人員能自信地做出變更，並快速有效地找出真正的錯誤。
在考慮要編寫的測試類型及各類型的測試時，想像測試安排成金字塔：
許多軟體測試出版社都提倡結合 70% 的單元測試、20% 整合測試、10% 系統測試。基於以下原因，Fchsia 建議在整合測試方面投入更多資源，而不需進行其他類型的測試：
- Fuchsia 著重於軟體構成。Fuchsia 上的應用程式和系統往往會廣泛地界定元件之間的界線。因此，建議您測試這些界線。
- Fuchsia 的元件架構有時可讓您輕鬆在測試中重複使用實際工作環境元件，進而降低開發整合測試的成本。
- Fuchsia 的測試執行階段為整合測試提供與單元測試相同的隔離層級，讓整合測試變得可靠。
- 元件之間的通訊比直接方法呼叫慢許多，但依然很快。一般來說，整合測試的執行速度不會低於人類開發人員可察覺的程度。
- Fuchsia 上已有許多整合測試可做為實用的範例。
如要進一步瞭解 Fuchsia 測試金字塔提供的各種測試，請參閱：
另外還有測試金字塔以外的專屬測試。詳情請參閱特殊測試。
另請參閱：
單元測試
在 Fuchsia 中，在單一元件中完整定義的測試稱為單元測試。
這麼做可避免測試取得非預期的功能、受到測試範圍外的系統狀態影響，以及影響在同一部裝置上同時或依序執行的其他測試。
單元測試是由測試主體中的直接叫用程式碼來控制。舉例來說，audio_effects_example_tests.cc 會在可載入的模組中執行程式碼，實作音效，並驗證程式碼是否正常運作。
在健康的測試金字塔中，單元測試是廣泛的測試基礎，因為單元測試提供最高程度的隔離能力，也是最快的測試，可以產生非常可靠且實用的正面信號 (通過測試) 以及負向信號 (測試失敗，指出實際存在的可行錯誤)。此外，單元測試也會產生最可行的測試涵蓋範圍資訊，並享受其他操作方法，例如搭配衛生器執行時。因此，使用單元測試應符合任何測試需求。
如果只有測試套件的內容會影響測試是否通過，就屬於單元測試。
另請參閱：
整合測試
在 Fuchsia 中，透過單一測試套件傳遞多個元件的測試稱為整合測試。
在健康狀態良好的測試金字塔中，整合測試是單元測試後最常見的測試類型。Fuchsia 的整合測試通常速度快，但速度比單元測試來得快。Fuchsia 的整合測試與系統的其他外部效果隔離，就像單元測試一樣。要定義及驅動整合測試，整合測試比單元測試更複雜。因此，如果單元測試無法滿足任何無法滿足，但可以透過整合測試達成的任何測試需求，就應該透過整合測試滿足。
與其他平台相比，整合測試在 Fuchsia 方面扮演舉足輕重的角色。 這是因為 Fuchsia 建議軟體開發人員將程式碼分解為多個元件，以符合平台的安全性和可更新目標，然後提供完善的跨元件通訊機制，例如 channels 和 FIDL。
測試是由測試運作範圍中的其中一個元件驅動，這個領域也會判斷測試是否通過，並提供額外的診斷資訊。舉例來說，字型伺服器整合測試會測試將 fuchsia.pkg.FontResolver FIDL 通訊協定公開為通訊協定功能的字型解析器元件，然後透過叫用用戶端合約中的方法，驗證預期的回應和狀態轉換，藉此驗證該元件。
整合測試是由測試驅動程式庫控制。測試驅動程式庫會設定一或多個測試中的元件、練習，並觀察結果，例如使用支援的介面和其他合約查詢這些元件的狀態。
在測試領域中，能力轉送通常是使用做為插入依附元件的機制。舉例來說，如果受測的元件依附於測試範圍外的另一個元件提供的能力，則可能會針對不同的元件 (「測試雙重測試」) 或獨立於測試領域內部單獨執行的正式版元件執行個體進行測試。
如果只有測試套件的內容會影響測試是否通過，就屬於整合測試。
另請參閱：
系統測試
在 Fuchsia 中，如果測試的範圍不是單一套件的內容，以及內含一或多個元件中的一或多個元件，則稱為系統測試。這類測試的範圍並非根據元件或套件嚴格定義，範圍可能取決於指定設定內建的整個系統，甚至包括整個系統。
系統測試有時也稱為關鍵使用者歷程 (CUJ) 測試或端對端 (E2E) 測試。有些人可能會認為，如果範圍甚至是單一 Fuchsia 裝置，這類測試屬於 E2E，例如針對遠端伺服器進行測試，或是在特定 Wi-Fi 存取點或其他已連接的硬體中進行測試時。
在健康狀態良好的測試金字塔中，系統測試是金字塔的細小提示，表示系統測試的數量比其他範圍中的測試更少。系統測試和單元測試和整合測試的速度通常遠比單元測試和整合測試慢，因為這類測試包含更多程式碼和依附元件，其中許多依附元件經過隱含定義，而不是明確指出的。系統測試無法進行固有的隔離措施，而且受到較多副作用或意外幹擾，因此所測試的可靠性通常不如其他類型的測試。由於系統測試所產生的程式碼範圍未定義，Fuchsia 的 CI/CQ 不會從 E2E 測試收集測試涵蓋率 (收集涵蓋率會產生不穩定或不穩定的結果)。 掃毒程式不支援 E2E 設定，也基於類似原因。因此，當單元測試或整合測試無法獲得其邊際優勢時，建議您編寫系統測試。
額外測試
Fuchsia 提供多種特殊測試：
核心測試
測試核心需要特別留意，因為牽涉到的獨特需求和限制。核心的測試涵蓋核心介面：系統呼叫、處理權限或信號物件等核心機制、vDSO ABI 和使用者空間開機程序，以及所有重要的實作詳細資料。
大多數核心測試會在使用者空間中執行，並從外部測試核心 API。稱為「核心使用者模式測試」。舉例來說，TimersTest 會測試核心的計時器 API。這類測試比一般測試更難撰寫：只有特定程式設計語言、測試之間的隔離界線較弱、無法同時執行測試、在未重新啟動及重新貼上的情況下無法更新測試，以及其他適用的限制與限制。這些取捨之處可讓測試減少針對執行階段環境的假設，也就是說，即使在最基本的建構設定 (啟動建構作業) 的情況下，即使沒有元件架構或進階網路功能，測試也能執行。
這些測試可在使用者模式下執行，不讓其他程式在使用者模式中執行，有助於找出核心錯誤。
部分核心行為無法從外部測試，因此這些行為會透過編譯至核心映像檔的程式碼進行測試，並在核心空間中執行。這些測試更難撰寫及疑難排解，但具有最多核心內部存取權，甚至可在使用者空間啟動程序中斷時執行。有時這是測試的必要步驟。舉例來說，timer_tests.cc 會測試計時器期限，但無法只從使用者空間執行核心 API 明確測試，因為核心會保留一些「配量」，讓核心保留從使用者空間設定的計時器。
相容性測試
相容性測試 (有時也稱為合規測試) 會擴大正確性，以符合特定規格，並持續遵循該規範。相容性測試會以特定合約條款形式呈現，可針對該合約的多個實作項目執行，以確保任意數量的實作項目都能夠相容。
舉例來說：
- 適用於 Fuchsia (CTF) 的相容性測試是驗證 Fuchsia 系統介面的測試。CTF 測試可針對不同版本的 Fusia 版本執行，以確保相容性和偵測破壞性變更。此後，CTF 測試涵蓋了 Fuchsia SDK 的所有介面。
- FIDL 會使用特定的二進位格式 (或「傳輸格式」) 對不同頻道之間在元件間交換的 FIDL 訊息進行編碼。FIDL 用戶端和伺服器端繫結和程式庫支援多種語言，例如 C、C++、Rust、Dart 和 Go。FIDL 相容性測試和Golden FIDL (GIDL) 測試可確保不同的實作項目與二進位檔相容，因此無論開發人員選擇哪種語言，都能以正確方式相互通訊。
- Fuchsia Inspect 會使用特定二進位格式將診斷資訊編碼。檢查功能以多種語言提供，基礎二進位檔格式可能會隨時間改變。檢查驗證工具測試，確保所有讀取器/寫入器實作之間的二進位檔相容性。
效能測試
效能測試會執行特定工作負載 (例如綜合基準或 CUJ)，並在測試期間評估各項效能指標，例如完成時間或使用資源用量。
效能測試可以確保達到特定門檻 (例如，以 60 FPS 的穩定速率轉譯影格)，也可以單純收集效能資訊並顯示做為結果。
例如：
- 端對端效能測試目錄中可找到許多效能測試和效能測試公用程式。這些目標涵蓋多種目標，例如核心啟動時間、觸控輸入延遲、Flutter 轉譯效能，以及適用於效能敏感程式碼的各種微型基準。
- CPU Performance Monitoring 可讓 CPU 效能計數器進行高頻率低負載效能測試。
- Perfcompare 是一個架構，用來比較指定基準在指定變更前後的結果。很適合用於衡量效能改善或迴歸
- FIDL 基準針對 FIDL 產生的程式碼提供多種大小的基準。
- 網路堆疊基準會使用熱程式碼適用的微型基準測試網路堆疊的效能。
壓力和持續性測試
壓力測試會以極高負載的方式演練系統，但這通常在系統合約內亦預期。其目標是展現系統對壓力的抵抗力，或暴露只在壓力時發生的錯誤。
在壓力測試中，受測試的系統與測試工作負載元件分開。測試工作負載元件可以執行任何所需操作，包括在不使受測試系統的情況下當機。
舉例來說，minfs 壓力測試會對 MinFS 分區重複執行多項作業。測試可驗證作業是否成功、結果是否如預期發生，以及 MinFS 不會當機或出現其他錯誤，例如檔案系統損毀。
刻意長時間練習系統的測試是一種壓力測試的一種，稱為長期測試。在長期測試中，時間長度與系統的負載或壓力有關。舉例來說，假設系統成功完成使用者歷程達 10,000 次的測試就是一項壓力測試，而測試是指系統以循環方式執行同一使用者歷程，持續 20 小時，保持正常運作，回應能力也是一項長期測試。
另請參閱：
模糊
模糊化程式會試圖為受測試的程式碼產生有效互動，進而產生錯誤狀況 (例如當機)。模糊的作業是以虛擬隨機行為為導向，有時透過檢測 (尋找涵蓋新程式碼路徑的輸入內容) 或其他掌握策略 (例如預先產生的字典或機器學習) 執行。
根據經驗，模糊測試工具可找出不重複的高嚴重性錯誤。舉例來說，reader_fuzzer.cc 在「檢查讀取器」程式碼中發現錯誤，該錯誤會導致執行階段異常終止，即使這個程式碼已受大量測試和掃毒程式影響。
另請參閱：