| RFC-0202：將測試管理員設為服務 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 設計測試管理員的服務。 |
| 問題 | |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2022-07-22 |
| 審查日期 (年-月-日) | 2022-12-14 |
摘要
目前，Fuchsia 上的測試會以 Test Manager 的動態子項執行。這項設計可讓 Test Manager 在任何領域 (產品擁有者有權建立) 啟動測試，進而讓測試作者能夠轉送必要的執行程式和功能，而無須變更 Test Manager。
提振精神
測試管理員會以動態子項啟動測試，為其提供各種密封/非密封功能和樹狀結構中的執行程式。目前的 Test Manager 設計是使用一組靜態內建測試執行器和測試領域來執行。這項功能不允許樹狀結構外 (OOT) 和樹狀結構內客戶納入自己的測試執行程式和必要功能，但隨著客戶人數增加，我們需要支援他們的用途。本文件提出「Test Manager 做為服務」的概念，讓客戶可以在自己選擇的測試領域 (可能位於 Test Manager 領域之外) 執行測試。這樣一來，Test Manager 在將必要系統功能轉送至測試時，負擔的責任就會減少。
相關人員
協助人員：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) 會將必要資訊傳遞給 Test Manager。我們會在 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 通訊協定 (範圍為「/」) 轉送至測試執行程式。
測試領域可以由平台本身編寫，也可以由產品擁有者使用某些現有/新機制編寫。目前只有平台可以定義測試領域，而這項工作旨在讓測試領域定義和管理作業民主化。
這項設計假設有兩種使用者。
- 測試 Realm 作者：這個使用者會建立並維護測試執行的領域 (他們應具備在拓樸中建立領域的權限)。
- 測試作者：測試作者，會在領域作者建立的領域中執行。
測試 Realm 作者會建立測試領域、設定並整合建構工具，以便測試作者執行測試。他們必須在測試領域中安裝 Realm 建構工具區塊，才能使用這項功能。
測試範例領域：
{
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 將這些物件傳遞給 Test Manager。
必要時，也會使用 LifecycleController API 解析路徑名稱。
此設計必須進行下列變更：
- 修改 RealmQuery API 以讀取「offer」宣告。
- 我們會修改 Realm Builder Rust 用戶端程式庫，讓您可以使用提供的
fuchsia.component/Realm代理程建構領域。 - Test Manager 會使用 Realm Builder 程式庫中的新方法，啟動使用 Realm Builder 且範圍限定為自訂領域的測試例項。
- 測試管理員會使用提供的
offers，並使用 RealmBuilder 進行路由。 - 測試管理工具會在測試環境中設定隔離的記錄器、偵錯資料通訊協定、樹狀結構內的執行者等。
由於 Test Manager 現已擁有元件執行個體的句柄，因此可連線至測試領域的所有功能。
測試結束後，Test Manager 會收集所有構件，並上傳測試結果。測試將可存取其父項領域提供的任何能力，以及 Test Architecture 提供的所有密封功能。
這種做法的優點
- 開發人員可以自行提供執行程式。
- 這項功能目前已可使用。無須等待任何額外功能。
其他福利
- 開發人員可以依照自己的需求設定測試領域，無須在核心產品或測試架構中進行任何變更。
- 不需要支援自訂測試類型。
這個解決方案的缺點如下：
- 開發人員可以建立自己的非密封領域來啟動測試，因此我們可能會得到一堆非密封測試，而這些測試其實只要稍加努力就能變成密封測試。
- 直接使用
ffx test的開發人員需要向工具提供自己的路徑名稱和收集名稱。- ffx 測試是基礎工具，因此開發人員應使用其他呼叫 ffx 測試的工具，這樣就不必手動傳遞路徑名稱。
在 Test Manager 可用於服務後，測試拓樸的圖表。
實作
- 變更 Realm 建構工具，讓它接受 fuchsia.component.Realm 物件，以便在任意 Realm 中啟動元件。
- 變更測試執行程式，接受要求資訊的領域資訊查詢路徑名稱。
- 變更 Test Manager 以實作新的 FIDL API，並在提供的領域和集合中啟動測試。
- 記錄變更內容和說明指南
- 與 OOT 開發人員合作，建立包含 OOT 執行工具的領域。
- 將目前的 OOT 測試移植至新領域
日後的作業：
- 將使用自訂測試類型的現有測試移植至各自的領域。
- 探索如何移除對別名的依賴性。
- 從測試管理員下方移除所有測試領域，並在產品領域中發布。
成效
這項變更不會影響測試的啟動方式，只會影響測試在拓樸圖中啟動的位置，因此對效能影響不大或完全沒有影響。
人體工學
本節將說明一些解決方案，可將路徑名稱和測試收集資料傳遞至測試執行程式。詳細解決方案不在本文的討論範圍內。
與版本整合
自訂領域定義完成後，產品擁有者就可以在建構系統中定義測試類別。測試作者會使用該類別，而建構系統會產生對應的路徑名稱和測試集合，做為測試執行者的輸入內容。
在測試資訊清單中新增資訊
我們可以將路徑名稱和測試收集資訊嵌入測試面向。測試執行程序需要解析及讀取元件資訊清單檔案，才能取得相關資訊。
為提供更人性化的體驗，Test Realm 作者會提供資訊清單區塊，讓測試作者可在測試資訊清單中加入這些區塊。
回溯相容性
我們會繼續支援目前的測試，並一如既往地支援不需要自訂執行程式的密封測試領域。
安全性考量
- 開發人員可以在系統的任何領域啟動測試，但由於測試會在 eng 版本上執行，因此使用者裝置不會受到這項變更的影響。
- 我們也會在測試執行程序中加入標記，在特定共用機器和版本中停用這項功能。
- 我們需要將 RealmQuery 和 LifecycleController 轉送至所有測試執行緒。這可能會造成安全性疑慮，具體取決於我們決定如何執行。我們會在下一篇文件中討論這項功能，說明如何設計測試執行者存取這項資訊的方式。
隱私權注意事項
我們不會收集任何個人資料，因此這項設計不會造成任何隱私權影響。
測試
您應該全面測試這項功能，包括目前的測試，以及用於在自訂領域中啟動測試的新整合和單元測試。
說明文件
說明這項功能，解釋用途和實作指南，方便開發人員自行建立測試領域。
並記錄測試開發人員使用自訂領域的方式。
缺點、替代方案和未知事項
替代做法：讓用戶端啟動自己的 Test Manager
測試開發人員會在拓樸中啟動自己的 Test Manager。ffx 測試會使用 RCS 連線至 fuchsia.test.manager.RunBuilder 通訊協定，執行並收集測試結果。
這項解決方案的優點如下：
- 我們只需要變更 ffx 測試即可支援這項功能
- 開發人員可以使用目前的 Test Manager 程式碼和自訂資訊清單，在拓樸中使用 Test Manager 元件
這個解決方案的問題如下：
- 一旦在各種拓樸和 OOT 中執行，就很難變更 Test Manager。這會大大影響測試架構團隊的速度。
- 用戶端必須將 Test Manager 所需的所有功能，路由至自己的拓樸圖。
- 用戶端需要編寫測試，確保 Test Manager 在其拓樸結構中運作正常，並防止任何迴歸
替代做法：子組件
子組件可以解決我們自帶測試執行元件的問題，但不如建議的解決方案靈活。
我們提出的解決方案可讓我們在日後靈活地從測試管理工具中移除所有硬式編碼的測試領域，並將完整的擁有權提供給產品擁有者。
替代做法：測試套件自行執行測試
測試可以套件自己的執行元件，並使用該執行程式執行測試元件
這項解決方案的優點如下：
- 不需要進行任何變更
- 這項功能目前已可使用
這個解決方案的問題如下：
- 為每項測試執行新的執行元件會對效能造成的影響。
- 需要將執行元件所需的功能轉送至測試 (會破壞密封性，並削弱保證)。
- 需要為每個新的執行元件建立自訂領域 (因能力路由需求而定)。這會導致技術債越積越多。
替代方案：測試設定
使用功能和這些功能的來源為測試建立參數，然後將這些參數傳送至測試領域本身。
"fuchsia.test.additional_capabilities": {
"runner": "dart_runner",
"source": "/core/dart/runner"
}
針對可路由的功能，Test Manager 可以使用 RealmQuery API，透過 Realm Builder 代管要求。針對執行程式，Test Manager 可以使用 hub 到 Proxy 執行元件通訊協定。
這項解決方案的優點如下：
- 測試會以 Test Manager 的子項執行，因此 Test Manager 可完全控制其功能。
這個解決方案的問題如下：
- 測試可能會依賴實際運作中的別名，因此會成為公開 API 的一部分。
- 使用 Hub 代理執行元件要求只是短期解決方案，我們最終需要巢狀或鏈結的執行程式。
- 測試可存取任何系統能力，這可能會造成安全性問題，導致明確的路由中斷，並在遠端建立動作。
替代做法：Test Manager 使用 RealmQuery API
在這個設計中，Test Manager 將可存取 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",
...
],
},
...
],
}
測試管理員會讀取切面，並使用提供的能力，在指定的測試領域中查詢及啟動測試。
替代做法：Test Manager 在拓撲中已知位置執行系統測試
這項設計建議在拓樸中建立一個已知的常用位置 (例如 /core/tests)，讓 Test Manager 執行所有系統測試。平台開發人員會建立及維護這個已知的領域，而 Test Manager 只會提供執行及收集測試成果的機制。
缺點
- 如果需要在多個位置執行測試，則設定彈性較低，且無法在日後擴充。
- 我們希望日後能夠在巢狀的 Test Manager 中執行測試，以便在同層網域中執行測試。這項設計不鼓勵這麼做。
- 我們可以使用這份 RFC 的設計來達成相同的功能，將 /core/tests 設為應執行測試的領域。這項 RFC 提供更大的彈性，我們認為這將非常實用。
既有技術與參考資料
這是 Fuchsia 專屬的概念，因此沒有先前相似的藝術作品。
未來工作
- 從測試管理員拓樸結構中移除所有非密封的領域，並與客戶合作，將測試移至他們的自訂測試領域。
- 設計「自備測試管理員」為測試領域的兄弟項目。這項功能可在工作階段或任何 OOT 領域下執行測試，而不需要在平台中提供任何特定產品支援。