RFC-0164：Test Suite API

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

將套件通訊協定發布至 SDK 的 API 審查
變更
  • 655031
作者
審查人員
提交日期 (年/月)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 樹狀圖客戶必須建構及執行沒有樹狀結構中的測試，因此向 SDK 公開這個 API 可讓他們實作通訊協定，並自行導入執行階段進行測試。

設計

  • API 的實際程式碼定義，例如介面的 FIDL 定義。
  • Gerrit 變更連結，其中含有 API 程式碼：
  • 設計需求
    • 針對目前在 Fuchsia 樹狀結構中常用的測試套件執行測試。
    • 將測試結果表示為「結構化資料」，而非 stdout 的字元串流、處理回傳代碼和系統上的各種副作用。
    • 避免過度適配特定執行階段和測試架構，
    • 您應輕鬆推出支援新語言和測試架構。
    • CFv2 遷移工作的說明
    • 支援 Cfv2 測試。
  • 非目標：
    • 重新定義/重新定義測試。
      「BYOR」是指開發人員將自行應用自己的概念、架構和期望。我們很樂意適時。

未知

在早期設計期間，我們研究了先前對於主機端控制器與測試執行器之間的通訊通訊協定的機制，我們發現了先進技術，可以減少對產品或執行階段特有的假設。舉例來說，Android Jetpack 和 google3 Nitrogen 會假設 Android APK 和 JUnit 語意，用來描述測試類別、方法、註解、結果和錯誤等。

我們從 gtest、Rust、Dart、JUnit、pytest 等語言和測試架構 (gtest、Rust、Dat、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，該 API 可傳輸相當於每次疊代 FIDL 大小上限的資料。其他 API 以低 KB 傳輸資料。

安全性考量

  • 您的 API 是否公開了安全性機密資訊？
    • 不可以
  • 您的 API 是否可讓使用者控管安全性機密資源？
    • 不可以
  • 您的 API 使用者是否彼此獨立？
    • 是 (如果根據 API 設計實作)。
  • 您的 API 是否遵循物件能力準則？
    • 是
  • 您的 API 是否鼓勵使用者安全使用您的 API？
    • 您的 API 是否鼓勵使用時間檢查 (TOCTOU) 安全漏洞？
    • 否，但不需要這麼做，因為我們只能透過這個 API 執行測試
    • 您的 API 是否清楚區隔任何控制層與任何資料層？
    • 是

隱私權注意事項

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

測試不是互動式使用者計畫。不會運送產品給消費者。 開發人員在自己擁有的裝置中叫用測試，或從共用集區下載到這些裝置的裝置上，並先抹除測試再返回集區。

缺點與替代方案

您可以繼續使用 Cfv1 設計來進行測試，但這會大幅限制我們無法提供結構化測試結果，以及將多項測試和對應的正式版元件遷移至 Cfv2。