如果你正在開發一個網站，每次改了一段程式碼，你是不是都會手動打開瀏覽器，自己點一遍看看有沒有壞掉？
這樣做一次兩次還行，但隨著功能越來越多，你根本不可能每次都手動測完所有流程。
這時候，End-to-End 測試（端對端測試） 就是來救你的。
它可以模擬一個真實使用者的操作，自動幫你跑過整個網站流程，確保每個環節都沒有問題。
這篇文章會帶你了解 End-to-End 測試到底在做什麼、為什麼它這麼重要，以及該用什麼工具來上手。
End-to-End 測試到底在做什麼？
先來聊聊「End-to-End」這個名字是怎麼來的。
End-to-End 翻成中文是「端對端」，但光看這三個字其實蠻容易搞混的。
這裡的兩個「端」，並不是指前端和後端，而是指 使用者動作的起點 和 預期結果的終點。
舉個例子：假設你的網站上有一個「登入」功能。
使用者從點擊「登入」連結、輸入帳號密碼、按下送出按鈕，到最後成功進入 Dashboard 頁面。
這整段旅程的「第一端」就是使用者點擊「登入」連結的那個動作，「第二端」就是成功看到 Dashboard 這個結果。
所以「端對端測試」的意思就是：從使用者的操作開始，一路測到預期結果出現為止，確保這整段流程都能走得通。
它不是只測「驗證密碼的函式有沒有寫對」（那是 Unit Test），也不是只測「前端送出的請求跟後端 API 能不能正確溝通」（那是 Integration Test）。
它測的是一段 完整的使用者旅程：從點擊登入、填寫表單、送出請求，到最後看到 Dashboard，中間每個環節是不是都能正常運作。
理解了命名的由來，接下來看看它實際上怎麼運作。
簡單來說，End-to-End 測試就是 用程式碼來模擬一個真實使用者操作網站的過程。
延續剛才的登入例子，你可以寫一段腳本（script），告訴電腦：
「幫我打開瀏覽器，找到 Logo 旁邊的『登入』連結，點擊它，檢查網址是不是跳到了 /login 頁面，然後在帳號欄位輸入 test@email.com，在密碼欄位輸入密碼，按下送出按鈕，最後檢查畫面是不是跳到了 /dashboard。」
這段腳本會自動打開 Chrome、Firefox、WebKit 等瀏覽器，然後一步一步執行你寫好的操作。
每個瀏覽器都會跑一遍同樣的流程，幫你確認這個登入功能在不同瀏覽器上都能正常運作。
為什麼 End-to-End 測試這麼重要？
你可能會想：「這聽起來好像沒什麼，我自己點一下不就好了？」
但真正的重點在於 使用者流程（User Flow） 的完整性。
用一個實際的情境來說明
假設你的網站有這樣一個新使用者的流程：
- 使用者第一次來到網站，點擊「註冊」
- 填寫個人資料
- 被導向到新手引導頁面（Onboarding）
- 有些人會跳過引導，有些人會完成引導
- 不管哪種情況，最後都要被導向到主畫面（Dashboard）
這只是一條使用者流程，你的網站上可能有好幾條不同的流程。
這條流程涉及好幾個頁面和元件。
註冊頁面有表單驗證的邏輯，新手引導頁面有跳過和完成兩條路線，Dashboard 有權限檢查確保只有登入後的使用者才能進入。
這些頁面背後可能分別由不同的工程師負責，或者在不同時間點被修改。
最常見的痛點：改 A 壞 B
舉個例子：你的同事今天改了註冊表單，把 Email 的格式檢查改得更嚴格。
他測了一下註冊頁面，沒問題，推上去了。
結果隔天客服收到一堆回報：「我註冊不了。」
原因是某些舊格式的 Email 過不了新的驗證，使用者卡在註冊頁，後面的引導和 Dashboard 完全到不了。
再舉一個：你把引導頁的「跳過」按鈕從右上角移到底部，純粹改 UI，功能完全沒動。
但移的時候不小心把按鈕的 CSS class 改掉了，結果點「跳過」之後頁面不跳轉了。
這種 Bug 特別陰險 —— 你覺得「我只是改了樣式而已」，根本不會想到要去測後面的跳轉邏輯。
這就是所謂的 「改 A 壞 B」。
如果每次改完程式碼，都要自己手動走一遍整條流程，光一條流程就要花 5 到 10 分鐘。
你的網站上可能有五條、十條不同的流程，每次改一行程式碼就要花一小時手動測試，根本不切實際。
End-to-End 測試幫你省下的東西
省時間：你只要寫一次測試腳本，之後每次部署程式碼的時候，它都會自動跑一遍。
不管你改了註冊頁面、引導頁面、還是 Dashboard，所有流程都會在幾分鐘內被自動驗證完畢。
省心力：你不用在腦中記住「改了這裡，要記得去測那裡」。
測試腳本會幫你記住所有該測的東西，你可以放心地專注在開發新功能上。
省成本：Bug 在上線之前被抓到，只需要工程師花時間修就好。
但如果 Bug 上了線，使用者遇到問題、客服被轟炸、信任度下降，這些代價遠比寫一段測試腳本高得多。
簡單來說，End-to-End 測試就是幫你把「手動走一遍流程」這件事自動化。
你寫一次，它跑一輩子。
如果有任何環節壞了，測試會馬上告訴你，不會等到使用者來投訴你才知道。
End-to-End 測試怎麼跟部署流程搭配？
在實務上，End-to-End 測試通常會整合到你的 部署流程（Deployment Pipeline） 裡面。
這是什麼意思呢？
就是每次你推一版新的程式碼，系統會自動執行以下步驟：
- 先把程式碼編譯（Build）起來
- 接著跑所有的 End-to-End 測試
- 測試會在多個瀏覽器上執行
- 如果有任何測試沒通過，這版程式碼就不會被部署到正式環境
這樣做的好處是：Bug 永遠不會偷偷溜上線。
你在正式環境出問題之前就能抓到它，省下大量的除錯時間和使用者投訴。
兩個主流的 End-to-End 測試工具：Cypress 與 Playwright
目前最主流的 End-to-End 測試工具有兩個：Cypress 和 Playwright。
Cypress：簡單好上手
Cypress 的語法很像 jQuery，簡潔又直觀。
用我們前面的登入例子來看，Cypress 的測試大概長這樣：
describe('登入流程', () => {
it('應該成功登入並跳到 Dashboard', () => {
// 打開網站首頁
cy.visit('/')
// 找到「登入」連結，點擊它
cy.contains('登入').click()
// 確認網址跳到了 /login
cy.url().should('include', '/login')
// 在帳號欄位輸入 Email
cy.get('#email').type('test@email.com')
// 在密碼欄位輸入密碼
cy.get('#password').type('mypassword123')
// 點擊送出按鈕
cy.get('button[type="submit"]').click()
// 確認最後跳到了 /dashboard
cy.url().should('include', '/dashboard')
})
})可以看到每一行都很像在「用英文描述你在做什麼」，讀起來非常直覺。
如果你是第一次接觸 End-to-End 測試，Cypress 是一個很好的起點。
它特別適合中小型專案，讓你可以快速寫出測試並看到結果。
不過 Cypress 有一些限制，例如它目前還不支援 Safari（準確來說是 WebKit 引擎）。
另外，如果你想要在 CI 上平行跑測試，你需要使用 Cypress 的付費 Dashboard 服務。
Playwright：更強大、更靈活
Playwright 是微軟推出的測試框架，功能上比 Cypress 更強大。
同樣用登入的例子，Playwright 的寫法是這樣的：
import { test, expect } from '@playwright/test'
test('應該成功登入並跳到 Dashboard', async ({ page }) => {
// 打開網站首頁
await page.goto('/')
// 找到「登入」連結，點擊它
await page.getByText('登入').click()
// 確認網址跳到了 /login
await expect(page).toHaveURL(/login/)
// 在帳號欄位輸入 Email
await page.fill('#email', 'test@email.com')
// 在密碼欄位輸入密碼
await page.fill('#password', 'mypassword123')
// 點擊送出按鈕
await page.getByRole('button', { name: '送出' }).click()
// 確認最後跳到了 /dashboard
await expect(page).toHaveURL(/dashboard/)
})你會發現 Playwright 的語法比 Cypress 多了 async/await，每一步都要加 await，寫起來稍微囉嗦一些。
但好處是它提供了更精確的元素選取方式（像是 getByRole、getByText），讓測試更接近真實使用者的操作邏輯。
它支援 Chromium、Firefox 和 WebKit 三種瀏覽器引擎。
這裡要補充一個觀念：這些工具其實不是直接跑在 Chrome 或 Safari 上，而是跑在它們底層的 瀏覽器引擎 上。
Chrome 的底層引擎是 Chromium，Safari 的底層引擎是 WebKit。
Playwright 的優勢在於：
- 支援平行測試：不需要額外付費，就能同時跑多個測試。
- 支援測試分片（Sharding）：可以把大量測試拆分到不同的機器上跑，加快速度。
- 內建錄製工具（Recorder）：你只要自己在瀏覽器上操作一遍，Playwright 就會自動幫你生成測試腳本，非常方便。
不過 Playwright 的語法比 Cypress 稍微複雜一些，學習曲線會高一點。
Cypress 和 Playwright 該選哪一個？
這裡整理一張比較表，幫助你快速做決定：
簡單的判斷原則：
如果你的專案規模不大，或者你是第一次接觸 End-to-End 測試，先從 Cypress 開始。
如果你的專案比較大、需要平行跑測試、或者你不想為了平行測試付費，那就選 Playwright。
小結
來整理一下這篇文章的重點：
- End-to-End 測試 就是用程式碼模擬真實使用者的操作，自動驗證網站流程是否正常。
- 它最大的價值在於 保護使用者流程的完整性，確保任何程式碼的改動不會搞壞既有功能。
- End-to-End 測試通常會整合到部署流程中，在程式碼上線之前自動執行。
- Cypress 適合新手和中小型專案，語法簡單好上手。
- Playwright 適合需要更多功能的中大型專案，支援平行測試和錄製工具。
如果你的網站已經在正式環境上運行，而且有一定的流量，那 End-to-End 測試不是「可以有」，而是「一定要有」。
現在就開始學吧。