樹狀結構元件測試支援

  • 專案負責人：shayba@google.com、crjohns@google.com
  • 領域：測試

問題陳述

缺少測試用的平台介面

以 Fuchsia 為目標的軟體開發人員可以編寫元件、建構及測試元件。不過，這些重要的開發人員歷程僅針對樹狀結構內開發人員進行全面且持續的測試，完全不適用於樹狀結構外開發人員。

目前有許多團隊在樹狀結構外開發及測試元件。我們有時會將這些團隊稱為「合作夥伴」，因為 Fuchsia 團隊與他們保持密切互動。由於下列原因，這項安排的維護成本高昂，且無法擴大規模：

  • 樹外測試依賴已淘汰的平台功能、通訊協定和工具。最值得一提的是：使用 SSH 通訊協定在目標上發出指令 (例如使用 fx shell 或 fssh)、dash 做為系統介面、fx log 在測試期間收集系統範圍的記錄，以及使用 SCP 通訊協定 (例如使用 fx scp) 收集其他測試構件，做為全域可變動檔案系統的副作用。這些通訊協定會產生不可靠的行為，導致測試不穩定且難以排解問題，這至少可部分歸因於文字通訊協定的脆弱本質。此外，傳輸作業僅適用於單一字元串流，非常適合全系統記錄 (例如序列記錄或系統記錄)，但不適用於多個記錄串流或大型二進位構件，例如測試中的狀態傾印和螢幕截圖。

  • 各種以文字為基礎的通訊協定，缺乏確保 ABI 穩定性或協調 ABI 演進的方法和做法。

  • 以舊版元件 (又稱 CFv1) 編寫的測試隔離程度較低，更容易發生不穩定情況，且無法使用新測試工具。

  • 用於定義測試、擷取測試結果和相關診斷資訊的自訂規則和指令碼不一致。

  • 對各種測試架構的支援不一致。舉例來說，所有樹狀結構外合作夥伴都支援 C++ 和 GoogleTest，但只有部分合作夥伴支援 Dart，而且儘管 Rust 在樹內元件開發中很受歡迎，但沒有任何合作夥伴支援 Rust。

  • 對可為測試增加價值的額外插樁支援不一致，例如清除器和涵蓋範圍。

  • 部分工具和原始碼會透過 Fuchsia IDK (SDK 工具集) 分發給合作夥伴。舉例來說，TestWithEnvironment 輔助類別會手動複製到 GitHub 上的 Flutter 存放區，以解除整合測試需求。

為克服這些問題，Fuchsia 團隊已為主要合作夥伴提供專屬支援。這類安排通常會產生專屬解決方案，無法在不同客戶之間轉移。此外，支援客戶問題通常是在客戶的來源存放區中進行，這對客戶來說可能很方便，但無法擴大規模，支援一般大眾開發人員。

我們現在有許多來自實際環境的體驗和觀察結果，可做為參考，進一步瞭解如何建立更通用的測試解決方案。現在正是時候運用這些洞察資料，為這些用途建構平台支援功能，進而打造功能更強大的 SDK，並減少及移除客製化解決方案，避免價值主張日益減少，但維護成本卻維持不變。

測試用的平台/基礎架構介面

Fuchsia 的內部測試基礎架構 (又稱「基礎架構」) 也有上述大部分問題，且受影響的方式與 Fuchsia 合作夥伴類似。由於 Fuchsia 的基礎架構不會持續運用平台解決方案和 SDK 工具進行測試，因此錯失了持續確保解決方案和工具品質的機會。

對樹狀結構外測試日益增長的需求

目前和即將推出的專案有數個，預計會擴大針對 Fuchsia 的樹狀結構外開發和測試範圍。包括：

  • 相容性測試套件 (CTS) 測試將可在 Fuchsia 的樹狀結構內建構和測試系統外執行，但其原始碼會託管在 fuchsia.git 上。

  • Flutter-on-Fuchsia Velocity 預期會在 Fuchsia 上建構及測試 Flutter 嵌入器，並在樹狀結構外建構元件和測試的 Flutter 執行元件，且至少會將部分整合測試上傳至 Flutter 專案。

  • 驅動程式即元件：將展示在樹狀結構外建構及測試的驅動程式庫，以實現 Fuchsia 上的強大硬體支援驅動程式 ABI 穩定性。

  • 如要在 LLVM 和 Rust 專案中，支援在 Fuchsia 上執行現有測試，需要支援樹狀結構外的 C++ 和 Rust 測試。

