| RFC-0202：測試管理員式服務 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 將測試管理員做為服務設計。 |
| 問題 | |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2022-07-22 |
| 審查日期 (年/月) | 2022-12-14 |
摘要
目前對 Fuchsia 的測試是以測試管理工具的動態子項執行。這項設計可讓測試管理員在任何領域 (該產品擁有者有權建立的權限) 中啟動測試，讓測試作者在不變更測試管理員的情況下，轉送必要的執行器和功能。
提振精神
測試管理員會以動態子項的形式啟動測試，提供不同的密封/非密封功能以及樹狀結構內執行器。「測試管理員」目前的設計是以一組靜態內建測試執行器和測試範圍執行。樹狀結構外 (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、yanhcom
顧問：
元件架構團隊對於這項設計中使用的能力轉送、架構和測試 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 通訊協定 (範圍為「/」) 轉送至測試執行工具。
測試領域可以由平臺本身，或由產品擁有者透過部分現有/新機制編寫。到目前為止，只有平台可以定義測試領域，這項工作的目標是讓所有人都能使用測試領域定義和管理。
這項設計會假設兩種使用者類型。
- 測試領域作者：這位使用者建立及維護測試執行的運作範圍 (他們應有權在拓撲中建立運作範圍)。
- 測試作者：撰寫測試的作者，在運作範圍作者所建立的領域中執行。
Test Realm 作者會建立測試領域、進行設定並與建構工具整合，讓測試作者執行測試。您必須在測試領域中安裝 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",
},
],
},
]
}
領域作者會與建構工具整合，方便測試執行工具在執行期間讀取路徑名稱和測試集合。
「電工學」一節會簡單介紹一些解決方案，會將部分解決方案傳遞至測試執行工具，並提供詳細討論內容。
測試作者會使用其中一種人體工學解決方案 (TBD) 來執行測試，這會傳送資訊以測試執行者來執行測試。
測試執行工具將使用 RealmQuery API 查詢領域的領域物件，並使用建議的 AddSuiteInRealm API，將這些物件傳送至測試集合，並傳送至測試管理員。
也會視需要使用 LifecycleController API 解析路徑名稱。
這個設計需要以下變更：
- 修改 RealmQuery API 以讀取「offer」宣告。
- 系統會修改 Realm Builder Rust 用戶端程式庫，以使用提供的
fuchsia.component/RealmProxy 建構運作領域。 - 測試管理員會使用 Realm Builder 程式庫中的新方法，使用範圍限定為自訂領域的 Realm Builder 啟動測試執行個體。
- 測試管理員會使用提供的
offers，並使用 Realm Builder 轉送這些項目。 - 測試管理員會在測試環境中設定隔離記錄器、偵錯資料通訊協定、樹狀結構內執行器等。
測試管理員現在可以從測試領域連線至所有功能，因為測試管理員現在具備元件執行個體的控制代碼。
測試管理員會收集所有構件，並在測試結束後上傳測試結果。測試可以存取其父項領域提供的所有能力，以及測試架構提供的所有密封功能。
這種做法的優點
- 開發人員可以帶自己的執行者。
- 要立即達成這個目標，無需等待任何其他功能。
其他福利
- 開發人員可以依自身需求設定測試領域，不需要對核心產品或測試架構進行任何變更。
- 不需要支援自訂測試類型。
這個解決方案的缺點如下：
- 開發人員可以自行建立非密封的運作範圍來啟動測試，因此最終可能會產生出一連串的非密封測試，執行起來不費吹灰之力。
- 直接使用
ffx test的開發人員需要向工具提供路徑名稱和集合名稱。- ffx 測試是一項基礎工具，因此開發人員應使用呼叫 ffx 測試的其他工具，因此無需手動傳遞。
測試管理員可做為服務使用後的測試拓撲圖表。
實作
- 接受 fuchsia.component.Realm 物件，變更 Realm Builder 以允許其在任何領域中啟動元件，
- 變更測試執行工具，以接受領域資訊查詢路徑名稱的必要資訊。
- 變更測試管理員以實作新的 FIDL API，並在提供的領域和集合中啟動測試。
- 記錄異動內容和說明指南
- 與 OOT 開發人員合作，建立包含 OOT 執行器的運作範圍。
- 將目前的 OOT 測試轉移至新的領域
未來的工作：
- 使用自訂測試類型將目前的測試移植到自己的領域。
- 探索移除對開發人員的依賴。
- 將測試管理員中的所有測試領域移除，並將其發布至產品運作範圍。
效能
這項變更不會影響效能，也不會降低效能的影響，因為這不會影響測試的啟動方式，只會影響在拓撲中啟動測試的位置。
人體工學
本節說明將路徑名稱和測試集合傳遞至測試執行工具的一些解決方案。詳細解決方案不在本文件的討論範圍內。
與版本整合
定義自訂領域後，產品擁有者就能在建構系統中定義測試類別。測試作者會使用該類別，建構系統也會產生對應的路徑名稱和測試集合做為測試執行工具的輸入內容。
將資訊新增至測試資訊清單
我們可以在測試 facet 內嵌入和測試集合資訊。測試執行工具必須解析並讀取元件資訊清單檔案，才能取得資訊。
為提升人體工學的品質，Test Realm 作者會提供資訊清單資料分割，而測試作者可在測試資訊清單中加入這些資料分割。
回溯相容性
我們會持續支援目前的測試，並一律支援不需要自訂執行器的密封測試領域。
安全性考量
- 開發人員可以在系統的任何領域中啟動測試，但由於測試會在 eng 版本上執行，使用者裝置並不會受到這項異動的影響。
- 我們也會在測試執行工具中提供旗標，針對特定共用機器和建構作業停用這項功能。
- 我們必須將 RealmQuery 和 LifecycleController 轉送至所有測試執行工具。這可能會引發安全疑慮，具體取決於我們如何決定。 我們會在下一份文件中探討相關資訊，說明測試執行工具如何存取這項資訊。
隱私權注意事項
我們不會收集任何個人資料，因此這項設計不會對隱私權造成任何影響。
測試
目前的測試、新的整合項目和單元測試，在自訂領域中啟動測試，應該可以完整測試這項功能。
說明文件
記錄這項功能說明用途和實作指南，方便開發人員建立自己的測試領域。
此外，也記錄測試開發人員使用自訂領域的方式。
缺點、替代方案和未知
替代做法：由客戶自行啟動測試管理工具
測試開發人員會在拓撲中啟動自己的測試管理員。ffx 測試將使用 RCS 連線至 fuchsia.test.manager.RunBuilder 通訊協定，以執行及收集測試的結果。
這項解決方案的優點：
- 我們只需要變更 ffx 測試來支援
- 開發人員可以使用目前的測試管理員程式碼搭配自訂資訊清單， 在拓撲中使用 Test Manager 元件
這個解決方案的問題為：
- 一旦測試管理員在不同拓撲和 OOT 中執行，就很難變更測試管理員。這會影響「測試架構」團隊的速度。
- 用戶端需要將測試管理員所需的所有功能轉送至自己的拓撲。
- 用戶端必須撰寫測試，確保測試管理工具可在其拓撲中正常運作，並避免發生迴歸問題
替代組件：組件
子組件可以解決手上自備測試執行元件的問題，但其彈性不足。
我們提議的解決方案可讓我們日後能靈活地從測試管理員中移除所有硬式編碼的測試領域，並向產品資訊擁有者提供完整擁有權。
替代方法：測試套件自己的執行器
測試可套件自己的執行元件，並使用這些項目執行測試元件
這項解決方案的優點：
- 不需要進行任何變更
- 如果要達成這個目標
這個解決方案的問題為：
- 每次測試執行新執行元件對效能的影響。
- 需要將執行元件所需的功能轉送至測試 (破壞記憶性並削弱保證)。
- 需要為每個新的執行元件建立自訂領域 (基於能力轉送需求)。這會造成技術債務加劇。
替代做法：測試設定
將具備功能和功能來源的測試參數化，然後再將這些測試傳遞至測試領域本身。
"fuchsia.test.additional_capabilities": {
"runner": "dart_runner",
"source": "/core/dart/runner"
}
對於可轉送連線的功能，測試管理員可使用 RealmQuery API 透過 Realm Builder 代理要求。對於執行器，測試管理員可以使用中樞至 Proxy 執行元件通訊協定。
這項解決方案的優點：
- 測試會以測試管理員的子項的形式執行，因此測試管理員可完全控管其功能。
這個解決方案的問題為：
- 測試可能會依附於實際工作環境 API，因此會成為公開 API 的一部分。
- 使用中樞傳輸執行元件要求只是短期解決方案，我們最終需要巢狀或鏈結執行器。
- 測試可以存取任何系統能力，這可能是有關安全性破壞明確轉送安全性的系統功能，進而在遠處建立動作。
替代方法：測試管理員使用 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",
...
],
},
...
],
}
測試管理員會讀取商情項目，並使用提供的能力在指定的測試領域中查詢和啟動測試。
替代方法：測試管理員在拓撲中的已知位置執行系統測試
本設計建議指出拓撲中具有一個共同的已知位置 (例如 /core/tests)，測試管理員可在其中執行所有系統測試。平台開發人員會建立並維護這個已知領域，而測試管理員只會提供執行和收集測試成果的機制。
缺點
- 如果我們需要多個位置執行測試，設定能力會降低，日後也無法擴充。
- 我們希望未來能夠擁有巢狀 Test Manager，並可在同層級運作範圍中執行測試。這種設計不如預期。
- 我們可以使用這個 RFC 的設計，將 /core/tests 做為執行測試的領域來達成相同的功能。這個 RFC 提供更實用的彈性。
先前的圖片和參考資料
這是 Fuchsia 特有的概念，所以沒有同樣的概念。
未來工作
- 請從測試管理員拓撲中移除所有非密封運作範圍，並與客戶合作，將測試遷移至其自訂測試領域。
- 將「使用自己的測試經理」做為測試領域中的同層級。這有助於在工作階段或任何 OOT 領域執行測試，而無需平台中的任何特定產品支援。