RFC-0221：用於樹狀結構測試系統的 Python

RFC-0221：用於樹狀結構外系統測試的 Python
狀態已接受
區域
  • 語言和程式庫
  • 測試
說明

核准 Python 用於樹狀結構外系統測試。
Gerrit 變更
作者
審查人員
提交日期 (年-月-日)2023-04-27
審查日期 (年-月-日)2023-06-13

編輯此 RFC

編輯 RFC 中繼資料

摘要

核准 Python 用於樹狀結構外 (OOT) 的系統測試。

提振精神

我們已知需要改善 Fuchsia 對最終開發人員的系統測試支援功能。隨著驅動程式庫開發作業移至樹狀結構外 (OOT)，我們必須立即透過 SDK 發布標準化系統測試解決方案，以支援硬體認證。

開始這項工作之前，您必須先選取用於建構解決方案的程式設計語言。本文件會提出評估標準，並提供各程式語言的資料點，以便評估 OOT 系統測試的各種程式語言。評估作業的結果將用於針對 Fuchsia 應使用的程式設計語言，提出明智的建議，以滿足現今 OOT 系統測試需求。

相關人員

協助人員：

  • David Moore (davemoore@google.com)

未定

審查者：

  • abarth@google.com
  • cpu@google.com
  • jamesr@google.com
  • keir@google.com
  • rlb@google.com

諮詢：

  • amituttam@google.com
  • crjohns@google.com
  • dannyrosen@google.com
  • dworsham@google.com
  • fmeawad@google.com
  • guptaritu@google.com
  • jeremymanson@google.com

社會化：

我們在 Google 文件中與 FEC、測試架構團隊、測試基礎架構團隊和工具團隊的成員討論 OOT 系統測試評估準則，以及各個考慮中的程式設計語言評估。

定義

  • 系統測試通常稱為端對端或 CUJ 測試，這些測試會在完整組裝的系統上進行，以驗證系統是否符合特定需求。如需完整定義，請參閱「什麼是系統測試？」。

產品相關規定

摘要說明產品動機和需求，以支援 Fuchsia 的新一代 OOT 系統測試。

主要使用者：測試 Fuchsia 平台和產品的開發人員和系統整合業者。

環境：樹狀結構，以及 SDK 運作的所有環境和花瓣。

策略遊戲

  • 將用途範圍限制為涉及一或多個目標裝置的端對端裝置測試。
  • 提供將現有 SL4F 測試和使用者遷移至新架構的路徑。
  • 使用 SL4F 解決現有痛點，並著重於以人體工學為重點，以易用語言編寫測試。
  • 確保可輕鬆整合 Google 的 E2E 測試架構。
  • 投資開發 Fuchsia 使用者要求的額外功能，以滿足平台測試需求 (例如效能監控、記憶體用量等)。

選擇程式設計語言的重要性

採用的測試架構很大程度上取決於所選語言。在這個系統測試用途中廣泛採用的簡易語言，對於擴大核心 SWE 範圍，並納入測試工程師和系統整合器，非常有幫助。

評估評分量表

每種語言的一般優缺點 (TypeScript 和 JavaScript 除外) 已在 Fuchsia 程式設計語言政策 (FPLP) 中詳述。本文件中使用的指標涵蓋與 OOT 系統測試特別相關的語言層面。

