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

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

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

編輯此 RFC

編輯 RFC 中繼資料

摘要

核准執行樹狀結構 (OOT) 系統測試的 Python。

提振精神

有一項已知需求，需要改善 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 系統測試評分量表以及每個程式設計語言的評估作業。

定義

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

產品相關規定

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

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

環境：樹狀圖以及 SDK 送往的所有環境和花瓣。

策略遊戲

  • 將用途範圍限定為涉及一或多個目標裝置的 E2E 裝置測試。
  • 提供將現有 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 故障，例如如何偵測匯出至 OOT 使用者的系統測試 API 的破壞性變更。
      • 程式碼健康狀態
        • 大型軟體專案通常能使用靜態輸入等語言功能。
        • 啟用自動化靜態分析工具 (例如 Linter 、涵蓋率等) 的難易度。

支援的語言

本節說明用於 OOT 系統測試的數種語言，並提供各項評估指標的證據。為方便比較語言，每種語言評估評分量表的分數可能是「Infeasible」、「Bad」、「Neutral」或「Good」等分數。

查看

生態系統採用：中立

  • 中立：Go 是普遍的用語 (TIOBE、PYPL)，但沒有任何證據顯示 Fuchsia 現有 OOT 合作夥伴在系統測試空間中廣泛使用 Go。
  • 專家：有證據顯示，貴機構在更廣泛的測試解決方案中使用 Go 進行系統測試：

人體工學：良好

  • 專家：這個語言使用者的工作效率高 (FPLP)。
  • 專家：支援垃圾收集和記憶體安全保證 (FPLP)。
  • 優點：Goroutines 可讓非同步通訊的密集度變得精簡，且更容易進行說明。
  • Con：經過編譯的語言，不適合用於互動式系統測試的開發。

Fuchsia 可攜性：中等

  • Pro：在 Fuchsia 中，Go 執行階段支援先有藝術 (例如 fidlgen)。
  • Con：不建議進行平台開發 (FPLP)。

需要投資：普通

  • 缺點：這個語言沒有實作一般的樹狀結構內系統測試解決方案。
    • 系統 OTA 測試中有一些舊版以 Go 為基礎的系統測試，但目前沒有解決方案，沒有一般支援所有類型的系統測試 (例如多裝置測試) 解決方案。
    • 沒有 Fuchsia 裝置互動程式庫的一般主機。
  • Pro： Fuchsia 原始碼中存在 SL4F 用戶端程式庫。
  • 中立：需要採用類似其他需要考慮的語言方面的 OOT 投資。
    • 來源分佈
      • 中立：與其他語言類似的投資。
    • 靜態分析
      • Pro：gofmt 和 govet 已在 Fuchsia CI 中啟用。
    • Bazel 整合

可維護性：良好

  • 優點：可更新性 - 沒有重大可更新性問題的證據。
    • 可使用工具重新編寫 Go 檔案，以符合新版 Go 版本的規定
    • https://pkg.go.dev/cmd/fix.
  • 專家：程式碼健康狀態 - 使用靜態輸入的語言對 OOT 程式碼沒有幫助。
  • 中立：Fuchsia API 版本管理 - 需要投資與其他應考量的語言類似的 API 版本管理。

Python

生態系統採用：良好

  • 專家：Python 是普遍的程式語言 (TIOBE、PYPL)。
    • Python 是成長最快速的主要程式設計語言產業 也在頂尖大學接受教育
    • 這也是 GitHub 活動中的 JavaScript 的第二階段，也是積極開發的跡象。
  • Pro：Mobly 是開放原始碼多裝置 e2e 測試架構，是內部光線充足的路徑，可在 Google 進行多裝置系統測試。

人體工學：良好

  • 專家：這個語言使用者的工作效率高 (FPLP)。
  • 專家：支援垃圾收集 (FPLP)。
  • 專家：Python 直譯器可讓使用者以互動的方式進行開發/測試，而無需編譯，這在遠端控制環境中特別實用。

Fuchsia 可攜性：中等

  • 優點：Python 是適用於所有現有主機平台的可移植語言，應支援 Fuchsia 全面支援，以做為一般用途的 OS。
  • Con：Python 有大量的執行階段環境，而且沒有先進支援 Fuchsia 中的 Python 執行階段，因此支援 Python 必須投入大量心力。

