Let's learn how to architect system software for testing.
你是否曾經思考過，為何自動化測試的維護成本，往往隨著產品規模的擴張而呈指數級增長？
在傳統流程中，SDET（自動化測試工程師）常扮演「翻譯官」的角色，將 QA 規劃的測試案例（Test Case）手動轉譯為以程式碼為主的測試腳本。然而，當腳本中混雜了大量的 requests (REST)、Serial (SSH) 或低階 I/O 指令時，測試邏輯便與通訊協定產生了深度耦合。這種領域語義的流失，使得測試資產難以跨產品復用。
為了解決這項痛點，我提出了一套**「三層抽象測試元件模型」**（如下圖所示）。透過將「產品邏輯」與「傳輸細節」徹底解耦，輔以「節點模型」實現動態綁定，達成「測試流即自動化流」的理想願景。
The 4 levels system testing architecture design.
一、 領域驅動架構：消除測試設計與實作的「解譯成本」
測試資源的浪費，往往源於 SDET 對測試流程的**「解譯成本」（Interpretation Cost）**。在架構圖最上方的 Test Case 中可以看到，理想的測試步驟應專注於待測物（DUT）的行為：初始化、設定參數、執行與斷言。
產品層（Product Layer）：實現「測項即程式」 在架構中，這一層以產品行為為核心。它負責定義高階行為（如 Reset(), Reboot()），不涉及任何通訊細節。這種設計確保了：
- Test-flow-as-code：測試腳本即是業務邏輯。例如執行韌體更新時，僅需呼叫
Product.FirmwareUpgrade(path)，無需關心技術背後是透過 HTTP 還是 FTP 傳輸。 - 高可讀性：即使是不諳程式碼的 QA 工程師，也能一眼看懂圖中
Product.FirmwareVersion() == "1.2.3"的驗證邏輯。
二、 協定抽象化：以多型設計應對多產品並行挑戰
在多產品並行的開發環境中，不同硬體版本可能採用不同的控制協定。若測試腳本與協定強耦合，每新增一個型號，就必須重構一次腳本。
模組層（Module Layer）：封裝行為細節 請觀察架構圖中央，這一層負責將產品意圖轉化為可執行的步驟 API。如同手機的電池或通訊模組，我們透過這層實現**「行為封裝與多型」（Product Polymorphism）**：
- 動態策略：SDET 透過圖中的 YAML Config 調整配置，測試框架便能動態決定最合適的傳輸策略。
- 跨平台相容：例如「系統模組」能同時處理 REST 與 SSH。工程師僅需在配置中定義
protocol: REST，即可完成切換，完全無需修改核心業務代碼。
三、 傳輸隔離：建立高穩定性的基礎設施層
自動化測試的穩定性，取決於對 I/O 異常處理的細膩度。我們將底層通訊操作收斂於通用元件層（Common Component Layer）。
- 功能單一化與傳輸隔離：請對照圖中的 RESTful/SSH/Web Client 元件。這一層嚴禁包含業務邏輯。當產品的通訊演算法需要升級時，工程師僅需調整此層的實作，全公司數千個測試案例即可自動同步獲得更新，確保底層變動不會波及上層業務邏輯。
四、 運行時拓墣驅動：實現節點角色的動態綁定
在複雜的網絡測試環境中，設備角色常隨測試情境改變。因此，在三層核心之上，我們引入了底層的**「節點模型（Node Model）」**維度。
所見即所得（Runtime Role Binding） 觀察架構圖底部，所有執行目標都被抽象化為「Node」。透過 Runtime Role Binding，系統能根據測試拓墣動態對接實體設備：
- 彈性配置：同一台 PC 能根據 YAML 配置，在不同場景下動態定義為「控制器（Controller）」或「測試設備（TE）」。這種設計讓測試資產能靈活適應不同的實驗室拓墣，大幅提升佈署彈性。
結語：架構決定測試的長遠生命力
一個優異的系統測試架構，不應僅追求「腳本能跑」，而應追求**「邏輯清晰、協定無關、角色靈活」**。
這套模型將測試案例從繁瑣的 I/O 細節與「解譯成本」中解放，讓測試團隊專注於驗證產品的真實價值。如果您也正面臨自動化維護成本居高不下的挑戰，建議從定義「領域 API」開始，逐步將傳輸協定剝離。這不只是技術轉型，更是為您的測試資產建立長期的競爭優勢。
