Why 為什么要學習測試金字塔

之前做測試培訓的時候經(jīng)常會被問到幾個問題——我們項目沒有自動化測試，老板想讓我做，我搞了幾個星期 selenium 怎么不行呢？我應該先做 API 測試還是 UI 測試，他們之前關(guān)系如何？很多初學者甚至認為自動化測試=UI 自動化=selenium。在學習具體自動化測試技術(shù)之前，我們應該先了解一個概念——自動化測試金字塔。

自動化測試金字塔，或者簡稱為測試金字塔，他不是一個標準或者規(guī)范，但是這個概念為我們提供了從 0 開始構(gòu)建自動化測試體系的一個最佳實踐的參考。尤其是對初學者來說，這個金字塔模型可以說是開展自動化測試之前的一個最高指導綱領(lǐng)，因此我們有必要了解測試金字塔的相關(guān)概念和落地方法。

當然，并不是任何項目在任何階段都適合開展自動化測試，什么時候應該開展自動化測試不再本文展開討論，我們先假設一個項目需要做自動化測試，那么這個時候應該如何開始。

What 到底什么是測試金字塔

測試金字塔是 2009 年 Mike Cohn 在他的著作《Succeeding with Agile》一書正式提出的。他是一個類比的概念，形容每一層，或者說不同集成階段測試覆蓋率和執(zhí)行效率之間的一個相對關(guān)系。話不多說，我們直接上圖。

接下來我們來看圖說話，這個圖看似很簡單，有些內(nèi)容可以很容有些內(nèi)容我們可以深挖一下。首先需要明白的是，這個三層分類是根據(jù)項目集成復雜度抽象出來的三個層級，實際有幾層看項目復雜情況，主要是中間層的集成測試展開可能有幾層。之前我做過一個電信核心網(wǎng)項目，代碼至少百萬級別那種，中間哪一層集成測試就會有多層。

▎覆蓋率

覆蓋率是金字塔的核心，底層是最寬的，象征著 UT 覆蓋率應該是最高的，越往上越低，這一點大家都能達成共識。但是有一點需要注意的是，每網(wǎng)上一層應該是對下面一層覆蓋率的一個補充。簡單說集成測試應該聚焦于 UT 不好覆蓋的場景或者 UT 采用 mock 方式測試的場景，而頂層的 UI 自動化應該聚焦于整個流程的集成測試，覆蓋集成測試和 UT 難以覆蓋到的場景。

▎執(zhí)行速度

越接近代碼層的測試，也就是單元測試，執(zhí)行速度越快，離代碼越遠的測試，也就是 UI 測試，或者說端到端的測試，執(zhí)行速度越慢。執(zhí)行速度越快，意味著我們發(fā)現(xiàn)問題的時間越快，從而進一步減少了測試失敗->定位問題->解決問題->再次觸發(fā)自動化測試這個閉環(huán)的時間。
用例開發(fā)和維護成本
我們構(gòu)建自動化測試通常是一個中間產(chǎn)品，是為了提高回歸測試效率而產(chǎn)生的一個工具，并不是最終向客戶交付的產(chǎn)品，因此我們更要考慮投入投入成本，也就是用例開發(fā)和維護的成本，成本對應圖上標記的 dollar。從圖上可以看出，UI 自動化顯然是最不劃算的，因為界面變化相對比較頻繁，UI 自動化自然很容易受影響，UI 自動化用例的創(chuàng)建和維護也相對比較麻煩。

▎顆粒度

越往底層，顆粒度越細，問題越好隔離，發(fā)現(xiàn)問題越快，解決問題越快，越往上顆粒度越粗，問題越不好隔離，解決問題越慢。

How 如何落地

測試金字塔看起來很簡單明了，真正落地沒有想象那么容易，我們從一下幾點展開討論。

▎對研發(fā)和測試團隊的整體要求

因為測試處于開發(fā)流水線的下游，項目團隊從一開始其實要有構(gòu)建自動化測試的概念，不僅僅是軟件架構(gòu)師，研發(fā)和測試也要有相應的意識，除此之外還需要有 CICD（持續(xù)化集成部署）的概念，不然項目一旦開始，很多自動化測試根本無法開展和落地。比如一個項目沒有任何自動化測試，全靠測試手動檢查，過了一段時間，老板突然心血來潮找到測試小張說，你看 XX 公司都在搞自動化測試了，我們也搞起來吧。天天黑盒測試的 tester 們首先想到了 UI 測試，研究了幾個星期之后發(fā)現(xiàn)不僅 UI 變來變?nèi)?，好多元素沒有唯一 ID 或者 name，于是花了大量經(jīng)歷去搞元素定位，最后 case 也沒寫幾個。老板過來一看，搞啥呢？看來你們技術(shù)不行啊，別搞了，還是繼續(xù)手動測試吧。
參考我們的測試金字塔概念，其實從一開始就錯了，自動化一定是從 UT 開始的，如果開發(fā)不配合，只靠測試通過后面的 API 自動化或者 UI 自動化發(fā)現(xiàn)問題，只能是事倍功半的效果。

▎資源不夠時候怎么辦？

有時候測試資源非常有限，沒法用自動化覆蓋每一層級的自動化測試，這個時候建議從 API 自動化或者集成測試的自動化開始，構(gòu)建除了 UT 測試的第一層防火墻，有了一定效果之后再考慮從下往上開始增加更多的自動化測試用例。

▎對 CICD 流水線依賴

在現(xiàn)代化的持續(xù)集成中，CICD 對于自動化測試就像基礎設施一樣。如果沒有構(gòu)建高效的 CICD 流水線，自動化測試的效果就會大打折扣，自動化測試其實只是整個 CICD 流水線的一個環(huán)節(jié)，只有構(gòu)建了高效的 CICD，我們才能快速的觸發(fā)自動化測試，發(fā)現(xiàn)問題，修復問題，然后再次觸發(fā)讓測試通過。

▎金字塔模型是萬能鑰匙么？

金字塔模型是自動化最佳實踐的一個參考，并不是銀彈，更不是萬能鑰匙。比如針對最近幾年流行起來的微服務的概念，有人提出了針對傳統(tǒng)測試金字塔的改進——蜂窩測試模型。

因為在微服務系統(tǒng)里面，每個微服務本身的功能相對單一，但是集成起來之后可能是一個蜘蛛網(wǎng)的模型，如果只是根據(jù)傳統(tǒng)金字塔模型去做大量的 UT 覆蓋，效果并不好，因為 UT 大量的 mock 外部接口測試無法快速發(fā)現(xiàn)上下游由于接口改動造成的一些問題，因此采用更多的集成測試可以更好地覆蓋微服務的模型，更多細節(jié)可以參考文末的參考文獻。

簡言之，金字塔模型只是一個框架級別的參考，具體怎么實施一定要考慮項目的具體情況，不能生搬硬套。

現(xiàn)在我邀請你進入我們的軟件測試學習交流群：【746506216】，備注“入群”， 大家可以一起探討交流軟件測試，共同學習軟件測試技術(shù)、面試等軟件測試方方面面，還會有免費直播課，收獲更多測試技巧，我們一起進階Python自動化測試/測試開發(fā)，走向高薪之路。

喜歡軟件測試的小伙伴們，如果我的博客對你有幫助、如果你喜歡我的博客內(nèi)容，請 “點贊” “評論” “收藏” 一 鍵三連哦！文章來源地址http://www.zghlxwxcb.cn/news/detail-458910.html

到了這里，關(guān)于敏捷實踐 | 淺談測試金字塔的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！