Selenium家族簡介及學前須知
專案實際需要,開始學習Selenium。
selenium 也不是簡單一個工具,而是由幾個工具組成,每個工具都有其特點和應用場景。其框架如下圖:
Selenium是基於WEB應用的驗收測試工具集合,直接執行在瀏覽器中,通過一系列命令來模擬使用者操作,Selenium可以將這些命令轉化成實際的HTTP請求在瀏覽器中執行 :
(1)Selenium Core:支援DHTML的測試案例(效果類似資料驅動測試),它是Selenium IDE和Selenium RC的引擎。(2)Selenium IDE:FireFox的一個外掛,支援指令碼錄製、除錯和用例生成。
(3)Selenium RC:Selenium Remote Control。
(4)Selenium Grid:允許同時並行地、在不同的環境上執行多個測試任務,極大地加快Web應用的功能測試。Selenium Grid是一種自動化的測試輔助工具,Grid通過利用現有的計算機基礎設施,能加快Web-app的功能測試。利用Grid,可以很方便地同時在多臺機器上和異構環境中並行執行多個測試事例。其特點為:a. 並行執行;b· 通過一個主機統一控制用例在不同環境、不同瀏覽器下執行。c· 靈活新增變動測試機。(5)Selenium WebDriver:selenium2.x,selenium1集成了webDriver的API實現
而Selenium Core和RC就是我們俗稱的Selnium1,而與webDriver集成了的Selenium就是我們俗稱的Selenium2,也叫Selenium WebDriver。 那為什麼要用Selnium2呢,因為
2、 selenium2比selenium1.0更簡單易學,有利於維護的API
3、selenium1.0必須操作真實瀏覽器,但是WebDriver可以HTML unit Driver來模擬瀏覽器,在記憶體中執行用例,更加的輕便 。
搞清了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學習路線:
需要熟悉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