我的女朋友是一名測試工程師，但她之前卻不知道測試金字塔的概念，為此我曾經在家里的白板上畫了一個圖一層一層給她講解過。我和同事在給團隊面試測試和開發崗位時，也會必問到這個問題，想到可能有很多開發童鞋都不知道，這里我就用一篇推文給大家科普一下。
一、傳說中的金字塔
我們都知道，針對項目的測試有很多分類，比如單元測試、集成測試、組件測試、端到端測試 以及 探索性測試等。那么，測試金字塔其實就是給我們的一個指導，它指導我們要在不同類型的測試工作投入多少的精力是最合適的。
廢話不多說，先上圖：
測試金字塔示意圖（來自波波老師的課程）
從上圖中我們可以看到，測試金字塔建議我們：
（1）盡可能地多做單元測試 和 集成測試，因為他們的執行速度相較於上層的幾個測試類型來說快很多且相對穩定，可以一天多次執行。一般來說，我們都會將單元測試 和 集成測試 做到持續集成構建任務中去，比如放到Jenkins中每天定時執行1~2次，或者每次push代碼到git倉庫后執行，總之，就是要確保可以頻繁執行以確保代碼質量。
（2）盡可能地少做 組件測試、端到端測試 和 探索性測試，因為他們的執行速度相較單元測試 和 集成測試 會慢很多，且不夠穩定，無法做到一天多次執行，每次執行都要等很久才能獲得反饋結果。但是，他們的覆蓋面比下層的單元測試 和 集成測試 要廣一些。總之，就是要確保一定周期內 或者 關鍵節點時間 執行以下這幾個測試以確保軟件質量。
畫外音：金字塔里，越往下速度越快且越穩定，那么就可以頻繁執行，反正執行一次也花不了多久時間，開發人員還可以知道我的代碼有沒有影響到其他模塊。越往上則速度越慢且越不穩定，跑一次要N久，開發人員往往會覺得還是先繼續開發吧，到時候出了bug再說，我可不想加班等測試結果。
二、端到端的測試實踐
在具體實踐中，位於上層的端到端測試是粒度相對較粗 但是 我們又不得不做的測試實踐。在微服務架構風格中，端到端測試涉及到的相關服務依賴很多，且異步等可變的因素較多，因此它也是一種最不穩定的測試。
端到端測試示意圖（來自波波老師）
端到端測試：驗證工作流中的所有流程，以檢查一切是否按預期工作。它還確保系統以統一的方式工作，從而滿足業務需求。
這里也跟大家分享一下在微服務架構場景中，對於端到端測試的一些實踐要點，僅供參考：
（1）80/20原則，花更多的精力聚焦核心業務服務；對於我司來說，可能就是統一登錄服務、訂單下單服務、統一支付、設計反饋服務等；
（2）用戶使用場景驅動，即盡可能使用最終用戶的用例流程來驅動測試，這樣可能更加容易覆蓋到產生業務價值的場景；
（3）適當Mock不穩定測試點，如果有些微服務依賴的第三方服務不夠穩定的話，那么可以適度犧牲一些覆蓋面，使用Mock來測試。
（4）規范測試環境和環境自動化，即團隊可以具備幾種測試環境一鍵創建的能力，比如使用Docker + Kubernetes就可以幫助實現這個點。這一點，我相信大部分的小團隊都不具備這個能力，我司其實也一樣，所以我建議小團隊盡可能上雲，直接使用雲上的能力幫助我們克服自身團隊的技術儲備弱的問題，提升端到端測試的效率。
（5）測試數據管理，即團隊可以具備一鍵生成測試數據的能力，而不是每次環境啟動起來才去修改數據以便於測試，一般都會通過維護測試數據的自動化腳本來實現。
畫外音：對你們團隊的測試同事好點，他們做端到端測試的時候會問候你的。
三、小結
本文介紹了測試金字塔的概念 及 耗時的端到端測試的實踐要點，最后溫馨提示一下，快下班時盡量別改自己不了解影響范圍的Bug，否則你會像下面這樣：
參考資料
楊波，《Spring Boot與K8s雲原生應用開發》（極客時間課程，推薦學習）
楊波，《微服務架構160講》（極客時間課程，推薦學習）
