在正式講自動化測試之前搪泳，我們不妨來先聊聊目前測試團隊一般存在的幾種模式丸氛。
1.1 冰淇淋模式(ice cream cone)
這個冰淇淋模式是2012年被提出來的，從圖我們可以非常明顯看到俭识，測試團隊在自動化測試投入主要在GUI界面渺氧，而在集成測試和單元測試的投入則非常少，更可怕的是在圖頂端還有一大堆的手工測試漂羊，相信看到這個我們的感受是一樣驾锰，這個測試團隊一定處于較低水平，大量的手工測試的存在走越，必然也就造成了這是一個難吃的冰淇淋椭豫。
出現(xiàn)這種情況的團隊很多是因為測試團隊為了盡快產(chǎn)出效果，獲得收益就從最容易上手的用戶界面測試開始买喧。還一個原因就是團隊成員自動化測試技能較弱捻悯，不得不采用更多的手工測試。
這種模式在傳統(tǒng)軟件公司非常常見淤毛，甚至會出現(xiàn)底下三種測試的投入幾乎為零今缚。 這是一種非常典型的依賴手工測試完成業(yè)務的測試，通過手工測試來測評產(chǎn)品的質量低淡。這樣系統(tǒng)隨著時間而越來越龐大姓言，業(yè)務邏輯越來越復雜，代碼耦合性越來越高蔗蹋，系統(tǒng)公共部分越來越多何荚，最后可能出現(xiàn)牽一發(fā)而動全身，到那時測試工作就變得極其困難猪杭。經(jīng)常遇到A功能之前測試是正常餐塘，等發(fā)布幾個周期后，因為測試時間緊皂吮，就沒有再去回歸A功能戒傻，結果上線后往往A功能就處于一個不可工作狀態(tài)。
1.2 金字塔模式
這是現(xiàn)在非常流行的一種自動化測試分層理念蜂筹，這個是由Mike Cohn提出的需纳，所以這個模型其實也是敏捷測試模型。 這個模型上艺挪，我們看一看到金字塔的底部是 Unit 而且占了絕大多數(shù)位置不翩，中間這層是 Service 有時我們也叫接口層API層，而金字塔的頂部是 UI 層，占有空間最小 口蝠。
這個自動化測試金字塔提出后器钟，幾乎被奉為主旨，甚至一度出現(xiàn)配合敏捷轉型亚皂，很多公司出現(xiàn)拆撤獨立的測試部分俱箱，將測試人員大散并入到各個Scrum 團隊的風潮。當然其實現(xiàn)實中真正長期執(zhí)行這種模型的團隊很少灭必，因為難度非常大。
為啥呢乃摹？
我們再看看這個圖禁漓，圖中自動化測試中 Unit 的自動化占比非常大，大概在80% 孵睬， Service 占比大概10% ~ 15% 播歼，而最頂端的 UI 自動化占比最少，大概 1% ~ 5%掰读。1% ~ 5% 其實也基本跟我們編寫 TestCase 中的冒煙級別的Case數(shù)量差不多秘狞，這也就說，UI 自動化測試建議做到冒煙回歸級別便可蹈集，通過UI自動化測試來保證系統(tǒng)不會出現(xiàn)大的問題烁试。
當然從實際工作中往往我們可以把這個比例提高到10%左右，也就是UI自動化測試主要去覆蓋系統(tǒng)的重要功能拢肆。
當然提個醒UI自動化測試减响，不要一味去追求覆蓋率，也不要去定一些不切實際的UI自動化覆蓋率郭怪。真正對覆蓋率要求高的應該是 Unit層支示，假設真的做到了80%以上的 UnitTest 覆蓋率，是不是覺得這種團隊已經(jīng)偏向TDD團隊了鄙才。TDD團隊對全員要求水平都很高颂鸿，所以這也就是為啥很少團隊真正執(zhí)行這種模型。
1.3 另一種的金字塔模型
這個跟上面的金字塔模型沒有太大的區(qū)別攒庵，隨著敏捷測試的不斷演進嘴纺，又有個敏捷大師在金字塔上加了頂帽子 --- 探索性測試。 團隊有了自動化測試叙甸，是不是手工測試團隊就解散了颖医？當然不是，還有無窮無盡的探索性測試等著你去做裆蒸。
1.4 橄欖模式（不倒翁模式）
剛上說的幾種模型要嘛不符合現(xiàn)在的敏捷團隊熔萧，要嘛難度大。那從個人經(jīng)驗上和測試效果上看，這個橄欖模式更為推薦佛致。
它相比冰淇淋模式它更符合現(xiàn)在的敏捷團隊贮缕，因為他重視自動化測試。 相比金字塔模式它相對更容易實操俺榆。
再來細看這個圖感昼，圖中占最大比例的是中間部分的接口API層，其次是Unit層罐脊，UI 層依舊占比最少定嗓。
為啥大力推薦多做接口自動化測試呢？
接口自動化測試與UI自動化測試或單元測試對比萍桌，有很多的優(yōu)勢宵溅。 單元測試通常針對代碼進行測試，系統(tǒng)往往還處于一個還未部署狀態(tài)上炎，而接口測試則是系統(tǒng)部署完成后才進行的測試恃逻，另外一個接口測試TestCase往往會比一個單元測試的TestCase覆蓋到的代碼更多，而且接口測試通常是面向業(yè)務的測試藕施。
這時你們可能就會問那一個UI測試的TestCase不是會覆蓋更多代碼寇损，更貼近業(yè)務，更貼近用戶實際操作裳食？
這話沒毛病矛市。 但為啥圖中反應出來的UI 測試占比還是最少。 原因是接口自動化測試相對UI自動化測試更加簡單直接胞谈，容易見成效尘盼，執(zhí)行效率也更高。而且根據(jù)經(jīng)驗隨著自動化測試用例個數(shù)的增長烦绳，接口自動化測試整體的維護難易度會比UI自動化測試低卿捎，因為接口自動化測試更簡單直接。
所以径密，按照以往經(jīng)驗看午阵，我個人認為一個團隊如果不是走TDD模式，測試還處在自動化測試的初級階段享扔，橄欖模式更適合這一團隊底桂。平時我也經(jīng)常喜歡說：重接口，輕UI惧眠。
最后如果我們在這橄欖模型上再加一部分的手工測試或者探索性測試籽懦，那這樣是不是就像一個不倒翁啦。
按照這個模式氛魁，將大部分自動化投資用于接口測試暮顺，可以獲得最高的投資回報厅篓。再結合持續(xù)測試與持續(xù)集成等最佳實踐，在團隊中通過接口測試這一承上啟下的測試類型捶码，可以自下而上地逐步翻越過冰淇淋模式中的那堵墻羽氮。
