測試金字塔

原文連結：http://zyzhang.github.io/blog/2013/04/28/test-pyramid/

測試金字塔概念由Mike Cohn提出，並在其著作《Succeeding with Agile》譯註1中做了詳細論述。其核心觀點是底層單元測試應多於依賴GUI的高層端到端測試。

在我職業生涯的大部分時間中，測試自動化就是使用自動化測試工具在使用者介面上操控應用程式。這些工具一般都提供錄製和回放的功能，並驗證應用程式返回了同樣的結果。開始時，這種方式工作得很好。測試也很容易錄製，即使沒有程式設計經驗，也可以輕鬆完成。

但是，這種方法很快就陷入了困境，演變成所謂的蛋卷冰淇淋。主要問題包括：基於UI的測試執行緩慢，增加了構建時間；測試自動化工具往往還需安裝授權許可，這意味著這些軟體只能在特定的機器上執行；通常這些測試還很難以“傻瓜”模式執行，即通過指令碼執行並置入合適的部署流水線（deployment pipeline）。

更重要的是，這些測試非常脆弱。對系統功能的增強（enhancement）很容易就會破壞大量的測試，導致我們不得不重新錄製。當然，可以摒棄錄製-回放工具以減少此類問題的發生，但這樣又增加了測試編寫的難度注1。即便應用一些優秀實踐，端到端測試依然會存在不確定性問題（non-determinism problems），這會破壞測試的可信性。簡言之，基於UI的端到端測試具有這樣的缺點：脆弱、編寫成本高，而且執行耗時。因此，金字塔理論認為，相對於傳統的基於GUI的測試，應採用更多的自動化單元測試。

金字塔理論還認為，應該引入面向應用程式服務層的中間層測試，我把它稱為皮下測試（Subcutaneous Tests）。這些測試既保持了端到端測試的諸多優勢，又避免了許多與UI框架相關的複雜性。在Web應用程式中，皮下測試相當於API層測試，而位於金字塔頂層的UI測試則相當於Selenium或者Sahi測試。

測試金字塔引申出敏捷測試生命週期的很多核心概念，它更強調建立一個合理的測試組合。現實中的一個常見的問題是：團隊將端到端測試、單元測試和麵向客戶的測試混為一談，但它們其實是正交的。例如，對於富javascript使用者介面來說，應該通過Jasmine之類的工具對絕大多數UI行為進行單元測試；對於複雜的業務規則集合，則應通過面向客戶的表單進行測試，而且應像單元測試一樣僅涉及相關模組。

特別地，我始終認為高層測試只是測試防護體系的第二防線。如果一個高層測試失敗了，不僅僅表明功能程式碼中存在bug，還意味著單元測試的欠缺。因此，無論何時修復失敗的端到端測試，都應該同時新增相應的單元測試。

---

• 注1: 對任何型別的自動化來說，錄製-回放工具幾乎都是個糟糕的主意，因為它們會降低易變性並且阻礙我們進行有用的抽象。它們僅值得作為生成指令碼片段的工具，以便我們隨後使用合適的程式語言進行改寫，就像Twist和Emacs那樣 譯註2 。
• 譯註1： 全名《Succeeding with Agile: Software Development Using Scrum》，中文版《Scrum敏捷軟體開發》
• 譯註2：Twist是ThoughtWorks出品的敏捷測試工具，提供錄製功能；Emacs是極富盛名的文字編輯器，可以錄製巨集。