對於許多工程師來說，撰寫端對端測試（End-to-End Testing, E2E）最痛苦的不是寫測試邏輯，而是維護。在快速迭代的開發環境中，只要前端工程師稍微改動一個 HTML 標籤的 ID 或調整 UI 佈局，原本正常的 E2E 測試腳本就會立即崩潰。這種現象被稱為測試脆弱性（Brittleness），導致團隊花費大量時間在修復那些並非功能錯誤、而僅是界面變動導致的失敗測試。
為了降低這種維護成本，Slack 工程團隊提出了一種稱為 Agentic Testing（代理人測試）的新方法。這不是要取代傳統測試，而是引入 AI Agent（人工智慧代理人）來處理那些對變動敏感的 UI 交互流程。
理解傳統 E2E 測試的痛點
傳統的傳統 E2E 測試是決定性的（Deterministic），其運作邏輯像是一本死板的說明書：點擊 A 按鈕，輸入 B 文字，然後驗證 C 結果。這種模式依賴於穩定的選擇器（Selectors，例如 CSS ID 或 XPath）和可預測的流程。一旦 UI 結構改變，選擇器失效，測試就會中斷。這導致了大量的偽陽性失敗（False Positives），即測試失敗了，但功能其實是正常的。
Agentic Testing 的核心邏輯：從步驟導向轉為目標導向
Agentic Testing 將測試的定義從 具體步驟 轉向 高層級意圖（Higher-level Intent）。
在這種模式下，工程師不再定義 點擊哪個按鈕，而是定義一個目標，例如 讓用戶成功發送一則訊息。AI Agent 接收到這個目標後，會扮演一個能觀察、思考並行動的角色。它會分析目前的 UI 狀態，決定下一步該採取什麼行動，並在執行後觀察結果。
如果 AI Agent 發現原先的按鈕位置變了，或者 UI 結構有所調整，它不會立即報錯，而是會嘗試尋找替代路徑來達成目標。只要最終結果符合預期的斷言（Assertions），這次測試就被視為通過。
Agentic Testing 的運作流程
一個典型的代理人測試流程包含以下環節：
首先是意圖傳遞，將測試目標交給 Agent 層。 接著是規劃與執行，Agent 根據當前應用程式的狀態，動態選擇要操作的 UI 元素或 API。 然後是觀察與迭代，Agent 檢查操作後的結果，若未達成目標則調整策略再次嘗試。 最後是驗證與記錄，將執行結果與斷言比對，並記錄完整的執行軌跡（Execution Traces），讓工程師能回溯 AI 當時是如何做決定的。
實務上的應用限制與定位
儘管 AI Agent 看起來很強大，但 Slack 工程團隊明確指出，它不能完全取代傳統測試，原因在於成本與穩定性。
首先是成本考量。調用 AI 模型執行每一次測試的成本遠高於執行一段靜態腳本，因此 Agentic Testing 目前更適合用於目標明確的除錯（Debugging）或探索性測試（Exploratory Testing），而非放在每次 Commit 都要跑的 CI（持續整合）流水線中。
其次是定位問題。在測試金字塔中，單元測試（Unit Tests）和整合測試（Integration Tests）依然負責驗證核心邏輯與合約正確性。而 Agentic Testing 被定位在 E2E 層的最頂端，專門處理那些對 UI 變動極其敏感、且流程複雜的場景。
為了防止 AI Agent 在測試過程中失控，Slack 引入了行為約束（Constraints），例如限制 Agent 可執行的動作範圍、設定探索邊界以及定義強制停止條件。同時，可觀測性（Observability）至關重要，所有 Agent 的決策過程都必須結構化記錄，以便工程師在測試失敗時能快速定位是 AI 迷路了，還是功能真的出錯。
總結：測試策略的互補
對開發團隊而言，最理想的配置是將 決定性測試 與 代理人測試 結合使用。
決定性測試負責快速、可重複地驗證關鍵路徑，確保回歸測試的效率。 代理人測試則負責處理不穩定的 UI 流程，減少因界面微調而產生的維護噪音，並協助開發者在複雜的 UI 行為中重現生產環境的問題。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。