目前這些專案無法順利完成，因為缺少樹狀結構外測試的支援。

解決方案聲明

我們將建立測試平台解決方案，專門根據 Fuchsia SDK 中公開提供的工具和通訊協定運作。

主機端

我們會使用 FFX 做為樹狀結構外測試的進入點。我們將完成ffx test的開發作業，以處理測試的所有主機端層面。我們將採用既有的 FFX 技術和做法，例如設定管理、目標裝置探索，以及 Overnet 通訊套件。

我們將以 ffx 工具取代現有的主機工具。目前 testrunner 和 Botanist 等工具會在 Fuchsia CI/CQ 中執行工作 (例如裝置探索、裝置設定、測試協調、測試構件收集)，這些工作可以逐步移交給 ffx。部分交接作業需要建構同等 ffx 外掛程式，例如透過序列連線執行 Bringup 測試時，需要支援 ffx test。這麼做的好處是，我們能持續使用現代化工具驗證工作，這些工具可在樹狀結構內和樹狀結構外的使用案例之間移植，並使用現有豐富且強大的樹狀結構內測試和樹狀結構內自動化功能。

我們會將使用sanitizers和測試涵蓋範圍的相關作業，從僅適用於樹狀結構內的工具 (例如 tefmocheck 和 covargs) 移植到 ffx 外掛程式。

目標端

我們會擴充 Test Runner Framework (TRF)，以滿足樹狀結構外測試的需求。

TRF 包含裝置端 Overnet Daemon、管理/排定測試的元件、用於密封測試的獨立領域、支援多種語言和架構的測試執行元件，以及用於連結上述所有項目的 FIDL 通訊協定。TRF 支援樹狀結構內和樹狀結構外測試工作流程。這個測試執行階段取代了只能在樹狀結構內運作，且僅支援 CFv1 元件的測試執行階段。

目前為止，TRF 的優先客戶是樹狀結構內測試，成功與否的衡量標準是透過 TRF 執行的測試比例。撰寫本文時，已有超過 70% 的 Fuchsia 樹狀結構內測試遷移至 TRF，且現代 (CFv2) 測試完全在 TRF 上執行。我們預計在 2021 年底前，除了 ZBI 測試外，所有剩餘測試都會透過 TRF 執行，這要歸功於即將推出的相容性層。

所有元件測試都遷移至 TRF 後，我們就會停用舊版目標端僅限 v1 的樹狀結構內測試執行階段。這樣我們就能專注於改善新的測試執行階段，這項改善措施將有助於樹狀結構內和樹狀結構外開發人員。

為提升開發人員體驗，樹狀結構外的開發人員將可納入 SDK 的測試執行器。透過這項機制，樹狀結構外的開發人員將可存取現有的測試執行器庫 (gtest、Rust、Go 和任意 ELF 二進位檔)，以及即將推出的 Dart 和 Flutter 測試執行器。TRF 也將成為開發更進階測試策略的基礎，例如壓力測試和 CTS 測試。這些測試策略會以執行器表示，也可能在 SDK 中提供。

此外，樹狀結構外開發人員可以建立及使用自己的測試執行器。目前認為這項技術可行，但尚未經過驗證。我們應該建立第一個樹狀結構外測試執行元件，這樣才能更有把握地說明這個工作流程。

測試執行控制

我們將完成新通訊協定的開發和推出作業，以控管測試執行。

新通訊協定以 FIDL 形式定義 (可確保 ABI 穩定性及演進，這對樹狀結構外的項目至關重要)，並由 Overnet 原生傳輸。新通訊協定不瞭解 Fuchsia 基礎架構，因此可強化所謂的平台/基礎架構合約。

新通訊協定可更妥善地分層和區隔問題。舉例來說，主機端負責測試選取作業，並要求在目標上執行測試。目標端測試管理員負責實際執行測試，這與舊版系統不同，舊版系統是由主機工具在目標裝置上逐一手動執行每項測試。將測試執行作業平行化，以盡量提高資源使用率的責任，會轉移至目標，目標更適合處理這項責任。

