RFC-0202：測試管理員服務

摘要

目前在 Fuchsia 中進行測試是做為測試管理工具的動態子項。 這項設計讓測試管理員在任何領域 (該產品) 中啟動測試 擁有者有權建立)，並允許測試作者 無須變更測試管理工具即可。

提振精神

Test Manager 以動態子項的形式啟動測試，提供各式各樣的 密封/非密封的能力，以及樹狀結構內跑者。Google 目前的設計 測試管理工具是使用一組靜態的內建測試執行器來執行，並進行測試 運作範圍不得加入樹狀結構外 (OOT) 和樹狀客戶內 為自己的測試跑者和必要的功能 而隨著我們開發的客源增加 就必須支援他們的用途本文件建議 的功能」讓客戶可以在 可能與測試經理的運作領域不同這樣一來， 負責將必要的系統功能轉送給測試經理 進行測試。

相關人員

講師：davemoore@google.com

審查人員：geb@google.com、shayba@google.com、richkadel@google.com、 kjharland@google.com、crjohns@google.com、cgonyeo@google.com、 aaronwood@google.com、satsukiu@google.com、xbhatnag@google.com、 yaneury@google.com、hjfreyer@google.com、akbiggs@google.com

諮詢：

元件架構團隊曾諮詢能力相關問題 此設計中使用的轉送、架構和測試 API

社交功能：

這個 RFC 經過了測試架構的設計審查 元件架構團隊

設計

在此設計產品中，產品擁有者將決定測試的執行位置和測試 執行程式 (ffx test/run-test-suite) 會將必要資訊傳入 測試經理。我們會在 RunBuilder 通訊協定中新增方法 稱為 AddSuiteInRealm 等資料庫服務，然後傳入必要的領域資訊

  AddSuiteInRealm(resource struct {
      // The realm which contains the collection to launch the test in
      realm client_end:fuchsia.component.Realm;
      // All offers from the realm to the test collection
      offers: Vec<Capabilities>
      // the test collection to launch the test in.
      test_collection: string

      // ... existing fields from AddSuite
  });

測試管理員會使用上述資訊，在 使用 Realm Builder 進行收集，同時提供獨立的記錄器、涵蓋率 集合、樹狀結構內執行器等，以便支援測試執行。元件管理員 會將 LifecycleController 和 RealmQuery 通訊協定 (範圍為「/」) 轉送至 測試執行程式

測試領域可由平臺本身或產品擁有者編寫 來解決整體問題目前，只有平台可以定義 研究領域，設法讓測試領域的定義開放所有人存取 和管理 AI 的方式

此設計假設使用者分為兩種類型。

• 測試領域作者：這位使用者會建立並維護 測試將會執行 (他們應有權在 拓撲)。
• 測試作者：測試的作者，會在 領域作者。

測試運作範圍作者：建立測試領域、設定測試運作範圍，並與建構作業整合 協助「測試作者」執行測試。使用者必須 測試運作領域中的Realm Builder 資料分割，才能讓這項功能正常運作。

測試領域範例：

{
  include: [
      "sys/component/realm_builder.shard.cml",
  ],
  collections: [
      // The collection to launch test in
      {
          name: "tests",
          environment: "#test_env",
          durability: "transient",
      },
  ],
  offer: [
      {
          protocol: [
              // Some system or mocked protocol
              "fuchsia.foo.bar",
              ...
          ],
          from: "parent",
          to: [
              "#tests",
          ],
      },
      ...
  ],
  environments: [
      {
          name: "test_env",
          extends: "realm",
          runners: [
              // Offer some OOT runner to the test
              {
                  runner: "fuchsia_oot_runner",
                  from: "parent",
              },
              // TODO(https://fxbug.dev/42063673): Abstract out into a shard.
              // This is important so that Realm Builder can work.
              {
                  runner: "realm_builder",
                  from: "#realm_builder_server",
              },
          ],
          resolvers: [
              // This is important so that Realm Builder can work.
              {
                  resolver: "realm_builder_resolver",
                  from: "#realm_builder_server",
                  scheme: "realm-builder",
              },
          ],
      },
  ]
}

領域作者會提供建構工具的整合功能，以便進行測試 執行器可以在執行期間讀取路徑名稱和測試集合。

倫理學一節簡短探討幾項可傳遞的解決方案 測試執行程式的路徑名稱和測試集合名稱，並提供詳細討論 則不在本文件的範圍內。

測試作者將使用其中一項人體工學解決方案 (待定) 執行測試。 這些指令會傳入資訊，用於測試執行程式來執行測試。

