一、自動化金字塔

自動化金字塔最早是在2009年由Mike Cohn提出的。最早提出來的時候是一個三層的金字塔，從上到下分別是UI/Service/Unit測試。后來Lisa Cripin 在她著名的《agile testing》 [1]這本書中，又給這個金字塔加了一個手工測試的帽子。隨著敏捷測試的不斷推進，帽子部分又轉變成了探索式測試，如圖1所示。當然service層可以也理解為 API測試，或者集成測試等等。這種下寬上窄的三角形結構，代表著各層自動化的投入分配應該是底層的單元測試最多，接口測試居中，UI層最少。

圖1自動化金字塔（敏捷測試）

自動化金字塔提出之后，幾乎為奉為圭旨，甚至還一度出現了配合敏捷轉型，大規模裁撤獨立測試部門，將人員打散并入各個Scrum團隊的風潮。但在現實中，真正能長期通過TDD等實踐大力發展單元測試，構建穩定的自動化金字塔的團隊是少之又少。

另外，有些重要的決策信息并沒有在金字塔模式中體現。如從每個用例的價值來說，手工或者UI層的用例價值最高，越往下越低。這里的價值，可以是用例帶來的質量信心，也可以是每個用例所覆蓋的代碼行數等等。并且自上而下，用例也是逐步從面向業務過渡到面向技術。

二、蛋筒冰激凌模式（反模式）

Alister Scott 在2012年提出了蛋筒冰激凌(ice cream cone)這一反模式[2]。從圖形上看，這其實是一個倒置的自動化測試金字塔。這個模式的特點就是，整個組織的自動化測試主要還是針對于用戶界面，對于單元測試和集成測試用例的數量或者投資要少許多。更為可怕的是，這個冰激凌桶上面有一大坨手工用例。這個冰淇淋吃起來，估計遠不如哈根達斯或者暴風雪那么好的口味了。

圖2 自動化冰激凌

這一模式中龐大的手工用例數量，反映了工程團隊對于自動化測試投資的不足。許多開始投資自動化測試的團隊，為了能盡快產出效果，獲得收益，就采取了一些短平快的措施，從最容易上手的用戶界面開始。在傳統的商用軟件供應商或者某些新興的SAAS服務提供商的系統中，往往用戶界面中包含有非常多的業務邏輯，他們的測試團隊過往主要依賴于通過手工測試來完成其業務的測試，評測產品的質量，因此其自動化測試的投資重點和目標，也往往是逐步提高現有手工測試用例的自動化替代率。這是一種非常典型的路徑依賴，由此產生的結果就是，團隊對于底層的自動化測試方面的關注相當不足。

三、紙杯蛋糕模式（反模式）

如果說蛋筒冰激凌模式還只是反應了自動化測試在測試類型和投資分配上的問題，那么來自ThoughtWorks的Fabio Pereira于2014年提出的紙杯蛋糕模式(Software Testing Cupcake)[3]這一反模式就反映出了許多更深層次的問題。

圖3 自動化紙杯蛋糕

從圖形上看，這個團隊的自動化測試投資在各個類型間的分布更加的合理。集成測試或者接口的數量相比蛋筒冰激凌模式來說大了許多，單元測試的規模也有較大增長。在引入敏捷和全員質量的意識之后，工程團隊也愈加重視測試和產品質量，于是測試用例可能來自于以下三個團隊:

1.開發團隊編寫單元測試、集成測試和組件測試用例

2.自動化測試團隊編寫UI自動化測試用例

3.手工測試團隊編寫手工運行的測試用例，以系統集成測試/業務場景測試為主

根據提出者的介紹，紙杯蛋糕模式的形成原因，主要是因為開發和測試團隊分屬不同部門，兩者中間有著厚厚的部門墻。從團隊協作的角度上來講，因為墻的存在，這些團隊都各自為政，彼此間并不能很有效地協作。在測試的級別/類型/場景劃分上，這三個團隊是彼此沒有協同的。這樣就必然導致某些重復工作，有些用例被反復地進行自動化；而另一方面，質量拼圖不完整也是不完整的，存在縫隙和漏洞，結果必然是1+1+1<3。

