為什麼 E2E 自動化測試還是沒辦法（完全）解決軟體測試上的問題

最近討論到如何替產品添加自動化測試的話題：現在 AI 很厲害！產生瀏覽器腳本精準又快速，應該馬上就能替代手動測試，每個情境都測過一次吧？

執行 E2E（End to End）測試有無法忽視的強大魅力：

• 黑箱測試易於執行
• 產生最高的信心度
• 一次測驗整體代碼
• AI 產固定測試腳本成熟穩定又高效

但真實環境實際要面對的考驗是：

• 不清楚的規格：如果連系統的預期行為都不明朗，要如何測試？
• 副作用：測試操作會影響測試環境
• 測試環境：全面真實的環境建構緩慢
• 不穩定：程式有更多理由改變而破壞測試
• ⋯⋯

舉例來說一個簡單的刪除角色功能：「點刪除按鈕，角色消失」，背後可能代表什麼？

功能: 刪除角色

  場景: 正確刪除
    假如：已登入的管理員
    當：刪除用戶
    那麼：用戶正確刪除

  場景: 缺少參數
    假如：已登入的管理員
    當：刪除用戶（缺少必要參數）
    那麼：提示參數錯誤

  場景: 沒有管理員權限
    假如：已登入的非管理員使用者
    當：刪除用戶
    那麼：提示權限不足錯誤

  場景: 刪除自己
    假如：已登入的管理員
    當：刪除自己的角色
    那麼：提示不可刪除自己角色錯誤

  場景: 刪除不存在的用戶
    假如：已登入的管理員
    當：刪除不存在用戶
    那麼：提示用戶不存在錯誤

  場景: 刪除主管理員
    假如：已登入的管理員
    當：刪除主管理員
    那麼：提示不可刪除主管理員錯誤

1. 看似簡單的功能也能有多種前提、壞掉的方式、壞掉的地方，AI 不會理解你的商業邏輯應該如何運作，陳舊系統大多都沒有具體規格。
2. 6 個場景意味著一個功能就需要全面重啟整個服務 6 次，如果不想？那麼測試副作用將會不可避免的交叉影響造成虛假的信心和假警報。
3. 每個測試都是需要維護才能生效的資產，否則就是累贅，E2E 測試是最容易被破壞，且難以維護的測試形式。

AI 解決了「產自動化測試腳本」的問題，但那只是其中一個瓶頸，要達成有效的測試更多是需要：

• 理解產品運作，且能夠有序定義規格的能力
• 能夠善用測試種類，用合適的方式與工具導入測試的能力（靜態測試、單元測試、元件測試、整合測試、E2E 測試、Mock Data、CI 反饋建構、架構分層⋯⋯）