用 Selenium 進行 API 測試：哪些適合、哪些不適合

為什麼會出現「用 Selenium 進行 API 測試」這件事

有三個原因，但其中只有一個站得住腳。

• 測試套件本來就在那裡。 CI 裡已經有一個 Selenium 工作，大家都知道怎麼執行，把 API 檢查加進去是阻力最小的做法。這可以理解，但它是組織上的理由，而不是技術上的理由。

• 流程橫跨兩邊。 送出表單，接著確認 API 建立的資料紀錄是否正確。這個理由站得住腳，也是值得專門設計的情境。

• 前置準備與事後清理。 因為透過介面建立測試資料太慢，所以改用 API 來建立。這很合理，但它算是管線工程，而不是測試本身。

代價是什麼

行得通的分工方式

讓 Selenium 負責只有瀏覽器才能回答的問題：使用者看得到的流程是否正常運作。API 則在它自己的層級涵蓋，在那裡一次檢查就是一個請求，而不是一次頁面載入。在 Selenium 測試套件中呼叫 API，只用於前置準備與事後清理，那裡的重點是速度，而且不涉及任何斷言。

唯一真正橫跨兩邊的情境，也就是送出表單並驗證後端存下了什麼，值得刻意寫出來，而不是不小心寫成那樣。這類測試數量不多，而且值回票價。

獨立的 API 測試層需要處理什麼

不論你用哪一種工具，有四件事決定一套 API 測試能不能撐過第一年：會過期的 session、只在執行期才存在的值、彼此相依的呼叫，以及沒人清掉的資料紀錄。TestSprite 把它們分別稱為 Auto-Authentication、Dynamic Variables、Dependency Chains 和 Auto-Cleanup，而 API 測試說明文件 說明了其中的運作機制。

把這四件事做對，正是一套能長期存活的測試與一套兩季之後就被刪掉的測試之間的差別，而在 API 層級處理這些事，遠比硬接在瀏覽器測試套件上容易得多。

把前置準備這件事做對

用 API 為瀏覽器測試建立測試資料，是這兩者真正該放在一起的唯一地方，而且值得刻意設計，而不是碰巧寫成那樣。

讓它保持乾淨的原則是：前置準備的呼叫絕不做斷言。它們的工作是盡快把系統帶到一個已知狀態；如果其中一個沒成功，測試應該是「出錯」而不是「失敗」，因為測試資料建立失敗是基礎設施的問題，不是產品的缺陷。把兩者混為一談，結果就是一套有一半紅燈都是雜訊的測試。

第二個原則是：前置準備建立了什麼，事後清理就移除什麼，而且要綁定在那個測試上，而不是靠名稱比對。瀏覽器測試累積資料的速度比任何人預期的都快，而一個每週都變慢的列表頁面，背後通常是一段從來沒被寫出來的清理程式碼。

兩套一起執行

兩套測試都不需要知道彼此的存在。Selenium 照現在的方式在你的 CI 工作中執行，API 測試則在旁邊同時執行。

如果這條管線由另一個團隊負責，那麼 GitHub App 就是阻力最小的做法：它是一個 webhook，不會改動你的儲存庫任何內容，而且會在你的建置回報新版本上線時觸發。如果你反而希望這項檢查直接顯示在儲存庫裡，那麼一個 GitHub Actions 步驟就能做到。請參考 CLI 儲存庫。

TestSprite 在 API 層級涵蓋了什麼

TestSprite 負責獨立的 API 測試層，你不必把它硬接在瀏覽器測試套件上。API Discovery 會列舉出執行中的服務對外開放了哪些內容，plan generation 會針對功能、結構描述、授權、錯誤處理與邊界等類別提出測試案例，你再用日常語言去調整它們。

這四個狀態問題以產品功能的形式提供，而不是丟回去讓你的基礎設施處理：Auto-Authentication 讓 session 保持有效、Dynamic Variables 在呼叫之間傳遞值、Dependency Chains 推導執行順序、Auto-Cleanup 移除一次執行所建立的資料。這些正是讓一套 API 測試難以長久維持的因素，而在 API 層級解決它們，遠比在瀏覽器執行器裡解決容易得多。

你的 Selenium 測試套件維持原樣，繼續涵蓋只有瀏覽器才能回答的問題。兩者都從同一條管線執行。