最後，新通訊協定並非以字元串流 (SSH) 為基礎。這樣一來，資訊就能雙向流動，並透過多個指令、結果和診斷串流，以及可能為二進位格式的大型測試輸入和輸出內容，進行雙向流動。

測試結果

測試結果不再僅限於套件層級的通過/失敗結果，而是會以結構化格式詳細列舉。測試期間收集的診斷資訊 (例如測試領域在測試期間擷取的記錄) 會以與產生這些資訊的測試相關聯的方式整理。系統會提供標準支援，處理測試中的其他構件，例如測試執行期間收集的設定檔，或是大型測試輸出內容，例如測試期間拍攝的螢幕截圖。結果格式的結構定義將發布在 SDK 中，以支援樹狀結構外的工具進行處理。

說明文件

我們會審查、編輯並簡化這類開發人員指南，讓樹狀結構外開發人員也能輕鬆上手。樹內和樹狀結構外測試工作流程將會統一，因此這些指南不會提供 Fuchsia 樹狀結構內/樹狀結構外開發人員專屬資訊，也不會為不同對象提供個別章節。

我們將開發新的入門指南，詳細說明「測試歷程」。本指南將為開發人員提供入門資訊，協助他們確保程式碼已透過單元和整合測試妥善測試。本指南的目標是：1) 協助開發人員正確選擇要編寫的測試類型；2) 讓開發人員快速準備好測試，以便運用更進階的測試策略 (例如 CTS 和壓力測試)。

虛擬化支援

模擬器等虛擬目標非常實用，且廣受歡迎，適合用於測試。 Fuchsia 目前提供下載 qemu 發行版本，該版本已通過測試，可與 Fuchsia 搭配使用。不過，還有其他工具可處理虛擬化目標，例如 fx qemu 和 fx gce，但這些工具僅適用於樹狀結構內。

我們會找出樹狀結構內和樹狀結構外支援的差異，以便在虛擬化目標上執行 Fuchsia，並視需要解決這些差異，縮短測試工作流程的差距。

依附元件

  • FFX 工具和相關堆疊。
  • Fuchsia IDK，以及樹狀結構外開發人員使用的任何 SDK 前端。
  • 在樹狀結構外提供 RealmBuilder。
  • 透過 SDK 公開 RealmBuilder。包括基礎通訊協定和至少一個用戶端程式庫。
  • 擴充 RealmBuilder，支援其他語言。

風險與緩解措施

不適用

不適用

端對端測試 (又稱系統測試)

這項提案著重於元件測試，也就是單一元件的單元測試，或是涵蓋多個元件的整合測試。系統測試也稱為端對端 (或 e2e) 測試，不會執行特定元件例項，而是測試整個系統。因此，這類測試在許多方面都與元件測試不同，例如開發人員需求和用途，以及平台在 E2E 測試之間提供隔離功能的能力。

目前熱門的端對端測試解決方案是 SL4F (Fuchsia 的指令碼層)。實作內容包括目標端常駐程式 (包含在部分 Fuchsia 映像檔中，可執行一組有記錄的系統自動化工作)，以及 以 Dart 編寫的用戶端程式庫 (可在 Fuchsia SDK 中使用)。

此外，還有 CFv1 元件測試，可說是系統測試。這是因為舊版 CFv1 測試執行階段允許存取實際的系統服務，這是舊版折衷方案，CFv2 測試刻意不支援。就本次討論而言，我們也將這類嚴格的非密封 CFv1 元件測試視為系統測試。

目前擴充端對端測試開發作業面臨的挑戰包括：

  • 如要在 SL4F 中新增 Facade，必須變更平台程式碼，並重新發布 Fuchsia 系統映像檔。樹外開發人員無法擴充 SL4F 的功能，自動化系統。

  • SL4F 不依賴 ffx，而是使用自己的傳輸層、通訊協定、目標探索和設定。這些差異會增加持續維護成本，並導致開發人員體驗不一致和摩擦。

  • 我們只提供 Dart 用戶端程式庫。

由於系統測試與元件測試的差異極大，因此本主題將在獨立的路線圖文件中說明。