測試執行工具會使用 RealmQuery API 查詢 領域內的領域物件，以及所有優惠傳送至測試集合並通過 他們可以使用提議的 AddSuiteInRealm API 來測試管理員

也會使用 LifecycleController API 解決問題 視需要路徑名稱

這個設計需要進行以下變更：

• 修改 RealmQuery API 以讀取「offer」宣告內容
• 將修改 Realm Builder Rust 用戶端程式庫，允許建構 和提供的 fuchsia.component/Realm Proxy 的領域。
• 測試管理工具會使用 Realm Builder 程式庫中的新方法啟動 使用範圍限定為自訂領域的 Realm Builder 測試執行個體。
• 測試管理員會使用提供的 offers，並透過運作範圍轉送這些變數 建立工具
• 測試管理員會設定獨立的記錄器、偵錯資料通訊協定、樹狀結構內 呼叫器等

測試管理員現在可以從測試領域連線至所有功能，因為現在這項功能 都能取得元件執行個體的控制代碼

測試管理工具會收集所有構件，並在 測試結束。測試可以存取父項領域的任何能力 並提供測試架構提供的所有密封功能

這種方法的優點

• 開發人員可以自備跑者。
• 你現在可以做到這一點了。不必等待任何其他 接著介紹網際網路通訊層 包括兩項主要的安全防護功能

其他福利

• 開發人員可以視需要設定測試領域，不必 核心產品或測試架構所需的變更。
• 不需要支援自訂測試類型。

這項解決方案的缺點如下：

• 開發人員可以自行建立非密封的領域並進行測試，因此， 我們就會訂出一堆非密封的測試，這些測試可以 不費吹灰之力
• 直接使用 ffx test 的開發人員需要提供自己路徑名稱 集合名稱提供給工具
  • ffx 測試是基本工具，因此開發人員建議使用其他工具 呼叫 ffx 測試，而您不需要手動傳遞 路徑名稱。

這個測試拓撲圖 可以做為測試經理 課程中也會快速介紹 Memorystore 這是 Google Cloud 的全代管 Redis 服務

實作

• 變更 Realm Builder，允許其以任意運作範圍啟動元件，方法是： 接受 fuchsia.component.Realm 物件
• 變更測試執行程式，接受領域資訊查詢篩選作業的必要資訊 可能不準確或不適當
• 變更測試管理員，導入新的 FIDL API，並利用提供的 領域和集合。
• 記錄異動內容和說明指南
• 與 OOT 開發人員合作，建立包含 OOT 跑者的領域。
• 將目前的 OOT 測試移植至新的領域

未來工作：

• 使用自訂測試類型將測試轉移至自己的領域。
• 瞭解如何移除對單手內容的依附元件。
• 請從測試管理工具中移除所有測試運作範圍，然後發布至產品中 運作範圍

成效

這項變更不會影響成效，也不會減少影響。 測試的啟動方式，只會影響 拓撲

人體工學

本節說明一些要傳入路徑名稱和測試集合的解決方案 測試執行程式詳細的解決方案不在本文件的討論範圍內。

與建構作業整合

定義自訂領域後，產品負責人就可以在 建構系統測試作者會使用該類別和建構系統 會產生對應的路徑名稱和測試集合，做為測試的輸入項目 執行程式

將資訊新增至測試資訊清單

我們可以在測試 facet 內嵌入路徑名稱和測試收集資訊。測試 執行程式必須解析及讀取元件資訊清單檔案 這些資訊

為提升作業效率，Test Realm 作者會提供資訊清單資料分割， 測試作者可以包含在測試資訊清單中。

回溯相容性

我們會持續支援目前的測試，並持續進行記憶測試 而不需要自訂執行器。

安全性考量

• 開發人員可以在系統中的任何領域啟動測試，但隨著測試 使用者裝置不會受到這項異動影響。
  • 我們也會在測試執行程式中，提供用來停用特定功能 共用機器和建構作業
• 我們必須將 RealmQuery 和 LifecycleController 轉送至所有測試 執行工具這可能會讓使用者擔心，這取決於我們如何決定。 設計測試執行者將如何設計測試時，我們會在下一份文件中討論 都能使用這類資訊

隱私權注意事項

我們不會收集任何個人資料，因此這項設計不會有任何隱私權 效果。

測試

進行現有測試，並在其中加入新的整合項目和單元測試，以便在 自訂領域應完整測試這項功能

說明文件

記錄這項功能，瞭解 建立自己的測試領域。

同時也記錄測試開發人員使用自訂運作範圍的方式。

缺點、替代方案和未知

替代做法：客戶啟動自己的測試管理工具

