什么測試自動化測試？

　　做測試好幾年了，真正學習和實踐自動化測試一年，自我感覺這一個年中收獲許多。一直想動筆寫一篇文章分享自動化測試實踐中的一些經(jīng)驗。終于決定花點時間來做這件事兒。

　　首先理清自動化測試的概念，廣義上來講，自動化包括一切通過工具（程序）的方式來代替或輔助手工測試的行為都可以看做自動化，包括性能測試工具（loadrunner、jmeter）,或自己所寫的一段程序，用于生成1到100個測試數(shù)據(jù)。狹義上來講，通工具記錄或編寫腳本的方式模擬手工測試的過程，通過回放或運行腳本來執(zhí)行測試用例，從而代替人工對系統(tǒng)的功能進行驗證。

　　當然，我們更普遍的認識把“自動化測試”看做“?基于產(chǎn)品或項目UI層的自動化測試”。

分層的自動化測試

　　這個概念最近曝光度比較高，傳統(tǒng)的自動化測試更關注的產(chǎn)品UI層的自動化測試，而分層的自動化測試倡導產(chǎn)品的不同階段（層次）都需要自動化測試。

　　相信測試同學對上面的金字塔并不陌生，這不就是對產(chǎn)品開發(fā)不同階段所對應的測試么！我們需要規(guī)范的來做單元測試同樣需要相應的單元測試框架，如java的Junit、testNG，C#的NUnit?，python?的unittest、pytest?等，幾乎所有的主流語言，都會有其對應的單元測試框架。

　　集成、接口測試對于不少測試新手來說不太容易理解，單元測試關注代碼的實現(xiàn)邏輯，例如一個if?分支或一個for循環(huán)的實現(xiàn)；那么集成、接口測試關注的一是個函數(shù)、類（方法）所提供的接口是否可靠。例如，我定義一個add()函數(shù)用于計算兩個參數(shù)的結果并返回，那么我需要調(diào)用add()并傳參，并比較返回值是否兩個參數(shù)相加。當然，接口測試也可以是url的形式進行傳遞。例如，我們通過get方式向服務器發(fā)送請求，那么我們發(fā)送的內(nèi)容做為URL的一部分傳遞到服務器端。但比如?Web?service?技術對外提供的一個公共接口，需要通過soapUI?等工具對其進行測試。?

　　UI層的自動化測試，這個大家應該再熟悉不過了，大部分測試人員的大部分工作都是對UI層的功能進行測試。UI測試就是最簡單的在頁面上面的點點點測試，也是最簡單的黑盒手工測試！但是UI自動化就很難了，因為在錄制的腳本在回放的時候很多都不能用，所以必須自己寫腳本！但是又不能缺少錄制腳本，因為一開始我們只有通過錄制腳本才能熟悉被測產(chǎn)品UI自動化腳本是怎樣寫的！例如，我們不斷重復的對一個表單提交，結果查詢等功能進行測試，我們可以通過相應的自動化測試工具來模擬這些操作，從而解放重復的勞動。UI層的自動化測試工具非常多，比較主流的是QTP，Robot?Framework、watir、selenium?等。

　　為什么要畫成一個金字塔形，則不是長方形?或倒三角形呢？?這是為了表示不同階段所投入自動化測試的比例。如果一個產(chǎn)品從沒有做單元測試與接口測試，只做UI層的自動化測試是不科學的，從而很難從本質(zhì)上保證產(chǎn)品的質(zhì)量。如果你妄圖實現(xiàn)全面的UI層的自動化測試，那更是一個勞民傷財?shù)呐e動，投入了大量人力時間，最終獲得的收益可能會遠遠低于所支付的成本。因為越往上層，其維護成本越高。尤其是UI層的元素會時常的發(fā)生改變。所以，我們應該把更多的自動化測試放在單元測試與接口測試階段進行。

　　既然UI層的自動化測試這么勞民傷財，那我們只做單元測試與接口測試好了。NO!?因為不管什么樣的產(chǎn)品，最終呈現(xiàn)給用戶的是UI層。所以，測試人員應該更多的精力放在UI層。那么也正是因為測試人員在UI層投入大量的精力，所以，我們有必要通過自動化的方式幫助我們“部分解放”重復的勞動。

　　在自動化測試中最怕的是變化，因為變化的直接結果就是導致測試用例的運行失敗，那么就需要對自動化腳本進行維護；如何控制失敗，降低維護成本對自化的成敗至關重要。反過來講，一份永遠都運行成功的自動化測試用例是沒有價值。?

