樹狀結構元件測試支援

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

問題陳述

缺少用於測試的平台介面

以 Fuchsia 為目標的軟體開發人員可以編寫元件、建構及測試。開發人員，但完全不適用於

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

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

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

  • 以舊版元件 (即 CFv1) 編寫的測試，隔離程度較低，因此會出現較多不穩定的情況，也無法使用新測試工具。

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

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

  • 不支援其他可為測試帶來更多價值的額外檢測功能，例如消毒劑和涵蓋率。

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

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

我們現在擁有豐富的實務經驗和觀察結果，可用於建立更通用的測試解決方案。我們現在正好運用這些洞察資料，為這些用途建立平台支援，進而打造功能更強大的 SDK，並減少和移除固定維護成本較高的客製化解決方案，以便提供更有價值的產品。

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

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

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

目前和即將推出的幾個專案，都會擴大以 Fuchsia 為目標的樹狀結構外開發與測試範圍。其中包括：

  • Compatibility Test Suite (CTS) 測試可在 Fuchsia 的樹狀結構內建構與測試系統外執行，但其原始碼會託管在 fuchsia.git 上。

  • Flutter-on-Fuchsia Velocity 預計在 Fuchsia 上建構及測試 Flutter 嵌入器，以及用於元件和其樹狀結構外測試的 Flutter 執行元件，並將至少部分整合測試匯出至 Flutter 專案。

  • Drivers as Components 將示範建構並樹狀結構外測試的驅動程式庫，透過驅動程式 ABI 穩定性，實現 Fuchsia 提供的強大硬體支援。

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

目前這些專案無法順利完成，因為它們依賴的功能缺乏對樹狀結構外測試的支援。

解決方案陳述式

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

主機端

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

我們會將現有的主機工具替換為 ffx 工具。testrunner 和 Botanist 等工具目前會在 Fuchsia CI/CQ 中執行任務，例如裝置探索、裝置設定、測試協調、測試構件收集，這些任務可逐步交由 ffx 執行。其中部分交接作業需要建構等同的 ffx 外掛程式，以便達到相同的效果，例如提供 ffx test 支援，以便透過序列連線執行 Bringup 測試。這樣一來，我們就能持續驗證在現有豐富且強大的樹狀結構內測試和樹狀結構內自動化工具中，可在樹狀結構內和樹狀結構外使用情境之間移植的現代化工具。

我們將從僅樹狀結構內可用的工具 (例如 tefmocheck 和 covargs) 移植使用清理器和測試涵蓋率的部分，移植至 ffx 外掛程式。

目標方

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

TRF 包含裝置端 Overnet 守護程序、用於管理/排程測試的元件、用於密封測試的隔離領域、支援各種語言和架構的測試執行器，以及用於連結上述所有項目的 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 的 Scripting Layer)。實作內容包括目標端守護程式，這項元素包含在部分 Fuchsia 映像檔中，可執行已記錄的系統自動化工作組合，以及 以 Dart 編寫的用戶端程式庫，可在 Fuchsia SDK 中使用。

此外，也有 CFv1 元件測試可視為系統測試。這是因為舊版 CFv1 測試執行階段允許存取實際的系統服務，這是舊版妥協做法，在 CFv2 測試中並未有意支援。為了方便討論，我們將這類嚴格非密封的 CFv1 元件測試視為系統測試。

擴大 e2e 測試開發規模目前面臨的挑戰包括：

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

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

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

由於系統測試與元件測試截然不同，因此我們會在另一份路線圖文件中說明這個主題。