引子
偶然在群里有人問自動化測試到底是啥，搞不懂。qtp對象庫好麻煩，jmeter怎么做測試。。。。一堆一堆的問題。其實說實話真心不知道該咋解答了，我的內(nèi)心是累的~
突然想到自己的新書里不就解釋過這些嗎！看來還是很多童鞋對于自動化測試的認知存在巨大的問題??！
so，以下內(nèi)容選擇《小強軟件測試瘋狂講義》
自動化測試到底是什么
重新認識性能測試之后我們再來看看自動化測試到底是什么。其實這個話題我在不同的場合多次談過，甚至在我創(chuàng)辦的“挨踢脫口秀”中也專門做了一次節(jié)目來說明，但可惜的是仍然有很多朋友對自動化測試的認知是不完整的，那本節(jié)就再次帶領(lǐng)大家重新認識一下。
自動化測試到底是什么？我們可以簡單的理解為前期通過人工編碼完成框架，后期來解放人力并自動完成規(guī)定的測試。更通俗點可以這么理解：現(xiàn)在有小強1號和2號兩個機器人，你對其中的小強1號機器人進行編碼告訴他“在每天中午12點的時候給小強2號機器人一巴掌”，那么當(dāng)?shù)搅酥形?2點的時候小強1號機器人就會按照你的編碼要求執(zhí)行，并給小強2號機器人一巴掌，這樣你就可以干其他事情去了，不需要自己來做，解放了人力，提升了效率（莫名的感覺到自己的臉被打了一巴掌?。?/p>
講到這里大家應(yīng)該明白什么是自動化測試了吧？嘿嘿，你真的以為自己明白了？我想這時候肯定有不少朋友會脫口而出，自動化測試不就是QTP、Selenium、Appium這些玩意嘛？如果你真的這么理解那還是不夠完整。大部分朋友都覺得一說自動化測試就是指UI層自動化測試，其實UI層自動化測試只是其中的一種而已，具體的層級我們會在后面的章節(jié)講解。
最后我也必須提出一點，任何無法服務(wù)于業(yè)務(wù)的技術(shù)都是沒有價值的，自動化測試也是，只有自動化測試能真正的服務(wù)于業(yè)務(wù)，并帶來較高性價比才有價值，單純拿代碼堆疊起來的自動化測試不可取。
自動化測試分層模型
我們?nèi)抡J識了自動化測試之后就來看看自動化測試分層模型，同時也會和大家聊聊自動化測試到底怎么用才能“恰當(dāng)好處”。此模型在網(wǎng)上也看到過，不知道是誰最先寫出來的，總之感謝此模型的創(chuàng)造者！我在這個模型上面做了一些微調(diào)，方便小白朋友們更好的理解。分層模型如圖1.3所示。
圖1.3 自動化測試分層模型
有了性能測試分層模型的經(jīng)驗，自動化測試分層模型就容易理解了，它主要是分為了三層，下面我們就一層層的來詳細講解。
UI層
這個是大部分朋友理解的自動化測試，UI指的就是用戶可以用肉眼看到的頁面?；旧衔医佑|的小白朋友一說自動化測試就認為是UI層的，這個誤解我覺得真的太可怕了。
我們先來聊聊UI層自動化測試的原理。不論是Web端還是移動端，原理都是一樣的：就是基于頁面元素的識別和定位來進行模擬用戶行為。首先識別到某個元素，比如一個按鈕，然后定義一個動作，比如點擊，這樣就通過代碼模擬完成了一次按鈕的點擊，代替了人工去點擊。如果后期再加入數(shù)據(jù)驅(qū)動和Page Object思想就基本可以形成一個UI層自動化測試框架了。明白了這個道理之后我們再來聊聊UI層自動化測試的適用范圍。
對于UI層自動化測試的適用范圍，我個人不建議做大規(guī)模的應(yīng)用，從自己的實踐經(jīng)驗來看大規(guī)模的應(yīng)用UI層自動化測試最后的結(jié)局總是悲劇的。主要是由于以下幾個原因?qū)е拢?/p>
1) UI變化頻繁，計劃根本趕不上變化（同意的小伙伴們請點贊）。
2) 初期見效太慢，等不了，我們都希望恨不得用了自動化測試技術(shù)就能立馬看到帶來的效果，但事實總是相反，自動化測試的效果是在后期體現(xiàn)的。
3) 前端的開發(fā)不規(guī)范，導(dǎo)致很多元素識別和定位起來較為困難。
那UI層自動化測試是不是就不能應(yīng)用了呢？必然不是！保持一個客觀、公正的態(tài)度來看待是非常重要的，至少從我個人的實踐經(jīng)驗來講，UI層自動化測試可以應(yīng)用到冒煙測試中，這里的冒煙測試是指主流程的測試，就是那些非常重要且不會頻繁變化的流程，可以利用UI層自動化測試來完成。比如，之前我們會對電商系統(tǒng)的主流程做每日的UI層自動化回歸測試，用來保證線上系統(tǒng)功能的正常，效果還不錯。所以，用與不用關(guān)鍵在于它的適用范圍，只有在合適的范圍內(nèi)使用了合適的技術(shù)才會表現(xiàn)出最好的效果。
最后用一句話總結(jié)下：“給你一把屠龍刀，如果你不會用那就和菜刀一樣”，只有對自動化測試有了正確的認知才能更好的去推動它的發(fā)展，也只有明白了它們的特點才能更好的運用。
接口層
接口層是現(xiàn)在在企業(yè)中應(yīng)用最為廣泛的自動化測試方法之一，它的優(yōu)點在于基本規(guī)避了UI層自動化測試的缺點，并且一旦形成較為穩(wěn)定、完整的框架后基本上是比較通用的，不論是在Web端還是移動端都可以使用。但缺點也很明顯，就是對測試工程師的編碼能力要求較高，這也是很多測試工程師止步于此的重要原因。
對于接口層自動化測試是我個人比較推薦，也是建議大家有能力多去學(xué)習(xí)一下的，對于自身測試技術(shù)的提升還是有明顯幫助的。一般接口層自動化測試都會用Python、Ruby等語言開發(fā)，比如，某租車公司的接口測試框架是用Ruby開發(fā)的，我們之前的接口測試框架是用Python開發(fā)的，這里大家不必糾結(jié)用什么語言開發(fā)，每個語言在編程思想上是通用的，只是在語法上稍有不同而已，基本上你熟悉了一門語言后學(xué)其他的語言都會非?？?。多說無益，只有做過的朋友才能體會它的好。后面的章節(jié)中也會給大家講解一些輕量級框架的設(shè)計與實現(xiàn)。
單元層
單元層的自動化測試對測試工程師的編碼能力要求較高，且要能看懂業(yè)務(wù)的實現(xiàn)代碼，這樣才能針對被測代碼編寫單元測試代碼，一般都是引入XUnit、TestNG等框架來完成。為什么大部分公司在這個層級也無法很好的推行呢？原因在1.2節(jié)性能測試分層模型中已討論過，此處不再講述。
其實，自動化測試的難點在于框架的設(shè)計，并不在于寫代碼?？蚣艿脑O(shè)計需要統(tǒng)籌全局，就好像一個指揮官。而最后來實現(xiàn)框架你招幾個有代碼能力的人怎么都可以實現(xiàn)。在小強自動化測試班中我也能深刻地感受到，很多學(xué)員在學(xué)寫代碼的時候表現(xiàn)還不錯，但在最終設(shè)計框架的時候毫無頭緒，或者說是沒有框架設(shè)計的思想，導(dǎo)致大腦一直空白，如果是這樣那你學(xué)的再好都沒有用，因為你學(xué)的用不上，只有當(dāng)你具備總體框架設(shè)計的思維能力，才能利用所學(xué)的語言去實現(xiàn)，過程中無非就是在實現(xiàn)的過程中遇到問題了查查資料而已，至少你能邁出這最重要的一步了?？梢姡袝r候思想是多么關(guān)鍵??！
初學(xué)者如何選擇學(xué)習(xí)哪種技術(shù)
這個話題有點沉重，因為一旦表述不好肯定會被一些無良的人罵之，但思前想后還是決定寫這一章節(jié)。因為我被太多的朋友問過這個問題了，大概統(tǒng)計了一下，基本每兩天就會被問到一次，有時候一天還會被問到N次，我回答的都要吐血了，為此還在《挨踢脫口秀》中專門做了一期節(jié)目，可見這個話題的必要性了，也希望能幫助有選擇糾結(jié)癥的朋友。
下面我盡量客觀的以我自己的學(xué)習(xí)經(jīng)歷來聊聊，也許這個經(jīng)歷不是最好的，甚至是錯的，但可以給大家一些參考，少走一些彎路，我覺得就是有價值的。
首先，我們說說學(xué)習(xí)性能測試需要面臨的幾個挑戰(zhàn)，大家可以結(jié)合自己的實際情況看看自己是否適合繼續(xù)學(xué)習(xí)。
第一，龐大的知識體系，這個是我們面臨的第一個挑戰(zhàn)。性能測試是一項復(fù)雜且需要耐心的工作，我們需要在復(fù)雜的系統(tǒng)中“抽絲剝繭”，一層層分析從而確定性能問題。這個過程會涉及中間件、Web服務(wù)器、緩存、數(shù)據(jù)庫、代碼等知識，所以沒有一個較為完整的知識體系就很難進行下去。雖然說是挑戰(zhàn)，但在我看來卻是大部分小白朋友最佳的入門途徑，因為它能幫助我們快速建立較為完善的知識體系，對于我們而言有百利而無一害。不知你是否遇到過這樣的場景，被指著鼻子說：連一個SQL語句都不會寫，連中間件是什么都不知道你還和我們討論什么。這樣的“羞辱”雖然讓我們不開心，但也直白地指出了現(xiàn)在很多測試工程師在整體知識體系方面的欠缺，只有把自己的短板補起來才有底氣和實力去爭取更美好的事物。
第二，較強的分析能力，這個是我們面臨的第二個挑戰(zhàn)。就好像動畫片《柯南》，在復(fù)雜的犯罪現(xiàn)場破案，需要不斷的推斷和論證，這個過程中有可能會把之前確定的事情推翻了，也有可能好幾天都沒有進展，但這也是它的魅力，可以說是痛并快樂的。
在我接觸過很多學(xué)員之后，我發(fā)現(xiàn)大家一個共性的問題就是邏輯分析能力較差，在分析的過程中經(jīng)常是東一點西一點，完全沒有邏輯可言，都是亂猜，并且經(jīng)常容易掉入細節(jié)，一旦掉入無法自拔，導(dǎo)致停滯不前，這也就是為什么很多人覺得性能測試難的原因。在我看來，性能測試的分析過程就像剝洋蔥，你需要一層層剝開才能看到問題所在，這個過程就需要你有較強的邏輯分析能力，同時也要具有宏觀性，只有站在一定的高度去看待問題才能豁然開朗，不然就會陷入死胡同。一旦這個思維能力培養(yǎng)好了，就會事半功倍，學(xué)習(xí)其他技術(shù)時效率也會提高，所以萬事都需付出才能有收獲。
其次，我們再來說說學(xué)習(xí)自動化測試需要面臨的幾個挑戰(zhàn)。
第一，編碼能力，這個是逾越不過的坎兒。說到這里可能會有朋友問難道性能測試不需要編碼能力嗎？答案是需要，但比起自動化測試來說門檻相對低點。其實對于一個優(yōu)秀的測試工程師來說編碼能力是必備的技能。
如何提升自己的編碼能力也是不少朋友咨詢過我的問題，真心沒有什么捷徑。我覺得就是要多練習(xí)多總結(jié)，我說的練習(xí)是真正的動手去做而不是看。我?guī)н^的學(xué)員中其實大部分同學(xué)都存在一個問題，就是上課講的時候聽起來感覺很簡單，不以為然，但當(dāng)自己下課后練習(xí)時卻出現(xiàn)各種問題，很簡單的知識點能搞一天，所以一定要多練習(xí)，每次犯過的錯誤也都要及時總結(jié)，不能讓自己在同一個地方跌倒兩次。我再苦口婆心一句：“沒有不起眼的磚，沒有看不到的框架，漂亮的樓房怎么能屹立不倒”。
第二，邏輯思維能力。在有了編碼能力之后就能做自動化測試了嗎？顯然不能，因為自動化測試最終是希望建立一個框架或者平臺，這是一個大工程，一定要有較強的邏輯思維能力和設(shè)計能力才行。就好比，你會焊接技術(shù)但不代表你會設(shè)計汽車啊。所以自動化測試真正的難點在于設(shè)計思想，一點經(jīng)驗都沒有的朋友做起來確實會比較吃力，這也就是為什么我個人建議可以先學(xué)習(xí)性能測試，培養(yǎng)能力和思維之后再學(xué)自動化測試的原因了。
說了這么多，我想大家應(yīng)該心中已經(jīng)有了答案，再次聲明，這些只是我個人的看法，不見得對，僅供參考而已，不喜勿噴。
重慶分公司
重慶分公司
