瞭解如何根據專案的需求，將不同的測試類型合併為合理策略。
歡迎回來！在最後一篇文章中，我們深入探討瞭如何製作不同的測試類型與內容，並闡明測試類型定義。還記得這張小網路迷因圖片嗎？您可能已經好奇，您學到的所有測試類型可以如何搭配運作。
接下來，您將清楚瞭解這一點。本文將介紹如何將這些測試類型合併為合理的策略，並選擇適合專案的策略。
您可以將策略與多種形狀進行比較，以便更瞭解策略的意義。以下列出各項策略，分別設定大小和開發範圍。
讓我們進一步探究各項策略，並瞭解這些策略名稱背後的意義。
決定測試目標：您希望透過這些測試達成什麼目標？
著手製定優質策略前，請先擬定測試目標。您何時認為自己的應用程式已經過充分測試？
開發測試時，獲得高測試涵蓋率通常是開發人員的最終目標。但一向是最合適的做法嗎？您在決定測試策略時，可能會考量另一個關鍵因素：滿足使用者的需求。
身為開發人員，您還使用許多其他應用程式和裝置。在此情況下，您就是仰賴這些系統「照顧工作」的使用者。因此，您需要仰賴無數開發人員來全力讓自己的應用程式和裝置順利運作。身為開發人員，您也努力履行這項信任。因此您的首要目標應該是推送可正常運作的軟體，並為使用者提供服務。這延伸至您撰寫的測試，確保應用程式品質。Kent C. Dodds 在「靜態、單元、整合與 E2E 前端應用程式的 E2E 測試」一文中得到非常不錯的總結：
越接近軟體使用方式的測試，測試的可信度就越高。
Kent C. Dodds
Kent 表示這是在測驗中獲取信心。選擇合適的測試類型越接近使用者，越能放心，測試得到有效的結果。換言之，您爬上金字塔越多，您的自信就越有。但等一下，金字塔是什麼？
決定測試策略：如何選擇測試策略
首先，請判斷您需要檢查哪些項目，確保符合相關規定。瞭解該使用哪種測試類型，以及哪些資料細節，在維持成本效益的同時，能夠達到最有信心。許多開發人員都會使用類比來說明這個主題。以下列出最常見的幾種，首先播放著名的經典內容。
經典：測試金字塔
開始找出測試策略時，您可能會看到測試自動化金字塔的第一個比喻。Mike Cohn 的《Succeeding with Agile》一書指出，之後，Martin Fowler 進一步展開「Practical Test Pyramid」文章中的這個概念。您可以用下列方式呈現金字塔：
如以下繪圖所示，測試金字塔包含三個圖層：
單位：這些測試是金字塔的基礎層，因為執行速度快，維護起來很簡單。這些單元分離，並且鎖定最次要的測試單元。例如，請參考極小型產品的一般單元測試。
整合。這些測試位於金字塔中，因為其執行速度可接受的速度，但運作速度越快，使用者就越接近單元測試所能達到的水準。API 測試就是整合測試的一個例子。您也可以將元件測試分類為這種類型。
E2E 測試 (也稱為 UI 測試)。這些測試模擬使用者真實的行為和互動情形。這類測試需要更多時間執行，因此費用也較高。它們位於金字塔的頂端。
提升信心與資源
如先前所述，圖層的順序並非巧合。並顯示優先順序和對應的成本。這樣您就能清楚掌握應該為每個層編寫的測試數量。您已經在測試類型的定義中看到這個概念。
由於 E2E 測試最接近使用者的位置，因此最能確保應用程式正常運作。不過，這類 API 需要完整的應用程式堆疊和模擬使用者，因此價格也可能是最昂貴的方案。因此相信，這些信心代表了執行測試所需的資源，彼此直接競爭。
為瞭解決這個問題，金字塔會更專注於單元測試，並嚴格優先處理 E2E 測試涵蓋的案例。例如，最重要的使用者歷程，或最容易出現瑕疵的位置。如 Martin Fowler 會強調，Cohn 金字塔的主要兩個重點如下：
- 以不同精細程度編寫測試。
- 獲得的測試越多，測試的量就越少。
金字塔演化了！測試金字塔的調整方法
多年來，相關討論都以金字塔為主。金字塔似乎過於簡化測試策略，留下許多測試類型，並不再適用於所有實際專案。因此可能會造成誤導。金字塔是否超出形狀？ Guillermo Rauch 是他們的意見：
編寫測試。太多了，大多是整合作業。
由 Guillermo Rauch 製作
這是針對這個主題最常引用的引述內容之一，讓我們詳細說明：
- 「編寫測試」。不僅能建立信任感，還可節省維護時間。
- 「數量不多」。涵蓋率只有 100% 並不理想，因為您的測試並非優先考量，因此會需要維護。
- 「大部分整合」。這裡再次強調整合測試：整合測試能提高每日信賴水準，同時維持合理的執行時間，進而創造最高的業務價值。
這會導致您再次思考測試金字塔，並將焦點移至整合測試。過去幾年間，有許多調整建議，因此來看看其中最常見的做法。
測試鑽石
第一次的調整會消除單元測試的過度強調效果，如測試金字塔中所示。想像一下，您已達到 100% 的單元測試涵蓋率。不過，您下次重構時，必須更新許多這類單元測試，您可能會想略過這些測試。這樣他們就會氣感激盪。
因此，以及更重視整合測試的決策，可能就會出現以下型態：
金字塔進化後成為鑽石。您可以看到前三個圖層，但圖層大小不同，且系統切割單元圖層：
- 單位：請依照之前定義單元測試的方式撰寫單元測試。然而，由於它們傾向腐蝕，因此請優先處理並僅涵蓋最關鍵的案例。
- 整合。您知道的整合測試，測試單一單元的組合。
- E2E：此層會處理與測試金字塔類似的 UI 測試。請僅針對最關鍵的測試案例編寫 E2E 測試。
測試蜂巢
Spotify 推出的另一項調整措施與測試版軟體類似，但更專門用於微服務型軟體系統。測試蜂巢是一種視覺類比，針對微服務型軟體系統編寫的測試精細程度、範圍和數量。由於微服務的規模不大，微服務本身最複雜的複雜性並非服務本身，而是與其他服務互動的方式。因此，微服務的測試策略應主要著重於整合測試。
這個形狀讓我們聯想到蜂巢，這就是它名字。它具備以下層：
- 整合式測試。Spotify 的文章採用了來自 J. B. Rainsberger 定義此層：「根據其他系統的正確性，將通過或失敗的測試。」這類測試具有必須考量的外部依附元件，但相對來說，系統可能是的依附元件會破壞其他系統。和其他類比測試中的 E2E 測試類似，這些測試請謹慎使用，並只針對最重要的情況。
- 整合測試：與其他調整方法類似，您應關注此圖層。其中包含的測試會以更獨立的方式驗證服務正確性，但仍與其他服務搭配使用。這代表測試也會包含其他系統，並將重點放在互動點，例如透過 API 測試。
- 測試實作詳細資料。這些測試與單元測試類似，也就是測試著重於自然隔離的程式碼部分，因此內部的複雜度本身。
如要進一步瞭解這項測試策略，請參閱 Martin Fowler 所撰寫的測試金字塔與蜂蜜 com 比較相關文章，以及 Spotify 的原始文章。
測試獎盃
您已看到我們重複聚焦於整合測試。不過，您在前一篇文章中遇到的另一種類型並不是在理論上測試，但仍然是測試策略時應考量的重要面向。測試金字塔缺少靜態分析，且您目前看過的大部分調整中都缺少了靜態分析。有鑑於測試獎盃調整策略，需要將靜態分析納入考量，同時將重點放在整合測試上。本測試獎盃源自於 Guillermo Rauch 之前的引言，由 Kent C 開發。圓點：
「測試獎盃」是一種比喻，以稍微不同的方式呈現測試的詳細程度。其中包含四個層：
- 靜態分析：這種比數在這種比喻中扮演重要的角色，它僅執行已概述的偵錯步驟，即可找出錯字、樣式錯誤和其他錯誤。
- 單元測試。它們可確保最小的單位經過適當測試，但測試獎盃不會與試驗金字塔相同。
- 整合。這將是重點，因為與其他調整一樣，會在費用與可信度之間取得平衡。
- UI 測試。我們將 E2E 和視覺測試列入了測試獎盃的頂端，類似測試金字塔中的角色。
若要進一步瞭解測試獎盃，請參閱 Kit C. 的網誌文章Dodds 這個主題。
更多以使用者介面為主的方法
雖然一切都沒問題，但無論您採用哪種策略「金字塔」、「蜂蜜市」或「鑽石」，還有一些機會還是少不了。雖然測試自動化功能很重要，但請記住，手動測試仍然是不可或缺的。自動化測試應能減少例行工作，並讓品質確保工程師專注於重要領域。與其取代手動測試，自動化應能相輔相成。有沒有方法能整合手動測試與自動化功能，以獲得最佳成效？
測試冰錐及測試螃蟹
實際上，測試金字塔有兩種調整，著重於這些以 UI 為主的測試方式。兩者都採用高信賴水準的優勢，但測試執行速度較慢，因此成本自然較高。
第一個是測試冰錐，看起來是倒金字塔。如果沒有手動測試步驟，則也稱為「測試披薩」。
冰錐則較重視手動或 UI 測試，而對單元測試的關注程度則最少。開發人員剛開始在專案時，通常只會對測試策略的看法進行思考，冰川屬於反模式，正好是這樣。它在資源和人工作業方面所費不貲。
試劑與試驗冰錐相似，但著重在 E2E 和視覺測試：
此測試策略還有一個層面：驗證應用程式是否正常運作，且看起來沒問題。測試標準特別指出視覺測試的重要性，詳情請參閱前一篇文章。整合測試分為元件和 API 測試，進一步進到背景，單元測試更是次要角色。如要進一步瞭解這項測試策略，請參閱這篇有關測試條件的文章。
這兩種測試策略的成本較高，但各有其特色：舉例來說，在規模較小的專案中需要測試較少，或者需要降低複雜程度時，便適合採用這兩種測試策略。在這種情況下，著重於整合測試的全面測試策略可能會過於複雜。
雖然這兩種測試策略的成本較高，但用途不同，例如採用小型專案所需的測試較少，且不需要處理太多複雜性。在這種情況下，著重於整合測試的大規模測試策略可能極為複雜。
實用建議：一起擬定策略！
現在您已瞭解最常見的測試策略。您一開始使用的是經典測試金字塔，但瞭解其中有許多改編過的層面。現在您需要評估這些產品，並決定何者最適合專案。這個問題的答案應先從大家最喜歡的「確切資訊」開始。但這無法提高精確度。
請根據您的應用程式選擇內容，選擇最合適的測試策略，甚至是沒提到的策略。其中應涵蓋您的架構和需求，最後但又非最關鍵的是使用者及其需求。上述資訊可能因應用程式而異。這很正常。提醒您，您的首要目標是為使用者提供服務，而非教科書的定義。
真實世界測試通常難以分別定義及定義。即使是 Martin Fowler 本身也注重不同定義的正面面向，例如單元測試的情況。如同 Justin Searls，在他的推文中正確狀態一樣：
[...] 編寫表達式測試，以確立明確的界線，快速可靠地執行測試，且只基於實用原因而失敗。
由 Justin Searls 提供
專心測試會回報使用者可能會遇到的實際錯誤，以免分散您的目標。測試的設計應是為了造福使用者，而不僅是提供 100% 的涵蓋率，也應針對要撰寫的測試類型百分比進行辯論。
專心測試會回報使用者可能會遇到的實際錯誤，以免分散您的目標。測試的設計目的應是為了造福使用者，而非只是提供 100% 的涵蓋率，或是對於您應該撰寫的特定測試類型所佔百分比的辯論。