1、分層自動化測試概念
傳統的自動化市場更關注產品UI層的自動化測試，而分層的自動化測試倡導產品開發的不同階段都需要自動化測試
大多公司與研發團隊其實是忽略了單元測試與集成測試階段的自動化測試工作，所以，在分層的自動化測試中，我們有必要對這些定義重新理解和定義。
單元測試：我們需要規范的來做單元測試同樣需要相應的單元測試框架，如java的Junit、testNG，C#的NUint，Python的unittest、pytest等，幾乎所有的主流語言，都會有其對應的單元測試框架。
集成、接口測試：單元測試關注代碼的實現邏輯，例如一個if分支或一個for循環的實現，那么集成、接口測試關注的是一個函數、類（方法）所提供的接口是否可靠。例如我們定義一個add()函數用於計算兩個參數的結果並返回，那么我需要調用add()並傳參，並比較返回值是否是兩割參數相加。當然，接口測試也可以是url形式進行傳遞。例如，我們通過get方法想服務器發送請求，那么我們發送的內容作為URL的一部分傳遞到服務器端。但比如Web service技術對外提供的一個公共接口，需要通過soapUI等工具對其進行測試。
UI層的自動化測試：大部分測試人員的大部分工作都是對UI層的功能進行測試。例如，我們不斷重復的對一個表單提交，結果查詢等功能進行測試，我們可以通過相應的自動化測試工具來模擬這些操作，從而解放重復的勞動。UI層的自動化測試工具非常多，比如QTP、Robot Framework、waiter、Selenium等。
為什么分層自動化是一個金字塔形，而不是長方形或三角形？這是為了表示不同階段所投入自動化測試的比例。如果一個產品從來沒有做單元測試與接口測試，只做UI層的自動化測試是不科學的，很難從本質上保證產品的質量。如果妄圖實現全面的UI層的自動化測試，那更是一個勞民傷財的舉動，投入了大量的人力時間，最終獲得的收益可能會遠遠低於所支付的成本。因為越往上層，其維護成本越高。尤其是Ui層的元素會時常的發生改變。所以，我們應該把更多的自動化測試放在單元測試與接口測試階段進行。
2、什么樣的項目適合做自動化測試
並不是所有項目都適合實施自動化測試的，關於什么樣的項目適合做自動化測試，在這里，主要整理以下幾點
1）任務測試明確，不會頻繁變動
2）每日構建后的測試驗證
3）比較頻繁的回歸測試
4）軟件系統界面穩定，變動少
5）需要在多平台上運行的相同測試用例、組合遍歷型的測試、大量的重復任務
6）軟件維護周期長
7）項目進度壓力不太大
8）被測軟件系統開發比較規范，能夠保證系統的可測試性
9）具備大量的自動化測試平台
10）測試人員具備較強的編程能力
注意，並非以上10條都具備的情況下才能開展自動化測試，在業界大牛普遍的自動化測試經驗中，一半滿足以下三個條件就可以對項目開展自動化測試：
軟件需求變動不頻繁
項目周期較長
自動化測試腳本可重復使用
3、Selenium工具介紹
要做selenium自動化測試，首先要要了解什么是Selenium。
Selenium自動化測試工具，主要是用於web應用程序的自動化測試，但並不只局限於此，
它還支持所有給予web的管理任務自動化。
Selenium的特點：
·開源，免費
·支持多瀏覽器：FireFox、Chrome、IE、Opera
·支持多平台：Linux、Windows、MAC
·支持多語言：java、Python、Ruby、php、C#、JavaScript
·對web頁面有良好的支持
·簡單、靈活（API簡單，開發語言驅動靈活）
·支持分布式測試用例執行
Selenium經歷了三個版本，Selenium1.0和Selenium2.0,跟3.0，Selenium也不是簡單一個工具，而是有幾個工具組成，每個工具都有其特點和應用場景。
Selenium 1.0
用簡單的公式：
Selenium 1.0 = Selenium IDE + Selenium Grid + Selenium RC
Selenium IDE
Selenium IDE是嵌入到FireFox瀏覽器中的一個插件，實現簡單的瀏覽器操作的錄制與回放功能。
那么什么情況下用到它呢？
快速的創建bug 重現腳本，在測試人員的測試過程中，發現了bug 之后可以通過IDE 將重現的步驟錄制下來，以幫助開發人員更容易重現bug。
Selenium Grid
Selenium Grid是一種自動化的測試輔助工具，允許同時並行地、在不同的環境上運行多個測試任務，極大地加快Web應用的功能測試。其特點：
·並行執行
·通過一個主機統一控制用例在不同環境、不同瀏覽器下運行。
·靈活添加變動測試機
Selenium RC
Selenium RC（Remote Control）是Selenium家族的核心部分。Selenium RC支持多種不同語言編寫的自動化測試腳本，通過Selenium RC的服務器作為代理服務器去訪問應用，從而達到測試的目的。
Selenium RC分為Client Libraries和Selenium Server。Client Libraries庫主要用於編寫測試腳本，用來控制Selenium Server的庫。Selenium Server負責控制瀏覽器行為。
簡單的理解：
Selenium RC(API) <-> Selenium Server <-> 瀏覽器（FireFox、Chrome...）
在2006年的時候，Google的工程師Simon Stewart發起了WebDriver的項目；因為長期以來Google一直是Selenium的重度用戶，但卻被限制在有限的操作范圍內。
Selenium RC 是在瀏覽器中運行JavaScript應用，使用瀏覽器內置的JavaScript翻譯器來翻譯和執行selenese命令（selenese是Selenium命令集合）。
WebDriver是通過原生瀏覽器支持或者瀏覽器擴展來直接控制瀏覽器。WebDriver針對各個瀏覽器而開發，取代了嵌入到被測Web應用中的JavaScript，與瀏覽器緊密集成，因此支持創建更高級的測試，避免了JavaScript安全模型導致的限制。除了來自瀏覽器廠商的支持之外，WebDriver還利用操作系統級的調用，模擬用戶輸入。
Selenium與WebDriver原是屬於兩個不同的項目，WebDriver的創建者Simon Stewart早在2009年8月的一份郵件中解釋了項目合並的原因。
Selenium與WebDriver合並原因：為何把兩個項目合並？部分原因是WebDriver解決了Selenium存在的缺點（例如能夠繞過JavaScript沙箱，我們有出色的API），部分原因是Selenium解決了WebDriver存在的問題（例如支持廣泛的瀏覽器），部分原因是因為Selenium的主要貢獻者和我都覺得合並項目是為用戶提供最優秀框架的最佳途徑。
Selenium2.0
因為Selenium和Webdriver的合並，所以，Selenium 2.0由此誕生。簡單用公式表示為：
Selenium 2.0 = Selenium 1.0 + WebDriver
需要強調的是，在Selenium 2.0中主推的是WebDriver，可以將其看作是Selenium RC的替代品。因為Selenium為了保持向下的兼容性，所以在Selenium 2.0中並沒有徹底地拋棄Selenium RC。
Selenium 2.0的核心WebDriver工作原理：
webdriver api（java/python/ruby） <-> chromedriver.exe <-> chrome瀏覽器
大概是在2013年，Selenium官方博客發布Selenium團隊將會在聖誕節發布Selenium3.0。然鵝，這一等就等到2016年7月，Selenium3.0悄悄發布第一個beta版，官方解釋為：
“在seleniumconf 2013，我們宣布，Selenium的一個新的主要版本將在‘聖誕節’發布。幸運的是，我們從來沒有說過哪個聖誕節，因為我們已經花了一段時間來做我們想做的所有改變！我們很興奮地宣布第一個bate版--Selenium 3.0 - beta1的發布。”
Selenium 3.0
Selenium 3.0做了一些不大不小的更新：
1）終於去掉了RC
2）規范了所有瀏覽器廠商，設計自己的瀏覽器驅動 （WebDriver規范，所有瀏覽器廠商協商一致）
3）Selenium3.0只支持Java8版本以上
4）Selenium3.0中的Firefox瀏覽器驅動獨立了，以前裝完selenium2就可以驅動Firefox瀏覽器了，現在和Chrome一樣，必須下載和設置瀏覽器驅動
5）MAC OS 集成Safari的瀏覽器驅動。默認在/usr/bin/safaridriver 目錄下
6）只支持IE 9.0版本以上
Selenium 3.0 <-> geckodriver.exe <-> FireFox瀏覽器
注：本篇內容大部分轉自蟲師博客http://www.cnblogs.com/fnng/p/7426928.html，僅供學習使用