很多敏捷團隊已經使用了Selenium和Watir等 工具進行驗收測試或用戶接口測試。這些工具通過驅動Web瀏覽器的方式反映用戶體驗，并且為測試那些使用DHTML和Ajax構建的動態接口提供強力支 持。然而，隨著更多的團隊采納類似的工具，他們發現，運行這一整套瀏覽器驅動的Web接口測試會花費很長時間，而導致構建太慢。敏捷團隊可能就不得不在全 面測試和構建速度之間做出艱難的選擇。使用Selenium的用戶中，有人通過使用Selemium-RC運行多個測試，也有人將測試分配給多個 Selemium-RC運行測試，但幫助有限。雖然對于少量并行是有效的，但對于大量并行卻無能為力。Selenium用戶現在有了另一種選擇：Selenium Grid。
Selenium Grid是Selenium的一個擴展，也是免費且開源的(Apache License 2.0)。它把管理一小撮Selenium-RC實例的事情和為了運行一個測試而連接一個Selenium實際的事情分開了。實際上，Selenium Grid是提供了一個hub，象個用于控制測試的遠程控制器，但是是顯式地將測試請求發送到一個或多個機器上的某個有效的Selenium-RC實例上。 這個Selenium Hub負責以下這些事情：
- 將一個SeleniumRC顯式地分配給一個具體的測試
- 限制在每個RC最大并發測試數
- 將測試屏蔽在一個實際的網格結構之外。
使用Selenium Gird時，Selenium測試可以通過名稱選擇具體環境的實例，例如某個測試可以運行在Windows XP系統的IE7上，而其它實例卻指定運行在Ubuntu的Firefox 1.5之上。
更重要的是，它允許組織構建一個復雜的包含多種必要的測試環境的測試機群，并在其上并行運行一個或多個項目的測試。這將在測試方面有顯著的提高，最終減少每個項目所需要的基礎設施。某些大型組織對這一點認識的最為深刻（比如Google就在用相似的方法），但即使是對于單個項目的單個機器也是有價值的。
Selenium-RC 最近已經大幅度地改進了性能，包括在單一線程的環境下。但是，多機器多線程測試對于長時間測試來說還是有相當大的益處的。利用足夠的測試處理能力和測試的獨立性，對于減少最長測試的時間是可行的。
雖然這些測試可以不必知道自己是在單機上順序運行還是運行于整個機群，但Selenium Grid卻不負責這些測試的并行執行，這些是由TestNG，Parallel JUnit和DeepTest for Ruby等完成的。
InfoQ采訪了Selenium Grid的團隊成員，并問及并行執行測試可能對Selenium測試用例的影響：
我們討論過隔離性，以及開發Grid之前所面臨的問題。我們想現在就把這個擔子交給寫測試的人，讓他們來設計測試用例，以確保它們之間不會相互影響。當 然，這個問題在Gird產生之前就已經存在了。你不想讓你的Selenium受其執行順序的影響，那在每個測試執行之前要做一些數據初始化工作，執行這后 再清理掉。然而，這不是一個優雅的解決方案。理想情況下，你的Selenium test最好只了解這個應用的前端，但實際上，通過暴露一點數據給測試，會使針對具體的Scenarios寫測試比較快且方便，而且由于只要較少的導航頁 就可達到被測試頁，運行時間會較少。嗯，看來有一點兒道理啦！但是不管怎么樣，我們還是希望Grid能夠支持這兩種方式，不久前我們找到了一些方法可以在 數據庫層隔離這些測試。雖然還只算是alpha版，但它可能會成為Grid的一部分，也可有是一個獨立的項目。
在談到Selenium Grid的未來時，開發團隊認為以下特性中的內容最終會成為Selenium Grid的一部分：
- 一個更完善的管理控制臺
- 成為Windows服務(以及solaris，Linux等操作系統的等價物)
- 屏保功能（桌面電腦在閑置時可以加入Grid）
- 為用Amazon's EC2 (Electronic Compute Cloud)基礎設施作為Selenium測試機群提供支持
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
