用不同的測試模型來(lái)構建測試套件

2009年，Mike Cohn在他的Succeeding with Agile 一書(shū)中用金字塔來(lái)比喻軟件的測試模型。逐漸，該說(shuō)法流傳開(kāi)來(lái)，如今它已成為了業(yè)界的行業(yè)標準。

總的說(shuō)來(lái)，測試金字塔能夠直觀(guān)地表示出測試的標準化邏輯結構。它由如下三個(gè)不同的層次所組成：

金字塔的底部是單元測試。該單元實(shí)際上是一些小段的邏輯代碼。它們可以是函數、類(lèi)、甚至是類(lèi)中的方法。單元測試僅會(huì )檢查目標單元的行為，是否符合開(kāi)發(fā)人員的預期。開(kāi)發(fā)人員可以通過(guò)編寫(xiě)單元測試，在無(wú)需依賴(lài)任何其他組件、服務(wù)或UI的情況下,直接調用被測試代碼，進(jìn)而評估其輸出。

金字塔的中間層是集成測試，Mike在他的書(shū)中也稱(chēng)為“服務(wù)測試”，其主要目的是測試系統的不同組件是如何協(xié)同工作的。例如，代碼中的模型是否可以正確地與數據庫交換數據，或者某個(gè)方法是否可以從API中檢索到信息。同樣，集成測試不需要UI的交互，便可以直接調用接口處的代碼。

金字塔的頂層是端到端(end-to-end，E2E)測試，也稱(chēng)為UI測試，E2E是從最直觀(guān)的角度進(jìn)行測試，即通過(guò)運行應用程序，來(lái)查看其效果。當然，E2E測試并不一定需要人工去執行，而可以完全依靠自動(dòng)化。E2E測試能夠模擬出每個(gè)用戶(hù)與應該交互的動(dòng)作，例如：?jiǎn)螕舭粹o、輸入信息、以及捕獲UI的顯示內容等。

可見(jiàn)，這三種類(lèi)型的測試會(huì )涉及到不同的范疇：

單元測試，只能在最基本的層面上發(fā)現邏輯錯誤。它們速度比較快，而且運行時(shí)所需的資源也比較少。

集成測試，主要驗證應用服務(wù)和數據庫，是否能與編寫(xiě)的代碼和類(lèi)進(jìn)行良好的系統化協(xié)同。他們只能在兩個(gè)或多個(gè)組件交互的接口處發(fā)現問(wèn)題。

E2E測試，關(guān)注能否啟動(dòng)的完整應用程序。由于屬于最全面的測試類(lèi)型，因此它在運行時(shí)往往會(huì )耗費最多的計算資源和時(shí)間。

1.測試金字塔的復雜性

在了解了測試金字塔的基本測試層次后，讓我們來(lái)討論一下每種測試的復雜性。單元測試由于比較簡(jiǎn)單，因此易于編寫(xiě)和維護。雖然它們僅僅測試的是非常狹窄的代碼部分，但是卻經(jīng)常被使用到。我們往往可以在幾秒鐘內運行數千個(gè)單元測試。

集成測試在復雜性、以及數量級上與單元測試差不多，畢竟我們只對待測應用程序的“邊界”部分感興趣。不過(guò)，與單元測試相比，集成測試需要更多的資源才能運行。

E2E測試則具有編寫(xiě)復雜、難以維護、需要大量資源、并且運行緩慢等特征。不過(guò)，由于我們可以通過(guò)各種E2E測試工具來(lái)覆蓋更多的應用程序，因此我們需要執行的測試工作量并不大。

由金字塔的形狀可知，每一層次的寬度會(huì )與該層的測試量成正比。也就是說(shuō)，端到端的測試量相對較少、而集成測試的數量不及單元測試那么多、那么廣。

如前所述，三類(lèi)測試的復雜程度和代碼庫的覆蓋率都是逐層增加的。下圖展示了各種測試在編寫(xiě)、運行和維護方面的工作量比例。據此，您可以最大限度地利用更少的工作，找到更多的缺陷與錯誤。

2.如何給測試金字塔符能

