| RFC-0015： Fuchsia 相容性測試 (CTF) | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | Fuchsia (CTF) 相容性測試的規定、目標和背景資訊。 |
| 問題 | |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2020-11-13 |
| 審查日期 (年/月) | 2020-12-09 |
摘要
本文件說明 Fuchsia 相容性測試 (CTF) 的要求、設計和實作策略。CTF 將提供測試平台實作的方式，確保這些實作方式符合 Fuchsia 的規格。Fuchsia 開發人員會編寫測試，確保平台來源和行為在變更時更加相容。測試通過後，就能確保特定版本在特定裝置上執行時，能與目標 API 級別和目標 ABI 修訂版本相容 (如 RFC-0002 所定義)。
為配合本文件，我們將 API 和 ABI 共同稱為平台介面區域。「平台介面區域元素」是與平台介面區域相關聯的命名和版本 ID (例如方法名稱)。未來的 RFC 可能會使這些定義標準化。
提振精神
目前，所有 Fuchsia 平台行為的開放原始碼測試目前都是在平台建構作業中建構及執行 (2020 年 12 月)。隨著平台的進化，我們仍會保持測試是否通過。因此，我們沒有任何測試能保證與舊版平台的回溯相容性。
目前，我們進行多項產品測試來確保相容性和穩定性。這些產品測試很難進行分類，因為它們仰賴產品的穩定性，並且鎖定平台的許多不同部分，因此平台工程師很難判斷錯誤可能在哪裡。
同時，開發人員也會編寫以舊版 Fuchsia 平台途徑區域為目標的程式碼。在本文件中，我們將稱為「開發人員」等開發人員。
API 推出破壞性變更時，我們沒有保護措施，會在與最終開發人員程式碼的相容性受損時提高標記。在專案中，未記錄的 API 變更經常發布，導致外部程式碼停止建構。
此外，我們目前也針對回溯 ABI 相容性建構強而有力的保證。截至 2020 年 11 月 9 日，我們要求將 ABI 相容性期設為六週，但目前並未施加強制執行機制。
我們需要一組可從平台版本獨立執行的測試，並且瞭解我們與開發人員簽訂合約的時間點。這有助於確保我們與外部開發的程式碼維持相容性，並為目前僅由產品測試執行的平台部分，提供更為目標的測試涵蓋範圍。
長期來看，我們也需要一組系統整合商可以執行的測試，以瞭解他們是否會產生符合規定的 Fuchsia 實作。
Fuchsia 的 CTF 將提供測試平台實作的方式，確保這些實作與特定平台版本相容 (如 RFC-0002 中的定義)。我們希望能對平台介面區域中的每個記錄行為進行測試。
建立版本時，我們可以透過 CTF 告訴我們其表面區域與其他發布版本的相容性。
如果有人正在開發搭載 Fuchsia 的裝置，並想知道與特定 SDK 是否相容，他們可以使用 CTF 和要展示相容性的 SDK，藉此展現相容性、通過測試，並確信自家產品正確實作 Fuchsia 的語意，結果將「與 Fuchsia 相容」。
如果開發人員想瞭解如何針對特定 API 編寫程式碼，或使用特定 ABI，則可以使用這些測試做為參照。
RFC-0002 允許在實作平台上提供部分回溯相容性支援。CTF 可讓您測試部分相容性。
請注意，針對平台演進和回溯相容性，CTF 並非完整的解決方案。CTF 測試不太可能涵蓋每個用途。仍須根據未來用途設計 API 和 ABI。如需其他討論，請參閱「撤銷和替代方案」一節。
設計
CTF 設計涵蓋在開發便利性和在 Fuchsia 存放區外建構和執行 CTF 本身的需求。相關規定如下：
每個平台途徑區域元素的每種記錄行為都應執行 CTF 測試。雖然我們預期這最終會成為硬性規定，但此 RFC 並未指定這類要求。
CTF 測試不得仰賴特定系統映像檔的任何內部詳細資料。 如果應用程式仰賴非本身需要測試的其他平台程式碼，該程式碼也必須納入 CTF 的一部分，而且不仰賴特定系統映像檔的任何內部細節。
CTF 測試在新增或變更平台途徑區域元素時，開發人員必須更新 (也就是說，必須新增或修改測試)。
必須能夠判斷特定 CTF 構件目標的 Fuchsia API 級別和 ABI 修訂版本。
CTF 測試不包含在測試套件中，因為預先建構的構件必須以用於測試的 SDK 支援的語言編寫 (詳情請參閱下方的「支援的語言文件」和「語言」一節)。
編寫測試
我們會搭配對應的 SDK 元素來開發 CTF 測試。這表示我們現在使用 fuchsia.git 開發測試。如果 CTF 開發人員和使用 SDK 的樹狀結構開發人員具有相同的體驗，會對您很有幫助，但這麼做表示要忽略的樹狀結構內開發項目太多：
由於功能開發與測試開發一併完成，因此測試者在樹狀結構開發過程中可以使用他們熟悉的工作流程，並在同一個 CL 中提交測試的功能。
這項功能會與測試同時提交，因此您不需要任何機器將 CTF 和符合資格的版本對齊。
CTF 測試將採用建構時間強制執行機制，確保 CTF 測試只能依附 SDK 元素或其他預先核准的 CTF 程式碼。開發樹狀結構內的其中一個危險，是可能會不小心採用依附元件並非透過 SDK 公開的平台實作詳細資料。CTF 測試只能存取平台的公開元素，以免意外依賴實作詳細資料。CTF 測試可能會使用適合編寫測試的平台程式碼 (例如 zxtest)；這類程式碼會隨 CTF 構件一起傳送。
CTF 測試不得對仰賴 SDK 的第三方程式庫執行依附元件，以便支援 Fuchsia。需要 SDK 元素支援 Fuchsia 的第三方程式庫將根據特定 SDK 進行建構。我們必須確保測試盡可能與其他人的 SDK 依附元件分離，因為第三方程式碼可能會仰賴我們從測試中排除的平台功能。舉例來說，如果我們仰賴大量使用鎖定功能的測試套件，可能就不適合測試用於實作鎖定的 Zircon 功能。基於這項限制，我們會使用 zxtest 而非 gtest。
除了該 SDK 外，系統也會發布包含與特定 SDK 相關的 CTF 測試的構件。此構件也將包含建構系統支援，足以在樹狀結構外建構及執行 CTF 測試。將不會包含工具鍊。
測試必須徹底執行語言支援。詳情請參閱語言支援一節。
實作
保固範圍規定
對 Fuchsia 平台介面區域元素進行的所有更新，都應包含記錄所記錄途徑的測試。這包括但不限於 C/C++ 標頭、FIDL API、FIDL 傳輸格式，以及 Fuchsia System Interface 文件描述的任何途徑。如果開發人員可透過 SDK 存取表面區域元素，就必須測試該元素。
我們瞭解目前要求測試可能不太實際。隨著 CTF 和平台的成長，這項規定將會更嚴格。
大多數需要 API 審查的變更都應進行 CTF 測試，且 API 審查人員應考量這一點。最終審查將由可測試審查人員進行，他們只應核准在 CTF 測試適當涵蓋的平台途徑區域變更項目。
所有測試都必須符合與提交至樹狀結構的任何其他程式碼相同的審查要求。請注意，這並不表示測試必須做為修訂佇列的一部分執行，但我們預期大多數都會包含於此。可能不會包含在修訂佇列中執行的測試範例包括手動測試，以及耗時超過修訂佇列允許的測試時間。
目錄結構
//sdk/ctf/tests 目錄的結構會反映已發布的 SDK 結構。測試會位在 SDK 中找到受測試介面的目錄。例如：
- 主機工具測試應納入
//sdk/ctf/tests/tools - FIDL 介面測試應位於
//sdk/ctf/tests/fidl的適當子目錄中。舉例來說，fuchsia.sysmem的測試應在//sdk/ctf/tests/fidl/fuchsia.sysmem中。 - 程式庫測試應位於
//sdk/ctf/tests/pkg的適當子目錄中。舉例來說，async-loop的測試應納入//sdk/ctf/tests/pkg/async-loop。
如果 Fuchsia 開發人員不清楚該在哪裡執行測試，則應洽詢相關目錄的「擁有者」。
建立支援
CTF 測試的目標 API 和 ABI (可透過外部使用的 SDK 取得)。建構支援可確保測試僅依附於可透過 SDK 提供的 API 元素，或是已獲準用於 CTF 的 API 元素。所有未加入許可清單的建構目標都必須使用 //sdk/ctf/build 中的 cts_ 規則變化版本，而非標準 fuchsia.git 規則 (即使用 ctf_fuchsia_component、ctf_executable 等)。
您可以在 //sdk/ctf/build/allowed_ctf_deps.gni 中找到非 SDK 程式碼的許可清單。如果測試作者認為自己需要額外收錄內容，請與這個目錄的擁有者聯絡。
語言
目標端測試
所有 API 測試都必須以測試 SDK 支援的語言編寫。在大多數情況下，這意味著 C++ 之意。ABI 測試能以任何語言編寫。為避免不必為透過 SDK 不支援的語言建構外部支援，只要 ABI 測試需要使用其他語言，我們就會將其做為預先建構的二進位檔或套件 (視情況而定) 來完成。
特定標頭的測試必須使用支援該標頭的語言。截至本文撰寫時，C 標頭會指定 C11 和 C++11 以上級別，而 C++ 標頭會指定 C++14 以上版本。
CTF 測試可能會限制自身使用特定語言版本。舉例來說，我們可能會決定將特定測試限制為 C++14，以便確保標頭能與 C++14 相容。
主機端測試
目標端測試的語言限制不適用於主機端測試。主機端測試的語言專屬於測試語言。如果需要 CTF 依附於新的工具鍊，就應與 CTF 團隊協商做出決定。針對在主機上執行的端對端測試和指令碼，我們支援使用 Dart (特別是 sl4f)。當支援的語言有所變更時，我們也會提供相關說明文件，說明主機端測試支援哪些語言。
測試規定
測試應包含對每個有關特定 API 或 ABI 的斷言檢查。舉例來說，如果有類別 fit::basic_string_view，且其中有記錄傳回 string_view 大小的方法 size，我們會執行一個測試來建立 string_view、呼叫 size 方法，並斷言回傳值正確無誤。
我們瞭解在某些情況下可能很難執行這項操作，且某些測試可能需要特定的裝置設定，而可能難以複製。我們建議開發人員在開發週期的早期階段開始測試。長期目標是讓 CTF 測試成為對平台途徑區域所有變更的要求。
測試應反映特定 API 使用情形的最佳做法。在非正式的情況下，如果測試作者複製了測試的 API 使用情況，測試作者就會誤以為開發人員正確使用 API。測試應盡可能進行，而非仰賴未記錄的應用程式專用不變性。日後，如果廣泛使用 Fuchsia 樹狀結構以外的未記錄行為，我們可能就需要為未遵循建議用途的用途新增測試。
盡可能避免為目標裝置的內部狀態建立測試替身，例如模擬和假。CTF 的用意是確保整個裝置都能正常運作，而不是確保特定元件獨立正常運作。
然而，這並不代表 CTF 測試無法受益於某些環境中的假。舉例來說，為了使用 CTF 測試來確保平台穩定性，我們可能會在無法使用這類功能的自動化環境中，執行需要實際硬體或手動輸入測試 (例如音訊或連線能力測試) 的測試。雖然 CTF 測試本身應避免使用測試替身，但受測試的裝置可以使用假驅動程式來提供測試假資料。CTF 測試可在無法使用實際硬體的情況中仰賴這類驅動程式。
此外，CTF 測試也應維持互相區隔。如果有一個測試失敗，或測試中系統的某個方面出現錯誤，最好能將故障的本地化版本，而不是影響其他測試。測試之間缺乏隔離機制有時也稱為「測試交叉交談」。舉例來說，假設要在裝置設定元件中變更全域狀態的測試。如果測試在終止前無法還原原始狀態，或者如果系統上的其他元件在測試執行期間變更全域狀態，則可能會發生交叉交談。如要隔離這類測試，測試作者可能會考慮為本機範圍設定建立預設用途，而非變更全域狀態。
如有需要，測試可能需要手動介入才能通過。我們建議開發人員徹底調查自動化系統的可能性。
部署作業
系統會連同包含相關平台介面元素的 SDK 構件一併產生 CTF 構件。由於 RFC-0002 的軟性轉換要求，我們預期每個 SDK 版本都能成功執行與相同 SDK 的先前版本相關聯的 CTF。為了進行概念驗證 我們會導入基礎架構來保證這一點
CTF 構件將含有測試控管工具，以及建構妊娠規則。這些並未包含建構系統或工具鍊；您必須在測試執行環境中提供該套件。我們將記錄已知能與特定 CTF 相容的工具鍊。
範例
您可以在 fuchsia.git 的 //sdk/ctf/ 中找到測試範例。
效能
這項變更會對成效產生下列影響：
- 變更執行所有平台測試的時間會增加，源自於增加的測試數量。
- 不會影響實際工作環境的效能，因為變更僅供測試。
安全性考量
與這個 RFC 相關的變更僅供測試之用，因此屬於低安全性風險。測試作業不應與來自外部來源不受信任的資料互動。
隱私權注意事項
與這個 RFC 相關的變更僅供測試之用，因此是低隱私權風險。測試不應與使用者資料互動。
測試
本提案將增加平台的測試矩陣。舉例來說，根據 6 週的 ABI 穩定性保證，CTF 產生的所有 ABI 測試都應比特定建構作業在六週前執行並順利完成。
本提案中的新要求也會增加平台測試的總數。
由於測試架構的許多必要屬性是實際做法，因此會自動強制執行；例如，架構會自動檢查是否只包含允許的依附元件。
說明文件
//docs 中收錄瞭如何編寫 CTF 測試的說明文件。我們會更新可測試性和 API 程序文件，以反映新的 CTF 測試授權規定。我們會記錄在樹狀結構外執行 CTF 所需的步驟，讓開發人員和系統整合商能夠獨立執行這些工作。
缺點、替代方案和未知
本提案的主要缺點是，對平台介面區域的所有變更都必須建立一項全新的測試需求。
我們並不是 CTF 致力為演進和回溯相容性問題提供完整解決方案。API 和 ABI 必須謹慎設計，確保開發人員能以合理的費用遷移程式碼。舉例來說，FIDL 團隊不斷演變語言繫結，我們採取極度謹慎的態度：這些團隊擁有繫結運作方式的明確規範，並主動追蹤各種繫結的配合程度。
CTF 做法是維持回溯相容性的標準業界標準，其他方法包括：
- 要小心謹慎，我們瞭解這無法完全發揮作用，
- 平台不會改變。顯然地，絕對不會做出任何調整。這種軟體的縮減版本 (例如傳送大部分的應用程式依附元件，或為每個應用程式提供虛擬環境) 與 Fuchsia 的設計原則和產品目標不符。
- 正式驗證。我們並未將正式驗證視為可擴充的替代方案。
先前的圖片和參考資料
為解決這個問題，Android 會發布包含產品的 CTF。新 Android 裝置的開發人員必須確保裝置通過 CTF。
Microsoft 於 Windows 硬體相容性計畫後產生 Windows Hardware Lab Kit，提供給新 Windows 硬體的開發人員。