測試金字塔

測試金字塔是一種思考方式，說明如何使用不同類型的自動化測試來建立平衡的投資組合。其重點在於，您應該執行更多低階 單元測試，而不是透過 GUI 執行高階 廣域堆疊測試。

在我的職業生涯中，測試自動化大多是指透過使用者介面驅動應用程式的測試。此類工具通常會提供一種功能，可以記錄與應用程式的互動，然後讓您回放該互動，並檢查應用程式是否傳回相同的結果。這種方法一開始運作良好。記錄測試很容易，而且不懂程式設計的人也可以記錄測試。

但這種方法很快就會遇到問題，變成 冰淇淋甜筒。透過 UI 進行此類測試很慢，會增加建置時間。通常需要安裝測試自動化軟體的授權，這表示只能在特定機器上執行。通常無法在「無頭」模式下輕鬆執行這些測試，也無法由腳本監控以放入適當的部署管線中。

最重要的是，此類測試非常脆弱。系統的增強很容易導致大量此類測試中斷，然後必須重新記錄。你可以放棄記錄播放工具來減少這個問題，但這會讓測試更難寫。[1]即使在撰寫它們的良好實務中，端到端測試也更容易出現非確定性問題，這可能會破壞對它們的信任。簡而言之，透過 UI 執行端到端的測試是：脆弱的、撰寫成本高昂的，以及執行耗時的。因此，金字塔論點是，你應該透過單元測試執行比透過傳統的基於 GUI 的測試更多的自動化測試。[2]

金字塔也主張測試的中間層，透過應用程式的服務層執行，我稱之為皮下測試。這些測試可以提供許多端到端測試的優點，但避免處理 UI 架構的許多複雜性。在網路應用程式中，這將對應於透過 API 層進行測試，而金字塔頂端的 UI 部分將對應於使用Selenium或 Sahi 等工具進行的測試。

測試金字塔在敏捷測試圈中經常出現，雖然其核心訊息很明確，但關於建立平衡良好的測試組合還有很多話要說。一個常見的問題是，團隊混淆了端到端測試、UI 測試和面向客戶測試的概念。這些都是正交特性。例如，豐富的 javascript UI 應該使用Jasmine等工具，以 javascript 單元測試測試其大部分 UI 行為。一組複雜的業務規則可以在面向客戶的表單中擷取測試，但僅在相關模組上執行，就像單元測試一樣。

我總是認為高階測試是作為第二線測試防禦。如果你在高階測試中遇到失敗，不僅你的功能程式碼有錯誤，你還缺少或有錯誤的單元測試。因此，我建議在修復高階測試暴露的錯誤之前，你應該使用單元測試複製錯誤。然後，單元測試可確保錯誤保持失效狀態。