軟體測試 — E2E 測試是什麼? 跟整合測試有什麼區別?

E2E 測試如其名是一種端到端 (end-to-end) 的測試，釐清 E2E 測試的定義、E2E 與整合測試的區別，不僅是在實務工作上重要 (因為能讓你確保真正能測到想要測的東西)；在準備面試上，因為這是個常會被問的問題，所以如果有要找新工作，也會是推薦要準備的題目之一。

因此，希望透過這篇貼文，用更完整的方式介紹 E2E 測試，讓對這類測試還不熟的讀者，有更全盤的了解。

首先，E2E 這個詞，單看「端到端」其實蠻混淆人的，因為所謂的「端到端」並不是指整個應用流程的全部，而是從使用者這一端開始的動作，一路到相對應的結果完成。

因此，E2E 測試多半會從使用者流程的角度出發看事情，例如在電商網站中測試使用者能順利完成購物，這時的端到端，就會是從使用者這端進到網站，到完成購物後收到確認信這個結果。

具體來說，在上述的流程中，可能會一路測試包含使用者能夠順利登入、能搜尋商品、能看到商品詳情、能把商品加到購物車、能順利結帳，以及最後有收到確認信，這一路下來需要每一個環節連在一起都順利完成，才能通過測試。

整合測試與 E2E 測試的關鍵區別在哪?

相信讀完上面這一段 E2E 測試的介紹，有些讀者可能會有疑問，因為在業界中有另一個叫「整合測試 integration testing」的方式，也是用來測不同環節能順利整合在一起，那這兩者有什麼區別?

或者換個方式問，假如今天整合測試也是把從登入到結帳完成的所有步驟都測過，這樣跟 E2E 測試有區別嗎?

事實上即使如此，兩者仍是有區別的，因為整合測試與 E2E 測試的關注點不同，所以即使整合測試也是把從登入到結帳完成的所有步驟都測過，跟 E2E 的測試方式也會不一樣。

這兩種測試的關鍵區別在於

E2E 測試的關注點在是使用者與系統的互動，所以是從使用者的視角出發來測試。
整合測試的關注點則是元件與模組之間能否順利整合在一起，因此測試的視角不是特別從使用者的視角出發

在整合測試下，需要先釐清「想要測什麼之間的整合」，然後根據這個問題，來規劃測試案例。在有了清楚明確要測試的東西後，就可以把非重點要測試的東西，直接模擬 (mock) 掉就好。這樣做的好處，是可以把關注點切得很乾淨 (俗稱關注點分離)，讓想要測的部分不會被其他因素干擾。

在 CircleCI 的《How to test software, part I: mocking, stubbing, and contract testing》一文中 (連結) 用很精闢的方式總結這個觀點：在進行整合測試時，測試的是服務與服務之間的關係。一種方法是將所有相依的服務在測試環境中都跑起來，但這並不必要。這麼做可能會讓那些你無法控制的服務，產生潛在的故障點，從而增加你測試的時間與複雜度。

With integration tests, you are testing relationships between services. One approach might be to get all the dependent services up and running for the testing environment. But this is unnecessary. It can create a lot of potential failure points from services you do not control, adding time and complexity to your testing.

而相較之下，E2E 測試全程仿照使用者的使用流程，不會模擬任何部分。因此，同樣是要測試 GitHub 發完 PR 後可以看到 PR 的詳細資訊，用整合測試可以模擬掉登入的部分，專注在測試發 PR 的 API 跟拿到 PR 詳細資訊的 API 兩者共同運作時不會出問題。但是 E2E 測試就不會模擬登入的部分，而是會真的如使用者登入一樣，點擊輸入框、輸入帳號密碼、點擊登入按鈕這樣詳細的操作。

所以假如今天使用者登入的 API 出問題，E2E 測試會無法通過，但是整合測試會能通過 (因為會模擬掉登入的部分)。

為什麼不要寫太多 E2E 測試?

在了解完 E2E 測試與整合測試之間的區別後，接著我們要來談過去在業界中普遍有的觀點「不要寫太多 E2E 測試」。

從早期的測試金字塔 (testing pyramid)、Google 改良後推出的推薦測試比例 (連結)，到後來有的測試金盃 (testing trophy)，可以看到 E2E 測試的比例都很低。甚至在早期 Google 的 Testing Blog 中有一篇文章標題就叫《Just Say No to More End-to-End Tests》的文章 (直譯成中文就是「跟寫更多 E2E 測試說不」)。

過去業界之所以一直有「不要寫太多 E2E 測試」這個觀點，最主要是因為以下幾個原因

寫與維護 E2E 測試比較耗時間，特別是過去因為網頁技術還不夠成熟，所以要寫模擬使用者的操作，會比較複雜一點。
跑 E2E 測試比較花時間，試想同樣的從登入到結帳流程測試，整合測試可以拆成不同的子流程，然後同時跑所有測試；但 E2E 測試因為模擬使用者流程，所以必須從頭執行到尾，無法拆開併行，因此會花比較多時間。
假如測試沒有通過，要找原因會比較慢，因為不像整合測試因為範圍比較限縮所以能馬上定位問題；許多時候假如是第三方依賴出問題導致測試沒通過，E2E 測試會特別難辨別問題出在哪。
測試的不穩定性，因為 E2E 測試不用任何模擬，意即假如有第三方依賴出問題，對開發者本身來說，就會是「自己寫的程式碼沒問題，但測試沒通過」的窘境。理論上，假如測試沒通過，開發者應該要修復問題讓測試通過；但假如是第三方依賴出問題，開發者只能苦等到第三方依賴被修好才能讓測試通過。

換句話說，即使 E2E 測試本身是有幫助與價值，因為過去寫 E2E 測試、維護 E2E 測試，以及跑 E2E 測試的成本都偏高，所以導致整體的投資報酬率 (ROI) 不如單元測試與整合測試。因此，相較之下不推薦寫 E2E 測試，而是推薦把有限的時間花在單元測試與整合測試上。

閱讀更多

以上是關於 E2E 測試的介紹，在 E+ 成長計畫中，我們有關於 E2E 測試更深入討論的主題文，會額外涵蓋 E2E 與整合測試具體的測試案例與測試腳本，以及探討在 AI 時代下，可以如何重新思考「不要寫太多 E2E」這個論點，以及如何透過 AI 來加速完成 E2E 測試的撰寫。

對更深入了解這個主題，以及其他前後端開發、軟體工程主題感興趣的讀者，歡迎加入 E+ 成長計畫一起成長 (連結)。