| RFC-0015：Fuchsia 相容性測試 (CTF) | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | Fuchsia 相容性測試 (CTF) 的條件、目標和背景。 |
| 問題 | |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2020-11-13 |
| 審查日期 (年-月-日) | 2020-12-09 |
摘要
本文將說明 Fuchsia 相容性測試 (CTF) 的一系列要求、設計和實作策略。CTF 會提供一種測試平台實作方式，確保平台的行為符合 Fuchsia 規格。Fuchsia 開發人員會編寫測試，確保平台來源和行為變更之間的相容性。這些測試通過後，就能保證特定版本在特定裝置上執行時，與目標 API 級別和目標 ABI 修訂版本相容，如 RFC-0002 所定義。
為方便說明，本文將 API 和 ABI 合稱為平台途徑。平台途徑區域元素是與平台途徑區域相關聯的命名和版本 ID (例如方法名稱)。日後的 RFC 可能會將這些定義正式化。
提振精神
目前 (2020 年 12 月)，所有 Fuchsia 平台行為的開放原始碼測試都會在平台建構作業中建構及執行。隨著平台的演進，我們會持續讓測試在最新版本中通過。因此，我們沒有任何測試可保證與舊版平台的回溯相容性。
目前，我們會使用多項產品測試來確保相容性和穩定性。這些產品測試很難進行分類，因為它們依賴產品的穩定性，並且鎖定平台的許多不同部分，因此平台工程師很難判斷錯誤可能發生的位置。
與此同時，開發人員也正在編寫以舊版 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 修訂版本。
未納入測試套件做為預先建構構件，且由用於測試的 SDK 支援的語言，必須以 CTF 測試編寫 (詳情請參閱支援的語言文件和下方的語言一節)。
編寫測試
我們會一併開發 CTF 測試和對應的 SDK 元素。這表示我們會在 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 相關的 CTF 測試的構件，會與該 SDK 一併發布。這個構件也會包含足夠的建構系統支援，可在樹狀結構外建構及執行 CTF 測試。但不會包含工具鍊。
測試必須徹底測試語言支援功能。詳情請參閱「語言支援」一節。
實作
涵蓋範圍規定
所有 Fuchsia 平台介面元素的更新都應包含可測試已記錄介面的測試。這包括但不限於 C/C++ 標頭、FIDL API、FIDL 線路格式，以及 Fuchsia 系統介面文件所述的任何介面。如果開發人員可以透過 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 會測試可透過外部可用 SDK 取得的目標 API 和 ABI。建構支援功能可確保測試只依賴可透過 SDK 取得的 API 元素，或已加入 CTF 許可清單的元素。所有未列入許可清單的建構目標都必須使用 //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 類別，且該類別含有方法 size，而該方法的說明是傳回字串_檢視畫面的大小，那麼我們就會建立一個測試，建立字串_檢視畫面、呼叫 size 方法，並斷言傳回值是否正確。
我們瞭解在某些情況下，這可能很難做到，而且某些測試可能需要特定裝置設定，而這可能難以複製。我們建議開發人員在開發週期初期就開始測試。長期目標是讓 CTF 測試成為平台介面區域的所有變更必備項目。
測試應反映特定 API 的使用最佳做法。非正式測試中，如果使用者開發人員複製測試對 API 的使用方式，測試作者會認為開發人員正確使用 API。測試應盡可能不依賴未記錄的應用程式專屬不變量。日後，如果在 Fuchsia 樹狀結構外廣泛使用未記錄行為，我們可能需要針對不符合建議用法的用途新增測試。
盡可能避免為目標裝置的內部狀態建立測試影本 (例如模擬和假設)。CTF 的目的是確保整部裝置的運作正常，而非確保特定元件在獨立情況下運作正常。
不過，這並不表示在某些環境中，CTF 測試無法從假資料中受益。舉例來說，為了使用 CTF 測試來確保平台穩定性，我們可能會在沒有這些功能的自動化環境中，執行需要實際硬體或手動輸入的測試，例如音訊或連線測試。雖然 CTF 測試本身應避免使用測試影本，但受測裝置可以使用可提供測試偽資料的偽裝驅動程式。在使用實體硬體不切實際的情況下，CTF 測試可以依賴這類驅動程式。
此外，CTF 測試應保持彼此隔離。如果某項測試失敗，或受測試系統的某個方面發生異常，則理想情況下，這項失敗應會局部化，而不會影響其他測試。測試之間缺乏隔離性有時稱為「測試交談」。舉例來說，假設有個測試會變更裝置設定元件的全域狀態。如果測試無法在結束前還原原始狀態，或是系統中的其他元件在測試執行期間變更全域狀態，就可能會發生交談。為了隔離這類測試，測試作者可能會考慮為本機範圍的設定建立操作元素，而非變更全域狀態。
如有需要，測試可能需要手動介入才能通過。我們建議開發人員徹底調查自動化可能性。
部署作業
CTF 構件會與包含相關平台途徑元素的 SDK 構件一併產生。根據 RFC-0002 的軟性轉換要求，我們預期每個 SDK 版本都會成功執行與相同 SDK 上一個版本相關聯的 CTF。我們會實作基礎架構來證明這項概念。
CTF 成果物會包含 gn 的測試裝置和建構規則。這些檔案不會包含建構系統或工具鍊，必須在測試執行環境中提供。我們會記錄哪些工具鍊與特定 CTF 相容。
範例
您可以在 //sdk/ctf/ 的 fuchsia.git 中找到測試範例。
成效
這項異動會對效能造成下列影響：
- 由於測試次數增加，因此執行所有平台測試的時間也隨之增加。
- 變更僅限於測試，因此不會影響實際效能。
安全性考量
由於與此 RFC 相關的變更僅限於測試，因此安全性風險較低。測試不應與來自外部來源的不可信任資料互動。
隱私權注意事項
由於與此 RFC 相關的變更僅限於測試，因此隱私權風險較低。測試不應與使用者資料互動。
測試
這項提案會增加平台的測試矩陣。舉例來說，如果有六週的 ABI 穩定性保證，則 CTF 產生的所有 ABI 測試，應比特定版本早六週執行，並且在該版本中成功完成。
這項提案中的新規定也會增加整體平台測試次數。
系統會自動強制執行測試架構的必要屬性，例如自動檢查是否只納入允許的依附元件。
說明文件
//docs 中將納入有關如何編寫 CTF 測試的文件。我們將更新可測試性和 API 處理文件，以反映新的 CTF 測試作者要求。我們會記錄執行 CTF 所需的步驟，方便最終開發人員和系統整合人員獨立執行這些步驟。
缺點、替代方案和未知事項
這項提案的主要缺點，是針對平台介面區域的所有變更，建立了重大的新測試要求。
CTF 計畫的目標並非針對演進和回溯相容性問題提供完整解決方案。您必須仔細設計 API 和 ABI，確保開發人員能以合理的成本遷移程式碼。舉例來說，FIDL 團隊會小心翼翼地改進語言繫結：他們有明確的規格說明繫結應如何運作，並積極追蹤各種繫結的符合程度。
CTF 方法是維持回溯相容性的標準業界方法。其他做法包括：
- 只是為了謹慎起見。我們從經驗得知，這項做法本身並無法運作。
- 未改良平台。顯然，永遠不做任何變更是不切實際的做法。大多數縮減版本 (例如，與應用程式大部分的依附元件一起出貨，或為每個應用程式提供虛擬環境) 都與 Fuchsia 的設計原則和產品目標不符。
- 形式驗證。我們不認為正式驗證是可擴充的測試替代方案。
既有技術與參考資料
Android 解決這個問題的方法，就是透過產品發布 CTF。開發新款 Android 裝置時，必須確保裝置通過 CTF。
在 Windows 硬體相容性計畫中，Microsoft 會製作 Windows 硬體實驗室套件，並發送給新 Windows 硬體的開發人員。