軟件測試金字塔
在敏捷方法中，持續集成是其基石，持續集成的核心是自動化測試。下面這篇關于測試金字塔的文章，來自大師Martin Fowler。
測試金字塔的概念來自Mike Cohn，在他的書Succeeding With Agile中有詳細描述：測試金字塔最底層是單元測試，然后是業務邏輯測試，最后是端到端的測試（GUI或CLI）。
在我的職業生涯中，很多次聽到過自動化測試，自動化測試意味著端到端的通過界面完成的測試。完成這種自動化測試的工具一般是錄制然后回放，初始使用很容易，不需要任何編碼技能。
不過你使用一段時間后就會遇到很多麻煩，GUI的自動化測試運行速度都很慢導致版本發布速度下降，同時完成自動化測試的軟件，一般都是商業軟件需要license因此只能在特定的機器上部署，且不容易通過腳本集成。
GUI測試用例還很脆弱，如對系統的一些修正可能導致很多用例的失敗，這時候你需要重新錄制。你可以放棄錄制的方法來解決這個問題，通過寫GUI測試代碼，但是這樣效率非常低。就算你已經很精通了GUI測試代碼的編寫，端到端的GUI測試用例也很容易出現不可預期結果的問題－一些用例成功一些用例失敗，因此，基于GUI的自動化測試是脆弱、耗時（包括用例維護和執行）的。所以測試金字塔要表達的是：底層應當有更多的單元測試和接口測試和邏輯測試，GUI測試用例能覆蓋到主業務流程即可。
我們注意到測試金字塔中間這一層：服務。業務服務的測試，我稱其為皮下測試，因為這一層就在用戶界面GUI下面。服務測試可以完成很多端到端的功能測試而不需要像GUI自動化測試那樣需要使用復雜的框架。如一個Web應用，你可能使用自己寫的腳本測試端到端的邏輯，而GUI自動化你可能會使用Selenium這個工具。
測試金字塔發源與敏捷測試實踐，使用測試金字塔原則很容易將你項目中的測試用例達到平衡的狀態。在很多項目中都混淆了“端到端測試”，“UI測試”，“面向用戶的測試”的概念，其實他們都是測試的不同角度。例如你有一個javascript開發的應用，那UI部分就需要用javascript的單元測試工具Jasmine完成大部分的UI功能測試；復雜的業務邏輯需要使用面向用戶的表單（form）來測試，而不僅僅是底層的單元測試。
因此我通常將上層的測試稱為“測試的第二防線”，如果你的一個上層測試用例執行失敗，表現出來不僅僅是這個功能有問題，還說明你遺漏了這個地方的單元測試，因此你在修復功能之后，還需要補充相關的單元測試用例。