從流程上來講，測試工作也依然是依次線性發生的，而不是同步的。首先，開發編寫代碼以及對應的測試用例；然后手工測試者設計并運行自己編寫的用例；最后，自動化測試團隊編寫UI自動化測試用例并執行。這個場景可能某些讀者非常熟悉，這就是許多聲稱已經敏捷化的團隊的工作模式，在Scrum的流程中依舊使用傳統的瀑布式開發模式。他們的Scrum模式，有同行給取了個名字，叫做Scrummerfall[4] 。

類似的模式還有ThoughtWorks公司的Anand Bagmar 在《Is Selenium Finely Aged Wine?》中提到的“雙金字塔反模式”(Dual Test Pyramid Anti-Pattern)以及Graham Russell 提出的以佇立在英國紐卡斯爾南部的地標性雕塑“北方天使”（Angel of North）命名的“北方天使反模式”(Angel of North Anti-Pattern)等，這里就不一一贅述了。它們都不約而同地關注于協作與溝通、利益與壁壘等有關人員與組織層面的問題，而不僅僅集中在如何進行自動化測試自身。

當然，很多時候拘泥于部門間職責的切分，有些很好的建議，在現實中比較難以展開。如使用垂直分布的自動化測試度量目標，實現針對某個story或者某個發布在所有級別(UI, Unit)上與所有團隊(開發、測試)進行共享。因為度量目標是分享的，更容易達到雙贏和互相補位的結果。而現實中，有些Scrum團隊的工作DOD(Definition of Done，完成的定義)并不包含測試團隊或者測試人員的交付物。當在看板里把一個story置為“Done”的時候，那么很可能只是"Dev Done"(開發完成)，然后交付給測試去實現“Test Done”(測試完成)。另外，出于專注于本職工作，做精做細功能和非功能測試的考慮，一般獨立的測試團隊也很少去參與開發團隊的測試，更不要說共同探討如何分享測試資源、度量目標了。

四、橄欖模式（不倒翁模式）

眾所周知，軟件測試的邊際成本會隨著缺陷探測率的提高而提高，這就是軟件測試的基本公理之一"測試的不可窮盡性"的經濟學體現。這一規律也適用于自動化測試，也就是說隨著自動化覆蓋率的提升，自動化的成本也呈現指數式上升。按照這個思路進行拓展，可以分析下單元測試，集成測試和UI測試的自動化成本曲線如圖4所示。與通常理解的一致，為了達到相同的自動化率(x0)，UI的成本最高、其次是API，Unit則最低。

經濟學中有另外一個著名的理論叫做邊際效益遞減。當做一項投資，隨著投資量的增加，單位投資增量所帶來的單位收益是越來越少的，甚至在某個臨界點之后，這個收益有可能是負數。而這個零界點，就是投資收益最大的點。在這個點之前的所有投資，都可以擴大總收益，而在超過之后繼續進行投資，就不那么明智了。

圖4 自動化成本/收益曲線

按照這個思路，在圖4上，針對三種不同類型的自動化測試，可以獲得三個零界點。而總收益最大的點在集成測試上，隨后是單元測試，UI測試則最低。

如果從測試效果上看，接口測試和UI/單元測試相比，有很多優勢。 對于單元測試來說，通常單元測試是針對代碼進行的測試，而接口測試是在測試一個活的，經過部署的系統。 另外，單個接口測試與單個單元測試用例相比，也可以覆蓋更多的代碼。更重要的是，接口測試也可以是面向業務的測試，通過接口進行業務層面的測試。

而相比UI自動化用例，接口測試更加的簡單直接，執行效率更高。 除了部分如企業級應用軟件，可能很多業務在前端進行之外，很多情況下，絕大部分通過UI完成的業務操作完全可以通過API端完成。某些情況下，API的測試條件覆蓋率甚至可以多過UI。

綜合上述的分析，筆者認為在在自動化測試的初級階段，適合奔小康的測試團隊的自動化模式應該是中間層的接口最大，兩端的UI和Unit測試適度實施。從圖形上看，就是一個橄欖型。如果再加上一部分的手工測試，那就是一個不倒翁了。

按照這個模式，將大部分自動化投資用于接口測試，可以獲得最高的投資回報。再結合持續測試與持續集成等最佳實踐，在團隊之間彼此共享測試用例、測試框架或者平臺，通過接口測試這一承上啟下的測試類型，可以自下而上地逐步翻越過紙杯蛋糕模式中的那堵墻。

查看更多軟件測試資訊、產品、教程>>>>

您也可了解更多>>