　　至于在金字塔中三種測試的比例要根據(jù)實際的項目需求來劃分。在《google?測試之道》一書，對于google產(chǎn)品，70%的投入為單元測試，20%為集成、接口測試，10%?為UI層的自動化測試。

我為什么要做自動化測試？

　　根據(jù)51testing的《中國軟件測試從業(yè)人員調(diào)查報告》，手工測試占到的89%?，相對開發(fā)來說，測試的門檻底，薪資普遍較底，所要求的知識面雖然有一定廣度，但缺乏深度。這是測試的普遍現(xiàn)狀。

　　正因為手功測試人門檻不高，使大量的畢業(yè)生，甚至是非專業(yè)人員涌入這個行業(yè)。從而增加了這個行業(yè)的激烈競爭。對于工作幾年扔處于手工測試的人員來說都會有強列的危機感。由于工作的技術含量不高，薪資的漲幅遇到瓶頸，另一方面受到新進入者的威脅，同樣的工作公司花5K招來的人就可以做，那么就不會花8K?的招。

　　好吧，這個問題不應該出現(xiàn)討論技術的話題中，但他的確是大多測試人員不得不面對的一個問題。所以，從測試人員自身的發(fā)展來說，我其實非常需要通過自動化技術來增加自己有競爭力。當然，做到一定年限測試人員會選擇轉管理或其它崗位，這又是另一個話題了。

　　從測試行業(yè)的發(fā)展來說，國內(nèi)產(chǎn)品由于產(chǎn)品特點，世界級的產(chǎn)品不多，技術含量相對不高，質(zhì)量要求相對要求不高，外包國外項目，測試人力成本低廉，所以需要大量的手工測試人員。

　　所以，在不遠的未來，我認為純的工手測試人員的需求是遞減，公司更需要更高技術能力的測試。質(zhì)量需要測試，測試行為永遠不會消失，但純的手工測試人員是否消失是有可能的。

　　好吧，你可以說測試多朝陽的行業(yè)，我純屬在危言聳聽。不管未來如何，我們都需要提升自身的技能對吧！

什么項目適合做自動化測試？

　　假如你已經(jīng)決定要學習自動化測試了，如何學習是要面臨的下一個問題？這個問題以被測試產(chǎn)品為出發(fā)點進行分析，假如你所學的技術不能得到應用（驗證），將會使你的學習過程寸步難行。

　　首先考考慮產(chǎn)品是否適合做自動化測試。這方法比較普遍的共識是從三個方面進行權衡。

　　軟件需求變動不頻繁

　　測試腳本的穩(wěn)定性決定了自動化測試的維護成本。如果軟件需求變動過于頻繁，測試人員需要根據(jù)變動的需求來更新測試用例以及相關的測試腳本，而腳本的維護本身就是一個代碼開發(fā)的過程，需要修改、調(diào)試，必要的時候還要修改自動化測試的框架，如果所花費的成本不低于利用其節(jié)省的測試成本，那么自動化測試便是失敗的。

　　項目中的某些模塊相對穩(wěn)定，而某些模塊需求變動性很大。我們便可對相對穩(wěn)定的模塊進行自動化測試，而變動較大的仍是用手工測試。

　　項目周期較長

由于自動化測試需求的確定、自動化測試框架的設計、測試腳本的編寫與調(diào)試均需要相當長的時間來完成。這樣的過程本身就是一個測試軟件的開發(fā)過程，需要較長的時間來完成。如果項目的周期比較短，沒有足夠的時間去支持這樣一個過程，那么自動化測試便成為笑談。

　　自動化測試腳本可重復使用

　　自動化測試腳本的重復使用要從三個方面來考量，一方面所測試的項目之間是否很大的差異性（如C/S系統(tǒng)和B/S系統(tǒng)的差異）；所選擇的測試工具是否適應這種差異；最后，測試人員是否有能力開發(fā)出適應這種差異的自動化測試框架。

選擇什么工具進行自動化測試

　　假如你已經(jīng)確認了XX?項目適合做自動化測試，那么接下來你要做的就是選測試工具了。

　　首先要先確認你所測試的產(chǎn)品是桌面程序（C/S）還是web應用（B/S）。

　　桌面程序的工具有：QTP、?AutoRunner

