作自動化測試以前須要瞭解的

首先理清自動化測試的概念，什麼是自動化測試？

廣義上來說，自動化包括一切經過工具(程序）的方式來代替或輔助手工測試的行爲均可以看作是自動化，包括性能測試工具（Loadrunner、Jmeter）,或本身所寫的一段程序，用於生成1到100個測試數據。

狹義上來說，經過工具記錄或編寫腳本的方式模擬手工測試的流程，經過回放或運行腳原本執行測試用例，從而代替人工對系統的功能進行驗證。

通常咱們廣泛認識把「自動化測試」看作「基於產品或項目UI層的自動化測試」。

分層的自動化測試：這個概念最近曝光度比較高，傳統的自動化測試更關注產品UI層的自動化測試，而分層的自動化測試倡導產品的不一樣階段（層次）都須要自動化測試。

不少人會認爲這個不就是產品開發不一樣階段所對應的測試麼！但咱們須要規範來作，單元測試一樣須要相應的單元測試框架，如java的Junit、testNG ；C#的Nunit ；Python的Unittest 、pytest等，幾乎全部的主流語言都會有其對應的單元測試框架。

集成、接口測試對於很多測試新手來講不太容易理解，單元測試關注代碼的實現邏輯，例如一個if分支或一個for循環的實現，那麼集成、接口測試關注的是一個函數、類（方法）所提供的接口是否可靠，例如我定義一個add（）函數用於計算兩個參數的結果並返回，那麼我須要調用add（)並傳參，並比較返回值是否兩個參數相加。固然，接口測試也能夠是url的形式進行傳遞。例如，咱們經過get方式向服務器發送請求，那麼咱們發送的內容作爲URL的一部分傳遞到服務器端。但好比WEB service 技術對外提供的一個公共接口，須要經過soapUI等工具對其進行測試。

UI層的自動化測試，大部分測試人員的大部分工做都是對UI層的功能進行測試，例如，咱們不斷重複的對一個表單提交，結果查詢等功能進行測試，咱們能夠經過相應的自動化測試工具來模擬這些操做，從而解放重複的勞動。UI層的自動化測試工具特別多，比較主流的是QTP、 Robot Framework 、watir 、selenium等。

爲何要畫成一個金字塔形，不是長方形或者金字塔形呢？這是爲了表示不一樣階段所投入自動化測試的比例。若是一個產品從沒有作單元測試與接口測試，只作UI層的自動化測試是不科學的，從而很難從本質上保證產品的質量，若是妄圖實現全面的UI層的自動化測試，那更是一個勞民傷財的舉動，投入了大量的人力時間，最終得到的收益可能會遠遠低於所支付的成本。由於越往上層，維護成本越高。尤爲是UI層的元素會時常發生改變。因此，咱們應該把更多的自動化測試放在單元測試與接口測試階段進行。

既然UI層的自動化測試這麼勞民傷財，那咱們只作單元測試與接口測試就行了，NO！由於無論什麼樣的產品，最終呈現給客戶的是UI層。因此，測試人員應該更多的精力放在UI層，有必要經過自動化的方式部分解放「重複的勞動」。

在自動化測試中，最怕的就是變更，由於變更的直接結果就是致使測試用例執行的失敗，那麼就須要對自動化腳本進行維護，如何控制失敗，下降維護成本對自動化的成敗相當重要，反過來說，一份永遠都運行成功的自動化測試用例是沒有價值的。

至於在金字塔中三種測試的比例要根據實際的項目需求來劃分，在《Google測試之道》一書，對於Google產品，70%投入爲單元測試，20%爲集成、接口測試，10%爲UI層的自動化測試。

爲何要學習自動化測試？

從測試人員自身的發展來講，其實很是須要經過自動化測試技術來增長本身的競爭力。

從測試行業發展來講，國內產品因爲產品特色，世界級的產品很少，技術含量相對不高，質量要求相對不高，外包國外項目，測試人力成本低廉，因此須要大量的手工測試人員。

也許不久的獎勵，手工測試會消失。

什麼項目適合作自動化測試？

軟件需求變更不頻繁

測試腳本的穩定性決定了自動化測試的維護成本。若是軟件需求變更過於頻繁，測試人員須要根據變更的需求來更新測試用例以及相關的測試腳本，而腳本的維護自己就是一個代碼開發的過程，須要修改、調試。必要的時候還要修改自動化測試框架，因此所花費的成本不能低於利用其節省的測試成本，那麼自動化測試是失敗的。

項目中的某些模塊相對穩定，而某些模塊需求的變更性很大，咱們即可對相對穩定的模塊進行自動化測試，而變更較大的仍是用手工測試。

項目週期較長

因爲自動化測試需求的肯定、自動化測試的框架設計、測試腳本的編寫與調試均須要至關長的時間來完成。若是項目的週期比較短，沒有足夠的時間去支持這樣的一個過程，那麼自動化測試是不可行的。

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

自動化測試腳本的重複要從三個方面來考量，一方面所測試的項目之間是否很大的差別性（如C/S、B/S系統的差別性），所選擇的測試工具是否適應這種差別性，最後，測試人員是否有能力開發適應這種差別的自動化測試框架。

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

首先要先確認所測試的產品是桌面程序（C/S）仍是WEB應用（B/S）。

桌面程序的工具備：QTP、Autorunner；

WEB應用的工具備：QTP、Autorunner、Robot Framework、watir、selenium

因爲B/S架構的諸多優點，早幾年前大量C/S架構的應用轉爲B/S架構，從而也推進了WEB開發與測試技術的發展。

