SeleniumRC
早期的Selenium使用的是Javascript注入技术与浏览器打交道，需要SeleniumRC启动一个Server，将操作Web元素的API调用转化为一段段Javascript，在Selenium内核启动浏览器之后注入这段Javascript。开发过Web应用的人都知道，Javascript可以获取并调用页面的任何元素，自如的进行操作。由此才实现了Selenium的目的：自动化Web操作。这种Javascript注入技术的缺点是速度不理想，而且稳定性大大依赖于Selenium内核对API翻译成的Javascript质量高低。
WebDriver
当Selenium2.x提出了WebDriver的概念之后，它提供了完全另外的一种方式与浏览器交互。那就是利用浏览器原生的API，封装成一套更加面向对象的SeleniumWebDriverAPI，直接操作浏览器页面里的元素，甚至操作浏览器本身（截屏，窗口大小，启动，关闭，安装插件，配置证书之类的）。由于使用的是浏览器原生的API，速度大大提高，而且调用的稳定性交给了浏览器厂商本身，显然是更加科学。然而带来的一些副作用就是，不同的浏览器厂商，对Web元素的操作和呈现多少会有一些差异，这就直接导致了SeleniumWebDriver要分浏览器厂商不同，而提供不同的实现。例如Firefox就有专门的FirefoxDriver，Chrome就有专门的ChromeDriver等等。（甚至包括了AndroidDriver和iOSWebDriver）
引用一句个人赞同的原文：如果你使用的是WebDriver，你就可以直接抛弃SeleniumServer。因为你根本不需要启动一个服务器来处理浏览器交互。
使用WebDriver的心得
其中WebDriver的更加面向对象的方式大大降低了Selenium的入门门槛，对Web元素的操作也非常之简单易学。实际项目用起来，工作量最大的部分就是你如何解析定位到你的目标项目页面中的各种元素。好比你要定位一个Button，你可以用ID，可以用CSS，可以用XPATH，你为了点击这个Button，写了一个函数调用Selenium里的API，即WebElement里的click()或者submit()，那么另外一个Button怎么办？成百上千个Button又怎么办？
所以，你需要有一套自己实现的算法或者封装，来根据项目页面的特点提供一套通用的元素定位方式。当你的通用定位逻辑能准确的找到任何一个元素的时候，剩下的事情就顺理成章了，交给SeleniumWebElement的API就可以了。这一套定位逻辑笔者觉得才是使用Selenium做Web自动化工作量最大的部分。当然有的公司Web项目使用了自己开发的UI框架，例如笔者所在的公司，这样Web元素的定位规则和算法就比较容易设计。如果Web项目开发出来的页面代码比较杂乱无章，那么你就需要更加高明和严谨的逻辑去寻找你想要操作和查看的元素了！
在笔者的项目里，笔者自己设计并封装了一套通用的API，去智能的定位页面中的各种类型的元素。比如项目里的页面有大量的dialog和wizard，都是用div+css实现的。我就提供了一个dialog组件，带有next()，save()，finish()，click(StringbuttonName)，cancel()等方法，然后根据遮罩层和loadingIcon的时间来追踪操作完成的进度。这里只是举个小小的例子，有机会再分享更多的细节。
文章来源：http://blog.csdn.net/ant_ren/article/details/7970793