　　web應用的工具有：QTP、AutoRunner、Robot?Framework、watir、selenium

　　由于B/S架構的諸多優(yōu)勢，早幾年前大量C/S架構的應用轉為B/S結構。從而也推動了web開發(fā)與測試技術的發(fā)展。假如，被測試有產(chǎn)品是C/S架構的，那么推薦QTP?，QTP在UI自動化測試領域占到了一半的試用率。所以，足以說明QTP在自動化領域強大，易用性等。學習主流的工具也可以使你獲得更多的機會。市面上關于QTP的書籍也非常豐富。當然，要想學好QTP?，你必須要掌握VBS腳本語言。

　　如果，被測產(chǎn)品是B/S?結構，那么推薦selenium?，為什么不是QTP?或其它工具？因為selenium?對B/S應用支持很好，更重要的一點，它支持多語言的開發(fā)，真正的試用selenium?，你所要掌握的不僅僅是一個工具而已，你還需要學習一門語言。我為什么要選擇selenium？還要學一門語言，這無疑增加了我的學習成本。增加成本的同時，也增加的你的競爭力，而且，在這個過程中你不單單只是學會了一個自動化工具而已，你完全可以使用所學的語言去做更多的事情。

　　好吧！假如你決定試用selenium?了之后，你又面臨了一個新的問題，選擇一門語言。selenium?是支持java、python、ruby、php、C#、JavaScript?。

　　從語言易學性來講，首選ruby?，python

　　從語言應用廣度來講，首選java、C#、php、

　　從語言相關測試技術成度（及?資料）來講：ruby?,python?,java

　　或者你可以考慮整個技術團隊主流用什么語言，然后選擇相應的語言。

selenium?用前須知

　　OK！經(jīng)過上的過程，我相信你一定做出的相應的選擇，如果你選擇的是selenium?工具，那么接著往下閱讀。

首選你在開始selenium之前，需要花一到兩個月時間去學一門語言，這里是根據(jù)沒有語言基礎的同學而定的。我推薦ruby?,python?,java?任意一門語言來進行學習。

　　當然，已經(jīng)如果有很好的語言基礎略過這個環(huán)節(jié)，或者你的豐富的java編程能力，那么學習python?可能只需要幾天時間或更短。

　　假如，你已經(jīng)搞定了一門語言的基礎，接下來你需要先了解selenium?，selenium?并不是單純的一個工具，他是一組工具的集合，而且，他還有1.0與2.0之分，當然3.0也已經(jīng)到來。

　　selenium?也不是簡單一個工具，而是由幾個工具組成，每個工具都有其特點和應用場景。

selenium?IDE

　　selenium?IDE?是嵌入到Firefox瀏覽器中的一個插件，實現(xiàn)簡單的瀏覽器操作的錄制與回放功能。那么什么情況下用到它呢？

　　快速的創(chuàng)建bug重現(xiàn)腳本，在測試人員的測試過程中，發(fā)現(xiàn)了bug之后可以通過IDE將重現(xiàn)的步驟錄制下來，以幫助開發(fā)人員更容易的重現(xiàn)bug。

　　IDE錄制的腳本可以可以轉換成多種語言，從而幫助我們快速的開發(fā)腳本，關于這個功能后而用到時再詳細介紹。

selenium?Grid

　　Selenium?Grid是一種自動化的測試輔助工具，Grid通過利用現(xiàn)有的計算機基礎設施，能加快Web-app的功能測試。利用Grid，可以很方便地同時在多臺機器上和異構環(huán)境中并行運行多個測試事例。其特點為：

·?并行執(zhí)行

·?通過一個主機統(tǒng)一控制用例在不同環(huán)境、不同瀏覽器下運行。

·?靈活添加變動測試機

selenium?RC

　　selenium?RC?是selenium?家族的核心工具，selenium?RC?支持多種不同的語言編寫自動化測試腳本，通過selenium?RC?的服務器作為代理服務器去訪問應用從而達到測試的目的。

　　selenium?RC?使用分Client?Libraries和selenium?Server，Client?Libraries庫主要主要用于編寫測試腳本，用來控制selenium?Server的庫。

　　Selenium?Server負責控制瀏覽器行為，總的來說，Selenium?Server主要包括3個部分：Launcher、Http?Proxy、Core。其中Selenium?Core是被Selenium?Server嵌入到瀏覽器頁面中的。其實Selenium?Core就是一堆JS函數(shù)的集合，就是通過這些JS函數(shù)，我們才可以實現(xiàn)用程序對瀏覽器進行操作。Launcher用于啟動瀏覽器，把selnium?Core加載到瀏覽器頁面當中，并把瀏覽器的代理設置為Selenium?Server?的Http?Proxy。

