1、分层自动化测试概念
传统的自动化市场更关注产品UI层的自动化测试，而分层的自动化测试倡导产品开发的不同阶段都需要自动化测试
大多公司与研发团队其实是忽略了单元测试与集成测试阶段的自动化测试工作，所以，在分层的自动化测试中，我们有必要对这些定义重新理解和定义。
单元测试：我们需要规范的来做单元测试同样需要相应的单元测试框架，如java的Junit、testNG，C#的NUint，Python的unittest、pytest等，几乎所有的主流语言，都会有其对应的单元测试框架。
集成、接口测试：单元测试关注代码的实现逻辑，例如一个if分支或一个for循环的实现，那么集成、接口测试关注的是一个函数、类（方法）所提供的接口是否可靠。例如我们定义一个add()函数用于计算两个参数的结果并返回，那么我需要调用add()并传参，并比较返回值是否是两割参数相加。当然，接口测试也可以是url形式进行传递。例如，我们通过get方法想服务器发送请求，那么我们发送的内容作为URL的一部分传递到服务器端。但比如Web service技术对外提供的一个公共接口，需要通过soapUI等工具对其进行测试。
UI层的自动化测试：大部分测试人员的大部分工作都是对UI层的功能进行测试。例如，我们不断重复的对一个表单提交，结果查询等功能进行测试，我们可以通过相应的自动化测试工具来模拟这些操作，从而解放重复的劳动。UI层的自动化测试工具非常多，比如QTP、Robot Framework、waiter、Selenium等。
为什么分层自动化是一个金字塔形，而不是长方形或三角形？这是为了表示不同阶段所投入自动化测试的比例。如果一个产品从来没有做单元测试与接口测试，只做UI层的自动化测试是不科学的，很难从本质上保证产品的质量。如果妄图实现全面的UI层的自动化测试，那更是一个劳民伤财的举动，投入了大量的人力时间，最终获得的收益可能会远远低于所支付的成本。因为越往上层，其维护成本越高。尤其是Ui层的元素会时常的发生改变。所以，我们应该把更多的自动化测试放在单元测试与接口测试阶段进行。
2、什么样的项目适合做自动化测试
并不是所有项目都适合实施自动化测试的，关于什么样的项目适合做自动化测试，在这里，主要整理以下几点
1）任务测试明确，不会频繁变动
2）每日构建后的测试验证
3）比较频繁的回归测试
4）软件系统界面稳定，变动少
5）需要在多平台上运行的相同测试用例、组合遍历型的测试、大量的重复任务
6）软件维护周期长
7）项目进度压力不太大
8）被测软件系统开发比较规范，能够保证系统的可测试性
9）具备大量的自动化测试平台
10）测试人员具备较强的编程能力
注意，并非以上10条都具备的情况下才能开展自动化测试，在业界大牛普遍的自动化测试经验中，一半满足以下三个条件就可以对项目开展自动化测试：
软件需求变动不频繁
项目周期较长
自动化测试脚本可重复使用
3、Selenium工具介绍
要做selenium自动化测试，首先要要了解什么是Selenium。
Selenium自动化测试工具，主要是用于web应用程序的自动化测试，但并不只局限于此，
它还支持所有给予web的管理任务自动化。
Selenium的特点：
·开源，免费
·支持多浏览器：FireFox、Chrome、IE、Opera
·支持多平台：Linux、Windows、MAC
·支持多语言：java、Python、Ruby、php、C#、JavaScript
·对web页面有良好的支持
·简单、灵活（API简单，开发语言驱动灵活）
·支持分布式测试用例执行
Selenium经历了三个版本，Selenium1.0和Selenium2.0,跟3.0，Selenium也不是简单一个工具，而是有几个工具组成，每个工具都有其特点和应用场景。
Selenium 1.0
用简单的公式：
Selenium 1.0 = Selenium IDE + Selenium Grid + Selenium RC
Selenium IDE
Selenium IDE是嵌入到FireFox浏览器中的一个插件，实现简单的浏览器操作的录制与回放功能。
那么什么情况下用到它呢？
快速的创建bug 重现脚本，在测试人员的测试过程中，发现了bug 之后可以通过IDE 将重现的步骤录制下来，以帮助开发人员更容易重现bug。
Selenium Grid
Selenium Grid是一种自动化的测试辅助工具，允许同时并行地、在不同的环境上运行多个测试任务，极大地加快Web应用的功能测试。其特点：
·并行执行
·通过一个主机统一控制用例在不同环境、不同浏览器下运行。
·灵活添加变动测试机
Selenium RC
Selenium RC（Remote Control）是Selenium家族的核心部分。Selenium RC支持多种不同语言编写的自动化测试脚本，通过Selenium RC的服务器作为代理服务器去访问应用，从而达到测试的目的。
Selenium RC分为Client Libraries和Selenium Server。Client Libraries库主要用于编写测试脚本，用来控制Selenium Server的库。Selenium Server负责控制浏览器行为。
简单的理解：
Selenium RC(API) <-> Selenium Server <-> 浏览器（FireFox、Chrome...）
在2006年的时候，Google的工程师Simon Stewart发起了WebDriver的项目；因为长期以来Google一直是Selenium的重度用户，但却被限制在有限的操作范围内。
Selenium RC 是在浏览器中运行JavaScript应用，使用浏览器内置的JavaScript翻译器来翻译和执行selenese命令（selenese是Selenium命令集合）。
WebDriver是通过原生浏览器支持或者浏览器扩展来直接控制浏览器。WebDriver针对各个浏览器而开发，取代了嵌入到被测Web应用中的JavaScript，与浏览器紧密集成，因此支持创建更高级的测试，避免了JavaScript安全模型导致的限制。除了来自浏览器厂商的支持之外，WebDriver还利用操作系统级的调用，模拟用户输入。
Selenium与WebDriver原是属于两个不同的项目，WebDriver的创建者Simon Stewart早在2009年8月的一份邮件中解释了项目合并的原因。
Selenium与WebDriver合并原因：为何把两个项目合并？部分原因是WebDriver解决了Selenium存在的缺点（例如能够绕过JavaScript沙箱，我们有出色的API），部分原因是Selenium解决了WebDriver存在的问题（例如支持广泛的浏览器），部分原因是因为Selenium的主要贡献者和我都觉得合并项目是为用户提供最优秀框架的最佳途径。
Selenium2.0
因为Selenium和Webdriver的合并，所以，Selenium 2.0由此诞生。简单用公式表示为：
Selenium 2.0 = Selenium 1.0 + WebDriver
需要强调的是，在Selenium 2.0中主推的是WebDriver，可以将其看作是Selenium RC的替代品。因为Selenium为了保持向下的兼容性，所以在Selenium 2.0中并没有彻底地抛弃Selenium RC。
Selenium 2.0的核心WebDriver工作原理：
webdriver api（java/python/ruby） <-> chromedriver.exe <-> chrome浏览器
大概是在2013年，Selenium官方博客发布Selenium团队将会在圣诞节发布Selenium3.0。然鹅，这一等就等到2016年7月，Selenium3.0悄悄发布第一个beta版，官方解释为：
“在seleniumconf 2013，我们宣布，Selenium的一个新的主要版本将在‘圣诞节’发布。幸运的是，我们从来没有说过哪个圣诞节，因为我们已经花了一段时间来做我们想做的所有改变！我们很兴奋地宣布第一个bate版--Selenium 3.0 - beta1的发布。”
Selenium 3.0
Selenium 3.0做了一些不大不小的更新：
1）终于去掉了RC
2）规范了所有浏览器厂商，设计自己的浏览器驱动 （WebDriver规范，所有浏览器厂商协商一致）
3）Selenium3.0只支持Java8版本以上
4）Selenium3.0中的Firefox浏览器驱动独立了，以前装完selenium2就可以驱动Firefox浏览器了，现在和Chrome一样，必须下载和设置浏览器驱动
5）MAC OS 集成Safari的浏览器驱动。默认在/usr/bin/safaridriver 目录下
6）只支持IE 9.0版本以上
Selenium 3.0 <-> geckodriver.exe <-> FireFox浏览器
注：本篇内容大部分转自虫师博客http://www.cnblogs.com/fnng/p/7426928.html，仅供学习使用