一、自動(dòng)化金字塔

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

圖1自動(dòng)化金字塔（敏捷測(cè)試）

自動(dòng)化金字塔提出之后，幾乎為奉為圭旨，甚至還一度出現(xiàn)了配合敏捷轉(zhuǎn)型，大規(guī)模裁撤獨(dú)立測(cè)試部門，將人員打散并入各個(gè)Scrum團(tuán)隊(duì)的風(fēng)潮。但在現(xiàn)實(shí)中，真正能長(zhǎng)期通過(guò)TDD等實(shí)踐大力發(fā)展單元測(cè)試，構(gòu)建穩(wěn)定的自動(dòng)化金字塔的團(tuán)隊(duì)是少之又少。

另外，有些重要的決策信息并沒(méi)有在金字塔模式中體現(xiàn)。如從每個(gè)用例的價(jià)值來(lái)說(shuō)，手工或者UI層的用例價(jià)值最高，越往下越低。這里的價(jià)值，可以是用例帶來(lái)的質(zhì)量信心，也可以是每個(gè)用例所覆蓋的代碼行數(shù)等等。并且自上而下，用例也是逐步從面向業(yè)務(wù)過(guò)渡到面向技術(shù)。

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

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

圖2 自動(dòng)化冰激凌

這一模式中龐大的手工用例數(shù)量，反映了工程團(tuán)隊(duì)對(duì)于自動(dòng)化測(cè)試投資的不足。許多開始投資自動(dòng)化測(cè)試的團(tuán)隊(duì)，為了能盡快產(chǎn)出效果，獲得收益，就采取了一些短平快的措施，從最容易上手的用戶界面開始。在傳統(tǒng)的商用軟件供應(yīng)商或者某些新興的SAAS服務(wù)提供商的系統(tǒng)中，往往用戶界面中包含有非常多的業(yè)務(wù)邏輯，他們的測(cè)試團(tuán)隊(duì)過(guò)往主要依賴于通過(guò)手工測(cè)試來(lái)完成其業(yè)務(wù)的測(cè)試，評(píng)測(cè)產(chǎn)品的質(zhì)量，因此其自動(dòng)化測(cè)試的投資重點(diǎn)和目標(biāo)，也往往是逐步提高現(xiàn)有手工測(cè)試用例的自動(dòng)化替代率。這是一種非常典型的路徑依賴，由此產(chǎn)生的結(jié)果就是，團(tuán)隊(duì)對(duì)于底層的自動(dòng)化測(cè)試方面的關(guān)注相當(dāng)不足。

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

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

圖3 自動(dòng)化紙杯蛋糕

從圖形上看，這個(gè)團(tuán)隊(duì)的自動(dòng)化測(cè)試投資在各個(gè)類型間的分布更加的合理。集成測(cè)試或者接口的數(shù)量相比蛋筒冰激凌模式來(lái)說(shuō)大了許多，單元測(cè)試的規(guī)模也有較大增長(zhǎng)。在引入敏捷和全員質(zhì)量的意識(shí)之后，工程團(tuán)隊(duì)也愈加重視測(cè)試和產(chǎn)品質(zhì)量，于是測(cè)試用例可能來(lái)自于以下三個(gè)團(tuán)隊(duì):

1.開發(fā)團(tuán)隊(duì)編寫單元測(cè)試、集成測(cè)試和組件測(cè)試用例

2.自動(dòng)化測(cè)試團(tuán)隊(duì)編寫UI自動(dòng)化測(cè)試用例

3.手工測(cè)試團(tuán)隊(duì)編寫手工運(yùn)行的測(cè)試用例，以系統(tǒng)集成測(cè)試/業(yè)務(wù)場(chǎng)景測(cè)試為主

根據(jù)提出者的介紹，紙杯蛋糕模式的形成原因，主要是因?yàn)殚_發(fā)和測(cè)試團(tuán)隊(duì)分屬不同部門，兩者中間有著厚厚的部門墻。從團(tuán)隊(duì)協(xié)作的角度上來(lái)講，因?yàn)閴Φ拇嬖?，這些團(tuán)隊(duì)都各自為政，彼此間并不能很有效地協(xié)作。在測(cè)試的級(jí)別/類型/場(chǎng)景劃分上，這三個(gè)團(tuán)隊(duì)是彼此沒(méi)有協(xié)同的。這樣就必然導(dǎo)致某些重復(fù)工作，有些用例被反復(fù)地進(jìn)行自動(dòng)化；而另一方面，質(zhì)量拼圖不完整也是不完整的，存在縫隙和漏洞，結(jié)果必然是1+1+1<3。

