測試金字塔的概念是由敏捷大師Mike Cohn在他的《Succeeding with Agile》一書中首次提出，如上圖所示。他的基本觀點是：我們應該有更多的低級別的單元測試，而不僅僅是通過有界面運行的高層的端到端的測試。
Martin Fowler大師在測試金字塔模型的基礎上提出分層自動化測試的概念。在自動化測試之前加了一個“分層”的修飾，以區別於“傳統的”自動化測試。那麼什麼是傳統的自動化測試？為何要提倡分層自動化對測試的思想呢？
所謂傳統的自動化測試我們可以理解為基於產品UI層的自動化測試，它是將黑盒功能測試轉化為由程序或工具執行的一種自動化測試。
在目前大多數研發組織當中，都存在開發與測試團隊割裂（部門牆）、質量職責錯配（測試主要對質量負責）的問題，在這種狀態下，測試團隊的一個“正常”反應就是試圖在測試團隊能夠掌控的黑盒測試環節進行儘可能全面的覆蓋，甚至是儘可能全面地UI自動化測試。
這樣的行為可能會導致兩個惡果：一是測試團隊規模的急劇膨脹；二是所謂的全面UI自動化測試運動。因為UI是非常易變的，所以UI自動化測試維護成本相對高昂。
分層自動化測試倡導的是從黑盒（UI）單層到黑白盒多層的自動化測試體系，從全面的黑盒自動化測試到對系統的不同層次進行自動化測試，如下圖所示：
單元自動化測試
單元自動化測試是指對軟件測試中的最小可測試段園進行檢查和驗證。隊員單元測試中單元的含義，一般來說，要根據實際情況去判定其具體含義，如C語言中單元是指一個函數，Java中單元是指一個雷，圖形化的軟件中單元是指一個窗口或一個菜單等。總的來說，單元就是人為規定的最小的被測功能模塊。規範的進行單元測試需要藉助單元測試框架，如Java語言的Junit、TestNG，C#語言的NUnit，以及Python語言的Unittest、pytest等，目前幾乎所有的主流語言都有其相應的單元測試框架。
Code Review中文翻譯為代碼評審或代碼審查，是指在軟件開發過程中，通過對源代碼進行系統性檢查的過程。通常的目的是查找系統缺陷、保證軟件總體質量以及提高開發者自身水平。與Code Review相關的插件和工具有很多，例如Java語言中基於Eclipse的ReviewClipse和Jupiter、主要針對Python語言的Review Board等。
接口自動化測試
根據我的理解，Web應用的接口自動化測試大體分為兩類：模塊接口測試和Web接口測試。
模塊接口測試：主要測試模塊二之間的點用於返回。當然，我們也可以將其看作是單元測試的基礎。他強調對一個類方法或函數的調用，並對返回結果的驗證，所用到的測試工具與單元自動化測試相同。
Web接口測試又可分為兩類：服務器接口測試和外部接口測試。
服務器接口測試：指測試瀏覽器與服務器的接口。我們知道Web開發一般分前端和後端，前端開發人員用HTML/CSS/JS等技術，後端開發人員用PHP/Java/C#/Ruby等各種語言。用戶的操作是在前端頁面上，需要後端提供服務器接口，前端通過調用這些藉口來獲得需要的數據，通過HTTP協議實現前後端的數據傳遞。
外部接口測試：指調用的接口由第三方系統提供。典型的例子就是第三方登錄，例如新上線的產品為了免於新用戶註冊賬號的麻煩會提供第三方登錄，那麼用戶在登陸的時候調用的就是第三方登錄的接口，用戶登陸信息的驗證由第三方完成，並返回給當前系統是否驗證通過。
當然，接口測試也有相信的類庫或工具，例如測試HTTP的有HttpUnit、Postman等。
UI自動化測試
UI層是用戶使用該產品的入口，所有功能都通過這一層提供冰戰士給用戶，所以測試工作大多集中在這一層進行。為了減輕這一層測試人力和時間成本，早期的自動化測試主要針對該層設計。目前主流的測試工具有UFT、Watir、Robot Framework、Selenium等。
除UI層所展示的功能外，前端代碼同樣需要進行測試。在前端開發中最主要的莫過於JS甲苯語言，而QUnit就是針對JS的一個強大的單元測試框架。
上面圖片的測試金字塔映射了不同測試階段所投入的自動化測試的比例，UI層被放到了塔尖，這也說明UI層應該投入較少的自動化測試。如果系統只關注UI層的自動化測試並不是一種明智的做法，因為其很難從本質上保證產品質量。如果妄圖實現全面的UI層的自動化測試，那麼尋藥投入大量的人力和時間，然而，最終獲得的收益可能遠低於所投入的城本。因為對於一個系統來講，越接近用戶其越容易變化，為了適應這種變化就必須投入更多的成本。
既然UI層的自動化測試這麼勞民傷財，那麼我們是不是隻做單元測試與接口測試就可以了呢？答案是否定的，因為不管什麼樣的產品，最終呈現給用戶的都是UI層功能，所以產品才需要超頻大量的測試人員進行UI層面的功能測試。也正是因為測試人員在UI層面投入了大量的時間與精力，所以我們才有必要通過自動化的方式幫助測試人員解放部分重複的工作。所以，我更提倡“半自動化”的開戰測試工作，把可以自動化測試的工作交給工具或腳本完成，這樣測試人員就可以把更多的精力放在更重要的測試工作上，例如探索性測試等。
至於在金字塔中的每一層測試的投入比例則要根據實際的產品特徵來劃分。在《GooGle測試之道》一書中提到，Google對產品測試類型劃分為：小測試、中測試和大測試，採用70%（小）、20%（中）、10%（大）的比例，大體對應測試金字塔中的Unit、Serveice和UI層。
在進行自動化測試中最擔心的是變化，因為變化會直接導致測試用例的運行失敗，所以需要對自動化腳本進行不斷調整。如何控制失敗、降低維護成本是對自動化測試工具及人員能力的挑戰。
反過來講，一份永遠都運行通過的自動化測試用例已經失去了它存在的價值。
閱讀更多 BattleLine軍迷社區 的文章