須投資：良好

  • Pro：樹狀結構中已有 Python Mobly 式系統測試解決方案。

  • 專家：Pigweed in Fuchsia 投入大量心力發展 Python 應用程式。

    • 在我們的下游專案中，大量使用 Python 進行開發、測試自動化、工廠工具等。
    • 未來將無限期針對 OOT Python 投入大量資源 (連結 1、連結 2)。
    • 他們投入 GN 和 Bazel 工具；GN 工具已經成熟，而 Bazel 工具仍在持續開發中。

  • 中立：需要採用類似其他需要考慮的語言方面的 OOT 投資。

    • 來源分佈
      • 中立：與其他語言類似的投資。
    • 靜態分析
      • Con：透過類型提示進行靜態輸入的優點 (PEP 484) 需要投資基礎架構，才能自動進行靜態類型檢查。
      • 專家：Pigweed 已在 GN 中自動化處理，以便 Fuchsia.git 使用。
    • Bazel 整合
      • Pro：Bazel 建構系統支援 Python。
      • Pro：無論 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 屬於測試導向，因此每次發生執行階段版本碰撞時，都應該透過現有的樹狀結構內檢查來行使這些檢查。為了達到最大信賴水準，您必須在 Python 原始碼涵蓋率方面投入資金，以便監控並對所有以 SDK 為基礎的 Python 模組進行高程度的絕對涵蓋率。
  • Con (還算投資)：程式碼健康狀態 - 需要投資 Python 靜態分析工具以達到中立分數，否則 Python 缺乏靜態輸入機制可能會導致程式碼健康狀態不良。
    • 可能無法將靜態輸入強制執行措施延伸到以 SDK 的 Python API 建構的 OOT 系統測試專案。雖然 Fuchsia 可在匯出 OOT 的 Python API 中強制套用類型提示和程式碼涵蓋率，但 Python 中沒有內建語言功能，因此必須執行 OOT 作業。
    • 解決這些挑戰的方法有很多種，例如投資上游 Bazel Python 支援，以便在建構期間強制執行類型提示。
  • 中立：Fuchsia API 版本管理 - 需要投資類似於其他需要考量的語言的 API 版本管理。

TypeScript

生態系統採用：中立

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

人體工學：良好

  • 專業版：非同步支援，適合將裝置本身的指令碼編寫使用。
  • 優點：支援垃圾收集。
  • 優點：JS 解譯器可讓使用者以互動的方式進行開發/測試，而不需編譯，在遠端控制上特別實用。

Fuchsia 可攜性：良好

  • 專家：Fuchsia 透過實驗性 JavaScript 解譯器/殼層 - Josh (未生產) 證明瞭 JS 執行階段支援。

須投資：不良

  • Con：並非經過核准的語言，可用於富奇亞 (FPLP)。
  • Con：不支援這個語言的樹狀結構內 GN 建構系統。
  • 缺點：沒有以這個語言實作的樹狀結構內系統測試解決方案。
  • Con： Fuchsia 原始碼中不存在 SL4F 用戶端程式庫。
  • 中立：需要採用類似其他需要考慮的語言方面的 OOT 投資。
    • 來源分佈
      • 中立：與其他語言類似的投資。
    • 靜態分析
      • Con：目前沒有 TypeScript 的樹狀結構內支援。
    • Bazel 整合
      • Pro：Bazel 建構系統支援 TypeScript。
      • Con：Pigweed 團隊在整合 TS 與 Bazel 時，發現到開始刪除所有 TS Bazel 整合時，都會出現負面體驗。評分 Pigweed 團隊：
        • TS Bazel 故障無法進行偵錯。
        • 節點生態系統未穩定地整合。
        • 優先處理 Google 內部工具，因此 Bazel 團隊未提供支援。
    • OOT 基礎架構整合
      • Con：在 Bazel 中，沒有使用 TS/JS 進行裝置導向系統測試的證據。

可維護性：良好

  • 專家：程式碼健康狀態 - 使用靜態輸入的語言對 OOT 程式碼沒有幫助。
  • 中立：Fuchsia API 版本管理 - 需要投資類似於其他需要考量的語言的 API 版本管理。

系統判定無法使用的語言

由於一或多個評估指標有功能性，因此系統會將程式設計語言從深入分析中移除。

C/C++