在項目伊始時(shí)編寫(xiě)E2E測試往往極富挑戰性。除非開(kāi)發(fā)團隊能夠采用BDD等框架，并從一開(kāi)始就著(zhù)手編寫(xiě)驗收測試(https://semaphoreci.com/blog/the-benefits-of-acceptance-testing)，否則大多數E2E測試都將只能在基本原型、或最小可行產(chǎn)品就緒時(shí)，才能被編寫(xiě)。如下圖所示，開(kāi)發(fā)人員在整個(gè)開(kāi)發(fā)過(guò)程中，也會(huì )逐步增加單元測試與集成測試的編寫(xiě)工作量。

讓我們再來(lái)看看測試的效率。眾所周知，緩慢的測試往往會(huì )拖慢生產(chǎn)環(huán)境所需的重要信息反饋。因此開(kāi)發(fā)人員需要高效地運行三種測試套件，以穩定提升軟件質(zhì)量。

位于金字塔底部的單元測試具有最高的運行效率，因此開(kāi)發(fā)人員往往樂(lè )于編寫(xiě)與使用。相反，鑒于復雜性，E2E測試的效率最低。一個(gè)大型的Web應用程序往往需要進(jìn)行數千個(gè)單元測試、數百個(gè)集成測試、以及幾十個(gè)E2E測試。而它們的用時(shí)，可以體現在下圖中：

3.使用測試獎杯來(lái)測試前端

測試金字塔的歷史可以追溯到2009年。隨著(zhù)技術(shù)的快速發(fā)展，人們在應對不同的開(kāi)發(fā)需求時(shí)，也可能需要不同的測試模型。由Kent C. Dodds提出的測試獎杯(https://twitter.com/kentcdodds/status/960723172591992832)就是一種針對前端開(kāi)發(fā)所構建的測試模型。

測試獎杯重排了優(yōu)先級。它認為由于大多數現代UI都會(huì )依賴(lài)于各種后端組件，而且難以開(kāi)展單獨的測試，因此集成測試才是王道。

與金字塔相比，單元測試處于次要地位，而且可以被ESLint和JSHInt等靜態(tài)測試工具所取代。它們通過(guò)掃描代碼，便可發(fā)現諸如：使用了不安全的語(yǔ)句、或未遵守變量命名規則等潛在問(wèn)題。

獎杯的頂端是E2E測試，它與在測試金字塔中的占比相似。

4.測試矩陣

在測試金字塔中，我們往往容易忽略測試結果可信度的問(wèn)題。也就是說(shuō)，唯一可以真正驗證應用程序可行性的測試，只有E2E測試。通常，我們認為開(kāi)發(fā)人員投入在測試上(如E2E測試)的精力越多，測試結果的可信度就越高。對此，Gleb Bahmutov和Roman Sandler提出了測試矩陣(https://portal.gitnation.org/contents/testing-pyramid-makes-little-sense-what-we-can-use-instead)作為規劃測試相關(guān)策略時(shí)的工具。

如上圖矩陣所示，開(kāi)發(fā)人員精力的投入是從左到右增加的，而可信度是從下到上上升的。顯然，最佳位置是在綠色區域。而大多數軟件項目都是從低投入和低可信度的黃色區域開(kāi)始的。

隨著(zhù)項目的成熟和新功能的添加，測試需求也會(huì )隨之處于熵增的狀態(tài)。倘若測試團隊未能在測試方案上持續改進(jìn)和維護，那么他們會(huì )很快滑到紅色區域。

對此，我們應該如何以盡量少的投入，增加測試的可信度呢?我們需要定期重新評估如下五類(lèi)與測試相關(guān)的方面：

安裝：包括安裝和設置測試框架所涉及的工作。

編寫(xiě)：涉及到為給定框架編寫(xiě)測試的復雜程度、以及開(kāi)發(fā)人員的技能水平。

運行：包括運行測試套件的難度、以及CI/CD的性能。

調試：涉及到發(fā)生測試失敗時(shí)，發(fā)現和修復問(wèn)題難易程度。

維護：包含在項目的整個(gè)生命周期中，維護測試所耗費的精力。

在該模型中，我們往往需要在項目的開(kāi)端，給予單元測試一定的投入。不過(guò)，一旦項目功能穩定下來(lái)，開(kāi)發(fā)團隊就需要通過(guò)添加更多的E2E測試、以及減少其他測試類(lèi)別，來(lái)平衡組合測試。據此，測試有效性在穩步增加的同時(shí)，團隊可以有條不紊地調整在不同類(lèi)別上的投入。

5.謹防教條思維

由于速度、成本和維護問(wèn)題，金字塔在一定程度上限制了我們盡早地開(kāi)展E2E測試。當然，也有人認為：鑒于端到端測試更接近于用戶(hù)的真實(shí)場(chǎng)景操作，團隊可以通過(guò)應用提供的公共界面予以開(kāi)展。因此，如果您更改了后臺的實(shí)現，甚至更換了整個(gè)后端的話(huà)，那么E2E測試不應被推倒重來(lái)，而只需沿用原有的測試案例，進(jìn)行測試微調便可。據此，其維護的工作量實(shí)際上也并非多得驚人。

當然，每個(gè)團隊、每個(gè)項目、以及每個(gè)組織都是不同的。而且隨著(zhù)需求的變化，團隊可能會(huì )需要通過(guò)重新決定或規范化測試套件，以靈活的方式停止現有的、或評估新的測試模型，按需進(jìn)行調整，以達到多快好省的測試效果。

6.小結

歷史悠久的測試金字塔模型，為整個(gè)測試領(lǐng)域樹(shù)立了一個(gè)典型的通用模型，方便大家參考與交流。當然，隨著(zhù)新技術(shù)、新實(shí)踐、以及新理念的出現，各種不同的改進(jìn)模型也相繼出現。它們各有專(zhuān)攻，服務(wù)于特定的開(kāi)發(fā)領(lǐng)域。其中不乏服務(wù)于CI/CD管道的自動(dòng)化測試套件?？傊?，您需要根據自己的實(shí)際項目，來(lái)選擇最適合的測試套件。

原文轉自：http://www.uml.org.cn/Test/202205314.asp