所謂端到端測試，英文為 End-to-End（簡稱 E2E）Testing，是一種從使用者端的角度，來檢查整個服務是否能達到預期功能和行為的一種測試。

我們之前聊到測試金字塔時提過端到端測試，這是位於金字塔頂端，Scope 最大、開發和測試成本最高的。

那麼，在什麼情況我們需要撰寫 E2E Testing 呢？

E2E Testing 的目的

在談及驗收清單時，我們聊了從需求出發，怎麼用 Acceptance Criteria（AC）定義「做完」這件事。

透過需求撰寫出的 AC，只要所有的項目都驗收通過，也就代表這個需求已經被完成。每一個 AC 的出發點都是從使用者的角度來使用這個功能，和 E2E Testing 做的事情本質上是一樣的，所以可以這麼說，E2E Testing 就是一種在驗證整個產品的需求是否被滿足的測試。

而通常我會執行 E2E Tests 的時間點，也就是當一些需求中列出的功能被完成了之後，在大約產品的 Release 週期最後，所有的子模塊都開發完畢了，這個時候綑起來驗證整個服務。

如果通過所有重要的 E2E Tests，這個 Release 的服務就能交付了。

怎麼寫 E2E Tests的測項細節

至於 E2E Tests 要寫些什麼，來看看一些例子：

我們一樣舉在上一講的整合測試有聊過的商品管理這個例子，假設一個商品的欄位有名稱、數量兩種欄位，延伸整合測試的 E2E Testing 就是將前端的 UI 操作也納入測試中。

E2E Tests 一個 Test Suite 及的其中的部分測項，架構和範例如下所示：

A. 環境

1. 硬體及瀏覽器：使用 x86 CPU >= 2 Cores，RAM >= 4GB；使用 > Windows 10 版本、 Chrome > 129.0 版本

2. 使用者資料：使用帳號 tester 為登入 User

3. 預設 Config：（使用之資料庫 host / password, etc.）

*商品列表示意圖

E. 風險

1. 測項 8 的「刪除之商品不存在」，可能造成使用者混淆，不知道是刪除的實際商品為何

如上所述，將每個測項的操作步驟記錄下來，然後列出哪個步驟的期望結果為何、最終測試結果為何，如果失敗的話下次測試的時間及結果又為何，又有沒有可能的風險或能改進的地方，這樣就是一個算是完整的 E2E Test 了。

重點是我們能否看著這樣一份文件，等幾個月後還能看懂，並且能重複同樣的操作流程即可，這是為了未來改到相關功能的時後，不會把原本的既有功能改壞。

自動化與手動 E2E Testing 的取捨

如果已經撰寫了這樣的一份 E2E Testing 文件，下一個步驟就是可以考慮「自動化」了。不過，我們雖然在測項的內容寫得容易，但實際上要將其寫成程式還是一點麻煩的。

透過如 Cypress、Selenium 這樣的 E2E Testing 框架，雖然能夠操控瀏覽器來點選元件，但是在 Select 到某個 DOM Element 時就不免需要用到 XPath、CSS Selector 來找到要點的按鈕或輸入的內容，在開發時就要考慮先加上一些 HTML Tag 來方便定位。

上面舉的例子還算是簡單，如果遇到更複雜一些的例子，例如收發即時的 WebSocket 資料、點下按鈕需要等待延遲時間的操作、串接一些難以 Mock 或 Stub 的第三方服務時，要將測試步驟確實的自動化，就有些困難了。

因此最好再評估 E2E 自動化的開發成本，以及我們多久會跑一次 E2E Tests，最終再決定我們是否該花這個時間去寫程式讓測試自動化。不然，若是測項複雜，又是每 3 個月才跑一次 E2E Tests，我們不如照著文件手動跑一次還比較有效率。

總結來說，E2E Tests 的目的在於可以幫助我們確認需求是否真的被完成，能夠最終交付出去，是相當必要的測試。至於自動化 E2E Testing，我們還是需要依據執行的頻率和開發的成本，再看看是否要投資時間開發。