轉念學 – 敏捷三叔公的學習之旅

近幾年因為生成式 AI／大模型（LLM）、電腦視覺、機器學習技術的進展，市場、工具廠商，以及部分測試／QA 社群，對「AI 幫你自動生成／自我維護 UI 自動化程式」這樣的願景抱以相當期待。甚至有人宣稱：在未來，UI 自動化測試不再是手動寫定位碼、等待訊息、設置 timeout，那些痛點可以「交給 AI 來做」，你只需要聚焦在更高層的測試邏輯。

這樣的說法，乍聽有些誘人：測試金字塔中 UI 層次的測試可以大幅被減少，甚至「失去那麼重要性」。但這樣的願景，真實落地後會發生什麼？我們先來看看在 GEN-AI 浪潮中，UI 自動化確實有什麼樣的新變化與承諾。

AI／GEN-AI 帶來的 UI 自動化新承諾：什麼被強調了？

以下是目前市場／工具／論文常會強調的幾點「AI 能在 UI 自動化上帶來的進步」：

1. Self-healing / 智能定位重捕 (locator recovery / re-mapping)：
   當 UI 結構改動（例如 DOM 改變、屬性改名、按鈕位置移動）時，AI／ML 模型可以自動比對舊的定位器 (locator)、執行失效「修補 (repair)」，無需人工來調整。這在許多工具中，作為一個賣點（selling point）被強調。
   — Applitools 的 Visual AI 就提出：「不只是檢查元素是否存在於 DOM，還要確保畫面呈現正確」的能力。(applitools.com)
   — 在系統性研究中，也常將 self-healing 作為 AI 驅動工具的一個重要分類功能。(arXiv)
2. 視覺比對 / 視覺驗證 (Visual Regression / Visual AI)：
   傳統 UI 自動化多是針對結構／屬性做驗證（例如按鈕是否能點、文字是否正確、元素是否出現），但視覺錯誤（樣式跑掉、重疊、漸層偏差、佈局微差）往往難以察覺。AI 可對整體畫面做相似度分析、差異偵測。這是很多工具宣稱能補足的短板。(applitools.com)
3. 自動生成測試／場景 (Test Generation / Scenario Suggestion)：
   AI、特別是 LLM，可能根據系統結構、使用者流程、歷史錯誤紀錄，自動提出測試場景／案例，甚至自動生成 UI 測試腳本草稿。這可以減輕測試工程師從零開始撰寫測試的負擔。(arXiv)
4. 錯誤根因 (Root Cause) 分析輔助與註解：
   當 UI 測試失敗時，AI 可嘗試判斷是定位器失效？畫面佈局變動？等待時間不夠？或其他原因，並給出提示／建議，協助人工作診斷。這可以節省很多除錯時間。

這些都是工具與研究常被宣傳或聚焦的方向。但它們並未根除 UI 自動化的根本挑戰。下面我們就來回到「原理」層面，說明為什麼那些挑戰仍在。

UI 自動化的原理與固有限制

即便 AI 在定位、比對上能做輔助或增強，UI 自動化背後仍有一些無法被 AI 神化掉的本質限制。了解這些原理，能幫我們判斷 AI 工具的真正價值與極限。

原理回顧：UI 自動化是怎麼工作的？

以常見的桌面／網頁 UI 自動化為例，其背後常見流程大致如下：

1. 定位元件 (locator / selector / UI 元件標識)
   測試程式必須知道「我要點哪個按鈕、讀哪段文字、操作哪個欄位」。這通常透過 DOM 結構、屬性 (id, class, xpath, CSS selector) 或工具庫提供的 UI 樹 (UI tree / accessibility tree) 來識別。
2. 發送操作命令 (click, sendKeys, scroll, etc.)
   一旦定位到元件，測試程式需要向該元件所在的視窗傳送操作訊息（滑鼠點擊、鍵盤輸入、焦點移動、滾動等等）。底層可能被封裝在 WebDriver（Selenium、Playwright／Puppeteer）或平台自動化 API (UI Automation frameworks) 中。
