Selenium 與 TestSprite:2026 年各自適合的位置

先講結論

• 選擇 Selenium,如果 你需要精確的控制、少見的瀏覽器或平台涵蓋範圍,或是你身處一個早已圍繞 WebDriver 建立起來的生態系。

• 選擇 TestSprite,如果 你的瓶頸在於決定要測什麼、以及讓測試套件不致失效,尤其當大部分程式碼是由 coding agent 產出的時候。

• 兩者並行,如果 你已經有一套大家信任的 Selenium 測試套件。把它留著,再加上 agent 驗證,補足沒人有時間撰寫的覆蓋廣度。

並列比較

Selenium 依然是正確答案的場合

• 特殊的涵蓋需求。 舊版瀏覽器、特定的驅動程式行為、嵌入式目標環境。論涵蓋範圍,沒有其他工具能與之相比。

• 確定性的操作順序。 當互動的確切順序本身就是規格的一部分,絕對不容許任何偏移時。

• 既有的 Grid。 多年累積下來的基礎設施、技能與慣例是資產,不是遺留下來的問題。

這套模式會在哪裡耗盡

極限是算術問題。每一個測試都由人撰寫,而人的數量是固定的,功能的數量卻不是。最先出現的是兩個徵兆:測試覆蓋集中在寫起來有趣的流程,而不是真正會壞掉的流程;以及每個 sprint 裡維護所佔的比重不斷上升,直到有人提議把不穩定的測試砍掉。

遷移的真正代價

決定離開 Selenium 的團隊,通常會低估一件事,又高估另一件事。

被低估的是:Grid 不只是基礎設施,而是一整組烘進每個測試裡的假設。逾時設定是照它的延遲調的,平行度是照它的容量調的,截圖處理是照它的儲存空間調的。這些假設沒辦法一起搬走,而且在你第一次換個地方執行之前,它們完全看不見。

被高估的是:測試本身。多數測試套件的核心是二、三十條大家真正依賴的流程,其餘則是一整條已經一年沒人看過的長尾。搬核心只要一週。決定放棄長尾才是要開三次會的部分,而那通常是正確的決定。

這也是為什麼在旁邊多跑一套,比整批遷移更划算。哪些流程真的在承重,是靠觀察哪些流程安靜下來會有人發現,才看得出來的。

兩者並行

用「這個測試是誰決定要存在的」來劃分。刻意指定的流程留在 Selenium。大範圍的迴歸測試,以及對 coding agent 產出變更的驗證,交給 agent。兩者從同一條 pipeline 執行,彼此不必知道對方的存在。

如果你正在評估,就刻意弄壞一個東西

製造一個真正的迴歸,例如一個按下去不再真的存檔的儲存按鈕,然後看看每個工具回報什麼。三個問題:它會不會失敗?失敗訊息有沒有指出真正的落差?負責修的人或 agent 能不能直接從那份輸出著手,而不必自己把來龍去脈重新推一遍?如果一個工具在根本沒跑到斷言的那次執行上回報通過,它就沒通過唯一重要的那項測試。

兩條路線,而選擇的關鍵其實在於誰擁有這條 pipeline。從儀表板連接 GitHub App ,不需要對你的儲存庫做任何更動,因為它反應的是你的建置本來就會發出的部署。而加入一個 GitHub Actions 步驟,則是把這項檢查放進儲存庫裡,像建置流程的其他部分一樣接受審查;目前的指令都放在 CLI 儲存庫。

TestSprite 能為使用 Selenium 的團隊補上什麼

不吃撰寫人力的測試覆蓋。測試案例由你的產品產生,再用白話文調整,覆蓋廣度不再受限於你能挪出多少工程師去寫測試。

日常使用中還會看到另外兩個差異。步驟表達的是意圖而不是定位器,因此一次不改變任何功能的改版不會讓整套測試變紅,這消除了維護工作最大的單一來源。而失敗會以一段描述回報:嘗試做了什麼、應用程式實際做了什麼、兩者在哪裡分歧,這樣的輸出人看得懂,coding agent 也用得上。

你的 Grid 和既有的測試套件維持原樣。實際的結果是:沒人有時間自動化的流程被涵蓋了,而你的團隊刻意寫下的那些,依然掌握在你手上。