評估量表 (順序不分先後)：

  • 生態系統採用率：在 OOT 系統測試領域中，語言的受歡迎程度

    • 系統測試的常用主流語言，有助於採用 OOT。
    • 請優先使用在 OOT 客戶程式碼集中用於系統測試的語言。

  • 人因工程：語言支援系統測試用途的常見模式程度

    • 常見的系統測試模式是協調主機-裝置互動，例如在測試中的 Fuchsia 裝置 (DUT) 上觸發 API 並斷言行為。與傳統 Fuchsia 平台開發不同，這類用途可從不同的語言功能組合中受益，其中一些主要差異如下：
      • 開發靈活性優先，效能次之。
        • 建議使用自動記憶體管理和垃圾收集功能。
        • 主機上的測試效能通常是次要考量。
      • 建議使用互動模式/REPL 快速建立原型。
      • 較大的二進位檔/來源檔案占用空間較小。
      • 非同步語言支援功能雖然實用，但並非必要。
      • 系統測試通常是較小的專案，程式碼行數只有數百行。請使用易讀的語言，方便檢查數百行程式碼的正確性。(測試是實際工作環境程式碼，通常沒有經過充分測試，因此簡單的正確性推理很有用)。

  • Fuchsia 移植性：輕鬆在主機和 Fuchsia 目標上執行

    • 雖然本文件中評估的語言主要用於主機語言，但仍有測試案例只能透過目標導向方式完成 (例如使用未匯出至主機的介面、僅在目標端可用的時間和吞吐量保證)；因此，在 Fuchsia 目標上執行語言的移植性，對於系統測試而言十分重要。使用可移植語言進行系統測試，也有重複使用的好處 (例如在主機和目標上重複使用編碼/解碼等常見邏輯)。

  • 必要投資：將 OOT 系統測試解決方案導入實際作業所需的工作

    • 瞭解語言特定差異，有助於我們在考量時間和資源限制的情況下，更有效地比較替代方案。
    • 以下列舉部分必要投資項目：
      • 建構支援
      • 現有程式庫支援
      • 測試架構開發
      • 主機裝置互動程式庫和工具 (例如 SL4F 支援)
      • SDK 中的語言支援
      • 說明文件和開發人員教育

  • 可維護性：維持 OOT 系統測試解決方案所需的工作

    • 視所選語言而定，人力需求、程式碼健全性和技術債務可能會產生長期影響。
    • 可維護性方面的示例：
      • 執行階段可更新性 - 能夠在不影響 OOT 使用者的情況下更新執行階段。
      • Fuchsia API 版本管理 - 用於防止 Fuchsia API 變更導致 OOT 中斷的工具，例如如何偵測系統測試 API 中導出至 OOT 使用者的破壞性變更。
      • 程式碼健康狀態
        • 大型軟體專案通常可從靜態型別等語言功能中受益。
        • 輕鬆啟用自動化靜態分析工具 (例如 Linter、涵蓋率等)。

考慮使用的語言

本節將介紹幾種可用於 OOT 系統測試的語言，並提供各評估指標的證據。為簡化各語言之間的比較，每種語言的評估標準中，每個類別都會指派不可行、不良、中立或良好的分數。

查看

生態系統採用率：普通

  • 中立：Go 是一般來說相當熱門的語言 (TIOBE、PYPL)，但目前沒有證據顯示，Go 在 Fuchsia 現有 OOT 合作夥伴的系統測試空間中廣泛使用。
  • 優點：有證據顯示，Go 已在現實世界中，用於廣泛的所有測試解決方案進行系統測試：

人體工學：良好

  • 優點：使用這種語言的使用者工作效率極高 (FPLP)。
  • 優點：支援垃圾收集，並提供記憶體安全保證 (FPLP)。
  • 優點：協同程式可讓非同步通訊更精簡，也更容易推理。
  • 缺點：編譯語言不太適合用於互動式系統測試開發。

Fuchsia 可攜性：中性

  • 優點：Fuchsia 支援 Go 執行階段，這項技術已在先前發表的技術中出現 (例如 fidlgen)。
  • 缺點：不建議使用 Go 進行平台開發 (FPLP)。

必要投資：無

  • 缺點：這個語言沒有實作一般樹狀結構內的系統測試解決方案。
    • 系統 OTA 測試中有一些以 Go 為基礎的系統測試先例，但沒有任何解決方案可一般支援所有類型的系統測試 (例如多裝置測試)。
    • 沒有通用主機可供 Fuchsia 裝置互動程式庫使用。
  • 優點：Fuchsia 原始碼中包含 SL4F 用戶端程式庫。
  • 中性：需要投資 OOT，類似於其他考慮中的語言。
    • 來源分發
      • 中性：投資程度與其他語言相似。
    • 靜態分析
      • 專業版：Fuchsia CI 已啟用 gofmt 和 govet。
    • Bazel 整合功能

