譯者 | 陳峻
審校 | 孫淑娟
2009年，Mike Cohn在他的Succeeding with Agile 一書中用金字塔來比喻軟件的測試模型。逐漸，該說法流傳開來，如今它已成為了業界的行業標準。
總的說來，測試金字塔能夠直觀地表示出測試的標準化邏輯結構。它由如下三個不同的層次所組成：
金字塔的底部是單元測試。該單元實際上是一些小段的邏輯代碼。它們可以是函數、類、甚至是類中的方法。單元測試僅會檢查目標單元的行為，是否符合開發人員的預期。開發人員可以通過編寫單元測試，在無需依賴任何其他組件、服務或UI的情況下,直接調用被測試代碼，進而評估其輸出。
金字塔的中間層是集成測試，Mike在他的書中也稱為“服務測試”，其主要目的是測試系統的不同組件是如何協同工作的。例如，代碼中的模型是否可以正確地與數據庫交換數據，或者某個方法是否可以從API中檢索到信息。同樣，集成測試不需要UI的交互，便可以直接調用接口處的代碼。
金字塔的頂層是端到端(end-to-end，E2E)測試，也稱為UI測試，E2E是從最直觀的角度進行測試，即通過運行應用程序，來查看其效果。當然，E2E測試并不一定需要人工去執行，而可以完全依靠自動化。E2E測試能夠模擬出每個用戶與應該交互的動作，例如：單擊按鈕、輸入信息、以及捕獲UI的顯示內容等。
可見，這三種類型的測試會涉及到不同的范疇：
單元測試，只能在最基本的層面上發現邏輯錯誤。它們速度比較快，而且運行時所需的資源也比較少。
集成測試，主要驗證應用服務和數據庫，是否能與編寫的代碼和類進行良好的系統化協同。他們只能在兩個或多個組件交互的接口處發現問題。
E2E測試，關注能否啟動的完整應用程序。由于屬于最全面的測試類型，因此它在運行時往往會耗費最多的計算資源和時間。
1.測試金字塔的復雜性
在了解了測試金字塔的基本測試層次后，讓我們來討論一下每種測試的復雜性。單元測試由于比較簡單，因此易于編寫和維護。雖然它們僅僅測試的是非常狹窄的代碼部分，但是卻經常被使用到。我們往往可以在幾秒鐘內運行數千個單元測試。
集成測試在復雜性、以及數量級上與單元測試差不多，畢竟我們只對待測應用程序的“邊界”部分感興趣。不過，與單元測試相比，集成測試需要更多的資源才能運行。
E2E測試則具有編寫復雜、難以維護、需要大量資源、并且運行緩慢等特征。不過，由于我們可以通過各種E2E測試工具來覆蓋更多的應用程序，因此我們需要執行的測試工作量并不大。
由金字塔的形狀可知，每一層次的寬度會與該層的測試量成正比。也就是說，端到端的測試量相對較少、而集成測試的數量不及單元測試那么多、那么廣。
如前所述，三類測試的復雜程度和代碼庫的覆蓋率都是逐層增加的。下圖展示了各種測試在編寫、運行和維護方面的工作量比例。據此，您可以最大限度地利用更少的工作，找到更多的缺陷與錯誤。
2.如何給測試金字塔符能
在項目伊始時編寫E2E測試往往極富挑戰性。除非開發團隊能夠采用BDD等框架，并從一開始就著手編寫驗收測試(https://semaphoreci.com/blog/the-benefits-of-acceptance-testing)，否則大多數E2E測試都將只能在基本原型、或最小可行產品就緒時，才能被編寫。如下圖所示，開發人員在整個開發過程中，也會逐步增加單元測試與集成測試的編寫工作量。
讓我們再來看看測試的效率。眾所周知，緩慢的測試往往會拖慢生產環境所需的重要信息反饋。因此開發人員需要高效地運行三種測試套件，以穩定提升軟件質量。
位于金字塔底部的單元測試具有最高的運行效率，因此開發人員往往樂于編寫與使用。相反，鑒于復雜性，E2E測試的效率最低。一個大型的Web應用程序往往需要進行數千個單元測試、數百個集成測試、以及幾十個E2E測試。而它們的用時，可以體現在下圖中：
3.使用測試獎杯來測試前端
測試金字塔的歷史可以追溯到2009年。隨著技術的快速發展，人們在應對不同的開發需求時，也可能需要不同的測試模型。由Kent C. Dodds提出的測試獎杯(https://twitter.com/kentcdodds/status/960723172591992832)就是一種針對前端開發所構建的測試模型。
測試獎杯重排了優先級。它認為由于大多數現代UI都會依賴于各種后端組件，而且難以開展單獨的測試，因此集成測試才是王道。
與金字塔相比，單元測試處于次要地位，而且可以被ESLint和JSHInt等靜態測試工具所取代。它們通過掃描代碼，便可發現諸如：使用了不安全的語句、或未遵守變量命名規則等潛在問題。
獎杯的頂端是E2E測試，它與在測試金字塔中的占比相似。
4.測試矩陣
在測試金字塔中，我們往往容易忽略測試結果可信度的問題。也就是說，唯一可以真正驗證應用程序可行性的測試，只有E2E測試。通常，我們認為開發人員投入在測試上(如E2E測試)的精力越多，測試結果的可信度就越高。對此，Gleb Bahmutov和Roman Sandler提出了測試矩陣(https://portal.gitnation.org/contents/testing-pyramid-makes-little-sense-what-we-can-use-instead)作為規劃測試相關策略時的工具。
如上圖矩陣所示，開發人員精力的投入是從左到右增加的，而可信度是從下到上上升的。顯然，最佳位置是在綠色區域。而大多數軟件項目都是從低投入和低可信度的黃色區域開始的。
隨著項目的成熟和新功能的添加，測試需求也會隨之處于熵增的狀態。倘若測試團隊未能在測試方案上持續改進和維護，那么他們會很快滑到紅色區域。
對此，我們應該如何以盡量少的投入，增加測試的可信度呢?我們需要定期重新評估如下五類與測試相關的方面：
安裝：包括安裝和設置測試框架所涉及的工作。
編寫：涉及到為給定框架編寫測試的復雜程度、以及開發人員的技能水平。
運行：包括運行測試套件的難度、以及CI/CD的性能。
調試：涉及到發生測試失敗時，發現和修復問題難易程度。
維護：包含在項目的整個生命周期中，維護測試所耗費的精力。
在該模型中，我們往往需要在項目的開端，給予單元測試一定的投入。不過，一旦項目功能穩定下來，開發團隊就需要通過添加更多的E2E測試、以及減少其他測試類別，來平衡組合測試。據此，測試有效性在穩步增加的同時，團隊可以有條不紊地調整在不同類別上的投入。
5.謹防教條思維
由于速度、成本和維護問題，金字塔在一定程度上限制了我們盡早地開展E2E測試。當然，也有人認為：鑒于端到端測試更接近于用戶的真實場景操作，團隊可以通過應用提供的公共界面予以開展。因此，如果您更改了后臺的實現，甚至更換了整個后端的話，那么E2E測試不應被推倒重來，而只需沿用原有的測試案例，進行測試微調便可。據此，其維護的工作量實際上也并非多得驚人。
當然，每個團隊、每個項目、以及每個組織都是不同的。而且隨著需求的變化，團隊可能會需要通過重新決定或規范化測試套件，以靈活的方式停止現有的、或評估新的測試模型，按需進行調整，以達到多快好省的測試效果。
6.小結
歷史悠久的測試金字塔模型，為整個測試領域樹立了一個典型的通用模型，方便大家參考與交流。當然，隨著新技術、新實踐、以及新理念的出現，各種不同的改進模型也相繼出現。它們各有專攻，服務于特定的開發領域。其中不乏服務于CI/CD管道的自動化測試套件。總之，您需要根據自己的實際項目，來選擇最適合的測試套件。
原文標題：https://dzone.com/articles/the-testing-pyramid-how-to-structure-your-test-sui
譯者介紹
陳峻 (Julian Chen)，51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗;持續以博文、專題和譯文等形式，分享前沿技術與新知;經常以線上、線下等方式，開展信息安全類培訓與授課。