從流程上來(lái)講，測(cè)試工作也依然是依次線性發(fā)生的，而不是同步的。首先，開發(fā)編寫代碼以及對(duì)應(yīng)的測(cè)試用例；然后手工測(cè)試者設(shè)計(jì)并運(yùn)行自己編寫的用例；最后，自動(dòng)化測(cè)試團(tuán)隊(duì)編寫UI自動(dòng)化測(cè)試用例并執(zhí)行。這個(gè)場(chǎng)景可能某些讀者非常熟悉，這就是許多聲稱已經(jīng)敏捷化的團(tuán)隊(duì)的工作模式，在Scrum的流程中依舊使用傳統(tǒng)的瀑布式開發(fā)模式。他們的Scrum模式，有同行給取了個(gè)名字，叫做Scrummerfall[4] 。

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

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

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

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

經(jīng)濟(jì)學(xué)中有另外一個(gè)著名的理論叫做邊際效益遞減。當(dāng)做一項(xiàng)投資，隨著投資量的增加，單位投資增量所帶來(lái)的單位收益是越來(lái)越少的，甚至在某個(gè)臨界點(diǎn)之后，這個(gè)收益有可能是負(fù)數(shù)。而這個(gè)零界點(diǎn)，就是投資收益最大的點(diǎn)。在這個(gè)點(diǎn)之前的所有投資，都可以擴(kuò)大總收益，而在超過(guò)之后繼續(xù)進(jìn)行投資，就不那么明智了。

圖4 自動(dòng)化成本/收益曲線

按照這個(gè)思路，在圖4上，針對(duì)三種不同類型的自動(dòng)化測(cè)試，可以獲得三個(gè)零界點(diǎn)。而總收益最大的點(diǎn)在集成測(cè)試上，隨后是單元測(cè)試，UI測(cè)試則最低。

如果從測(cè)試效果上看，接口測(cè)試和UI/單元測(cè)試相比，有很多優(yōu)勢(shì)。 對(duì)于單元測(cè)試來(lái)說(shuō)，通常單元測(cè)試是針對(duì)代碼進(jìn)行的測(cè)試，而接口測(cè)試是在測(cè)試一個(gè)活的，經(jīng)過(guò)部署的系統(tǒng)。 另外，單個(gè)接口測(cè)試與單個(gè)單元測(cè)試用例相比，也可以覆蓋更多的代碼。更重要的是，接口測(cè)試也可以是面向業(yè)務(wù)的測(cè)試，通過(guò)接口進(jìn)行業(yè)務(wù)層面的測(cè)試。

而相比UI自動(dòng)化用例，接口測(cè)試更加的簡(jiǎn)單直接，執(zhí)行效率更高。 除了部分如企業(yè)級(jí)應(yīng)用軟件，可能很多業(yè)務(wù)在前端進(jìn)行之外，很多情況下，絕大部分通過(guò)UI完成的業(yè)務(wù)操作完全可以通過(guò)API端完成。某些情況下，API的測(cè)試條件覆蓋率甚至可以多過(guò)UI。

綜合上述的分析，筆者認(rèn)為在在自動(dòng)化測(cè)試的初級(jí)階段，適合奔小康的測(cè)試團(tuán)隊(duì)的自動(dòng)化模式應(yīng)該是中間層的接口最大，兩端的UI和Unit測(cè)試適度實(shí)施。從圖形上看，就是一個(gè)橄欖型。如果再加上一部分的手工測(cè)試，那就是一個(gè)不倒翁了。

按照這個(gè)模式，將大部分自動(dòng)化投資用于接口測(cè)試，可以獲得最高的投資回報(bào)。再結(jié)合持續(xù)測(cè)試與持續(xù)集成等最佳實(shí)踐，在團(tuán)隊(duì)之間彼此共享測(cè)試用例、測(cè)試框架或者平臺(tái)，通過(guò)接口測(cè)試這一承上啟下的測(cè)試類型，可以自下而上地逐步翻越過(guò)紙杯蛋糕模式中的那堵墻。

查看更多軟件測(cè)試資訊、產(chǎn)品、教程>>>>

您也可了解更多>>