做自动化测试之前需要了解的

首先理清自动化测试的概念，什么是自动化测试？

广义上来讲，自动化包括一切通过工具(程序）的方式来代替或辅助手工测试的行为都可以看做是自动化，包括性能测试工具（Loadrunner、Jmeter）,或自己所写的一段程序，用于生成1到100个测试数据。

狭义上来讲，通过工具记录或编写脚本的方式模拟手工测试的流程，通过回放或运行脚本来执行测试用例，从而代替人工对系统的功能进行验证。
一般我们普遍认识把“自动化测试”看做“基于产品或项目UI层的自动化测试”。

分层的自动化测试：这个概念最近曝光度比较高，传统的自动化测试更关注产品UI层的自动化测试，而分层的自动化测试倡导产品的不同阶段（层次）都需要自动化测试。

很多人会认为这个不就是产品开发不同阶段所对应的测试么！但我们需要规范来做，单元测试同样需要相应的单元测试框架，如java的Junit、testNG ；C#的Nunit ；Python的Unittest 、pytest等，几乎所有的主流语言都会有其对应的单元测试框架。

集成、接口测试对于不少测试新手来说不太容易理解，单元测试关注代码的实现逻辑，例如一个if分支或一个for循环的实现，那么集成、接口测试关注的是一个函数、类（方法）所提供的接口是否可靠，例如我定义一个add（）函数用于计算两个参数的结果并返回，那么我需要调用add（)并传参，并比较返回值是否两个参数相加。当然，接口测试也可以是url的形式进行传递。例如，我们通过get方式向服务器发送请求，那么我们发送的内容做为URL的一部分传递到服务器端。但比如WEB service 技术对外提供的一个公共接口，需要通过soapUI等工具对其进行测试。

UI层的自动化测试，大部分测试人员的大部分工作都是对UI层的功能进行测试，例如，我们不断重复的对一个表单提交，结果查询等功能进行测试，我们可以通过相应的自动化测试工具来模拟这些操作，从而解放重复的劳动。UI层的自动化测试工具特别多，比较主流的是QTP、 Robot Framework 、watir 、selenium等。

为什么要画成一个金字塔形，不是长方形或者金字塔形呢？这是为了表示不同阶段所投入自动化测试的比例。如果一个产品从没有做单元测试与接口测试，只做UI层的自动化测试是不科学的，从而很难从本质上保证产品的质量，如果妄图实现全面的UI层的自动化测试，那更是一个劳民伤财的举动，投入了大量的人力时间，最终获得的收益可能会远远低于所支付的成本。因为越往上层，维护成本越高。尤其是UI层的元素会时常发生改变。所以，我们应该把更多的自动化测试放在单元测试与接口测试阶段进行。

既然UI层的自动化测试这么劳民伤财，那我们只做单元测试与接口测试就好了，NO！因为不管什么样的产品，最终呈现给客户的是UI层。所以，测试人员应该更多的精力放在UI层，有必要通过自动化的方式部分解放“重复的劳动”。
在自动化测试中，最怕的就是变动，因为变动的直接结果就是导致测试用例执行的失败，那么就需要对自动化脚本进行维护，如何控制失败，降低维护成本对自动化的成败至关重要，反过来讲，一份永远都运行成功的自动化测试用例是没有价值的。
至于在金字塔中三种测试的比例要根据实际的项目需求来划分，在《Google测试之道》一书，对于Google产品，70%投入为单元测试，20%为集成、接口测试，10%为UI层的自动化测试。
为什么要学习自动化测试？

从测试人员自身的发展来说，其实非常需要通过自动化测试技术来增加自己的竞争力。

从测试行业发展来说，国内产品由于产品特点，世界级的产品不多，技术含量相对不高，质量要求相对不高，外包国外项目，测试人力成本低廉，所以需要大量的手工测试人员。
也许不久的奖励，手工测试会消失。
什么项目适合做自动化测试？
软件需求变动不频繁
测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试。必要的时候还要修改自动化测试框架，所以所花费的成本不能低于利用其节省的测试成本，那么自动化测试是失败的。

项目中的某些模块相对稳定，而某些模块需求的变动性很大，我们便可对相对稳定的模块进行自动化测试，而变动较大的还是用手工测试。

项目周期较长