測試開發人員會在拓撲中啟動自己的測試管理工具。ffx 測試 將使用 RCS 連線至 fuchsia.test.manager.RunBuilder 通訊協定以執行 測試並收集結果

這項解決方案的優點：

• 我們只需變更 ffx 測試來支援這項功能
• 開發人員可以將目前的測試管理員程式碼與自訂資訊清單搭配使用 在拓撲中使用測試管理工具元件

這項解決方案的問題如下：

• 一旦測試管理員在各種不同的環境中執行，就很難變更 頂層和 OOT這將大幅影響測試架構團隊
• 用戶端必須將測試經理所需的所有功能轉送到 和各自的拓撲
• 用戶端必須編寫測試，確保測試管理工具正常運作 並防止發生迴歸問題

替代做法：子組裝

子組件可以解決我們派出測試執行元件的問題，但 不像提案的解決方案一樣靈活。

提議的解決方案方便日後能靈活運用 透過測試管理員取得編碼測試運作範圍，並提供產品的完整擁有權 擁有者。

替代做法：測試套件自己的跑者

測試可以套件專屬的執行元件，並使用這些元件執行測試元件

這項解決方案的優點：

• 不需要進行任何變更
• 想立即達成這個目標嗎？

這項解決方案的問題如下：

• 為每項測試執行新執行元件對效能影響。
• 需要將執行元件所需的功能轉送至測試 (中斷情形) 並削弱我們的保證)。
• 必須為每個新執行元件建立自訂領域 (因為能力 轉送需求)。這會加重技術債。

替代做法：測試設定

根據功能和這些功能的來源，將測試參數化。 然後傳送到測試領域本身

"fuchsia.test.additional_capabilities": {
  "runner": "dart_runner",
  "source": "/core/dart/runner"
}

對於可路由系統傳送的功能，測試管理員可使用 RealmQuery API 以使用 Realm Builder 代理要求。適用對象 執行器，測試管理員可使用中樞 Proxy 執行元件通訊協定。

這項解決方案的優點：

• 測試會以測試管理工具的子項的形式執行，以便測試管理員能完整控管 Kubernetes 的功能

這項解決方案的問題如下：

• 測試可能取決於實際環境，因此會成為 暴露在風險中
• 使用 Hub 代理執行元件要求只是短期解決方案 最終需要巢狀或鏈結的執行器
• 這些測試可以存取任何可能為安全的系統能力 包括破壞明確路徑，在一段距離下創造行動。

替代方法：Test Manager 使用 RealmQuery API

在此設計中，測試管理員將可存取 RealmQuery API，並透過該 API 查詢必要資訊 再開始測試

測試作者會使用資料分割來包含領域和測試集合 測試資訊清單中的資訊

資料分割：

{
  facets: {
    "fuchsia.test": {
      launch: {
        realm: "/core/foo/bar/test_realm",
        collection: "tests" // default is "tests", can be omitted.
      }
    },
  },
}

test.cml:

{
    include: [
        "syslog/client.shard.cml",
        "//some/path/oot_runner/default.shard.cml",
        "//some/path/test_realm/default.shard.cml",
    ],
    program: {
        binary: "bin/sample_test",
    },
    use: [
      {
          protocol: [
              "fuchsia.foo.bar",
              ...
          ],
      },
      ...
  ],
}

測試管理工具會讀取 facet，並使用提供的能力來查詢及 在指定的測試領域中啟動測試。

替代做法：測試管理工具會在拓撲中的已知位置執行系統測試

這項設計建議，拓撲會產生一個常見的已知位置 (例如 /core/tests)，測試經理可執行所有系統測試。 平台開發人員會建立及維護這個已知領域和測試環境 管理員只會提供執行及收集構件的機制 進行測試。

缺點

• 設定的可用性較低，日後如果需要多個專案，也無法擴充 執行測試
• 我們希望日後能建立巢狀測試管理工具，以便執行測試 同理，但我們不建議這種設計。
• 我們可以透過這個 RFC 設計實現相同的功能 。墨西哥聯邦納稅義務人編號 (RFC) 提供了更多彈性，我們認為這方面的用途

既有藝術品和參考資料

這項概念是 Fuchsia 獨有的概念，因此並無與先前相同。

未來工作

• 請從測試管理員拓撲中移除所有非密封運作範圍，並與我們的 以便將測試環境移至自訂的測試領域。
• 「使用自己的測試經理」設計和測試領域的同層這個 在沒有 OOT 運作的情況下，在工作階段或 OOT 領域執行測試 需要平台中任何產品方面的支援。