今天開始換一個場景：AI E2E 測試。

傳統自動化的痛點

做自動化的人都知道成本很高，主要是：要知道元素位置在哪裡。

元素會變，而腳本認的是死的路徑。

我自己踩過最深的一次，是一個全新系統的專案。
初期效果非常漂亮，「改 A 壞 B」當天就抓得到，但到了中後期需求跟 UI 頻繁調整，腳本幾乎每天都要修。

當時也建議過「等穩定再改」，但這種事你我都知道...建議歸建議，現實總是有很多無法預期的東西存在的（懂的都懂）XDDD。

所以我們要讓 AI 能「決定現在要點哪個元素」這件事，到底怎麼做

就是我們接下來會說明的核心了

AI 自動化：Web 跟 App

因為 Web、APP 都屬於 E2E 的範疇，所以他們 執行思維完全是同一套：

找到元素 → 執行操作 → 驗證結果 → 失敗的時候，判斷它是抓到 bug 還是自己走錯路。

我該怎麼判斷 AI E2E 工具好與壞？

市面上已經有很多套 AI E2E 的工具存在了

但我不逐一列舉了，後面的文章會待到相關工具應用教學

但對我來說，想要的自動化測試不是「能跑」就好

而是：

同一支測試，跑一百次，要有一百次相同的行為
失敗的時候，它是真的抓到 bug，還是它自己走錯路

如果分不出這兩件事，那自動化就會變成雜訊，而雜訊比沒有測試更恐怖，因為會消耗人力去查，結果查完發現是假的，導致團隊對自動化信任度會逐漸降低。

四個維度

我實際拿來比的是這四個：

最重要莫過於 知識沉澱（E2E 的知識庫）：因為要裝的是「Xpath 是什麼、這一頁長什麼樣子、這顆按鈕在哪裡、上次它換過什麼名字、有沒有常用的術語詞彙 ..等等」。

這會大大影響我們用 AI 開發 E2E 的成果！

觀念先鋪到這裡，明天開始動手。

要講的是 Browser-use 這套工具，是「完全交給 AI 判斷並執行」，你只講一句白話，元素完全不用管，他自己都能搞定。