可維護性：良好

  • 優點：可更新性 - 沒有重大可更新性問題的證據。
    • 工具可用於重寫 Go 檔案，以符合新的 Go 版本
    • https://pkg.go.dev/cmd/fix.
  • 優點：程式碼健全性 - 靜態型別語言有助於維持 OOT 程式碼的健全性。
  • 中性：Fuchsia API 版本管理 - 需要投資於 API 版本管理，類似於其他考慮中的語言。

Python

生態系統採用率：良好

  • 優點：Python 是一般常見的語言 (TIOBE、PYPL)。
    • Python 是目前成長最快的主要程式設計語言，也是頂尖大學的熱門課程。
    • 在 GitHub 活動中，它僅次於 JavaScript，這也是積極開發的跡象。
  • 專業：Mobly 是開放原始碼多裝置 e2e 測試架構，是 Google 內部多裝置系統測試的最佳選擇。

人體工學：良好

  • 優點：使用這種語言的使用者工作效率極高 (FPLP)。
  • Pro：支援垃圾收集 (FPLP)。
  • 優點：Python 轉譯器可讓使用者不必編譯，即可進行互動式開發/測試，這在遠端控制的情況下特別實用。

Fuchsia 可攜性：中性

  • 優點：Python 是所有現有主機平台的移植性語言，且應在 Fuchsia 成為通用作業系統的可行選項時，獲得 Fuchsia 的支援。
  • 缺點：Python 有大量的執行階段環境，且沒有先進技術可支援 Fuchsia 中的 Python 執行階段，因此支援 Python 所需的投資會相當可觀。

投資金額：良好

  • 優點：Python Mobly 系統測試解決方案已在樹狀結構中存在。

  • 優點：Fuchsia 中的 Pigweed 大量投資於 Python。

    • 在我們的下游專案中，Python 幾乎都用於開發、測試自動化、工廠工具等。
    • 將持續大力投資 OOT Python (連結 1、連結 2)。
    • 同時投入 GN 和 Bazel 工具；GN 工具已成熟，Bazel 工具仍在積極開發中。

  • 中性：需要投資 OOT，類似於其他考慮中的語言。

    • 來源分發
      • 中性：投資程度與其他語言相似。
    • 靜態分析
      • 缺點：透過型別提示 (PEP 484) 實現靜態型別的好處，需要基礎架構投資才能自動執行靜態型別檢查。
      • 優點：Pigweed 已在 GN 中自動化這些功能，Fuchsia.git 可加以利用。
    • Bazel 整合功能
      • 優點：Bazel 建構系統支援 Python。
      • 優點：無論 Fuchsia 的決定為何，Pigweed 都會進一步擴充現有的 Bazel Python 整合功能。

可維護性：不佳 (投資效益為中性)

  • 缺點 (投資後中性)：可更新性 - 需要投資 Python 靜態分析工具才能達到中性分數，否則 Python 的大型執行階段介面和非編譯語言的特性，會分別導致執行階段更新中斷的機率提高，以及難以斷言執行階段支援。
    • 優點：可更新性 - RFC-0129 會建立樹狀結構內 Python 最佳做法 (例如 Python 3.8 以上版本)，這應該可避免主要的 Python 執行階段可更新性問題。
      • Python 已在 2020 年加強回溯相容性的規則 (PEP 387)。
      • Python 創作者和核心 Python 開發人員引用了從 Python 2 到 3 的經驗教訓，指出由於可能會發生廣泛的相容性問題，因此不會在短期內推出主要版本更新。
    • 缺點：Python 的執行階段介面相對較大，因此執行階段更新比其他考慮中的語言更有可能導致中斷。
    • 缺點：Python 是一種解譯語言，因此更難偵測可能在執行階段更新時發生的 API 中斷情形，因此只能透過執行而非編譯來斷言正確性。雖然為 OOT 系統測試而開發的 API 會以測試為導向，但每次執行階段版本升級時，都應透過現有的樹狀結構內檢查徹底執行這些 API。為確保最高可靠度，您必須投資 Python 原始碼涵蓋率，以便監控並強制執行所有以 SDK 為基礎的 Python 模組的絕對涵蓋率。
  • 缺點 (投資後中性)：程式碼健全性 - 需要投資 Python 靜態分析工具才能獲得中性分數，否則 Python 缺乏靜態型別強制執行功能，可能會導致程式碼健全性不佳。
    • 可能無法將靜態型別強制執行功能擴充至以 SDK 的 Python API 建構的 OOT 系統測試專案。雖然 Fuchsia 可以在匯出 OOT 的 Python API 中強制執行類型提示和程式碼涵蓋率，但 Python 中沒有內建的語言功能，要求這項做法必須繼續在 OOT 中執行。
    • 我們已著手解決這些挑戰 (例如，投資於上游 Bazel Python 支援，以便在建構期間強制執行類型提示)。
  • 中立：Fuchsia API 版本管理 - 需要投資於 API 版本管理，類似於其他考慮中的語言。