假如，被測試產品是C/S架構的，那麼推薦QTP，QTP在UI自動化測試領域佔到了一半的試用率。因此，足以說明QTP在自動化領域強大、易用性等。要想學好QTP，必需要掌握VBS腳本語言。

若是，被測產品是B/S架構，那麼推薦selenium，爲何不是QTP或其餘工具？由於selenium對B/S應用支持很好，更重要的一點，它支持多語言開發，同時學習一門變成語言是最好的。

selenium 是支持Java 、Python、Ruby 、Php、C#、JavaScript。

從語言易學性來說，首選Ruby、Python；

從語言應用廣度來說，首選Java 、Php、C#；

從語言相關測試技術程度來說：Java 、Python、Ruby 。

selemiun 用前須知：

在開始selenium以前，須要花一到兩個月的時間去學習一門語言，Java 、Python、Ruby 任意一門。

學好語言以後，就要先了解selenium ，selenium並非單純的一個工具，它是一組工具的集合，每一個工具都有其特色和應用，有1.0、2.0、3.0的區分。

selenium IDE 

selenium IDE 是嵌入到Firefox瀏覽器中的一個插件，實現簡單的瀏覽器操做的錄製與回放功能，那麼什麼狀況下用到它呢？

快速的建立Bug重現腳本，在測試人員的測試過程當中，發現了Bug以後能夠經過IDE將重現的步驟錄製下來，以幫助開發人員更容易的重現Bug。

IDE錄製的腳本能夠轉換成多種語言，從而幫助咱們快速的開發腳本。

selenium Gird 

selenium Gird 是一種自動化的測試輔助工具，Gird經過利用現有的計算機基礎設施，能加快WEB-APP的功能測試，利用Gird ，能夠很方便的同時在多臺計算器上和異構環境中並行運行多個測試用例。其特色爲：

並行執行

經過一個主機統一控制用例在不一樣環境、不一樣瀏覽器下運行。

靈活添加變更測試機

selenium RC

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

selenium RC使用分Client Libraries 和 selenium server , Client Libraries庫主要用於編寫測試腳本，用來控制selenium server 的庫。

selenium server負責控制瀏覽器行爲，主要包括三個部分，Launcher 、 Http Proxy 、Core 。其中selenium core 是被 selenium server 嵌入到瀏覽器頁面中的，其實selenium core 就是一堆JS函數的集合 ，就是經過這些JS函數，咱們才能夠實現用程序對瀏覽器進行操做，Launcher用於啓動瀏覽器，把selenium core 加載到瀏覽器頁面當中，並把瀏覽器的代理設置爲selenium server 的 Http Proxy 。

selenium 2.0 

selenium 2.0 是把Webdriver加入 ，簡單用公式表示爲：

selenium 2.0=selenium 1.0 + Webdriver 

須要強調的是，selenium 2.0 主推Webdriver ，Webdriver是selenium RC的替代品，由於，selenium爲了向下兼容性，因此selenium RC並無完全拋棄，若是你使用selenium 開發一個新的自動化測試項目，強烈推薦使用Webdriver ，那麼selenium RC與Webdriver有什麼區別呢？ 

selenium RC在瀏覽器中運行JavaScript應用，使用瀏覽器內置的JavaScript翻譯器來翻譯和執行selenese命令，（selenese是selenium命令集合）。

Webdriver經過原生瀏覽器支持或者瀏覽器擴展直接控制瀏覽器，Webdriver針對各個瀏覽器開發，取代了嵌入到被測Web應用中的JavaScript，與瀏覽器的緊密集成支持建立更高級的測試，避免了JavaScript安全模型致使大限制，除了來自瀏覽器廠商的支持，Webdriver還利用操做系統級的調用模擬用戶輸入。

若是是新項目直接學習Webdriver就能夠了 ，RC是過期技術。

selenium 學習路線

配置測試環境，針對所學語言配置相應的selenium 的測試環境。

而後熟悉Webdriver API ，API就是selenium 所定義一方法 ，用於定位 ，操做頁面上的各類元素。

先學習元素的定位，selenium提供了id 、name、class name 、tag name 、link text 、partial link text、xpath 、css 等定位方法 。xpath和css功能強大且語法稍微複雜，因此還須要瞭解更多的前端知識，xml 、 javascript 等。

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

通過一段時間的學習，能夠遊刃有餘的模擬手工測試來操做頁面上的各類元素了，而後把這些用例組織起來，統一來跑。

須要學習並使用單元測試框架，單元測試框架自己就解決了用例的組織與運行。

當寫了一些測試用例後，發現測試用例中有大量的重複操做，能不能單獨寫到一個文件當中，須要的時候調用這些操做，因此運用編程能力實現這點跟簡單。

而後發現每一個測試用例中都有一些數據，這些數據也是同樣的，但若是變化了修改起來很麻煩，能夠把它寫到一個單獨的文件去讀取。

而後又發現腳本測試用例都是流水式的，怎麼知道用例運行是失敗仍是成功呢？那麼就須要在腳本中加一些驗證與斷言。

而後就會發現單元測試框架的Log太簡陋了，能不能生成一張漂亮的測試報告出來？能不能定時的跑一下這個腳本？能不能把每次跑腳本的結果能不能直接發到郵箱等等新的想法。。。

爲了解決這些問題，不得不學習更多的編程技術，而後測試結構的功能會愈來愈強大，愈來愈靈活，產生了必定的通用性和移植性，最後一個有模有樣的自動化測試框架就這麼的誕生了。

深刻學習就會發現本身的知識是不足的，咱們就要不斷的去學習，正所謂「活到老、學到老」嘛！