在正式講自動(dòng)化測(cè)試之前，我們不妨來(lái)先聊聊目前測(cè)試團(tuán)隊(duì)一般存在的幾種模式。
1.1 冰淇淋模式(ice cream cone)
這個(gè)冰淇淋模式是2012年被提出來(lái)的，從圖我們可以非常明顯看到，測(cè)試團(tuán)隊(duì)在自動(dòng)化測(cè)試投入主要在GUI界面，而在集成測(cè)試和單元測(cè)試的投入則非常少，更可怕的是在圖頂端還有一大堆的手工測(cè)試，相信看到這個(gè)我們的感受是一樣，這個(gè)測(cè)試團(tuán)隊(duì)一定處于較低水平，大量的手工測(cè)試的存在，必然也就造成了這是一個(gè)難吃的冰淇淋。
出現(xiàn)這種情況的團(tuán)隊(duì)很多是因?yàn)闇y(cè)試團(tuán)隊(duì)為了盡快產(chǎn)出效果，獲得收益就從最容易上手的用戶界面測(cè)試開(kāi)始。還一個(gè)原因就是團(tuán)隊(duì)成員自動(dòng)化測(cè)試技能較弱，不得不采用更多的手工測(cè)試。
這種模式在傳統(tǒng)軟件公司非常常見(jiàn)，甚至?xí)霈F(xiàn)底下三種測(cè)試的投入幾乎為零。 這是一種非常典型的依賴手工測(cè)試完成業(yè)務(wù)的測(cè)試，通過(guò)手工測(cè)試來(lái)測(cè)評(píng)產(chǎn)品的質(zhì)量。這樣系統(tǒng)隨著時(shí)間而越來(lái)越龐大，業(yè)務(wù)邏輯越來(lái)越復(fù)雜，代碼耦合性越來(lái)越高，系統(tǒng)公共部分越來(lái)越多，最后可能出現(xiàn)牽一發(fā)而動(dòng)全身，到那時(shí)測(cè)試工作就變得極其困難。經(jīng)常遇到A功能之前測(cè)試是正常，等發(fā)布幾個(gè)周期后，因?yàn)闇y(cè)試時(shí)間緊，就沒(méi)有再去回歸A功能，結(jié)果上線后往往A功能就處于一個(gè)不可工作狀態(tài)。
1.2 金字塔模式
這是現(xiàn)在非常流行的一種自動(dòng)化測(cè)試分層理念，這個(gè)是由Mike Cohn提出的，所以這個(gè)模型其實(shí)也是敏捷測(cè)試模型。 這個(gè)模型上，我們看一看到金字塔的底部是 Unit 而且占了絕大多數(shù)位置，中間這層是 Service 有時(shí)我們也叫接口層API層，而金字塔的頂部是 UI 層，占有空間最小 。
這個(gè)自動(dòng)化測(cè)試金字塔提出后，幾乎被奉為主旨，甚至一度出現(xiàn)配合敏捷轉(zhuǎn)型，很多公司出現(xiàn)拆撤獨(dú)立的測(cè)試部分，將測(cè)試人員大散并入到各個(gè)Scrum 團(tuán)隊(duì)的風(fēng)潮。當(dāng)然其實(shí)現(xiàn)實(shí)中真正長(zhǎng)期執(zhí)行這種模型的團(tuán)隊(duì)很少，因?yàn)殡y度非常大。
為啥呢？
我們?cè)倏纯催@個(gè)圖，圖中自動(dòng)化測(cè)試中 Unit 的自動(dòng)化占比非常大，大概在80% ， Service 占比大概10% ~ 15% ，而最頂端的 UI 自動(dòng)化占比最少，大概 1% ~ 5%。1% ~ 5% 其實(shí)也基本跟我們編寫(xiě) TestCase 中的冒煙級(jí)別的Case數(shù)量差不多，這也就說(shuō)，UI 自動(dòng)化測(cè)試建議做到冒煙回歸級(jí)別便可，通過(guò)UI自動(dòng)化測(cè)試來(lái)保證系統(tǒng)不會(huì)出現(xiàn)大的問(wèn)題。
當(dāng)然從實(shí)際工作中往往我們可以把這個(gè)比例提高到10%左右，也就是UI自動(dòng)化測(cè)試主要去覆蓋系統(tǒng)的重要功能。
當(dāng)然提個(gè)醒UI自動(dòng)化測(cè)試，不要一味去追求覆蓋率，也不要去定一些不切實(shí)際的UI自動(dòng)化覆蓋率。真正對(duì)覆蓋率要求高的應(yīng)該是 Unit層，假設(shè)真的做到了80%以上的 UnitTest 覆蓋率，是不是覺(jué)得這種團(tuán)隊(duì)已經(jīng)偏向TDD團(tuán)隊(duì)了。TDD團(tuán)隊(duì)對(duì)全員要求水平都很高，所以這也就是為啥很少團(tuán)隊(duì)真正執(zhí)行這種模型。
1.3 另一種的金字塔模型
這個(gè)跟上面的金字塔模型沒(méi)有太大的區(qū)別，隨著敏捷測(cè)試的不斷演進(jìn)，又有個(gè)敏捷大師在金字塔上加了頂帽子 --- 探索性測(cè)試。 團(tuán)隊(duì)有了自動(dòng)化測(cè)試，是不是手工測(cè)試團(tuán)隊(duì)就解散了？當(dāng)然不是，還有無(wú)窮無(wú)盡的探索性測(cè)試等著你去做。
1.4 橄欖模式（不倒翁模式）
剛上說(shuō)的幾種模型要嘛不符合現(xiàn)在的敏捷團(tuán)隊(duì)，要嘛難度大。那從個(gè)人經(jīng)驗(yàn)上和測(cè)試效果上看，這個(gè)橄欖模式更為推薦。
它相比冰淇淋模式它更符合現(xiàn)在的敏捷團(tuán)隊(duì)，因?yàn)樗匾曌詣?dòng)化測(cè)試。 相比金字塔模式它相對(duì)更容易實(shí)操。
再來(lái)細(xì)看這個(gè)圖，圖中占最大比例的是中間部分的接口API層，其次是Unit層，UI 層依舊占比最少。
為啥大力推薦多做接口自動(dòng)化測(cè)試呢？
接口自動(dòng)化測(cè)試與UI自動(dòng)化測(cè)試或單元測(cè)試對(duì)比，有很多的優(yōu)勢(shì)。 單元測(cè)試通常針對(duì)代碼進(jìn)行測(cè)試，系統(tǒng)往往還處于一個(gè)還未部署狀態(tài)，而接口測(cè)試則是系統(tǒng)部署完成后才進(jìn)行的測(cè)試，另外一個(gè)接口測(cè)試TestCase往往會(huì)比一個(gè)單元測(cè)試的TestCase覆蓋到的代碼更多，而且接口測(cè)試通常是面向業(yè)務(wù)的測(cè)試。
這時(shí)你們可能就會(huì)問(wèn)那一個(gè)UI測(cè)試的TestCase不是會(huì)覆蓋更多代碼，更貼近業(yè)務(wù)，更貼近用戶實(shí)際操作？
這話沒(méi)毛病。 但為啥圖中反應(yīng)出來(lái)的UI 測(cè)試占比還是最少。 原因是接口自動(dòng)化測(cè)試相對(duì)UI自動(dòng)化測(cè)試更加簡(jiǎn)單直接，容易見(jiàn)成效，執(zhí)行效率也更高。而且根據(jù)經(jīng)驗(yàn)隨著自動(dòng)化測(cè)試用例個(gè)數(shù)的增長(zhǎng)，接口自動(dòng)化測(cè)試整體的維護(hù)難易度會(huì)比UI自動(dòng)化測(cè)試低，因?yàn)榻涌谧詣?dòng)化測(cè)試更簡(jiǎn)單直接。
所以，按照以往經(jīng)驗(yàn)看，我個(gè)人認(rèn)為一個(gè)團(tuán)隊(duì)如果不是走TDD模式，測(cè)試還處在自動(dòng)化測(cè)試的初級(jí)階段，橄欖模式更適合這一團(tuán)隊(duì)。平時(shí)我也經(jīng)常喜歡說(shuō)：重接口，輕UI。
最后如果我們?cè)谶@橄欖模型上再加一部分的手工測(cè)試或者探索性測(cè)試，那這樣是不是就像一個(gè)不倒翁啦。
按照這個(gè)模式，將大部分自動(dòng)化投資用于接口測(cè)試，可以獲得最高的投資回報(bào)。再結(jié)合持續(xù)測(cè)試與持續(xù)集成等最佳實(shí)踐，在團(tuán)隊(duì)中通過(guò)接口測(cè)試這一承上啟下的測(cè)試類(lèi)型，可以自下而上地逐步翻越過(guò)冰淇淋模式中的那堵墻。
