測試時最常用的參數是範圍 (或有時稱為「尺寸」)。
範圍是相對於可測試單位的相對基準。著重於單一單元的測試稱為單元測試，而整合多個單元的測試稱為整合測試。大多數的測試也可以在測試金字塔中安排。
測試單位是從測試作者的觀點中任意定義。舉例來說，在物件導向程式設計中，單位通常是類別。除非另有說明，否則在本文件 (通常位於 Fuchsia) 中，通常會提及受測的單元是元件。
撰寫 Fuchsia 測試時，建議您確保熟悉測試原則和編寫測試的最佳做法。
測試範圍
不同範圍的測試互補了彼此的優缺點。多樣化的測試可以建立良好的測試計畫，讓開發人員能更有自信地做出變更，並快速有效地找出實際錯誤。
當您考慮要編寫哪些類型的測試，以及測試的執行數量時，請想像測試以金字塔排列的方式如下：
許多軟體測試出版品皆提倡執行 70% 單元測試、20% 整合測試及 10% 系統測試。Fuchsia 建議在整合測試上投入更多資源，並放棄其他類型的測試，原因如下：
- Fuchsia 注重軟體的組成要素，Fuchsia 的應用程式和系統通常會大幅行使元件之間的界線。因此，建議您測試這些界線。
- Fuchsia 的元件架構可讓您輕鬆在測試中重複使用實際工作環境元件，從而降低開發整合測試的成本。
- Fuchsia 的測試執行階段為整合測試提供與單元測試相同的隔離層級，使整合測試具有可靠的可靠性。
- 元件之間的通訊比直接方法呼叫慢，但速度仍非常快。在人工審查員可察覺的情況下，整合測試的執行速度通常不會低於單元測試。
- Fuchsia 目前有許多整合測試做為實用範例。
如需更多有關福奇亞測試金字塔各種測試的資訊：
此外，我們也有一些特殊測試不在此限，但不在測試金字塔範圍內。詳情請參閱專門測試。
另請參閱：
單元測試
在 Fuchsia 中，在單一元件中完整定義的測試稱為單元測試。
這樣做可避免測試取得非預期的功能、影響測試範圍外的系統狀態，以及影響其他在相同裝置上執行或連續執行的測試。
單元測試是由測試主體中程式碼的直接叫用控管。舉例來說，audio_effects_example_tests.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。相較於一般測試，這類測試更難以編寫：僅支援特定程式設計語言、測試間有強度較低的隔離界線、無法同時執行測試、無法在不重新啟動及回覆的情況下更新測試，並套用其他限制和限制。這些優缺點可讓測試減少對執行階段環境的假設，也就是說，即使在最基本的建構設定 (橋接版本) 中，即使沒有元件架構或進階網路功能，也能執行測試。
您可以執行這些測試，避免其他程式在使用者模式下執行，這有助於找出核心錯誤。
部分核心行為無法從外部進行測試，因此會使用編譯至核心映像檔的程式碼進行測試，並在核心空間中執行。這類測試更難撰寫和疑難排解，但具有核心內部存取權的最多存取權，即使使用者空間啟動程序故障，也可以執行。這有時是測試的必要步驟。舉例來說，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 個影格的一致速率轉譯執行個體影格)，或者只是收集效能資訊，並將其作為結果。
例如：
- 您可以在端對端效能測試目錄中找到許多效能測試和效能測試公用程式。這些內容涵蓋各種目標，例如核心啟動時間、觸控輸入延遲、Flutter 轉譯效能，以及針對效能影響性的程式碼的各種微型基準測試。
- CPU 效能監控可讓 CPU 效能計數器用於高頻率低負載效能測試。
- Perfcompare 是比較特定基準前後特定基準結果的架構。適合用於衡量效能改善或迴歸情形
- FIDL 基準針對 FIDL 產生的程式碼提供多種大小的基準測試。
- 網路堆疊基準會使用熱程式碼的微型基準測試網路堆疊的效能。
壓力和持續性測試
壓力測試會以達到極高負載量的方式訓練系統，但在系統合約中預期會出現其他情況。其目標是展示系統對壓力的抵抗力，或顯示只發生壓力的錯誤。
在壓力測試中，受測試的系統與測試工作負載元件隔離。測試工作負載元件可執行任何需求，包括在不造成測試狀態下的系統停止運作。
例如，分鐘壓力測試會在重複性的 MinFS 分區上執行多項作業。此測試可驗證作業是否成功、觀察到其結果，以及 MinFS 不會當機，或出現檔案系統損毀等錯誤。
刻意長時間運動系統的測試是一種壓力測試，稱為長時間測試。在長期性測試中，時間範圍與系統負載或壓力是固有的。例如，若系統成功通過使用者歷程 10,000 次的測試就是一種壓力測試，而壓力測試是測試系統以循環執行相同的使用者歷程 20 小時，並保持正確且回應速度，也是持續性測試。
另請參閱：
模糊
模糊工具是用來嘗試與受測程式碼產生有效互動的程式，而導致出現錯誤等錯誤狀況。模糊行為是以虛擬行為為導向，有時是透過檢測設備 (尋找涵蓋新程式碼路徑的輸入內容) 或其他知情策略 (例如預先定義的字典或機器學習) 進行導向。
經驗顯示，拼圖人可以找到不重複的高嚴重性錯誤。例如，reader_fuzzer.cc 發現「檢查讀取器程式碼」中的錯誤會導致執行階段當機，即使此程式碼已經通過大量測試和衛生處理。
另請參閱：