GUI 自動化為何不穩？狀態驗證、協作與回歸測試指南

GUI 自動化看起來像是「看見按鈕、點一下、等結果」的工作，但真正困難的地方不在點擊，而在於系統是否真的進入了正確狀態。網頁載入變慢、彈出視窗遮住目標、權限過期、資料尚未寫入伺服器，甚至畫面看起來一樣但目前帳號或工作區不同，都可能讓自動化在沒有明顯錯誤的情況下做錯事。

因此，可靠的 GUI 自動化不該被當成黑盒子：輸入一段指令，最後只回報「完成」。它應是一條可觀察、可驗證、可停止的流程。本文從狀態驗證、協作分工與回歸測試出發，整理把瀏覽器、桌面或手機操作做得更可控的方法；若想先了解 GUI-Owl 與 Mobile-Agent-v3 等多代理工具的能力範圍，可另讀本站的多代理 GUI 自動化介紹。

先釐清：自動化的目標是狀態改變，不是游標移動

「按下送出」不是工作完成的定義；「訂單已建立並取得訂單編號」、「表單欄位已通過驗證」、「檔案已出現在指定資料夾」才是。兩者的差別會直接影響設計方式。只記錄座標或截圖，最多能證明系統嘗試點擊；它不能證明後端資料已成功寫入，也不能證明下一步使用的是正確資料。

開始自動化前，先為每個關鍵步驟寫出一份狀態契約。至少包括：執行前必須存在的條件、要採取的動作、預期出現的結果、可以保存的證據、可接受的等待時間，以及不符合時的停止或復原方式。例如「登入後新增客戶」可要求目前租戶名稱正確、表單欄位可編輯、送出後出現客戶 ID，並由客戶列表或 API 回應再次確認。這類描述比「點選新增後輸入資料」更能防止靜默失敗。

畫面是線索，不應是唯一的事實來源

純視覺辨識很容易受縮放比例、深色模式、廣告遮罩、A/B 測試、語言與版面改版影響。若系統提供可存取性名稱、角色、欄位標籤、穩定的測試識別碼、頁面標題、URL、下載檔案名稱或正式 API 回應，這些通常比像素位置更適合當定位與驗證依據。

瀏覽器自動化框架 Playwright 也把 locator 視為自動等待與重試的核心，並建議優先採用使用者可見的語意，例如角色、文字與標籤，而非脆弱的 CSS 或 XPath 路徑。它的 actionability 檢查會在點擊前確認目標是否唯一、可見、穩定、能接收事件且已啟用；不過，這只能說明「此刻可以互動」，並不等於商業動作已成功。因此點擊後仍必須驗證後置條件。Playwright locators 文件與actionability 文件可作為網頁流程的實作參考。

截圖仍然有價值，但應定位為診斷證據，而不是成功判斷的唯一依據。對需要人工辨識的介面，可同時保存執行前後截圖、目前頁面 URL、元素語意名稱、資料列 ID 與時間戳；發生問題時才能回放「看見什麼、採取什麼動作、系統回了什麼」。截圖若含個資、帳務資料或權杖，應先遮罩並採用受控的保存期限。

把等待拆成兩件事：可操作與已完成

許多不穩定流程把固定等待當成萬用解法，例如每次點擊後等五秒。這會在網路快時浪費時間，在網路慢或背景工作較久時仍然失敗。較好的做法是分兩層等待：第一層等待介面目標可操作，例如按鈕沒有被遮住；第二層等待業務結果成立，例如成功訊息出現、指定列的狀態改為已完成、下載檔案存在，或伺服器回傳可查詢的識別碼。

為每一層設定合理的逾時與失敗訊息。若第一層逾時，較可能是登入失效、版面改變或彈窗干擾；若第二層逾時，可能是背景排程、資料驗證或後端服務失敗。分開記錄能讓維護者找對問題，也避免代理把「畫面沒有報錯」誤解成「工作完成」。

重試之前，先確認動作是否可重複

重新整理頁面或重試讀取通常風險較低，但重送付款、寄信、刪除資料、發佈文章和提交申請可能造成重複副作用。可靠的流程在重試前應先查詢目前狀態：是否已建立同一筆資料、是否已存在回執編號、是否已寄出、是否已有相同內容等待審核。能使用冪等鍵、草稿 ID、唯一請求 ID 或伺服器端去重機制時，應優先使用。

若無法辨識結果是否已寫入，最安全的策略是停在可檢查的關卡，而不是要求代理「再試一次」。對金流、帳號權限、公開發布、刪除與不可逆修改，建議把人工核准設為明確的門檻：自動化準備資料、顯示預期影響與證據，由人確認後才執行最後一步。

多代理協作要交接結構化證據

把規劃、辨識、操作與驗證交給不同代理，確實能降低單一步驟同時猜測太多事情的風險；但代理數量增加也會引入交接錯誤。最常見的問題是上一個代理只說「已完成」，下一個代理卻不知道它在哪個帳號、哪個畫面、用什麼條件確認成功。

較穩定的分工可分為四個角色。規劃者把目標拆成有限狀態與可接受路徑；感知者取得目前畫面、語意元素與環境資訊；執行者只在被授權的步驟內操作；驗證者以獨立訊號檢查後置條件。交接資料不只是一段自然語言，還要包含工作項目 ID、前置狀態、目標元素、採取的動作、結果 ID、證據位置與下一步允許的範圍。驗證者若無法取得足夠證據，應回報「未驗證」而不是推測成功。

在長流程中加入檢查點也很重要。每完成一個可回復階段，就保存已確認的狀態與最小必要上下文；中斷後可從檢查點繼續，而不必重跑整段流程。若環境意外跳到不同租戶、頁面標題不符、權限對話框出現，或高風險動作即將觸發，代理應中止並要求人工處理，而不是自行猜測下一步。

用回歸測試守住介面變更

GUI 自動化會隨產品更新而老化，因此需要一組小而重要的回歸案例。先挑選登入、切換工作區、建立資料、查詢結果、取消或復原等核心旅程；每個案例都應有明確的成功條件與可比對的資料，而非只比對整張截圖。當介面改版、瀏覽器更新或模型提示詞調整後，先在測試帳號與非正式資料上跑這組案例，再擴大到正式流程。

失敗紀錄至少應帶有：操作時間、瀏覽器或裝置版本、帳號或租戶的非敏感識別、步驟名稱、使用的定位方式、動作前後狀態、遮罩後的截圖、網路或主控台錯誤，以及是否已觸發副作用。這些紀錄能區分「找不到按鈕」、「按鈕不可點」、「資料沒有送達」與「驗證條件設錯」；只有分類正確，修正才不會變成一再增加等待秒數。

何時應改用 API、資料匯入或人工流程

GUI 自動化適合沒有正式整合介面、需要跨多個既有系統、或確實必須模擬使用者操作的任務。若產品提供受支援的 API、CSV 匯入、Webhook、批次工具或後台工作佇列，這些通常更容易驗證、更能處理大量資料，也較不受介面變動影響。評估時不只比較開發速度，也要比較權限控管、可觀測性、錯誤復原與維護成本。

而有些工作本質上需要人的判斷，例如同意條款、辨認例外個案、對外發布、調整帳務或刪除資料。自動化可以協助收集資料、預填欄位與提出建議，但不應假裝能取代責任歸屬。把人放在高影響節點，通常比讓代理在不確定狀態中繼續操作更有效率。