自動化測試到底是什么

引子

偶然在群里有人問自動化測試到底是啥，搞不懂。qtp對象庫好麻煩，jmeter怎么做測試。。。。一堆一堆的問題。其實說實話真心不知道該咋解答了，我的內心是累的~

突然想到自己的新書里不就解釋過這些嗎！看來還是很多童鞋對于自動化測試的認知存在巨大的問題啊！

so，以下內容選擇《小強軟件測試瘋狂講義》

自動化測試到底是什么

重新認識性能測試之后我們再來看看自動化測試到底是什么。其實這個話題我在不同的場合多次談過，甚至在我創辦的“挨踢脫口秀”中也專門做了一次節目來說明，但可惜的是仍然有很多朋友對自動化測試的認知是不完整的，那本節就再次帶領大家重新認識一下。

自動化測試到底是什么？我們可以簡單的理解為前期通過人工編碼完成框架，后期來解放人力并自動完成規定的測試。更通俗點可以這么理解：現在有小強1號和2號兩個機器人，你對其中的小強1號機器人進行編碼告訴他“在每天中午12點的時候給小強2號機器人一巴掌”，那么當到了中午12點的時候小強1號機器人就會按照你的編碼要求執行，并給小強2號機器人一巴掌，這樣你就可以干其他事情去了，不需要自己來做，解放了人力，提升了效率（莫名的感覺到自己的臉被打了一巴掌啊）。

講到這里大家應該明白什么是自動化測試了吧？嘿嘿，你真的以為自己明白了？我想這時候肯定有不少朋友會脫口而出，自動化測試不就是QTP、Selenium、Appium這些玩意嘛？如果你真的這么理解那還是不夠完整。大部分朋友都覺得一說自動化測試就是指UI層自動化測試，其實UI層自動化測試只是其中的一種而已，具體的層級我們會在后面的章節講解。

最后我也必須提出一點，任何無法服務于業務的技術都是沒有價值的，自動化測試也是，只有自動化測試能真正的服務于業務，并帶來較高性價比才有價值，單純拿代碼堆疊起來的自動化測試不可取。

自動化測試分層模型

我們全新認識了自動化測試之后就來看看自動化測試分層模型，同時也會和大家聊聊自動化測試到底怎么用才能“恰當好處”。此模型在網上也看到過，不知道是誰最先寫出來的，總之感謝此模型的創造者！我在這個模型上面做了一些微調，方便小白朋友們更好的理解。分層模型如圖1.3所示。

圖1.3 自動化測試分層模型

有了性能測試分層模型的經驗，自動化測試分層模型就容易理解了，它主要是分為了三層，下面我們就一層層的來詳細講解。

UI層

這個是大部分朋友理解的自動化測試，UI指的就是用戶可以用肉眼看到的頁面。基本上我接觸的小白朋友一說自動化測試就認為是UI層的，這個誤解我覺得真的太可怕了。

我們先來聊聊UI層自動化測試的原理。不論是Web端還是移動端，原理都是一樣的：就是基于頁面元素的識別和定位來進行模擬用戶行為。首先識別到某個元素，比如一個按鈕，然后定義一個動作，比如點擊，這樣就通過代碼模擬完成了一次按鈕的點擊，代替了人工去點擊。如果后期再加入數據驅動和Page Object思想就基本可以形成一個UI層自動化測試框架了。明白了這個道理之后我們再來聊聊UI層自動化測試的適用范圍。

對于UI層自動化測試的適用范圍，我個人不建議做大規模的應用，從自己的實踐經驗來看大規模的應用UI層自動化測試最后的結局總是悲劇的。主要是由于以下幾個原因導致：

1) UI變化頻繁，計劃根本趕不上變化（同意的小伙伴們請點贊）。

2) 初期見效太慢，等不了，我們都希望恨不得用了自動化測試技術就能立馬看到帶來的效果，但事實總是相反，自動化測試的效果是在后期體現的。

3) 前端的開發不規范，導致很多元素識別和定位起來較為困難。

那UI層自動化測試是不是就不能應用了呢？必然不是！保持一個客觀、公正的態度來看待是非常重要的，至少從我個人的實踐經驗來講，UI層自動化測試可以應用到冒煙測試中，這里的冒煙測試是指主流程的測試，就是那些非常重要且不會頻繁變化的流程，可以利用UI層自動化測試來完成。比如，之前我們會對電商系統的主流程做每日的UI層自動化回歸測試，用來保證線上系統功能的正常，效果還不錯。所以，用與不用關鍵在于它的適用范圍，只有在合適的范圍內使用了合適的技術才會表現出最好的效果。

最后用一句話總結下：“給你一把屠龍刀，如果你不會用那就和菜刀一樣”，只有對自動化測試有了正確的認知才能更好的去推動它的發展，也只有明白了它們的特點才能更好的運用。

接口層

接口層是現在在企業中應用最為廣泛的自動化測試方法之一，它的優點在于基本規避了UI層自動化測試的缺點，并且一旦形成較為穩定、完整的框架后基本上是比較通用的，不論是在Web端還是移動端都可以使用。但缺點也很明顯，就是對測試工程師的編碼能力要求較高，這也是很多測試工程師止步于此的重要原因。

對于接口層自動化測試是我個人比較推薦，也是建議大家有能力多去學習一下的，對于自身測試技術的提升還是有明顯幫助的。一般接口層自動化測試都會用Python、Ruby等語言開發，比如，某租車公司的接口測試框架是用Ruby開發的，我們之前的接口測試框架是用Python開發的，這里大家不必糾結用什么語言開發，每個語言在編程思想上是通用的，只是在語法上稍有不同而已，基本上你熟悉了一門語言后學其他的語言都會非常快。多說無益，只有做過的朋友才能體會它的好。后面的章節中也會給大家講解一些輕量級框架的設計與實現。

