- 專案主管：shayba@google.com、anthak@google.com、fsamuel@google.com
- 專案合作夥伴：borthakur@google.com、jasoncampbell@google.com、lite@google.com、ppi@google.com
- 區域：測試
問題陳述
Fuchsia 平台和產品開發人員進行樹狀結構外系統測試的需求，目前可能不符合需求，或是符合特定工具，導致缺少測試涵蓋範圍或低品質測試。
以 Fuchsia 為基礎的產品開發工作 (在 Fuchsia 來源樹狀結構 (在樹狀結構外，或 OOT) 之外)，大量仰賴無沙箱的系統測試，在平台嚴格定義合約之外執行 Fuchsia 平台。之所以會如此，是因為平台元件大多並未提供支援，以執行滿足產品測試需求所需的檢測方法。測試作者得以找到各種限制方法，但這些解決方案會導致品質低落。
如果 Fuchsia 平台對 OOT 測試的開發流程允許規避平台合約， Fuchsia 將難以更新。
什麼是系統測試？
系統測試是在完成組合的系統上進行，以驗證系統是否符合特定需求。在實用測試金字塔中，系統測試可補強單元測試與整合測試，以填補測試缺口，而這些差異只能藉由觀察測試中的完整系統來解決。
系統測試有時也稱為：
端對端 (或 e2e) 測試，尤其是在系統測試範圍超過特定目標裝置時 (例如，一個包含網路介面的遠端伺服器或控制主機機器) 時。
關鍵使用者旅程 (CUJ) 測試，尤其是以模擬和自動化的使用者輸入和輸出方式表示測試時，例如插入按鈕事件 (例如按下按鈕，以及比較 UI 狀態摘要或螢幕截圖) 與預期的測試結果。
此外，這些測試還可進一步檢測產生其他值，如下所示：
效能測試 (除了執行產品 CUJ) 之外，測試控管工具也會收集效能資訊，例如時間、追蹤記錄、 FPS 統計資料等。
長時間測試，相同的 CUJ 會在緊湊的迴圈中執行，並監控系統是否有資源外洩 (RAM、處理等) 或當機等壓力跡象。
此外，還有一種系統測試類別，可運動平台功能並樹狀結構內進行。這些是本文件超出範圍。
Fuchsia 今日的系統測試挑戰
非密封的舊版 (v1) 元件測試
Fuchsia 元件架構提供廣泛的測試支援，高度區隔測試環境與系統的其他部分。舊版 (CFv1) 測試仍支援測試尚未遷移至 CFv2 的舊版元件。雖然大部分的生產元件仍是 CFv1，但大多數測試 (超過 70%) 都使用 CFv2 測試架構，因為這個架構更可靠，且為開發人員提供了一些新功能。
基於舊版原因，v1 測試執行階段在許多方面並不密封，例如允許存取特定實際系統服務。因此，無意間許多 CFv1 測試實際上可當做系統測試。這些測試存在多個問題，包括：
由於測試的完整範圍非常廣泛，或未嚴格定義，測試失敗並不容易。
測試可能會受到外部狀態影響，或是保留外部狀態做為副作用。因此，這些測試可與其他這類系統測試進行交互通訊，原因是執行個體故障導致未重現 (「錯誤」) 或在不穩定情況下重現，例如重新執行相同的測試，但採用不同的順序。
測試中假設其他系統元件的實作細節超出其規定的合約。
元件測試架構旨在用來撰寫隔離的密封單元測試與整合測試。在這類測試中，任何導致失敗的原因都只能從測試領域內。考量到隔離的結果，也可以預期任兩個測試可以同時執行，也可以任意序列執行，不影響結果。使用已淘汰的 CFv1 功能來破壞測試沙箱，並編寫系統測試會導致這些測試中斷，並產生難以進行疑難排解的情況。許多說過測試的作者不會意識到自己是在進行系統測試。
違反 Fuchsia 系統介面的 OOT CUJ 測試
針對 OOT 軟體，預期透過 Fuchsia 系統介面 (FSI) 與 Fuchsia 平台互動及其支援的方法。不過，目前已有 OOT 開發人員適用的工具，可讓測試作者規避這個介面，並違反平台產品合約。
Fuchsia 的指令碼層 (SL4F) 是一種系統自動化架構，旨在編寫完善的系統測試。
SL4F 靈感來自 Android 指令碼層 (SL4A)。原先適用於樹狀結構內平台系統測試。特別適合用於移植目標裝置的 Android 通訊測試套件 (ACTS) 測試等項目，這類測試使用相同的基礎 JSON-RPC/HTTPS 通訊協定來驅動目標裝置。這種安排對 Fuchsia 連線測試來說非常有用。
SL4F 可做為系統自動化架構，也可用來測試 CUJ。比方說，執行個體 SL4F 會支援平台 CUJ 測試。
不過，SL4F 不適用於 OOT 測試。與 SL4F 互動的是 FSI 以外的通訊協定，而且不提供與 FIDL 執行個體相同的發展機制。藉由導入新的門面來擴充 SL4F 的自動化功能，但所有門面都必須樹狀結構內開發和建構。因此，當您針對已定義及開發 OOT 的產品測試 CUJ 時，使用 SL4F 會出現以下更進一步的問題。
另一種允許測試過於侵入的常見機制，是使用 SSH 取得遠端殼層，並在主機與目標之間複製檔案。這個問題不必與使用 SSH 做為通道通訊協定混淆，這對於做為 Overnet 傳輸的執行個體很有用。
Fuchsia 目前的工程版本包含 SSH Daemon，可透過不受沙箱限制存取全域命名空間的方式執行，並為用戶端提供 dash 殼層。相同的 Daemon 也允許 SCP 功能提供類似的全域命名空間讀取/寫入存取權，例如全域可變動儲存空間。這在 FSI 的常見用途之一，可讓測試作者在可變動儲存空間中觀察或變更其狀態，藉此存取平台元件支援的介面，並依賴 Fuchsia 基礎套件名稱等平台實作詳細資料。
針對使用 Dart 的 SL4F 用戶端程式庫執行個體，測試作者可以輕鬆使用 SSH 和 SCP 存取權。
細微測試模式
SL4F 為測試作者提供多種操控及觀察系統狀態的方式。其中有些機制會略過平台產品合約和必要的抽象層。編寫 SL4F 測試時並不需要使用這些機制，且並非所有測試都會用到這些機制。不過，我們的採納這些建議讓我們邀請了我們參與 SL4F 測試目錄的許多反面模式。
值得注意的是，由於平台無法提供可滿足測試需求的強大替代方案，因此我們開發了這些模式。以下列出這些模式的目的並非批評平台開發人員或測試作者，而是為了瞭解並分類我們現在必須支付的技術負債。
以非合約方式觀察狀態
測試中的程式碼可能會透過「檢查」或「檢查」，將狀態相關資訊發給系統記錄。這些實用的工具可將執行個體的診斷資料收集成快照。但不適合以合約形式販售。FIDL 用於定義穩定且具有進化機制的強型合約，例如：二進位格式和版本管理，讓未經協調的用戶端和伺服器可以交換 FIDL 訊息。FIDL 是為這個目的而設計，這一點十分謹慎，而自由文字記錄和檢查則並非如此。
值得注意的具體例子
測試中的記錄檔：部分長期測試會利用記錄檔，標註「錯誤」或更高的嚴重性等級，可識別產品在測試期間遇到未預期的問題。遺憾的是，測試執行期間產生的「錯誤」訊息，通常是以測試作者的角度判斷。因此，長期測試作者便不可免於維護已記錄錯誤訊息的許可清單。
在測試中檢查：部分測試驅動程式會讀取「檢查驅動程式中的資訊」，藉此觀察這些元件的狀態。由於檢查是型別資料，且可做為單一連貫快照取得，因此這項工具非常適合用來由元件的作者診斷元件的目前狀態。不過，在平台元件和產品測試之間作為合約使用時，可能會產生 ABI 極簡的 ABI，而且通常會導致故障。這些破壞性很難排解問題，因為在基礎平台變更後，嘗試執行 SDK 復原的數週後，可能會發生這類故障問題。
透過非合約操控狀態
SL4F 測試具備主機的許多控管權，包括在不採用沙箱機制的殼層 (即針對全域命名空間) 中執行任意 SSH 指令，以及對全域不可變和可變動儲存空間的完整讀取/寫入權限。以下提供一些重要範例：
啟動和重新啟動程序：通常用於測試中的設定與拆解處理常式。意圖是正向的 - 測試想要清除任何先前的狀態並重新開始。不過，受測試的平台元件並不是需要通過多次測試或以不同順序重新啟動的可靠平台元件，因為這些元件常會導致不穩定的行為。
這個方法的另一個問題是，在 OOT 測試終止平台程序的情況下，程序名稱 (不屬於平台合約的一部分) 會變成合約。這類違反預定介面和合約的情況，會讓平台重構變得更困難，而 OOT 測試也更加順暢。
操控可變動儲存空間：這種明顯的沙箱違規行為，常用於執行個體插入使用者憑證，做為特定 CUJ 測試的設定步驟。而不是在執行憑證插入的預期介面之前插入狀態，因為測試中的程式碼會在測試該狀態之前先插入狀態。如果時間不對，表示測試失敗。如果清理失敗，後續測試可能會失敗，因為這類測試會接觸到跨談話測試。
全域可變動檔案系統存取權的另一個用途是使用全域 /tmp 儲存空間目錄做為測試結果、構件和診斷的暫存區 (測試期間收集的執行個體效能追蹤記錄)。再次強調，這是測試無法清除狀態、透過交叉交談而影響彼此，或透過其他方式插入不實或不穩定行為的機會。
不同元件執行個體的隔離儲存空間目錄是在相同的分區上管理，因為為不同元件建立個別的分區既昂貴又沒有彈性。隔離方法是在共用分區上建立特定目錄版面配置。目錄版面配置反映了平台實作的詳細資料 (例如元件拓撲)，或是元件管理服務如何將拓撲轉換為檔案系統部分。再次說明，平台實作的詳細資料可能隨著時間變動，因此不應公開給 OOT 測試。
結果
在同一次測試中，以不可靠的方式混用開放式測試和封閉測試，會產生低品質的測試，例如設定不相關的期望，以及自動化調度管理和觀察狀態的方式，導致受測軟體未設計可支援。
但現在的情況是，從長期忽略系統測試工具 (即 Fuchsia 平台) 中而生。正如其所，我們發現在自己上有許多無法歸類於現有類別和防禦測試最佳做法的外來測試。
更糟的是，這些測試採用的平台實作細節會以非用於演進的字詞表示。例如 FIDL 的大部分 FSI 都會明確定義。FIDL 旨在讓平台開發人員進行與 ABI 相容的變更，或是偵測現有 ABI 何時因特定變更而損毀。FIDL 讓開發人員可以透過多種方式變更類型和通訊協定，而不會破壞 ABI，或是以控制的方式導入中斷情形：穩定的通訊協定方法序數、彈性資料表、版本管理等。
這與使用程序名稱做為合約 (例如，為了進行測試而終止程序) 相牴觸。由平台元件實作的程序名稱絕不會成為 FSI 的一部分，部分原因是，任何變更都沒有破壞性 - 任何變更都是破壞性變更、沒有版本管理可負擔，且極少數可能同時保留舊程序和新程序來執行暫時相容性視窗。同樣適用於全域檔案系統路徑、內部檔案格式、免費文字記錄和其他這類非合約。
缺少 OOT 支援
SL4F 用戶端可藉由說出 SL4F Daemon 執行系統自動化系統，平台映像檔中包含透過 Fuchsia SDK 階段提供給 OOT 測試人員的平台映像檔。Daemon 可以執行不同的工作，自動化調度管理及檢查組成「立面」的系統狀態。這種系統的這方面通常有效，因為其穩定合約穩定，而且有合理的方式會隨著時間演進。
但是，門面開發只能樹狀結構內完成，這代表 OOT 目前無法擴充系統自動化功能。這並不是令人驚訝的 SL4F 屬性，只是設計不適合 OOT 用戶端使用。
個別堆疊
SL4F 具有設定、裝置探索、主機目標網路傳輸通訊協定、一些擴充機制，以及向 SDK 客戶提供用戶端程式庫和工具的方法。
ffx 也解決了相同問題，可能更棒。開發 ffx 外掛程式時，如果主機端外掛程式需要目標端的協作元件才能測試目標，就可以開發 FIDL Proxy。接著，主機和目標之間的通訊會依照 FIDL 定義。FIDL 與透過 HTTP 的 JSON-RPC 不同，可視為 FSI 的一部分，且可隨著平台其餘部分和 SDK 的合約有所調整。這有部分是因為透過 FIDL 維持與 ABI 的相容性，比起僅將結構定義位於程式碼中的無型 JSON 合約，更簡單。
相關，ffx 堆疊會更充分瞭解 Fuchsia 元件，例如瞭解啟動測試所需元件的時機與方式。它也可以解決 SL4F 堆疊不會參與的問題，例如主機目標驗證。這會允許在 userdebug 建構類型中使用 ffx，而 SL4F 僅適用於 eng 建構類型。
其他自訂測試工具
其他測試解決方案確實不屬於上述項目。這些措施涵蓋了整個測試流程，但由於不會運用平臺本身的隔離機制進行測試，因此主要是以系統測試的形式進行自動化調度管理。
某些 OOT 合作夥伴會共用同一組測試解決方案和工具，但有部分且不一致。導致技術債增加。
解決方案陳述
Fuchsia 平台團隊將在樹狀結構和 OOT 中建立完善的系統測試解決方案。平台團隊會與產品團隊合作，藉此瞭解產品測試需求、滿足這些需求，並協助執行由產品團隊驅動的任何遷移作業。
新解決方案將採用元件架構和 ffx 外掛程式的沙箱功能，以便：
- 能夠編寫出色的 OOT 測試，包括出色的系統測試。
- 使不可能
具體違規事項如下：
在適用情況下推廣元件化單元和整合測試
您可以將 OOT 測試重新實作為在測試領域中執行的元件，以便產生密封單元測試或整合測試，並據此重新實作這類測試。為了啟用並推廣更健康的測試金字塔，我們將支援與樹狀結構內結構元件測試的 OOT 元件測試支援。
重新執行所有非密封的 CFv1 測試
透過存取實際系統服務而違反密封的現有舊版 CFv1 測試，將重新導入符合相同或更高測試需求的其他條款。無論是將這些測試重新實作為密封 CFv2 元件測試、做為新的系統測試，還是以其他形式重新實作，都必須由受測試程式碼的擁有者自行決定。
如果缺少平台測試支援或支援不足 (例如因 CFv1 元件擁有者遭到封鎖而無法遷移至 CFv2)，相關平台團隊會與測試擁有者合作，建立必要的平台解決方案。
為產品擁有者建立新的系統測試平台解決方案
系統測試可以開發及執行 OOT。
有一種方法可叫用這些測試並收集結果，確保無論身在何處，都能採用相同的工作流程和一致的結果、是否在本機開發人員工作流程中執行測試，或是在某些 CI/CQ 自動化作業中執行相同的測試，無論使用何種自動化解決方案都一樣。
非預期合約中的平台詳細資料 (例如 Fuchsia 系統介面中定義的內容) 不會提供給 OOT 系統測試開發人員。為了啟用沙箱所需的層級，如果測試和測試架構尚未遷移至 CFv2，則會遷移至 CFv2。
系統測試架構會盡可能與
ffx共用堆疊。其中包括設定、主機工具和用戶端程式庫發布機制、版本管理、設定、目標裝置探索、主機目標驗證、主機目標傳輸和遠端控制機制等。平台系統元件的擁有者可以且願意擴充系統測試架構，以滿足產品開發人員的測試需求。這樣一來，平台開發人員將建立可維護的 ABI，並為這些可測試性合約建立長期擁有權。
減少及排除舊版解決方案
平台和產品團隊會共同合作，藉此避免使用先前的解決方案，並針對所有地點採用新的無介面系統測試架構。系統不會長期使用舊版測試解決方案，除非有極佳的獎勵來繼續使用這類解決方案，例如視需要提供跨平台測試套件的相容性。
決定優先順序
相關團隊可以安排工作的優先順序。不過，建議您優先將工作視為擁有和維護最昂貴的測試，例如先遭受技術債務曲線的前端攻擊。
無論選擇何種任務，在考慮能夠償付技術債時，把處理系統測試的工作都視為高度優先任務。
依附元件
為了縮小平台可測試性缺口，並開發及推出新架構，必須仰賴多個平台團隊合作，包括元件架構、測試架構、SDK 工具、EngProd 測試和 EngProd Infra。
此外，所有產品合作夥伴團隊和多個平台元件擁有者都必須工作，才能協助找出可測試的落差，並遷移至新的測試架構和解決方案。
風險與緩解措施
系統測試的範圍不受特定元件或封裝，而是範圍限定為測試中的整個系統。因此並未嚴格定義要實際測試的程式碼。您可以將任何架構的系統測試遷移至另一個架構，但由於測試的涵蓋範圍很有利於系統測試收不到的好處，便很有可能發生。
有些系統測試的範圍非常大，因此為重新實作提供了非常高的門檻。建議在預先考量的準備步驟中，應縮減範圍或拆分部分測試。
部分現有的系統測試沒有專屬的長期擁有者。這類放棄軟體可能難以使用，有些遷移工作也難免受制於不同的肩膀。
如要調整現代解決方案 (特別是 OOT)，需要處理 OOT 和產品端 CFv2 遷移作業。CFv2 遷移作業已取得非常不錯的進展，但到目前為止，重點是系統元件，尚未開始遷移 OOT 或產品端元件。我們合理預期會有未知的封鎖程式
支付技術負債也會影響團隊其他要務的優先順序。您必須領導團隊協調，才能有效執行這項轉換作業。
不在範圍內
樹狀結構內系統測試
樹狀結構內開發的測試超出本文件的範圍。雖然上述工作中可能會有利於主幹系統測試的潛在風氣，但樹狀結構內測試的問題陳述式卻充分不同，因此不在本文討論。舉例來說，樹狀結構內測試可在 Fuchsia 平台介面下方運作，而不影響 Fuchsia 的可更新原則和目標。
元件測試
對於元件測試，如要以一組或一或多個實作單元測試或整合測試元件表示的測試，請參閱樹狀結構外結構元件測試支援藍圖文件。
特殊可攜性需求
在某些特殊情況下，必須在 Fuchsia 上執行現有的測試套件，以證明其與其他實作的相容性或合規，或是進行基準測試。在這種情況下，現有的測試必須未經修改，否則無法安心展現相容性。這基本上會定義裝置端測試自動化系統的規格。
解決這個問題的其中一個常見解決方案是將既有的測試架構移植至 Fuchsia。舉例來說，Fuchsia LLVM 工具鍊和 Fuchsia Rust Toolchain 團隊正在規劃分別移植 LLVM 和 Rust 測試架構，以便在 Fuchsia 上透過上游執行測試。這麼做的好處是，我們可以針對這些外部專案，將 Fusia 升級為更高層級的工具鍊支援。
另一個常見的解決方案是依據相同規格重新實作測試架構。舉例來說，Fuchsia Connectivity 團隊針對 SL4A 的 JSON-RPC/HTTPS 規範實作 SL4F，以便在 Fuchsia 上執行 ACTS 測試。這有益於為 Fuchsia 加入大量有用的測試，並展現連線能力，這對連線領域至關重要。
這類解決方案適用於這個獨特的問題空間，前提是應採取正確原因並謹慎使用。舉例來說，假設我們將 LLVM 測試架構移植到 Fuchsia，然後使用這個架構編寫新測試，而這個架構不在示範相容性範圍內，或是與合作夥伴專案分享測試範圍，則需要提供額外的理由或平台團隊不建議。