客戶使用新的 Wi-Fi 連線產品時，第一件要做的事就是完成 Wi-Fi 設定，因此它必須可靠且每次都能正常運作，無論產品的其他部分如何變更。
這是我們可以使用 Groundrun 系統完成的事情。讓我們來設定它。
首先，我們需要將硬體納入迴圈，就像我們之前測試 ESP32 的無線 (OTA) 更新一樣。我們在此測試中使用了 Espressif 的 ESP32-C6 開發板。使用 Groundrun，將其納入迴圈非常簡單：我們只需這樣做：
有幾種方法可以在連線裝置上設定 Wi-Fi 網路，ESP32 系列支援其中多種方法：
手機保持連線到家用網路，並將憑證廣播為一串編碼封包；裝置尚未連上任何網路，透過監聽混雜模式 (promiscuous mode) 來接收這些封包。
在典型情況下，您已經有一個智慧型手機應用程式。在我們的案例中，我們需要一些簡單的東西，只是為了示範如何連線 Wi-Fi，因此我們請 Claude 開發了一個快速的應用程式。它需要在正確的時間點為五種方法中的每一種發送正確的位元組，僅此而已。該應用程式不需要好看，事實上它也不好看。
該應用程式不需要好看，事實上它也不好看。
對於現有的連線產品，韌體已經寫好。在這種情況下，我們需要遵循最佳實踐，讓 AI 開發工具理解它 (請參閱如何在連線產品開發中使用 AI 編碼代理)。
我們請 Claude 為我們開發韌體程式碼。Groundrun 系統在此提供協助，透過提供處理 ESP32 韌體的技能，最終我們獲得了實現上述各種 Wi-Fi 設定機制的程式碼檔案。
由於 Claude Code 可以存取測試平台及其硬體，因此它可以獨立完成這項工作。我們給予它計畫、目標和停止條件，以便它知道要瞄準什麼以及何時停止。
產生的韌體程式碼看起來像這樣 (這是 WPS 機制)：
這裡的使用者流程很簡單：使用者打開應用程式，輸入 Wi-Fi 密碼，ESP32 就會加入網路。具體細節因方法而異，因此五種方法各有其路徑，在 Groundrun 的流程建構器中逐步寫出。
Claude 使用 Groundrun 的技能組進行了對應，並且每個流程都是 Claude Code 可以獨立再次執行的。
現在一切都已啟動並運行，因此我們可以執行 Wi-Fi 設定流程，既可以在 Groundrun coordinator 中互動執行，也可以作為持續整合 (CI) 的回歸測試執行。
我們在每次變更時執行回歸測試：無論我們在系統中變更什麼，這部分都必須保持穩固。
這些回歸測試也包含我們在「故意破壞 ESP32 的 OTA 更新」一文中討論的無線更新測試。
每次 CI 執行都會自動計時，協調器會單獨記錄每個步驟，因此我們可以按花費的時間細分：刷新韌體、安裝和啟動應用程式、執行機制本身，以及等待裝置確認連線。
圖表顯示，除了 SmartConfig 外，韌體刷新和開機的成本在所有地方都差不多，約為 22 到 24 秒，SmartConfig 還會刷新第二個用於監控其廣播的裝置，將該階段推遲到 37 秒。之後，機制部分的耗時因方法而異，因此值得單獨比較。
單獨來看，Soft AP 的機制時間幾乎是 WPS 的十三倍，這與其系統對話框和多螢幕流程相符。SmartConfig 和 WPS 的時間都保持在 15 秒以內，遠遠落後於藍牙、Soft AP 和入口網站。
同時測試所有五種方法，發現它們之間存在實際差異。
入口網站是五種方法中最棘手的。手機顯示的登入頁面僅開啟幾秒鐘，手機本身的作業系統會自行決定確切的關閉時間。整個表單必須在此視窗內填寫並提交，否則憑證永遠無法傳送給裝置。
藍牙和 Soft AP 在手機加入裝置網路之前都會觸發系統彈出視窗，而該彈出視窗可能需要幾秒鐘才能出現，因為手機正在掃描裝置。我們的測試會等待它出現。
WPS 完全不需要應用程式。一旦有人按下按鈕，路由器和裝置就會直接交換憑證。
在我們的測試中，SmartConfig 的運行速度明顯慢於其他四種方法，偶爾會慢得多，並且偶爾會出現無法追蹤單一原因的失敗。
測試 WPS 也意味著我們必須自己充當路由器。我們的測試平台會啟動自己的臨時 Wi-Fi 網路，固定在 2.4 GHz，因為裝置的無線電無法達到 5 GHz，然後在每次運行後將其關閉。
使用者使用任何 Wi-Fi 連線產品時，第一件要做的事就是設定 Wi-Fi，因此它必須是系統中最穩固的機制。
Groundrun 系統讓我們能夠為此機制設定使用者流程和自動化測試，並將硬體納入迴圈。
請參閱平台概覽中 Groundrun 如何執行硬體迴圈場景。
