測驗金字塔 （Test Pyramid）是一套使用單元測驗，集成測驗和端到端測驗來構建自動化測驗體系的方法，
如下圖所示，在金字塔的最下方是單元測驗，中段是集成測驗，最上方是端到端測驗，單元測驗實作的成本最低，運行速度最快，是毫秒級的，集成測驗的實作成本比單元測驗高，因為要跟外部系統連接，所以運行速度比單元測驗要慢1-2各個數量級，端到端測驗最符合用戶的完整體驗，從 UI 開始通過 API 直達系統內部代碼，因為涉及的環節更多，所以實作成本更高，運行速度比集成測驗更慢，
測驗金字塔理論推薦單元測驗應該是數量最多，覆寫范圍最大的測驗種類，道理很簡單，單元測驗成本低，運行速度快，在發現問題的時候解決問題也最快，集成測驗數量次之，最后才是昂貴的端到端測驗，由于端到端測驗經過的環節更多，所以通過端到端測驗發現的問題，解決起來用時更多，
單元測驗
單元測驗是一種由開發者實作的白盒測驗，在測驗金字塔里，單元測驗是自動化測驗體系的基礎，一般使用代碼覆寫率來評價單元測驗是否達到了測驗的要求，但是在實踐中開發團隊往往發現很難達到指定的代碼覆寫率，開發工程師寫的單元測驗和測驗工程師撰寫的測驗用例也很難匹配，跟產品經理的業務描述差得更遠，
這里的一個重要原因是許多開發者把程式簡單地理解為增刪改查（CRUD），而沒有圍繞業務邏輯來撰寫代碼，對外部服務沒有構建“以我為中心”的模型，撰寫代碼的時候直接使用要依賴服務定義的模型，這樣在撰寫單元測驗時就會因為模擬某些服務難度太高不得不放棄，只能使用集成測驗來驗證代碼的正確性，
我們可以借鑒《領域驅動設計》里的分層架構，以及六邊形架構來構建抽象的領域模型，并且使用單元測驗來驗證模型實作了產品經理的業務描述，這樣我們就可以使用面向物件知識圍繞業務構建領域層，把外界服務看做各種連接到模型的“埠”，在撰寫單元測驗時，就不會遇到無法模擬其他服務的問題，
總結一下，我們的單元測驗應該構建在“領域層”之上，以驗證領域模型對業務描述的正確性為主要目標，
單元測驗是否可以連接資料庫？
單元測驗是系統內部的測驗，單元測驗不能跨越系統，資料庫是另外一個系統，跨系統的測驗屬于集成測驗的范疇，所以單元測驗中是不可以連接資料庫的，單元測驗要遵循 FIRST 原則，其中的 “F” 就表示要快，單元測驗的范圍在系統內部不訪問外部系統才可能快，訪問資料庫會把毫秒級的測驗時間，提升到幾十甚至數百毫秒以上，這顯然是集成測驗的運行時間水平，
集成測驗
集成測驗是驗證系統和系統之間的相互呼叫是否符合預期的測驗，因為要跨越系統，所以和單元測驗相比集成測驗運行起來要慢1到2個數量級，
當發現問題時，問題可能會出在集成測驗連接的任意一個系統中，開發者需要排查每一個系統直到找到問題為止，而在單元測驗中發現問題時只需要排查本系統，所以集成測驗相比單元測驗排查問題用時也更多，
開發者在設計集成測驗時可以限定要集成的系統范圍，這樣就可以把測驗重點放在開發者關心的系統上，集成測驗往往以 API 呼叫的方式進行，開發者撰寫測驗腳本按順序呼叫 API，檢查結果是否符合預期，
集成測驗是系統之間的測驗，資料庫也是一種系統
端到端測驗
端到端測驗以 UI 為起點，模擬用戶使用系統的場景，從 UI 輸入驗證系統的輸出是否符合預期，因為涉及到 UI，端到端測驗必然會跨系統，又因為開發者只能控制 UI 部分的輸入順序和數量，所以開發者不能控制端到端測驗中被呼叫的 API 的順序和數量，在發現問題時不光要檢查各個可能要涉及的系統，還要考慮 API 可能被呼叫的順序和數量，排查問題的難度比集成測驗更高，
在運行時間上，UI 測驗模擬用戶的輸入而不是像集成測驗那樣直接呼叫系統 API，所以運行時間類似于人類反應的時間，與集成測驗相比端到端測驗整體運行時間又有數量級級別的下降，
端到端測驗也包含了部分探索性測驗和人工測驗，
端到端測驗的輸入從UI開始
端到端測驗在性能測驗上更能反映系統在真實世界的運行情況
如果以集成測驗的方式來做性能測驗，開發者可以按照指定的順序呼叫API，模擬在規定時間內呼叫 API 的數量下系統的回應能力，但是在真實世界，用戶是通過 UI 來驅動系統的，UI 頁面往往包含各類資訊，這類資訊會并發地以不同順序呼叫系統的 API，這樣在用戶流量大的情形下，不同 API 被糾纏在一起以不同的順序和數量傳遞到不同的系統里，
在上圖中，用戶打開“新浪財經”頁面會呼叫頁面UI，要聞，突發，股市指數，天氣預報等10幾個系統，這比單純的集成測驗要呼叫的系統數量上要多，呼叫順序由UI頁面結構決定，每次頁面調整都會導致 API 呼叫順序的改變，顯然端到端測驗要比集成測驗復雜，
和集成測驗相比，基于端到端測驗實作的性能測驗，結果可能會和開發者的預期差距更大，但是可能會發現更多問題，
如何使用測驗金字塔來構建自動化測驗體系
基于對測驗金字塔中 3 種不同種類測驗的特點的分析，考慮到運行速度和實作成本，我們推薦開發者以單元測驗為自動化測驗的基礎，以盡可能低的成本發現盡可能多的問題，通過集成測驗檢查系統間的相互呼叫問題，輔以端到端測驗優化用戶體驗來構建自動化測驗體系，
結論
本文通過比較單元測驗、集成測驗和端到端測驗在實作成本，負責范圍和糾錯時間的區別和聯系，介紹了測驗金字塔的概念，以及以按照單元測驗、集成測驗和端到端測驗的順序構建自動化測驗體系的必要性，
最后：這里有我建立的一個專門交流軟體測驗方面問題的學習群，里面也有很多大公司的技術大牛，很多時候，技術大牛的幾句話就會讓我們醍醐灌頂，少浪費時間，如果想要多跟有經驗的人學習，就找我加入我的軟體測驗交流群，以后有作業的內推機會都相互推薦一下，畢竟我們是關系社會，
軟體測驗技術交流群社：786229024 等待你的加入... 大家可以一起探討交流，共同學習軟體測驗技術、面試等軟體測驗方方面面，還會有免費直播課，識訓更多測驗技巧，我們一起進階Python自動化測驗/測驗開發，走向高薪之路，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/554585.html
標籤：其他
上一篇：【acwing】Trie字串統計
下一篇：返回列表