selenium?2.0

　　搞清了selenium?1.0?的家族關系，selenium?2.0?是把WebDriver?加入到了這個家族中；簡單用公式表示為：

　　selenium?2.0?=?selenium?1.0?+?WebDriver?

　　需要強調(diào)的是，在selenium?2.0?中主推的是WebDriver?，WebDriver?是selenium?RC?的替代品，因為?selenium?為了向下兼容性，所以selenium?RC?并沒有徹底拋棄，如果你使用selenium開發(fā)一個新自動化測試項目，強列推薦使用WebDriver?。那么selenium?RC?與webdriver?主要有什么區(qū)別呢？

　　selenium?RC?在瀏覽器中運行JavaScript應用，使用瀏覽器內(nèi)置的JavaScript?翻譯器來翻譯和執(zhí)行selenese命令（selenese?是selenium命令集合）。

　　WebDriver通過原生瀏覽器支持或者瀏覽器擴展直接控制瀏覽器。WebDriver針對各個瀏覽器而開發(fā)，取代了嵌入到被測Web應用中的JavaScript。與瀏覽器的緊密集成支持創(chuàng)建更高級的測試，避免了JavaScript安全模型導致的限制。除了來自瀏覽器廠商的支持，WebDriver還利用操作系統(tǒng)級的調(diào)用模擬用戶輸入。

　　如果是新項目直接學習webdriver?就OK了，RC是過時技術。

selenium學習路線

　　配置你的測試環(huán)境，真對你所學習語言，來配置你相應的selenium?測試環(huán)境。selenium?好比定義的語義---“問好”，假如你使用的是中文，為了表術問好，你的寫法是“你好”，假如你使用的是英語，你的寫法是“hello”。?所以，同樣有語義在不同的語言下會有不同的寫法（語法）。

?　　接著你需要熟悉webdriver?API?，API就是selenium?所定義一方法，用于定位，操作頁面上的各種元素。

　　先學習元素的定位，selenium?提供了id、name、class?name、?tag?name、link?text、partial?link?text、?xpath、css、等定位方法。xpath和css?功能強大語法稍微復雜，在這其間你可能還需要了解更多的前端知識。xml?,javascript?等。

　　定位元素的目的是為了操作元素，接就要學習各種元素有操作，輸入框，下拉框，按鈕點擊，文件上傳、下載，分頁，對話框，警告框...等等。

　　經(jīng)過一段時間的學習，你可以游刃有余的模擬手工測試來操作頁面上的各種元素了。接著你需要做的就是把這些“用例”組織起來，統(tǒng)一來跑。

　　那么你需要做的就是學習并使用單元測試框架，單元測試框架本身就解決了用例的組織與運行。

　　當你寫了一些“測試用例”?之后，你會發(fā)現(xiàn)用例中有大量重復的操作，能不能寫到一個單獨的文件中，需要的時候調(diào)用這些操作？當然可以，運用你的編程能力來實現(xiàn)這一點將非常簡單。然后，你又發(fā)現(xiàn)每個用例中都有一些數(shù)據(jù)，這些數(shù)據(jù)也是一樣的，但如果變化了修改起來非常麻煩，你也可以把他寫到一個單獨的文件中進行讀取。

　　接著你又遇到了新的疑問，我寫的腳本（用例）都是流水式的，我怎么知道用例運行失敗還是成功。那么就需要在腳本中加一些驗證與斷言。

　　接著你又有了更多的想法，單元測試框架的log太簡陋了，能不能生成一張漂亮的測試報告出來。我能不能定時的來跑這個腳本。能不能把每一次跑腳本的測試結果直接發(fā)到我的郵箱。能不能......

　　為解決這些問題，你不得不學習更多的編程技術，然后你的“測試結構”會功能越來越強大，越來越靈活。產(chǎn)生了一定的通用性和移植性。一個有模有樣的自動化測試框架誕生了。

?　　假如，有一天你不再做UI的自動化測試了，你會發(fā)現(xiàn)你去做單元測試?或接口測試基本沒什么難度。開發(fā)個測試工具之類的也不在話下，感謝selenium?吧！順便也感謝一下我吧！