由于自动化测试需求的确定、自动化测试的框架设计、测试脚本的编写与调试均需要相当长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样的一个过程，那么自动化测试是不可行的。
自动化测试脚本可重复使用
自动化测试脚本的重复要从三个方面来考量，一方面所测试的项目之间是否很大的差异性（如C/S、B/S系统的差异性），所选择的测试工具是否适应这种差异性，最后，测试人员是否有能力开发适应这种差异的自动化测试框架。
选择什么工具进行自动化测试？
首先要先确认所测试的产品是桌面程序（C/S）还是WEB应用（B/S）。
桌面程序的工具有：QTP、Autorunner；
WEB应用的工具有：QTP、Autorunner、Robot Framework、watir、selenium
由于B/S架构的诸多优势，早几年前大量C/S架构的应用转为B/S架构，从而也推动了WEB开发与测试技术的发展。
假如，被测试产品是C/S架构的，那么推荐QTP，QTP在UI自动化测试领域占到了一半的试用率。所以，足以说明QTP在自动化领域强大、易用性等。要想学好QTP，必须要掌握VBS脚本语言。
如果，被测产品是B/S架构，那么推荐selenium，为什么不是QTP或其他工具？因为selenium对B/S应用支持很好，更重要的一点，它支持多语言开发，同时学习一门变成语言是最好的。
selenium 是支持Java 、Python、Ruby 、Php、C#、JavaScript。
从语言易学性来讲，首选Ruby、Python；
从语言应用广度来讲，首选Java 、Php、C#；
从语言相关测试技术程度来讲：Java 、Python、Ruby 。
selemiun 用前须知：
在开始selenium之前，需要花一到两个月的时间去学习一门语言，Java 、Python、Ruby 任意一门。
学好语言之后，就要先了解selenium ，selenium并不是单纯的一个工具，它是一组工具的集合，每个工具都有其特点和应用，有1.0、2.0、3.0的区分。
selenium IDE
selenium IDE 是嵌入到Firefox浏览器中的一个插件，实现简单的浏览器操作的录制与回放功能，那么什么情况下用到它呢？
快速的创建Bug重现脚本，在测试人员的测试过程中，发现了Bug之后可以通过IDE将重现的步骤录制下来，以帮助开发人员更容易的重现Bug。
IDE录制的脚本可以转换成多种语言，从而帮助我们快速的开发脚本。
selenium Gird
selenium Gird 是一种自动化的测试辅助工具，Gird通过利用现有的计算机基础设施，能加快WEB-APP的功能测试，利用Gird ，可以很方便的同时在多台计算器上和异构环境中并行运行多个测试用例。其特点为：
并行执行
通过一个主机统一控制用例在不同环境、不同浏览器下运行。
灵活添加变动测试机
selenium RC
selenium RC是selenium家族的核心工具，selenium RC支持多种不同的语言编写自动化测试脚本，通过selenium RC的服务器作为代理服务器去访问应用从而达到测试的目的。
selenium RC使用分Client Libraries 和 selenium server , Client Libraries库主要用于编写测试脚本，用来控制selenium server 的库。
selenium server负责控制浏览器行为，主要包括三个部分，Launcher 、 Http Proxy 、Core 。其中selenium core 是被 selenium server 嵌入到浏览器页面中的，其实selenium core 就是一堆JS函数的集合 ，就是通过这些JS函数，我们才可以实现用程序对浏览器进行操作，Launcher用于启动浏览器，把selenium core 加载到浏览器页面当中，并把浏览器的代理设置为selenium server 的 Http Proxy 。
selenium 2.0
selenium 2.0 是把Webdriver加入 ，简单用公式表示为：

selenium 2.0=selenium 1.0 + Webdriver
需要强调的是，selenium 2.0 主推Webdriver ，Webdriver是selenium RC的替代品，因为，selenium为了向下兼容性，所以selenium RC并没有彻底抛弃，如果你使用selenium 开发一个新的自动化测试项目，强烈推荐使用Webdriver ，那么selenium RC与Webdriver有什么区别呢？
selenium RC在浏览器中运行JavaScript应用，使用浏览器内置的JavaScript翻译器来翻译和执行selenese命令，（selenese是selenium命令集合）。
Webdriver通过原生浏览器支持或者浏览器扩展直接控制浏览器，Webdriver针对各个浏览器开发，取代了嵌入到被测Web应用中的JavaScript，与浏览器的紧密集成支持创建更高级的测试，避免了JavaScript安全模型导致大限制，除了来自浏览器厂商的支持，Webdriver还利用操作系统级的调用模拟用户输入。
如果是新项目直接学习Webdriver就可以了 ，RC是过时技术。
selenium 学习路线
配置测试环境，针对所学语言配置相应的selenium 的测试环境。
然后熟悉Webdriver API ，API就是selenium 所定义一方法 ，用于定位 ，操作页面上的各种元素。
先学习元素的定位，selenium提供了id 、name、class name 、tag name 、link text 、partial link text、xpath 、css 等定位方法 。xpath和css功能强大且语法稍微复杂，所以还需要了解更多的前端知识，xml 、 javascript 等。
定位元素的目的是为了操作元素，接着就要学习各种元素操作、输入框、下拉框、按钮点击、文件上传、下载、分页、对话框、警告框等等。
经过一段时间的学习，可以游刃有余的模拟手工测试来操作页面上的各种元素了，然后把这些用例组织起来，统一来跑。
需要学习并使用单元测试框架，单元测试框架本身就解决了用例的组织与运行。
当写了一些测试用例后，发现测试用例中有大量的重复操作，能不能单独写到一个文件当中，需要的时候调用这些操作，所以运用编程能力实现这点跟简单。
然后发现每个测试用例中都有一些数据，这些数据也是一样的，但如果变化了修改起来很麻烦，可以把它写到一个单独的文件去读取。
然后又发现脚本测试用例都是流水式的，怎么知道用例运行是失败还是成功呢？那么就需要在脚本中加一些验证与断言。
然后就会发现单元测试框架的Log太简陋了，能不能生成一张漂亮的测试报告出来？能不能定时的跑一下这个脚本？能不能把每次跑脚本的结果能不能直接发到邮箱等等新的想法。。。
为了解决这些问题，不得不学习更多的编程技术，然后测试结构的功能会越来越强大，越来越灵活，产生了一定的通用性和移植性，最后一个有模有样的自动化测试框架就这么的诞生了。
深入学习就会发现自己的知识是不足的，我们就要不断的去学习，正所谓“活到老、学到老”嘛！