TypeScript

生態系統採用率：普通

  • 中立：TypeScript/JavaScript 是熱門語言 (TIOBE、PYPL)，但沒有證據顯示 TS/JS 在 Fuchsia 現有 OOT 合作夥伴的系統測試空間中廣泛使用。

人體工學：良好

  • 優點：非同步支援功能十分穩健，適合用於裝置本身的程式設計。
  • 優點：支援垃圾收集。
  • 優點：JS 轉譯器可讓使用者以互動方式進行開發/測試，無須編譯，這在遠端控制的情況下特別實用。

Fuchsia 可攜性：良好

  • 優點：Fuchsia 已透過實驗性 JavaScript 解譯器/殼層 - Josh (未正式發布) 展示 JS 執行階段支援功能。

需要投資：不良

  • 缺點：並非 Fuchsia 核准使用的語言 (FPLP)。
  • 缺點：這個語言不支援樹狀結構內 GN 建構系統。
  • 缺點：沒有以此語言實作樹狀結構內的系統測試解決方案。
  • 缺點：Fuchsia 原始碼中沒有 SL4F 用戶端程式庫。
  • 中性：需要投資 OOT，類似於其他考慮中的語言。
    • 來源分發
      • 中性：投資程度與其他語言相似。
    • 靜態分析
      • 缺點：目前沒有樹狀結構內的 TypeScript 支援。
    • Bazel 整合功能
      • 優點：Bazel 建構系統支援 TypeScript。
      • 缺點：Pigweed 團隊在將 TS 與 Bazel 整合時遇到負面經驗，因此已刪除所有 TS Bazel 整合作業。以下引述 Pigweed 團隊的說法：
        • 無法對 TS Bazel 損壞情形進行偵錯。
        • Node 生態系統無法可靠地整合。
        • 由於 Google 內部工具優先，因此缺乏 Bazel 團隊的支援。
    • 外部開發工具 (OOT) 基礎架構整合
      • 缺點：沒有證據顯示 TS/JS 可用於在 Bazel 中進行以裝置為中心的系統測試。

可維護性：良好

  • 優點：程式碼健全性 - 靜態型別語言有助於維持 OOT 程式碼的健全性。
  • 中立：Fuchsia API 版本管理 - 需要投入類似於其他考慮中的語言的 API 版本管理。

無法翻譯的語言

由於一或多項評估指標不切實際，因此從深入分析中移除這些程式語言。

C/C++

人體工學：不可行

  • 缺點：手動記憶體管理會影響開發敏捷性。
    • C/C++ 的效能優勢不適用於偏好簡單而非效能的常見 OOT 系統測試用途。
  • 缺點：在系統測試開發方面，編譯語言不如理想。

荒漠油廠

生態系統採用率：不可能

  • 缺點：Rust 並不是一般常見的語言 (TIOBE、PYPL)，也不常用於系統測試。