3. 等待 / 同步 / 超時控制 (wait / sync / timeout)
   UI 操作並不是瞬間完成。可能有頁面載入、網路請求、資料繫結、動畫、渲染延遲等環節。測試程式必須等待元素出現、可點擊、穩定、動畫完成等。這涉及顯式等待 (explicit wait)、隱式等待 (implicit wait)、固定等待 (sleep) 或自定義等待策略。若等待時間設定不當，就可能產生錯誤（timeout、元素不可見、重複定位失敗等）。
4. 驗證／斷言 (assertion / verification)
   在操作後，測試程式需要確認結果是否符合預期：界面是否切換到正確頁面？文字是否正確？元素是否顯示或隱藏？這些斷言有時需要讀取 UI 標籤、屬性、DOM 結構、甚至圖片比對。
5. 錯誤處理與恢復 (error handling / fallback / recovery)
   測試可能因為 network error、DOM 變動、環境異常、定位錯誤、閃爍 (flaky) 等而失敗。通常需要重試、替代定位器、截圖／log 記錄、fail-safe 機制。

這整條流程看起來沒什麼神祕，但每一步都潛藏不穩定點。AI／視覺輔助可以在定位、比對、錯誤分析上幫助，但 操作等待、環境穩定性、訊息傳遞、同步控制 這些部分仍然要靠合理的設計與測試工程師介入。

為什麼這些部分難以被 AI 完全取代？

1. 等待／同步／timeout 的不確定性
   即使 AI 輔助定位成功，也必須給足的時間讓 UI 穩定起來、資源載入完成、動畫結束等。這些延遲可能因為環境負載、網絡波動、後端回應速度改變、前端重構等而波動。AI 無法可靠預測所有環境下的延遲波動。
   在某些情況下，AI 判斷「畫面元素出現」但尚未可交互，這就會導致動作失敗。
2. 操作訊息必須被系統接受
   滑鼠／鍵盤輸入、焦點切換、視窗激活、對話框彈出、遮罩層擋住、浮動 UI ／動畫干擾等，都可能導致操作訊息無法正確被接受。AI 無法直接繞過這些平台層面的限制或環境異常。
3. 多變異常情境的處理
   比如彈出視窗、模態對話框、提示框、異常訊息、session 過期、重定向、有時 UI 被遮擋、動畫干擾、異步任務尚未完成、異步資料回來順序不同，這些情境千變萬化。AI 雖然可以幫忙分析與建議，但在很多 edge case 還是需要人工介入或設計防禦機制。
4. 維護成本與模型漂移 (model drift)
   隨著 UI 的版本升級、前端重構、CSS 變動、DOM 結構變化，AI 模型可能需要重新訓練、調整。特別在大型系統中頻繁改動的模組，AI 工具可能無法快速適應或會誤判。
5. False Positive / False Negative 的風險
   AI 在定位、比對、錯誤判斷上會有誤差。有時它可能誤判某個變動為錯誤／失敗（false positive），或漏掉真正的異常 (false negative)。在測試系統中，這是致命的，因為測試工具如果本身有錯，那就失去意義。這點在系統性研究中常被指出。(arXiv)

總之，AI／GEN-AI 在 UI 自動化中能夠提供「輔助定位」、「視覺比對」、「錯誤診斷支援」、「測試生成輔助」等增益，但並未脫離這些原理上的限制：訊息傳遞、同步控制、環境穩定性與異常處理依然是核心挑戰。

業界／研究中的案例與最近數據

下面我整理幾個較具代表性的案例與最近（這兩年）的統計數據，來說明 AI 驅動 UI 測試在真實場景中的成功／失敗及限制。

案例 A：IDT 用 testRigor 將自動化覆蓋率從 34% 拉到 91%

• 背景：IDT 公司在其 QA 自動化中曾陷入測試覆蓋率停滯（約 33–34%）的瓶頸。多數人力在「維護既有測試」上耗費過多時間，無法有效擴展新的測試覆蓋。(testrigor.com)
• 做法：導入 AI／自然語言描述為基底的工具 testRigor，使非資深的手動 QA 人員也能撰寫自動化測試腳本。並讓工具擔負大部分測試維護與穩定性處理。(testrigor.com)
• 結果：
  • 在 9 個月內由 34% 覆蓋率提升至 91%。(testrigor.com)
  • 在第一年節省成本約 $576,000（美元）(testrigor.com)
  • 測試維護成本大幅下降，團隊幾乎不需花費額外時間在修復過時測試的工作上。(testrigor.com)

