RFC-0164：Test Suite API

RFC-0164：Test Suite API
狀態已接受
區域
  • 測試
說明

API 審查，將套裝軟體通訊協定發布至 SDK
Gerrit 變更
作者
審查人員
提交日期 (年-月-日)2022-03-07
審查日期 (年-月-日)2022-05-05

編輯此 RFC

編輯 RFC 中繼資料

舊版 API 設計文件

這項 RFC 先前是以 API 設計文件提交，後來在 API 設計文件範本淘汰後轉換為 RFC。

目標和用途

  • 這個 API 或 API 功能解決了什麼問題？您的 API 使用者可以完成哪些工作？
    • 這個 API 將所有測試功能 (列舉、執行、觀察) 封裝至 FIDL 通訊協定。
    • 讓 Fuchsia 提供通用介面，以便使用統一的使用者體驗，在 Fuchsia 上列舉並執行 POSIX 測試。
    • 讓 Fuchsia 執行測試，並在各種測試架構中擷取標準結構化輸出內容。
    • 如要執行/執行 Cfv2 元件並取得其狀態，您必須公開部分能力。這個 API 提供不錯的介面，可封裝測試執行階段，並將其公開為 Fuchsia 能力。
    • OOT 樹狀結構客戶需要建構及執行不在樹狀結構內的測試，因此將此 API 公開給 SDK 可讓他們實作通訊協定，並提供自己的執行階段進行測試。

設計

  • API 的實際程式碼定義，例如介面的 FIDL 定義。
  • Gerrit 變更連結，其中包含 API 的程式碼：
  • 設計規定
    • 針對目前在 Fuchsia 樹狀結構中常用的測試套件執行測試。
    • 將測試結果表示為結構化資料，而非字元串流至 stdout、處理傳回碼，以及系統上的各種副作用。
    • 避免過度適合特定執行階段和測試架構。
    • 您應該可以輕鬆提供支援，以便使用新語言和測試架構。
    • 協助進行 CFv2 遷移作業
    • 支援 Cfv2 測試。
  • 非目標：
    • 重新定義/重新發明測試。
      BYOR 是指開發人員會自備概念、架構和期望。我們的角色是協助。

未知

在設計初期，我們研究了主機端控制器和測試執行程式之間通訊的先前技術。我們發現先前技術依賴的假設，多半與特定產品或執行階段相關。舉例來說，Android Jetpack 和 google3 Nitrogen 會假設 Android APK 和 JUnit 語意可用來描述測試類別、方法、註解、結果、錯誤等。

我們在設計時，參考了對語言和測試架構 (gtest、Rust、Dart、JUnit、pytest) 的一般知識。我們在腦中確認可以為這些範例實作用戶端和伺服器，並為 C++ gtest、Rust 和 Golang 實作可運作的範例。

我們無法得知自己不知道的事，因此未來會持續修訂這項通訊協定。

可用性

本節將說明 API 可用性相關問題：

  • API 的語意是否能從其簽名中看出？
    • 是
  • 您是否已設計適當的擴充功能點，以便日後改良 API？
    • 是
  • 您的 API 是否會以類似於其他 Fuchsia API 的方式運作？
    • 否，目前沒有這類 Fuchsia API，可在精細層級執行測試並傳回結構化結果。
  • 與其他平台的類似 API 相比，您的 API 的運作情形為何？
    • 無

我們使用 C++ 和 Rust 這兩種語言實作端對端用途範例，展示了這項工具的可用性和通用性

測試

  • 您打算如何測試 API？
    • 這個 FIDL API 的實作項目已在 Rust 和 C++ 中進行廣泛測試。
  • 如果開發人員需要使用您的 API 功能，他們會如何測試程式碼？
    • 這個實作基本上會實作執行測試的機制。開發人員應撰寫
    • 單元測試，用於測試內部程式碼。
    • 整合測試，確保實作內容與架構一致。

效能考量

  • 您的 API 是否涉及跨越程序或執行緒邊界進行大量往返作業？
    • 否
  • 您的 API 是否會在遠端程序或執行緒上造成阻斷？
    • 否
  • 您的 API 是否涉及大量資料的複製作業？
    • 可以，但必須使用通訊端和迭代器。
  • 您預期 API 每秒會收到多少查詢 (QPS)？
    • 每個測試都會透過測試執行元件實作並公開此通訊協定，並在測試執行完畢後解除。每個測試用戶的查詢數量取決於測試案例數量和吞吐量。
  • 您預期一般查詢會傳輸多少資料？
    • 對於列舉 API，它可以傳輸等同於每個迭代動作的最大 FIDL 大小資料。其他 API 則以低 KB 傳輸資料。

安全性考量

  • 您的 API 是否會公開安全性敏感資訊？
    • 否
  • 您的 API 是否允許使用者操作安全性敏感資源？
    • 否
  • 您的 API 使用者是否彼此獨立？
    • 是 (如果是依照 API 設計導入的話)。
  • 您的 API 是否遵循物件能力規範？
    • 是
  • 您的 API 是否鼓勵使用者安全地使用 API？
    • 您的 API 是否會導致「檢查時間到使用時間」(TOCTOU) 安全漏洞？
    • 否，但我們只會使用這個 API 執行測試，因此不需要執行測試
    • 您的 API 是否清楚區分任何控制層和任何資料層？
    • 是

隱私權注意事項

  • 您的 API 是否會公開隱私權敏感資訊？
    • 否
  • 您的 API 是否涉及任何個人識別資訊？
    • 否
  • 您的 API 是否涉及任何裝置 ID？
    • 否
  • 您的 API 是否可讓使用者控管資訊分享方式？
    • 不會分享任何使用者資訊。

測試不是互動式使用者程式。不會運送給消費者。開發人員會在自己擁有的裝置上執行測試，或是在共用資源池中借用裝置，並在歸還前將裝置清除。

缺點和替代方案

我們可以繼續使用 Cfv1 設計進行測試執行，但這會大幅限制我們提供結構化測試結果的能力，並將各種測試和對應的正式版元件遷移至 Cfv2。