人體工學：不可行

  • 缺點：嚴格的語言語法可確保記憶體安全，但會降低開發效率。
    • 對於偏好簡單性而非效能的常見 OOT 系統測試用途，Rust 提供的效能提升和記憶體安全性保證不適用。
  • 缺點：Rust 的學習曲線相對陡峭。
  • 缺點：Google 的內部程式碼庫不支援 Rust。
  • 缺點：編譯語言不太適合用於系統測試開發。

Dart

所需投資：不可行

  • 缺點：Dart 過去需要 2 位全職工程師，才能維護與該語言相關的樹狀結構內基礎架構。
    • 目前，我們已凍結測試機器人，並由成效團隊盡力維護現有測試。
    • 以往管理第三方程式庫生態系統時，經常會在上游推出新版本時中斷。
  • 缺點：Fuchsia.git 中允許使用歷史用途，但新增的用途必須獲得豁免 (RFC-0176、FPLP)。

可維護性：不可行

  • 缺點：RFC-0176 中提到的其他缺點，以及執行階段與程式庫之間的緊密連結，都讓 Dart 無法成為起步點。
    • 從 Dart 淘汰事件中學到的經驗總結：
      1. 請勿使用不穩定的開發中語言。
      2. 不要仰賴使用者族群較小的語言。
      3. 缺乏上游支援，難以廣泛採用。
  • 缺點：Dart 缺少支援 FIDL 版本化 (缺少條件式編譯) 或動態產生繫結所需的重要語言功能，因此很難隨著 Fuchsia API 途徑發展 Dart FIDL 繫結。

評估摘要

以下是 OOT 系統測試的程式設計語言評估結果。

替代文字：評估摘要

結語

根據上述評估結果，Go、Python 和 TypeScript 都是可用於 OOT 系統測試的語言。不過，每種語言都有各自的取捨，因此很難選出一致的「贏家」。最終，我們會將客戶需求 (「生態系統採用」維度) 的索引加重，以便在平手時決定勝負，並根據語言決定是否要解除現有 OOT 客戶的封鎖。

目前建議使用 Python 進行 OOT 系統測試，主要是因為 Python 符合產品規定，特別是能輕鬆整合 Google 現有的測試架構。基於技術因素，Python 可能不是系統測試的絕對首選，但 Fuchsia 的 OOT 客戶需要使用 Python。

總結來說，Python 的優點如下：

  1. 在 OOT 合作夥伴中普遍採用系統測試
  2. 符合人因工程學的語言功能，可改善系統測試的使用者體驗
  3. 由於 Fuchsia 原始碼中已有現有解決方案，因此可縮短正式化路徑

雖然樹狀結構內和 OOT 都需要額外投資，才能達到與其他靜態型別語言相同的維護性，但透過改善 Fuchsia 的 Python 靜態分析工具，我們可以透過型別提示和涵蓋率強制執行，達到相同的維護性。

不過，如果在類型提示和涵蓋率樹狀結構內強制執行後的 6 個月內，出現大量與 Python 可維護性相關的錯誤和疑慮，我們就會重新考慮使用 Python 進行 OOT 系統測試。此外，我們也會在一個 OOT 存放區中強制執行類型提示。

請注意，在本 RFC 中核准使用 Python 進行 OOT 系統測試，並不表示在這個領域中無法使用其他語言。事實上，Fuchsia 在 SDK 中匯出的關鍵 OOT 系統測試元件將是 Fuchsia 控制器，該控制器專門設計用於擴充至任何主機端語言，以支援主機端與 Fuchsia 裝置之間的通訊。

實作

Fuchsia 程式設計語言政策需要更新，以反映此 RFC 提出的建議，即核准使用 Python 進行 OOT 系統測試。

  • 將 Python 語言決定更新為「Python 不支援終端開發人員」至「Python 3 已獲准供終端開發人員用於系統測試」。

人體工學

上述各語言的評估指標 - 人體工學。

回溯相容性

上述各項語言的評估標準中都討論了可維護性。

缺點、替代方案和未知事項

請參閱上文的「考慮使用的語言」一節。

成效

無

安全性考量

無

隱私權注意事項

無

測試

無

既有技術與參考資料