單元層

單元層的自動化測試對測試工程師的編碼能力要求較高，且要能看懂業務的實現代碼，這樣才能針對被測代碼編寫單元測試代碼，一般都是引入XUnit、TestNG等框架來完成。為什么大部分公司在這個層級也無法很好的推行呢？原因在1.2節性能測試分層模型中已討論過，此處不再講述。

其實，自動化測試的難點在于框架的設計，并不在于寫代碼。框架的設計需要統籌全局，就好像一個指揮官。而最后來實現框架你招幾個有代碼能力的人怎么都可以實現。在小強自動化測試班中我也能深刻地感受到，很多學員在學寫代碼的時候表現還不錯，但在最終設計框架的時候毫無頭緒，或者說是沒有框架設計的思想，導致大腦一直空白，如果是這樣那你學的再好都沒有用，因為你學的用不上，只有當你具備總體框架設計的思維能力，才能利用所學的語言去實現，過程中無非就是在實現的過程中遇到問題了查查資料而已，至少你能邁出這最重要的一步了。可見，有時候思想是多么關鍵啊！

初學者如何選擇學習哪種技術

這個話題有點沉重，因為一旦表述不好肯定會被一些無良的人罵之，但思前想后還是決定寫這一章節。因為我被太多的朋友問過這個問題了，大概統計了一下，基本每兩天就會被問到一次，有時候一天還會被問到N次，我回答的都要吐血了，為此還在《挨踢脫口秀》中專門做了一期節目，可見這個話題的必要性了，也希望能幫助有選擇糾結癥的朋友。

下面我盡量客觀的以我自己的學習經歷來聊聊，也許這個經歷不是最好的，甚至是錯的，但可以給大家一些參考，少走一些彎路，我覺得就是有價值的。

首先，我們說說學習性能測試需要面臨的幾個挑戰，大家可以結合自己的實際情況看看自己是否適合繼續學習。

第一，龐大的知識體系，這個是我們面臨的第一個挑戰。性能測試是一項復雜且需要耐心的工作，我們需要在復雜的系統中“抽絲剝繭”，一層層分析從而確定性能問題。這個過程會涉及中間件、Web服務器、緩存、數據庫、代碼等知識，所以沒有一個較為完整的知識體系就很難進行下去。雖然說是挑戰，但在我看來卻是大部分小白朋友最佳的入門途徑，因為它能幫助我們快速建立較為完善的知識體系，對于我們而言有百利而無一害。不知你是否遇到過這樣的場景，被指著鼻子說：連一個SQL語句都不會寫，連中間件是什么都不知道你還和我們討論什么。這樣的“羞辱”雖然讓我們不開心，但也直白地指出了現在很多測試工程師在整體知識體系方面的欠缺，只有把自己的短板補起來才有底氣和實力去爭取更美好的事物。

第二，較強的分析能力，這個是我們面臨的第二個挑戰。就好像動畫片《柯南》，在復雜的犯罪現場破案，需要不斷的推斷和論證，這個過程中有可能會把之前確定的事情推翻了，也有可能好幾天都沒有進展，但這也是它的魅力，可以說是痛并快樂的。

在我接觸過很多學員之后，我發現大家一個共性的問題就是邏輯分析能力較差，在分析的過程中經常是東一點西一點，完全沒有邏輯可言，都是亂猜，并且經常容易掉入細節，一旦掉入無法自拔，導致停滯不前，這也就是為什么很多人覺得性能測試難的原因。在我看來，性能測試的分析過程就像剝洋蔥，你需要一層層剝開才能看到問題所在，這個過程就需要你有較強的邏輯分析能力，同時也要具有宏觀性，只有站在一定的高度去看待問題才能豁然開朗，不然就會陷入死胡同。一旦這個思維能力培養好了，就會事半功倍，學習其他技術時效率也會提高，所以萬事都需付出才能有收獲。

其次，我們再來說說學習自動化測試需要面臨的幾個挑戰。

第一，編碼能力，這個是逾越不過的坎兒。說到這里可能會有朋友問難道性能測試不需要編碼能力嗎？答案是需要，但比起自動化測試來說門檻相對低點。其實對于一個優秀的測試工程師來說編碼能力是必備的技能。

如何提升自己的編碼能力也是不少朋友咨詢過我的問題，真心沒有什么捷徑。我覺得就是要多練習多總結，我說的練習是真正的動手去做而不是看。我帶過的學員中其實大部分同學都存在一個問題，就是上課講的時候聽起來感覺很簡單，不以為然，但當自己下課后練習時卻出現各種問題，很簡單的知識點能搞一天，所以一定要多練習，每次犯過的錯誤也都要及時總結，不能讓自己在同一個地方跌倒兩次。我再苦口婆心一句：“沒有不起眼的磚，沒有看不到的框架，漂亮的樓房怎么能屹立不倒”。

第二，邏輯思維能力。在有了編碼能力之后就能做自動化測試了嗎？顯然不能，因為自動化測試最終是希望建立一個框架或者平臺，這是一個大工程，一定要有較強的邏輯思維能力和設計能力才行。就好比，你會焊接技術但不代表你會設計汽車啊。所以自動化測試真正的難點在于設計思想，一點經驗都沒有的朋友做起來確實會比較吃力，這也就是為什么我個人建議可以先學習性能測試，培養能力和思維之后再學自動化測試的原因了。

說了這么多，我想大家應該心中已經有了答案，再次聲明，這些只是我個人的看法，不見得對，僅供參考而已，不喜勿噴。