以后再有人問你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/selenium
Selenium 是用於測試 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 IDE

Selenium IDE (集成開發環境) 是一個創建測試腳本的原型工具。它是一個 Firefox 插件，實現簡單的瀏覽器操作的錄制與回放功能，提供創建自動化測試的建議接口。Selenium IDE 有一個記錄功能，能記錄用戶的操作，並且能選擇多種語言把它們導出到一個可重用的腳本中用於后續執行。

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 Grid

Selenium Grid 使得 Selenium RC 解決方案能提升針對大型的測試套件或者哪些需要運行在多環境的測試套件的處理能力。Selenium Grid 能讓你並行的運行你的測試，也就是說，不同的測試可以同時跑在不同的遠程機器上。這樣做有兩個有事，首先，如果你有一個大型的測試套件，或者一個跑的很慢的測試套件，你可以使用 Selenium Grid 將你的測試套件划分成幾份同時在幾個不同的機器上運行，這樣能顯著的提升它的性能。同時，如果你必須在多環境中運行你的測試套件，你可以獲得多個遠程機器的支持，它們將同時運行你的測試套件。在每種情況下，Selenium Grid 都能通過並行處理顯著地縮短你的測試套件的處理時間。

Selenium WebDriver

WebDriver 是 Selenium 2 主推的工具，事實上WebDriver是Selenium RC的替代品，因為Selenium需要保留向下兼容性的原因，在 Selenium 2 中， Selenium RC才沒有被徹底的拋棄，如果使用Selenium開發一個新的自動化測試項目，那么我們強烈推薦使用Selenium2 的 WebDriver進行編碼。另外， 在Selenium 3 中，Selenium RC 被移除了。