人體工學：無法行動

  • 缺點：手動管理記憶體，會對開發靈活度造成負面影響。
    • C/C++ 的效能主體不適用於一般 OOT 系統測試用途，而這些用途偏好簡便而非效能。
  • 缺點：編譯的語言不適合用於系統測試開發。

Rust

採用生態系統：不可行

  • Con：Rust 不是通用的常用語言 (TIOBE、PYPL)，也未廣泛用於系統測試。

人體工學：無法行動

  • Con：確保記憶體安全性採用嚴格的語言語法，可以降低開發的靈活性。
    • Rust 的效能管理服務和記憶體安全保證不適用於一般 OOT 系統測試用途，而這些用途偏好簡化作業而非效能。
  • 缺點：Rust 的學習曲線相對困難。
  • Con：Google 的內部程式碼集不支援 Rust。
  • 缺點：編譯的語言不適合用於系統測試開發。

飛鏢

須投資：無法行動

  • Con: Dart 過去要求 2 名全職工程師負責管理該語言周圍的樹狀結構內結構基礎架構。
    • 目前滾動週期會凍結，且效能團隊會盡力為現有的測試執行維護作業。
    • 以往管理 3p 程式庫生態系統時，在上游出現新的滾車時，往往會失敗。
  • Con：過去使用記錄已列入 Fuchsia.git 的許可清單，新新增項目需符合豁免條件 (RFC-0176、FPLP)。

可維護性：無法使用

  • Con：執行階段和程式庫之間的緊密耦合，以及 RFC-0176 中記錄的詳盡短片段。
    • Dart 淘汰作業摘要：
      1. 請勿採用不穩定的開發語言。
      2. 請勿只使用人數不多的專門使用者。
      3. 缺少上游支援會導致廣泛採用。
  • Con：Dart 缺少支援 FIDL 版本管理 (缺少條件式編譯) 或動態產生的繫結所需的主要語言功能，因此將難以根據 Fuchsia API 介面來改進 Dart FIDL 繫結。

評估摘要

以下視覺化摘要說明用於 OOT 系統測試的程式設計語言評估。

替代文字：評估摘要

結語

根據上述的評估範例，Go、Python 和 TypeScript 都是可能符合 OOT 系統測試工作的語言。不過，每種語言各有其優缺點，難以選取清楚的「勝出」這個說法。總結來說，客戶需求 (「生態系統採用」維度) 比拼湊出定位更嚴重，以使目前的語言無法滿足 OOT 客戶的需求。

目前，建議 Python 用於 OOT 系統測試，主要原因是其與產品需求一致，尤其適合與 Google 現有的測試架構整合。基於技術因素， Python 或許並不建議用於系統測試，但 Fuchsia 的 OOT 客戶需要此功能。

簡單來說，Python 的優點：

  1. OOT 合作夥伴全面採用系統測試的方式
  2. 符合人體工學的語言功能，有助系統測試使用者體驗
  3. 由於 Fuchsia 原始碼中現有解決方案，可縮短實際工作環境化的路徑

雖然要達到與其他靜態類型語言之間的可維護性，需要額外投資，

因此，如果已在樹狀結構中強制執行類型提示和涵蓋範圍，並在 6 個月後對 Python 維護性提供相關錯誤和疑慮，且已在一個 OOT 存放區中強制執行類型提示，系統將會重新審視 Python for OOT 系統測試的使用情況。

請注意，在這個 RFC 中允許執行 OOT 系統測試的核准，並不會防止其他語言在此空間中使用。事實上，Fuchsia 在 SDK 中匯出的主要 OOT 系統測試元件會是 Fuchsia Controller，這個控制器經過特別設計，可擴充到任何主機端語言，以支援主機對 Fuchsia 裝置的通訊。

實作

Fuchsia 程式設計語言政策需要更新，以反映此 RFC 針對 OOT 系統測試核准 Python 的提案。

  • 將 Python 語言決策從「Python 不支援端對端開發人員」更新為「Python 3 已獲開發人員核准用於系統測試」。

人體工學

上方討論了我們在評估指標：人體工學方面的每種語言。

回溯相容性

如上所述，我們在評估評分量表中列出了每種語言 - 可維護性。

缺點、替代方案和未知

請參閱上方考量語言一節。

效能

無

安全性考量

無

隱私權注意事項

無

測試

無

先前的圖片和參考資料