樹狀結構元件測試支援

  • 專案主管：shayba@google.com、crjohns@google.com
  • 區域：測試

問題陳述

缺少測試平台途徑

指定 Fuchsia 的軟體開發人員可以編寫元件、建構元件，以及進行測試。

如今，有多個團隊開發及測試樹狀結構外元件。我們有時會將這些團隊稱為「合作夥伴」，因為 Fuchsia 團隊密切合作。這項安排的維護成本高昂，而且無法擴充，原因如下：

  • 樹外測試仰賴已淘汰的平台功能、通訊協定和工具。最值得注意的是：使用 SSH 通訊協定在目標上發出指令 (例如使用 fx shell 或 fssh)、使用 dash 做為系統介面fx log、在測試期間收集全系統記錄，並使用 SCP 通訊協定 (例如與 fx scp 搭配使用) 收集其他測試成果，藉此對全域可變動系統造成副作用。這些程式碼會產生不可靠的行為，進而導致畫面變形，而且難以進行疑難排解。或許至少要部分歸因於文字通訊協定的脆弱性質。此外，單一字元串流的傳輸負擔更大，非常適合系統整個記錄 (例如序列記錄檔或 Syslog)，但不適用於多個記錄串流或大型二進位構件，例如狀態傾印和測試的螢幕截圖。

  • 各種文字型通訊協定，缺少確保 ABI 穩定性或自動化調度管理 ABI 演進的方法和做法。

  • 以舊版元件 (又稱 CFv1) 撰寫的測試，隔離程度較低、較不穩定，且沒有使用新的測試工具。

  • 使用不同的規則和指令碼，定義測試及擷取結果和相關診斷。

  • 對各種測試架構的支援不一致。舉例來說，雖然所有樹狀結構外合作夥伴都支援 C++ 和 GoogleTest，但只有部分合作夥伴支援 Daart，但 Rust 相當普及適合用於樹狀結構內結構元件開發。

  • 對其他測試 (例如消毒液和涵蓋率等測試) 新增更多價值的額外檢測支援不一致，

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

為瞭解決這些問題， Fuchsia 團隊為主要合作夥伴提供專屬支援服務。這樣的安排通常會製作量身打造的解決方案，無法在不同客戶之間轉移。此外，客戶問題的支援服務通常發生在客戶的原始碼存放區內。雖然客戶或許可以輕鬆解決問題，但無法擴大支援開發人員的一般公開目標對象。

現在，我們廣納了無數經驗與觀察結果，說明如何建立更通用的測試解決方案。現在正是時候，根據這些洞察資訊建構適用於這些用途的平台，因此建立更強大的 SDK 以及減少和移除自訂解決方案，讓費用固定大幅降低。

用於測試的平台/基礎架構途徑

Fuchsia 的內部測試基礎架構 (又稱「基礎架構」) 呈現了上述大部分問題，運作方式與 Fuchsia 合作夥伴類似。 由於 Fuchsia 的基礎架構不會持續執行平台解決方案和 SDK 工具測試，因此在這些解決方案和工具中，仍有可能錯失持續品質保證的機會。

越來越需要樹狀結構外測試

預計會有幾項目前和即將的專案會擴大以 Fuchsia 為目標的樹狀結構外開發及測試。以下是符合規定的功能：

  • Compatibility Test Suite (CTS) 測試可在 Fuchsia 的樹狀結構內結構和測試系統外執行，不過原始碼會在 fuchsia.git 上代管。

  • Flutter-on-Fuchsia 速度預期在 Fuchsia 上建構及測試 Flutter 嵌入器，以及用於元件及其樹狀結構外測試的 Flutter 執行元件，而且至少會有部分整合測試向上串流至 Flutter 專案。

  • 「驅動程式即元件」將提供在樹狀結構外建構及測試的驅動程式庫示範，透過驅動程式 ABI 穩定性實現堅固硬體在 Fuchsia 上的承諾。

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

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

解決方案陳述式

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

主機端

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

我們將以 ffx 工具取代現有的主機工具。testrunner 和 Botanist 等工具目前會在 Fauchsia CI/CQ 中執行各項工作，例如裝置探索、裝置設定、測試自動化調度管理、收集測試構件，這些工作可逐步送交 ffx。其中有些交接需要建構同等的同等 ffx 外掛程式，例如提供 ffx test 支援，以便透過序列連線執行 Bringup 測試。值得注意的原因是，我們使用現有豐富且可靠的樹狀結構內測試與樹狀結構內結構自動化的豐富目錄，持續驗證在樹狀結構內結構和樹狀結構外用途之間的現代化工具上運作成果。

我們將透過樹狀結構內僅可使用的工具 (例如 Tefmocheck 和 covargs) 移植使用消毒工具和測試涵蓋範圍的各種面向，並移植到 ffx 外掛程式。

目標端

我們會擴充「Test Runner Framework」(測試執行器架構)，以因應樹狀結構外測試的需求。

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 測試。

目前常見的 e2e 測試解決方案是 SL4F (Fuchsia 的指令碼處理層)。這個實作項目包括目標端 Daemon，後者包含在部分 Fuchsia 映像檔中，並可執行記錄的系統自動化工作組合，以及 Fuchsia SDK 提供的以 Dart 編寫的用戶端程式庫。

此外，也有可以模擬系統測試的 CFv1 元件測試。這是因為舊版 CFv1 測試執行階段允許存取真實的系統服務，因為 CFv2 測試中刻意不支援舊版入侵。基於本討論的目的，我們也將這類嚴格非密封的 CFv1 元件測試一併視為系統測試。

目前在擴大 e2e 測試開發規模時遇到的挑戰包括：

  • 為 SL4F 新增門面時，必須變更平台程式碼及重新發布 Fuuchsia 系統映像檔。樹系外開發人員無法擴充 SL4F 的功能來自動化系統。

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

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

由於系統測試與元件測試有太大差異，因此這個主題會在另一份藍圖文件中說明。