什麼是自動化測？
做測試好幾年了，真正學習和實踐自動化測試一年，自我感覺這一個年中收獲許多。一直想動筆寫一篇文章分享自動化測試實踐中的一些經驗。終于決定花點時間來做這件事兒。
首先理清自動化測試的概念，廣義上來講，自動化包括一切通過工具（程式）的方式來代替或輔助手工測試的行為都可以看做自動化，包括性能測試工具（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層。那麼也正是因為測試人員在UI層投入大量的精力，是以，我們有必要通過自動化的方式幫助我們“部分解放”重複的勞動。
在自動化測試中最怕的是變化，因為變化的直接結果就是導緻測試用例的運作失敗，那麼就需要對自動化腳本進行維護；如何控制失敗，降低維護成本對自化的成敗至關重要。反過來講，一份永遠都運作成功的自動化測試用例是沒有價值。
至于在金字塔中三種測試的比例要根據實際的項目需求來劃分。在《google 測試之道》一書，對于google産品，70%的投入為單元測試，20%為內建、接口測試，10% 為UI層的自動化測試。
我為什麼要做自動化測試？
根據51testing的《中國軟體測試從業人員調查報告》，手工測試占到的89% ，相對開發來說，測試的門檻底，薪資普遍較底，所要求的知識面雖然有一定廣度，但缺乏深度。這是測試的普遍現狀。
正因為手功測試人門檻不高，使大量的畢業生，甚至是非專業人員湧入這個行業。進而增加了這個行業的激烈競争。對于工作幾年扔處于手工測試的人員來說都會有強列的危機感。由于工作的技術含量不高，薪資的漲幅遇到瓶頸，另一方面受到新進入者的威脅，同樣的工作公司花5K招來的人就可以做，那麼就不會花8K 的招。
好吧，這個問題不應該出現讨論技術的話題中，但他的确是大多測試人員不得不面對的一個問題。是以，從測試人員自身的發展來說，我其實非常需要通過自動化技術來增加自己有競争力。當然，做到一定年限測試人員會選擇轉管理或其它崗位，這又是另一個話題了。
從測試行業的發展來說，國内産品由于産品特點，世界級的産品不多，技術含量相對不高，品質要求相對要求不高，外包國外項目，測試人力成本低廉，是以需要大量的手工測試人員。
是以，在不遠的未來，我認為純的工手測試人員的需求是遞減，公司更需要更高技術能力的測試。品質需要測試，測試行為永遠不會消失，但純的手工測試人員是否消失是有可能的。
好吧，你可以說測試多朝陽的行業，我純屬在危言聳聽。不管未來如何，我們都需要提升自身的技能對吧！
什麼項目适合做自動化測試？
假如你已經決定要學習自動化測試了，如何學習是要面臨的下一個問題？這個問題以被測試産品為出發點進行分析，假如你所學的技術不能得到應用（驗證），将會使你的學習過程寸步難行。
首先考考慮産品是否适合做自動化測試。這方法比較普遍的共識是從三個方面進行權衡。
軟體需求變動不頻繁
測試腳本的穩定性決定了自動化測試的維護成本。如果軟體需求變動過于頻繁，測試人員需要根據變動的需求來更新測試用例以及相關的測試腳本，而腳本的維護本身就是一個代碼開發的過程，需要修改、調試，必要的時 候還要修改自動化測試的架構，如果所花費的成本不低于利用其節省的測試成本，那麼自動化測試便是失敗的。
項目中的某些子產品相對穩定，而某些子產品需求變動性很大。我們便可對相對穩定的子產品進行自動化測試，而變動較大的仍是用手工測試。
項目周期較長
由于自動化測試需求的确定、自動化測試架構的設計、測試腳本的編寫與調試均需要相當長的時間來完成。這樣的過程本身就是一個測試軟體的開發過程，需要較長的時間來完成。如果項目的周期比較短，沒有足夠的時間去支援這樣一個過程，那麼自動化測試便成為笑談。
自動化測試腳本可重複使用
自動化測試腳本的重複使用要從三個方面來考量，一方面所測試的項目之間是否很大的差異性（如C/S系統和B/S系統的差異）；所選擇的測試工具是否适應這種差異；最後，測試人員是否有能力開發出适應這種差異的自動化測試架構。
選擇什麼工具進行自動化測試
假如你已經确認了XX 項目适合做自動化測試，那麼接下來你要做的就是選測試工具了。
首先要先确認你所測試的産品是桌面程式（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的書籍也非常豐富。當然，要想學好QTP ，你必須要掌握VBS腳本語言。
如果，被測産品是B/S 結構，那麼推薦selenium ，為什麼不是QTP 或其它工具？因為selenium 對B/S應用支援很好，更重要的一點，它支援多語言的開發，真正的試用selenium ，你所要掌握的不僅僅是一個工具而已，你還需要學習一門語言。我為什麼要選擇selenium？還要學一門語言，這無疑增加了我的學習成本。增加成本的同時，也增加的你的競争力，而且，在這個過程中你不單單隻是學會了一個自動化工具而已，你完全可以使用所學的語言去做更多的事情。
好吧！假如你決定試用selenium 了之後，你又面臨了一個新的問題，選擇一門語言。selenium 是支援java、python、ruby、php、C#、JavaScript 。
從語言易學性來講，首選ruby ，python
從語言應用廣度來講，首選java、C#、php
從語言相關測試技術成度（及 資料）來講：ruby ,python ,java
或者你可以考慮整個技術團隊主流用什麼語言，然後選擇相應的語言。
selenium 用前須知
OK！經過上的過程，我相信你一定做出的相應的選擇，如果你選擇的是selenium 工具，那麼接着往下閱讀。
首選你在開始selenium之前，需要花一到兩個月時間去學一門語言，這裡是根據沒有語言基礎的同學而定的。我推薦ruby ,python ,java 任意一門語言來進行學習。
當然，已經如果有很好的語言基礎略過這個環節，或者你的豐富的java程式設計能力，那麼學習python 可能隻需要幾天時間或更短。
假如，你已經搞定了一門語言的基礎，接下來你需要先了解selenium ，selenium 并不是單純的一個工具，他是一組工具的集合，而且，他還有1.0與2.0之分，當然3.0也已經到來。
selenium 也不是簡單一個工具，而是由幾個工具組成，每個工具都有其特點和應用場景。
selenium IDE
selenium IDE 是嵌入到Firefox浏覽器中的一個插件，實作簡單的浏覽器操作的錄制與回放功能。那麼什麼情況下用到它呢？
快速的建立bug重制腳本，在測試人員的測試過程中，發現了bug之後可以通過IDE将重制的步驟錄制下來，以幫助開發人員更容易的重制bug。
IDE錄制的腳本可以可以轉換成多種語言，進而幫助我們快速的開發腳本，關于這個功能後而用到時再詳細介紹。
selenium Grid
Selenium Grid是一種自動化的測試輔助工具，Grid通過利用現有的計算機基礎設施，能加快Web-app的功能測試。利用Grid，可以很友善地同時在多台機器上和異構環境中并行運作多個測試事例。其特點為：
· 并行執行
· 通過一個主機統一控制用例在不同環境、不同浏覽器下運作。
· 靈活添加變動測試機
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函數的集合，就是通過這些JS函數，我們才可以實作用 程式對浏覽器進行操作。Launcher用于啟動浏覽器，把selnium Core加載到浏覽器頁面當中，并把浏覽器的代理設定為 Selenium Server 的Http Proxy。
selenium 2.0
搞清了selenium 1.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 就OK了，RC是過時技術。
selenium學習路線
配置你的測試環境，真對你所學習語言，來配置你相應的 selenium 測試環境。selenium 好比定義的語義—“問好”，假如你使用的是中文，為了表術問好，你的寫法是“你好”，假如你使用的是 英語，你的寫法是“hello”。 是以，同樣有語義在不同的語言下會有不同的寫法（文法）。
接着你需要熟悉webdriver API ，API就是selenium 所定義一方法，用于定位，操作頁面上的各種元素。
先學習元素的定位，selenium 提供了id、name、class name、 tag name、link text、partial link text、 xpath、css、等定位方法。xpath和css 功能強大文法稍微複雜，在這其間你可能還需要了解更多的前端知識。xml ,javascript 等。
定位元素的目的是為了操作元素，接就要學習各種元素有操作，輸入框，下拉框，按鈕點選，檔案上傳、下載下傳，分頁，對話框，警告框…等等。
經過一段時間的學習，你可以遊刃有餘的模拟手工測試來操作頁面上的各種元素了。接着你需要做的就是把這些“用例”組織起來，統一來跑。
那麼你需要做的就是學習并使用單元測試架構，單元測試架構本身就解決了用例的組織與運作。
當你寫了一些“測試用例” 之後，你會發現用例中有大量重複的操作，能不能寫到一個單獨的檔案中，需要的時候調用這些操作？當然可以，運用你的程式設計能力來實作這一點将非常簡單。然後，你又發現每個用例中都有一些資料，這些資料也是一樣的，但如果變化了修改起來非常麻煩，你也可以把他寫到一個單獨的檔案中進行讀取。
接着你又遇到了新的疑問，我寫的腳本（用例）都是流水式的，我怎麼知道用例運作失敗還是成功。那麼就需要在腳本中加一些驗證與斷言。
接着你又有了更多的想法，單元測試架構的log太簡陋了，能不能生成一張漂亮的測試報告出來。我能不能定時的來跑這個腳本。能不能把每一次跑腳本的測試結果直接發到我的郵箱。能不能…
為解決這些問題，你不得不學習更多的程式設計技術，然後你的“測試結構”會功能越來越強大，越來越靈活。産生了一定的通用性和移植性。一個有模有樣的自動化測試架構誕生了。
假如，有一天你不再做UI的自動化測試了，你會發現你去做單元測試或接口測試基本沒什麼難度。開發個測試工具之類的也不在話下，感謝selenium吧！順便也感謝一下我吧！
轉自： http://www.cnblogs.com/fnng/p/3653793.html