之後再有人問你selenium是什麼，你就把這篇文章給他

1. 使用測試工具 《論語》有云：工欲善其事，必先利其器。在開始具體的自動化測試以前，咱們須要作好更多的準備，包括如下幾個方面： 認識自動化測試 準備自動化測試工具 使用有效的方式 針對具體的測試對象 接下來的第一部份內容，咱們將會從上述的幾個方面進行探討。 1.1 自動化測試理論介紹 自動化測試的5W 正如開篇所提到的，自動化測試再也不是一個陌生的話題，而是一個具體的存在。做爲測試實踐活動的一部分，咱們首先分析一下自動化測試的方方面面。 WHAT, 什麼是自動化測試 G.J.Myers在其經典的著做《軟件測試藝術》（The Art of Software Testing）一書中，給出了測試的定義： 「程序測試是爲了發現錯誤而執行的過程。」 這個概念產生於30年前，對軟件測試的認識還很是有侷限性，固然也是由於受瀑布開發模型的影響，認爲軟件測試是編程以後的一個階段。只有等待代碼開發出來之後，經過執行程序，像用戶那樣操做軟件去發現問題。 自動化測試：以人爲驅動的測試行爲轉化爲機器執行的一種過程 自動化測試，就是把手工進行的測試過程，轉變成機器自動執行的測試過程。該過程，依舊是爲了發現錯誤而執行。所以自動化測試的關鍵在於「自動化」三個字。自動化測試的內容，也就相應的轉變成如何「自動化」去實現本來手工進行的測試的過程。 全部的「自動化」，依靠的無疑都是程序。 經過程序，能夠把手工測試，轉變成自動化測試。 WHEN, 在何時開展自動化測試 自動化測試的開展，依賴於「程序」。那麼程序，其實就是由「源代碼」構建而來的。那麼原則上，只要能作出自動化測試所須要的「程序」的時候，變能夠進行自動化測試。但每每，並非全部的「時候」都是好的「時機」。從這個W開始，咱們將會加入對於成本的顧慮，也正是由於「成本」的存在，才使得下面的討論，變得有意義。 全部的開銷，都是有成本的。構建成「程序」的源代碼，也是由工程師寫出來的。那麼須要考慮這個過程當中的成本。基於這個考慮，在可以比較穩定的構建「程序」的時候，不須要花費太多開銷在「源代碼」的時候，就是開展自動化測試的好時機。這個開銷包括編寫和修改源代碼，而源代碼指的是構建出用來作自動化測試的程序的源代碼。 WHERE, 在什麼地方進行自動化測試 自動化測試的執行，依靠的是機器。那麼自動化測試必將在「機器」上進行。通常來講，這個機器包括桌面電腦和服務器。經過將寫好的源代碼部署在機器上，構建出用來作自動化測試的"程序"，而且運行該程序，實現自動化測試。 WHICH, 對什麼目標進行自動化測試 自動化測試的目標，是被測試的軟件。拋開人工智能的成分，手工測試必將在「人工智能」足夠普及和足夠「智能」以前，替代一大部分不須要「人類智能」的手工測試；以及自動化測試會作一些手工測試沒法實施的，或者手工測試沒法覆蓋的測試。 不須要「人類智能」的普通手工測試 界面的普通操做 經過固定輸入和固定操做而進行的流程化測試 重複的普通測試 手工測試沒法實施或者覆蓋的 大量的數據的輸入 大量的步驟的操做 源代碼基本的測試 系統模塊間接口的調用測試 HOW, 如何開展自動化測試 準備測試用例 找到合適的自動化測試工具 用準確的編程造成測試腳本 在測試腳本中對目標進行「檢查」，即作斷言 記錄測試日誌，生成測試結果 和全部的其餘測試同樣，自動化測試的流程也是由「用例」執行和「缺陷」驗證組成。差異是須要找到合適的「工具」來替代「人手」。不一樣目標的自動化測試有不一樣的測試工具，可是任何工具都無不例外的須要「編程」的過程，實現「源代碼」，也能夠稱之爲測試腳本。因而開展自動化測試的方式基本上以下： 自動化測試的典型金字塔原理 談到自動化測試，就不得不提的一我的和概念就是：Martin Fowler和他的金字塔原理 自動化測試包括三個方面：UI前端界面，Service服務契約和Unit底層單元 越是底層的測試，運行速度越快，時間開銷越少，金錢開銷越少 越是頂層的測試，運行速度越慢，時間開銷越多，金錢開銷越多 這是理想中的金字塔原理。 在實際的項目中，尤爲是結合國內的項目實踐，其實還隱藏了另外一個問題：越是頂層的測試，效果越明顯。有句話說「貴的東西，除了貴，其餘都是好的！」可以很清晰的闡述這個觀點。 金字塔原理在國內的適應性也有必定的問題 自動化測試的起步不是特別早 甚至軟件測試很長一段時間都在進行基於業務的手工測試，測試人員的代碼能力相對較弱 開發人員在代碼中不太習慣寫單元測試 近些年基於服務契約的API測試也在興起 相對來講，在基於UI前端界面的自動化測試反卻是開展和實施的不是特別多。儘管基於界面的測試帶來的效果仍是可以立竿見影的。對於產品的質量提高，仍是比較容易有保證。 自動化測試的適用範圍 自動化測試能夠涉及和試用的範圍主要在如下方面： 基於Web UI的瀏覽器應用的界面測試 基於WebService或者WebAPI的服務契約測試 基於WCF、.net remoting、Spring等框架的服務的集成測試 基於APP UI的移動應用界面測試 基於Java、C#等編程文件進行的單元測試 本文集中討論第一條：基於Web UI的瀏覽器應用的界面測試。界面的改動對於測試來講，具備較大的成本風險。主要考慮如下方面： 任務測試明確，不會頻繁變更 每日構建後的測試驗證 比較頻繁的迴歸測試 軟件系統界面穩定，變更少 須要在多平臺上運行的相同測試案例、組合遍歷型的測試、大量的重複任務 軟件維護週期長 項目進度壓力不太大 被測軟件系統開發比較規範，可以保證系統的可測試性 具有大量的自動化測試平臺 測試人員具有較強的編程能力 自動化測試的流程 自動化測試和普通的手工測試遵循的測試流程，與項目的具體實踐相關。通常來講，也是須要從測試計劃開始涉及自動化測試的。 測試計劃：劃定自動化測試的範圍包含哪些需求，涉及到哪些測試過程 測試策略：肯定自動化測試的工具、編程方案、代碼管理、測試重點 測試設計：使用測試設計方法對被測試的需求進行設計，得出測試的測試點、用例思惟導圖等 測試實施：根據測試設計進行用例編寫，而且將測試用例用編程的方式實現測試腳本 測試執行：執行測試用例，運行測試腳本，生成測試結果 1.2 自動化測試工具 基於Web UI的自動化測試工具主要有兩大類：付費的商業版工具和無償使用的開源版工具。典型的有兩種： UFT，QTP被惠普收購之後的新名稱。 經過程序的錄製，能夠實現測試的編輯 錄製的測試腳本是 VBScript 語法 成熟版的商業付費工具 工具比較龐大，對具體的項目定製測試有難度 SELENIUM，本次選擇的開源工具 自己不是測試工具，只是模擬瀏覽器操做的工具 背後有 Google 維護源代碼 支持所有主流的瀏覽器 支持主流的編程語言，包括：Java、Python、C#、PHP、Ruby、JavaScript等 工具很小，能夠實現對測試項目的定製測試方案 基於標準的 WebDriver 語法規範 1.2.1 Selenium 基本介紹 Selenium`是開源的自動化測試工具，它主要是用於Web 應用程序的自動化測試，不僅侷限於此，同時支持全部基於web 的管理任務自動化。 Selenium官網的介紹 Selenium is a suite of tools to automate web browsers across many platforms. runs in many browsers and operating systems can be controlled by many programming languages and testing frameworks. Selenium 官網：http://seleniumhq.org/ Selenium Github 主頁：https://github.com/SeleniumHQ/seleniumSelenium 是用於測試 Web 應用程序用戶界面 (UI) 的經常使用框架。它是一款用於運行端到端功能測試的超強工具。您可使用多個編程語言編寫測試，而且 Selenium 可以在一個或多個瀏覽器中執行這些測試。Selenium 經歷了三個版本：Selenium 1，Selenium 2 和 Selenium 3。Selenium 也不是簡單一個工具，而是由幾個工具組成，每一個工具都有其特色和應用場景。Selenium 誕生於 2004 年，當在 ThoughtWorks 工做的 Jason Huggins 在測試一個內部應用時。做爲一個聰明的傢伙，他意識到相對於每次改動都須要手工進行測試，他的時間應該用得更有價值。他開發了一個能夠驅動頁面進行交互的 Javascript 庫，能讓多瀏覽器自動返回測試結果。那個庫最終變成了 Selenium 的核心，它是 Selenium RC（遠程控制）和 Selenium IDE 全部功能的基礎。Selenium RC 是開拓性的，由於沒有其餘產品能讓你使用本身喜歡的語言來控制瀏覽器。這就是 Selenium 1。然而，因爲它使用了基於 Javascript 的自動化引擎，而瀏覽器對 Javascript 又有不少安全限制，有些事情就難以實現。更糟糕的是，網站應用正變得愈來愈強大，它們使用了新瀏覽器提供的各類特性，都使得這些限制讓人痛苦不堪。在 2006 年，一名 Google 的工程師， Simon Stewart 開始基於這個項目進行開發，這個項目被命名爲 WebDriver。此時，Google 早已經是 Selenium 的重度用戶，可是測試工程師們不得不繞過它的限制進行工具。Simon 須要一款能經過瀏覽器和操做系統的本地方法直接和瀏覽器進行通話的測試工具，來解決Javascript 環境沙箱的問題。WebDriver 項目的目標就是要解決 Selenium 的痛點。到了 2008 年，Selenium 和 WebDriver 兩個項目合併。Selenium 有着豐富的社區和商業支持，但 WebDriver 顯然表明着將來的趨勢。二者的合併爲全部用戶提供了一組通用功能，而且借鑑了一些測試自動化領域最閃光的思想。這就是 Selenium 2。2016 年，Selenium 3 誕生。移除了再也不使用的 Selenium 1 中的 Selenium RC，而且官方重寫了全部的瀏覽器驅動。Selenium 工具集Selenium IDESelenium IDE (集成開發環境) 是一個建立測試腳本的原型工具。它是一個 Firefox 插件，實現簡單的瀏覽器操做的錄製與回放功能，提供建立自動化測試的建議接口。Selenium IDE 有一個記錄功能，能記錄用戶的操做，而且能選擇多種語言把它們導出到一個可重用的腳本中用於後續執行。Selenium RCSelenium 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 GridSelenium Grid 使得 Selenium RC 解決方案能提高針對大型的測試套件或者哪些須要運行在多環境的測試套件的處理能力。Selenium Grid 能讓你並行的運行你的測試，也就是說，不一樣的測試能夠同時跑在不一樣的遠程機器上。這樣作有兩個有事，首先，若是你有一個大型的測試套件，或者一個跑的很慢的測試套件，你可使用 Selenium Grid 將你的測試套件劃分紅幾份同時在幾個不一樣的機器上運行，這樣能顯著的提高它的性能。同時，若是你必須在多環境中運行你的測試套件，你能夠得到多個遠程機器的支持，它們將同時運行你的測試套件。在每種狀況下，Selenium Grid 都能經過並行處理顯著地縮短你的測試套件的處理時間。Selenium WebDriverWebDriver 是 Selenium 2 主推的工具，事實上WebDriver是Selenium RC的替代品，由於Selenium須要保留向下兼容性的緣由，在 Selenium 2 中， Selenium RC纔沒有被完全的拋棄，若是使用Selenium開發一個新的自動化測試項目，那麼咱們強烈推薦使用Selenium2 的 WebDriver進行編碼。另外， 在Selenium 3 中，Selenium RC 被移除了。