| RFC-0221：適用於樹狀結構外系統測試的 Python | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 核准 Python 進行樹狀結構外系統測試。 |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2023-04-27 |
| 審查日期 (年-月-日) | 2023-06-13 |
摘要
核准 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 使用者要求的其他功能，以滿足平台測試需求 (例如效能監控、記憶體用量等)。
選擇程式設計語言的重要性
測試架構的採用情況很大程度上取決於所選語言。如果能使用簡單易懂的語言，且該語言已廣泛用於這個系統測試用途，將有助於擴大核心軟體工程師以外的範圍，納入測試工程師和系統整合人員。
評估量表
每種語言的一般優缺點 (TypeScript 和 JavaScript 除外) 已在 Fuchsia 程式設計語言政策 (FPLP) 中詳細說明。本文件使用的指標涵蓋與 OOT 系統測試特別相關的語言層面。
評估量表 (順序不代表重要性)：
生態系統採用：OOT 系統測試空間中的語言熱門程度
- 主流且廣泛使用的系統測試語言有助於採用 OOT。
- 請優先使用 OOT 客戶程式碼庫中已用於系統測試的語言。
人體工學：語言是否支援常見的系統測試模式
- 常見的系統測試模式是協調主機與裝置的互動，例如在受測的 Fuchsia 裝置 (DUT) 上觸發 API，並判斷行為。這類用途與傳統 Fuchsia 平台開發不同，需要使用另一組語言功能；以下是幾項主要差異：
- 優先考量開發靈活度，而非效能。
- 偏好自動記憶體管理和垃圾收集。
- 主機效能測試通常是次要考量。
- 偏好使用互動模式/REPL 快速設計原型。
- 較大的二進位檔/來源足跡較不具破壞性。
- 非同步語言支援是加分條件，但並非必要。
- 系統測試通常是較小的專案，程式碼行數只有數百行。相較於幾百行的程式碼，建議使用容易檢查正確性的可讀語言。(測試通常是正式版程式碼，但本身往往沒有經過充分測試，因此易於正確性推理很有用)。
- 優先考量開發靈活度，而非效能。
- 常見的系統測試模式是協調主機與裝置的互動，例如在受測的 Fuchsia 裝置 (DUT) 上觸發 API，並判斷行為。這類用途與傳統 Fuchsia 平台開發不同，需要使用另一組語言功能；以下是幾項主要差異：
Fuchsia 可攜性：輕鬆在主機和 Fuchsia 目標上執行
- 雖然本文件評估的語言主要會做為主機語言，但有些測試案例只能透過目標導向方式完成 (例如使用未匯出至主機的介面、只能在目標端實現的時間和輸送量保證)；因此，請務必考量語言的可攜性，以便在 Fuchsia 目標上執行系統測試。使用可攜式語言進行系統測試也有重複使用的好處 (例如在主機和目標上重複使用編碼/解碼等一般邏輯)。
所需投資：將 OOT 系統測試解決方案投入生產所需的作業
- 瞭解特定語言的差距，有助於我們在時間和資源有限的情況下，比較替代方案。
- 所需投資的例子：
- 建立支援
- 現有程式庫支援
- 開發測試架構
- 主機與裝置互動程式庫和工具 (例如 SL4F 支援)
- SDK 支援的語言
- 說明文件和開發人員教育
可維護性：維持 OOT 系統測試解決方案所需的工作
- 視所選語言而定，人員配置需求、程式碼健康狀態和技術債務可能會產生長期影響。
- 可維護性方面的例子：
- 執行階段可更新性 - 能夠更新執行階段，而不會中斷 OOT 使用者。
- Fuchsia API 版本管理 - 工具，可防止 Fuchsia API 變更導致 OOT 中斷。例如，如何偵測匯出至 OOT 使用者的系統測試 API 中斷性變更。
- 程式碼健康狀態
- 大型軟體專案通常會受益於靜態型別等語言功能。
- 輕鬆啟用自動靜態分析工具 (例如 Linter、涵蓋範圍等)。
考慮使用的語言
本節將介紹幾種考慮用於 OOT 系統測試的語言，並提供各項評估指標的證據。為簡化語言之間的比較，系統會根據每種語言的評估準則，為每個類別指派「不可行」、「不佳」、「中等」或「良好」的分數。
查看
生態系統採用情形：普通
- 中立：Go 是普遍受歡迎的語言 (TIOBE、PYPL)，但沒有證據顯示 Fuchsia 現有 OOT 合作夥伴廣泛使用 Go 進行系統測試。
- 優點：有證據顯示，在所有測試解決方案的廣泛範圍內，Go 都用於系統測試：
- Chromium 會在 Tast 作業中使用 Go。
- GCP Android 系統測試是以 Go 編寫。
人體工學：良好
- 優點：使用這種語言的人生產力很高 (FPLP)。
- 優點：支援垃圾收集，並提供記憶體安全保證 (FPLP)。
- 優點：Goroutine 可讓非同步通訊更精簡，更容易推論。
- 缺點：編譯語言不適合用於互動式系統測試開發。
Fuchsia 可攜性：中性
投資金額：無色彩
- 缺點：這個語言沒有實作通用的樹狀結構內系統測試解決方案。
- Go 語言的系統測試中有些先有技術，例如系統 OTA 測試，但沒有解決方案可泛用支援所有類型的系統測試 (例如多裝置測試)。
- 沒有通用的主機與 Fuchsia 裝置互動程式庫。
- 優點：Fuchsia 原始碼中存在 SL4F 用戶端程式庫。
- 中性：需要投入與其他考慮語言類似的 OOT 投資。
- 來源分布圖
- 中性：投資與其他語言類似。
- 靜態分析
- 優點：Fuchsia CI 已啟用
gofmt和govet。
- 優點：Fuchsia CI 已啟用
- 整合 Bazel
- 優點：Bazel 建構系統支援 Go。
- 來源分布圖
可維護性：良好
- 優點：可更新性 - 沒有證據顯示有重大更新問題。
- 您可以使用工具改寫 Go 檔案，使其符合新版 Go 的規定
- https://pkg.go.dev/cmd/fix.
- 優點：程式碼健康狀態 - 靜態型別語言有助於 OOT 程式碼健康狀態。
- 中立：Fuchsia API 版本管理 - 需要投入資源進行 API 版本管理，與其他考慮的語言類似。
Python
生態系統採用率：良好
- 優點：Python 是普遍使用的語言 (TIOBE、PYPL)。
- Python 是業界成長速度最快的程式設計語言，也是頂尖大學的熱門課程。
- 在 GitHub 活動中，Kotlin 的活躍程度僅次於 JavaScript，這代表 Kotlin 正在蓬勃發展。
- 優點：Mobly 是開放原始碼的多裝置 E2E 測試架構，也是 Google 內部多裝置系統測試的理想選擇。
人體工學：良好
Fuchsia 可攜性：中性
- 優點：Python 是可攜式語言，適用於所有現有主機平台，且隨著時間推移，Fuchsia 應會支援 Python，成為一般用途 OS 的可行選項。
- 缺點：Python 具有龐大的執行階段環境，且 Fuchsia 支援 Python 執行階段並無先例，因此支援 Python 需要投入大量資源。
所需投資：良好
優點：以 Python Mobly 為基礎的系統測試解決方案已在樹狀結構中存在。
- 優點：有 SL4F 用戶端程式庫。
優點：Fuchsia 中的 Pigweed 大量採用 Python。
中性：需要投入與其他考慮語言類似的 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 模組，達到高程度的絕對涵蓋範圍。
- 優點：可更新性 - RFC-0129 建立了樹狀結構內 Python 最佳做法 (例如 Python 3.8 以上版本)，應可避免發生重大的 Python 執行階段更新問題。
- 缺點 (中立，但需投入資源)：程式碼健全度 - 需要投入資源在 Python 靜態分析工具中，才能達到中立分數，否則 Python 缺乏靜態型別強制執行功能，可能會導致程式碼健全度不佳。
- 可能無法將靜態型別強制執行功能擴展至以 SDK 的 Python API 為基礎建構的 OOT 系統測試專案。雖然 Fuchsia 可以在 OOT 匯出的 Python API 中強制執行型別提示和程式碼涵蓋率，但 Python 沒有內建語言功能，可要求繼續執行這項做法。
- 我們有明確的解決方案來應對這些挑戰 (例如投資上游 Bazel Python 支援，在建構時強制執行型別提示)。
- 中立：Fuchsia API 版本管理 - 需要投入資源進行 API 版本管理，與其他考慮使用的語言類似。
TypeScript
生態系統採用情形：普通
人體工學：良好
- 優點：非同步支援功能完善，適合編寫裝置本身的指令碼。
- 優點：支援垃圾收集。
- 優點：JS 解譯器可讓使用者互動式開發/測試，不必編譯，這在遠端控制環境中特別有用。
Fuchsia 可攜性：良好
- 優點：Fuchsia 已透過實驗性 JavaScript 解譯器/殼層 - Josh (尚未正式推出)，展現 JS 執行階段支援功能。
投資需求：不佳
- 缺點：不屬於 Fuchsia 認可的語言 (FPLP)。
- 缺點：這個語言不支援樹狀結構內 GN 建構系統。
- 缺點：這個語言未實作樹狀結構內系統測試解決方案。
- 缺點：Fuchsia 原始碼中沒有 SL4F 用戶端程式庫。
- 中性：需要投入與其他考慮語言類似的 OOT 投資。
- 來源分布圖
- 中性：投資與其他語言類似。
- 靜態分析
- 缺點：樹狀結構內沒有現成的 TypeScript 支援。
- 整合 Bazel
- 優點：Bazel 建構系統支援 TypeScript。
- 缺點：Pigweed 團隊整合 TS 與 Bazel 時遇到負面體驗，因此刪除了所有 TS Bazel 整合項目。Pigweed 團隊的引言：
- TS Bazel 中斷無法偵錯。
- 節點生態系統未穩定整合。
- Google 內部工具是優先事項，因此 Bazel 團隊無法提供支援。
- OOT 基礎架構整合
- 缺點：沒有證據顯示 TS/JS 用於 Bazel 中以裝置為中心的系統測試。
- 來源分布圖
可維護性：良好
- 優點：程式碼健康狀態 - 靜態型別語言有助於 OOT 程式碼健康狀態。
- 中立：Fuchsia API 版本管理 - 需要投入資源進行 API 版本管理，與其他考慮的語言類似。
不適合的語言
由於一或多項評估指標不可行，因此深入分析中已移除程式設計語言。
C/C++
人體工學：不可行
- 缺點：手動記憶體管理會阻礙開發敏捷性。
- 對於偏好簡化而非效能的常見 OOT 系統測試用途，C/C++ 的效能優勢並不適用。
- 缺點：編譯語言不適合用於系統測試開發。
荒漠油廠
生態系統採用：不可行
人體工學：不可行
- 缺點：嚴格的記憶體安全語言語法會降低開發靈活度。
- Rust 的效能優勢和記憶體安全保障，不適用於偏好簡化而非效能的常見 OOT 系統測試用途。
- 缺點：Rust 的學習曲線相對陡峭。
- 缺點：Google 內部程式碼集不支援 Rust。
- 缺點：編譯語言不適合用於系統測試開發。
Dart
所需投資：不可行
- 缺點：從歷史來看，Dart 需要 2 位全職工程師，才能維護語言周圍的樹狀結構內基礎架構。
- 目前滾動式發布已凍結，現有測試的維護作業則由效能團隊盡力執行。
- 從上游推出新版本時，管理第三方程式庫生態系統通常會發生中斷。
- 缺點：Fuchsia.git 中允許使用過往用法，新增項目則須獲得豁免 (RFC-0176、FPLP)。
可維護性：不可行
- 缺點：執行階段與程式庫之間緊密耦合，以及 RFC-0176 中記錄的其他缺點，都讓 Dart 無法成為首選。
- 從 Dart 淘汰作業中歸納出的經驗：
- 請勿使用不穩定的開發中語言。
- 請勿依賴使用者人數較少的語言。
- 缺乏上游支援，難以廣泛採用。
- 從 Dart 淘汰作業中歸納出的經驗：
- 缺點：Dart 缺少支援 FIDL 版本控管所需的關鍵語言功能 (缺乏條件式編譯)，或動態產生的繫結，因此很難隨著 Fuchsia API 介面演進 Dart FIDL 繫結。
評估摘要
以下是 OOT 系統測試的程式設計語言評估摘要。
結論
根據上述評估結果，Go、Python 和 TypeScript 都是適合 OOT 系統測試的語言。不過，每種語言都有各自的優缺點，因此很難選出明確的「贏家」。最終，客戶需求 (「生態系統採用」維度) 的權重較高，可做為決勝因素，以便就語言達成共識，協助 OOT 客戶解除封鎖。
目前建議使用 Python 進行 OOT 系統測試核准，主要是因為 Python 符合產品需求，特別是能輕鬆與 Google 現有的測試架構整合。基於技術因素，Python 可能不是系統測試的絕對首選，但 Fuchsia 的 OOT 客戶需要這項功能。
總而言之，Python 的優點如下：
- OOT 合作夥伴普遍採用系統測試
- 符合人因工程學的語言功能，可提升系統測試的使用者體驗
- Fuchsia 原始碼中已有解決方案，因此可縮短產品化路徑
雖然在樹狀結構內和樹狀結構外，都需要額外投資才能達到與其他靜態型別語言相同的可維護性，但透過型別提示和透過改善 Fuchsia 的 Python 靜態分析工具強制執行涵蓋範圍，可望達到同等水準。
不過，如果自型別提示和涵蓋範圍在樹狀結構中強制執行，以及型別提示在一個 OOT 存放區中強制執行後 6 個月，出現大量與 Python 可維護性相關的錯誤和疑慮，我們就會重新評估是否要使用 Python 進行 OOT 系統測試。
請注意，本 RFC 核准 Python 用於 OOT 系統測試，並不代表其他語言無法用於這個領域。事實上，Fuchsia 將在 SDK 中匯出的重要 OOT 系統測試元件，就是專為擴充至任何主機端語言而設計的 Fuchsia 控制器，可支援主機與 Fuchsia 裝置之間的通訊。
實作
Fuchsia 程式設計語言政策需要更新，以反映這項 RFC 的提案，也就是核准 Python 用於 OOT 系統測試。
- 將 Python 語言決策從「不支援供終端開發人員使用 Python」更新為「核准終端開發人員使用 Python 3 進行系統測試」。
人體工學
如上所述，每種語言的評估指標 (人體工學) 都包含這項因素。
回溯相容性
如上所述，每個語言的評估標準都包含可維護性。
缺點、替代方案和未知事項
如上文「考慮使用的語言」所述。
效能
不適用
安全性考量
不適用
隱私權注意事項
不適用
測試
不適用