當你看到這篇文章時一定會詫異，2.0都廣泛使用了，為何還要了解1.0的內容呢？1.0的確已經慢慢的成為歷史，那我們先通過歷史來認識一下selenium的發展吧。
Jason Huggins在2004年發起了Selenium項目，當時他在ThoughtWorks公司開發內部的時間和費用（Time and Expenses）系統，該應用使用了大量的JavaScript。雖然IE在當時是主流瀏覽器，但是ThoughtWorks還使用一些其他瀏覽器（特別是Mozilla系列），當員工在自己的瀏覽器中無法正常運行T&E系統時會提交bug。當時的開源測試工具要么關注單一瀏覽器（通常是IE），要么是模擬瀏覽器（如HttpUnit），而購買商業工具授權的成本會耗盡這個小型內部項目的有限預算，所以它們都不太可行。
幸運的是，所有被測試的瀏覽器都支持Javascript。Jason和他所在的團隊有理由采用Javascript編寫一種測試工具來驗證應用的行為。他們受到FIT(Framework for Integrated Test）的啟發，使用基于表格的語法替代了原始的Javascript，這種做法支持那些編程經驗有限的人在HTML文件中使用關鍵字驅動的方式來編寫測試。該工具，初稱為“Selenium”，后來稱為“Selenium Core”，在2004年基于Apache 2授權發布。
Selenium的表格格式類似于FIT的ActionFixture。表格的每一行分為三列。第一列給出了要執行的命令名稱，第二列通常包含元素標記符，第三列包含一個可選值。例如，如下格式表示了如何在名稱為“q”的元素中輸入字符串“Selenium”：
type name=q Selenium
因為Selenium過去使用純JavaScript編寫，它的初設計要求開發人員把準備測試的應用和Selenium Core、測試腳本部署到同一臺服務器上以避免觸犯瀏覽器的安全規則和JavaScript沙箱策略。在實際開發中，這種要求并不總是可行。更糟的是，雖然開發人員的IDE能夠幫助他們快速處理代碼和瀏覽龐大的代碼庫，但是沒有針對HTML的相關工具。人們很快意識到維護一個中等規模的測試集是笨拙而痛苦的過程。
為了解決這個問題和其他問題，他們編寫了HTTP代理，這樣所有的HTTP請求都會被Selenium截獲。使用代理可以繞過“同源”規則（瀏覽器不支持Javascript調用任何當前頁面所在服務器以外的其他任何東西）的許多限制，從而緩解了首要弱點。這種設計使得采用多種語言編寫Selenium成為可能：它們只需把HTTP請求發送到特定URL。連接方法基于Selenium Core的表格語法嚴格建模，稱之為“Selenese”。因為語言綁定在遠程控制瀏覽器，所以該工具稱為“Selenium Remote Control”或者“Selenium RC”。
在Selenium處于開發階段的同時，另一款瀏覽
器自動化框架WebDriver也正在ThoughtWorks公司的醞釀之中。Selenium2.0之webdriver的介紹請期待下一篇文章。
上面介紹中其實也提到了1.0的概況，下圖是它的工作流程。
1. 測試用例通過Http請求建立與 selenium-RC server 的連接
2. Selenium RC Server 驅動一個瀏覽器，把Selenium Core加載入瀏覽器頁面當中，并把瀏覽器的代理設置為Selenium Server的Http Proxy
3. 執行用例向Selenium Server發送Http請求，Selenium Server對請求進行解析，然后通過Http Proxy發送JS命令通知Selenium Core執行操作瀏覽器的動作并注入 JS 代碼
4.Selenium Core執行接受到的指令并操作
5. 當瀏覽器收到新的請求時，發送http請求
6. Selenium Server接收到瀏覽器發送的Http請求后，自己重組Http請求，獲取對應的Web頁面
7. Selenium Server中的Http Proxy把接受到的頁面返回給瀏覽器。
同源策略，它是由Netscape提出的一個的安全策略，現在所有的可支持javascript的瀏覽器都會使用這個策略。所謂同源，是指域名、協議、端口相同。所以，打開一個baidu的網頁只能執行baidu下的JavaScript腳本，而另外一個tab是google，baidu下的JavaScript則不能執行，從而防止對本網頁的非法篡改。
那么Selenium RC通過http代理的方式很好的解決了同源策略并欺騙了瀏覽器。
