軟體測試介紹 — 為什麼推薦多寫一點整合測試？

什麼是 E2E 測試？

相信有接觸前後端開發的人，大概都對 E2E 測試這種測試不陌生。所謂的 E2E 是 end-to-end 的縮寫，也就是指端到端。

具體來說，E2E 測試會是以模擬使用者使用系統的方式，走過完整的流程，就像模擬使用者在用網站，測試的腳本一步步模擬使用者的行為，並寫下每個行為後預期會發生的結果。

測試的核心目的

寫自動化軟體測試的核心目的，是要給軟體產品團隊信心，讓團隊知道當軟體實際上線被使用者用時，不會有意想不到的事發生。也因此，當測試越貼近使用者實際使用軟體的方式，就能夠給團隊更多信心。

E2E 測試的優勢

從這個角度來看，E2E 測試因為在模擬使用者的行為，理想上應該最接近使用者使用軟體產品的形式，所以應該最能帶給軟體團隊信心。不過為什麼目前業界多數推薦多寫一點整合測試呢?

不論是早期的測試金字塔 (testing pyramid)，或者近幾年有聽到的測試金盃 (testing trophy)，在 E2E 測試的部分都是相對小的部分。甚至 Google 的 Testing Blog 之前也有一篇《Just Say No to More End-to-End Tests》在談跟寫更多 E2E 測試說不。

E2E 測試的耗時

這些論點背後有幾個共通點，第一個是 E2E 測試寫起來耗時、跑起來也耗時。這點相對好理解，畢竟要完整模擬使用者操作網站的每個流程，假如網站複雜一點、頁面與功能多一點，測試執行起來肯定很耗時。

E2E 測試的穩定性

第二個則是 E2E 測試實際上沒那麼穩定。怎麼說呢?

因為軟體團隊在寫程式時，通常會有外部依賴，所以如果出問題的是外部依賴的模組，那可能會出現團隊自己的程式碼沒問題，但仍無法通過測試的狀況。

外部依賴導致的測試問題

舉例來說，假如今天某個聊天機器人，背後是呼叫 OpenAI 的 API，而 OpenAI 的伺服器掛掉，導致 E2E 測試在模擬使用者的情況出現測試案例沒通過，但這時因為不是自身程式碼的問題，就會讓測試相對不穩 (俗稱有 flakiness)，導致測試案例沒過，但沒辦法透過修改程式碼讓測試案例跑過。

這種狀況就很尷尬，不是你的程式碼的錯誤，卻讓 E2E 測試的案例沒過；而因為是外部依賴出問題，所以測試沒有過你也沒辦法做什麼，那這樣測試測出沒過，對團隊程式碼的幫助何在呢?

難以測試的特殊案例

除了不穩定，E2E 測試還有一個問題是，相對難去測到某些特殊案例。舉例來說，假如今天我們想測試一個狀況是 A 模組先呼叫後呼叫 B 模組才可行，而 B 模組先呼叫後才呼叫 A 模組則會進到某個錯誤處理的情境。

從 E2E 測試的角度來看，這種狀況很難被測到，因為 E2E 是模擬使用者操作，所以一般都是照正常情境的 A 模組先呼叫。可能只有在極少數出問題時才會變成 B 模組先呼叫，這樣可能要跑非常多次測試才會出現一次異常，從測試角度來說很沒效率。

整合測試的優勢

因為上述這些點，讓業界目前更多人推崇整合測試，因為整合測試可以測到不同模組之間互動的結果，同時比起 E2E 測試更快、更穩定，且更容易去測一些特殊狀況。雖然沒有像 E2E 這樣完全模擬使用者，但總和考量下，還是比較推薦多寫一點的。

閱讀更多

如果你對軟體測試的內容感興趣，我們在 E+ 有更深入的討論。有興趣的讀者，歡迎加入 E+ 成長計畫。

本文為 E+ 成長計畫的深度內容，截取前三分之一開放免費閱讀。歡迎加入 E+ 成長計畫閱讀完整版本 (點此了解 E+ 的詳細介紹)