這是相對成功的案例，表明在某些應用場景（例如業務流程比較穩定、UI 變動頻率低或可被 AI 處理範圍內）中，AI 驅動的 UI 自動化確實能取得顯著效益。

但要注意，這類案例多是在工具能掌握定位器修補／元素偵測能力強、系統本身結構穩定性較高的情況下才可能成功；並不保證對所有複雜系統都能通用。

案例 B：Salesforce 的 AI 測試規模與錯誤量

• 背景 / 規模：截至 2025 年 4 月，Salesforce 的測試系統每天跑約 6 百萬次測試，涵蓋 780 億個測試組合 (test combinations)，每月約有 150,000 個測試失敗 (test failures)，以及每天 27,000 個程式變更 (changlists) 要驗證。(Salesforce Engineering Blog)
• 意涵：這是一個極大規模的驗測環境，顯示即便是一個重度投入自動化／AI 驗測的團隊，也會被龐大錯誤數、變更頻率高、組合多樣性等因素拉扯。
• 結論：即使使用 AI／自動化工具，也必須面對錯誤率／失敗數量的挑戰，以及變更頻繁所帶來的維護壓力。工具輔助雖能減少部分人工成本，但無法免除「錯誤檢視／修復／維護」的負擔。

這個案例提醒我們：在大規模真實產品中，測試失敗／異常仍是常態，不可能完全靠 AI 一鍵搞定。

系統性 / 文獻研究：AI 驅動工具的效益與限制

• 在 Garousi 等人的系統性研究中，對 56 款 AI 驅動測試工具做分類與評估。實證部分選了 Parasoft Selenic 和 SmartBear VisualTest 兩款工具，在開源系統上做對比。結論是：AI 工具確實可以 提升測試執行效率、降低部分維護成本，但在「處理複雜 UI 變化」、「誤判 (misclassification)」與「缺乏上下文理解」等方面仍有明顯限制。(arXiv)
• 比如在實驗中，有些 UI 改動是 AI 無法成功 self-repair 的，導致測試失敗；或 AI 判斷錯誤，把本來無害的 UI 微調當作異常而報錯。這些 false positive / negative 問題需人工審查。(arXiv)
• 另一篇名為 Future of Software Test Automation Using AI/ML 的論文，也指出雖然 AI/ML 在測試效率、覆蓋、缺陷偵測能力上有潛在加成，但維護成本、模型適應性、可靠性、可解釋性 (explainability) 等，是未來要克服的挑戰。(ResearchGate)
• 另外，在 Enhancing software test automation tools through Machine Learning 的研究中，透過問卷調查 22 位自動化測試工程師，也指出目前自動化工具（包含 AI／ML 擴充方案）在「維護性 (test script maintenance)」「動態元件處理 (dynamic element handling)」「可擴展性 (scalability)」等方面仍是主要痛點。(diva-portal.org)

最近統計數據：AI 測試／自動化採用率與痛點

• 根據 Testlio 的 “Top 30+ Test Automation Statistics (2025)” 報告，AI 驗測 (AI / ML in testing) 的採用率從 2023 年的 7% 提升到 2025 年約 16%。也就是說，AI 驗測仍在成長期，尚未成為主流。(Testlio)
• 在 TestResults 的 “Test Automation Report 2024–25” 中，有幾項值得注意的痛點數據：
  1. 約 53% 的受訪者認為他們的自動化工具「難用且難以維護」。(testresults.io)
  2. 有近 48% 表示“維護自動化測試”本身是時間與資源的大消耗。(testresults.io)
  3. E2E 測試（整體流程測試）被認為是最棘手、風險最高的部分。(testresults.io)
  4. 超過一半的團隊反映測試資料準備 (test data) 是常見痛點。(testresults.io)

這些數據印證，即使有 AI 加持，自動化測試在實務中仍面臨不少瓶頸與挑戰。

