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