綜合觀察與建議：AI 是輔助，不是解藥

回顧前述內容，我認為在 GEN-AI（或更廣義的 AI 驅動）時代下，UI 自動化依然應被視為「有助力但有界限」的領域。

綜合觀察

方向	AI 在 UI 自動化可扮演的角色	局限與風險
定位器 / 元件識別修補 (self-healing)	減少因 UI 重構或屬性改動造成的斷裂測試	對於極端 DOM 結構改動、重疊/遮蔽元件、嵌套元件、動畫／過渡效果可能失效
視覺比對 / UI 差異偵測	捕捉樣式錯位、排版錯誤、元素體積變動、顏色細節差異	對細微變動（微像素級差異）、動態內容（如圖表、動畫）可能誤判或漏判
測試生成輔助	減少人工設計場景、快速產出初稿	生成場景可能缺乏業務語義理解、覆蓋不全、邏輯不嚴謹，需要人工作校正
錯誤診斷 & 測試失敗分析	協助定位失敗原因、建議修正策略	AI 誤判風險 (false positive / negative)、對環境異常無法推斷、缺乏解釋性
測試維護支援	自動重映射過時定位器、移除失效測試	若變動頻繁、模型未更新、結構變動太大可能無法恢復，需要人工干預

總體來說，AI 驅動 UI 自動化可以降低維護成本、提升定位穩定性、為測試工程師減輕部分重複性工作，但它並不能完全克服等待 / 同步 / 環境異常 / 操作可靠性 / 極端例外情況 / 測試本身錯誤的可能性。

眾所皆知：UI 層自動化速度遠慢於 API／後端測試、錯誤率高、不穩定性大、timeout 機制複雜，這些現象在現實中還是普遍存在的。AI 的輔助能使 UI 自動化「更好做一些」，但不至於完全改寫它的本質限制。

建議給做 UI 自動化 + 想導入 AI 支援團隊的策略

1. 維持測試金字塔的思惟
   即使 AI 能讓 UI 自動化成本下降，也不要放鬆對中層／API／服務層的測試重視。因為那邊仍然具備速度快、穩定性高、偵錯明確的優勢。
2. 選擇對的場景切入 AI / GEN-AI 支援
   在那些 UI 變動頻率低、流程穩定、定位器結構清晰的模組先導入 AI 輔助會比較安全；對於高變動、動機複雜、動畫重、特殊交互強的模組要特別驗證與控制。
3. 將 AI 功能視為輔助工具，而非完全信任黑箱
   例如 self-healing 功能給予建議，仍要人工作審查與驗證；錯誤判斷應該可回退手動方式。避免因 AI 誤判導致偽陽性 / 偽陰性。
4. 設計良好的等待／同步策略與 fallback 機制
   不要完全依賴 AI 判斷元素存在／可交互，要有重試、可回退邏輯、延遲策略策略 (adaptive wait) 等設計。
5. 定期重新訓練／校正 AI 模型
   隨著 UI 的演進與重構，AI 模型需持續更新／監控其準確度，以防模型「過時」。
6. 建立監控／報表機制
   監控測試失敗率、異常類型、AI 修復失敗率、人工修正次數等指標，以評估導入 AI 帶來的真實效益與風險。
7. 讓測試工程師與 AI 協作 (Human-in-the-loop)
   測試工程師負責複雜邏輯、異常狀況、業務語意驗證；AI 負責重複性、維護性任務。這樣才能發揮協同效應。

結語

在 GEN-AI 的浪潮下，UI 自動化確實迎來新的機會：工具能夠輔助定位、重映射、視覺比對、測試生成輔助、錯誤分析，讓部分繁瑣維護工作變得更可控、更自動化。但這並不意味著 UI 自動化的根本挑戰—等待／同步不確定性、操作可靠性、環境異常、維護成本、錯誤誤判—就完全消失了。

即使 AI 幫你自動識別畫面變化，也必須走那條訊息送到視窗、等待它回應、處理 timeout／異常的那條路，不管怎樣它都還在。AI 只能改善「定位／識別／維護」那塊的負擔，但難以完全取代 UI 自動化的核心瓶頸。