自动化测试指软件测试的自动化，在预设状态下运行应用程序或者系统.
预设条件包括正常和异常，最后评估运行结果。
 
自动化测试，就是将人为驱动的测试行为转化为机器执行的过程。
【机器 代替 人工】

自动化测试包括UI自动化，接口自动化，单元测试自动化。
按照这个金字塔模型来进行自动化测试规划，可以产生最佳的自动话测试产出投入比（ROI），可以用较少的投入获得很好的收益。

单元测试：

最大的投入应该在单元测试上，单元测试运行的频率也更加高。
不过，单元测试在 开发阶段就可以做，而且一般都是由开发人员来测试。
因为方便开发人员观察代码运行的结果，从而及时修正。
所以说，一般单元测试 开发人员很有可能就顺手做了。
当然，也不排除测试人员来做的。
更常见的方式：开发人员 协助测试人员 进行单元测试。

因为代码不是测试人员写的，不知道某块代码对应的是哪个功能。
所以，一般是需要开发人员来协助的。

接口自动化

接口测试就是API测试，相对于UI自动化，API自动化更加容易实现，执行起来也更稳定。
接口自动化的有以下特点：
1、可在产品前期，接口完成后介入
2、用例维护量小
3、适合接口变动较小，界面变动频繁的项目
 
常见的接口自动化测试工具有，RobotFramework（RF框架），JMeter，SoupUI，TestNG+HttpClient，Postman【推荐使用】等。

UI自动化

虽然测试金字塔告诉我们尽量多做API层的自动化测试，但是UI层的自动化测试更加贴近用户的需求和软件系统的实际业务。
并且有时候我们不得不进行UI层的测试。
 
UI自动化测试是根据 界面元素，对元素进行操作，模拟用户的使用，编写自动化脚本，进行测试。
 
UI自动化的特点：
1、用例维护量大【缺点】
2、页面相关性强，必须在后期项目页面开发完成后介入
3、UI测试适合与界面变动较小的项目
4、可以支持繁琐复杂，手工不易操作，反复执行的功能测试【优点】

UI自动化测试的好处:

1、降低大型系统的由于变更或者多期开发引起的大量的回归测试的人力投入，这可能是自动化测试最主要的任务，特别是在程序修改比较频繁，效果是非常明显的.
 
2、自动化测试前期人力投入较多.，但后期进入维护期后，可节省大量人力，而手工测试后期需要增加大量人力用于回归测试
 
3、减少重复测试的时间，实现快速回归测试
 
4、创建优良可靠的测试过程，减少人为错误
 
5、可以运行更多更繁琐的测试
 
6、可以执行一些手工测试困难 或 不可能进行的测试
 
7、更好的利用资源【脚本的复用性】

UI层自动化测试框架 - Selenium

UI层的测试框架比较多，比如Windows客户端测试的AutoIT，web测试的selenium以及TestPlant，eggPlant，Robot framework，QTP等。
 
我们主要以Web UI自动化测试框架Selenium为例进行详细介绍。

selenium有以下优点：

1、免费，也不用再为破解软件而大伤脑筋
 
2、小巧，对于不同的语言它只是一个包而已，而QTP 需要下载安装1个多G 的程序。

3、支持多平台：windows、linux、MAC ；支持多浏览器：ie、ff、safari、opera、chrome
 
4、支持分布式测试用例的执行，可以把测试用例分布到不同的测试机器执行，相当于分 “学习委员发作业” 的功能。

UI自动化测试的适用对象

实施自动化测试的前提条件：
需求变动不频繁、项目周期足够长、自动化测试脚本可重复使用。
 
适合做自动化的项目：
1、产品型项目
        产品型的项目，新版本是在旧版本的基础上进行改进，功能变动不大的项目，但项目的新老功能都必须重复的进行回归测试。回归测试是自动化测试的强项，它能够很好的验证你是否引入了新的缺陷，老的缺陷是否修改过来了。
在某种程度上可以把自动化测试工具叫做回归测试工具。
 
2、机械并频繁的测试。每次需要输入相同、大量的一些数据，并且在一个项目中运行的周期比较长。比如兼容性测试。
 
以下情况的项目不适合做自动化测试：
1、需求变动频繁的项目，自动化脚本不能重复使用，维护成本太大，性价比低
 
2、项目周期短，自动化脚本编制完成后使用次数不多，性价比低
 
3、交互型较强的项目，需要人工干预的项目，自动化无法实施

如何实施自动化测试

单纯的讲，自动化测试的具体实现，应该是包含下面七个过程的。
1、分析：总体把握系统逻辑，分析出系统的核心体系架构。
2、设计：设计测试用例，测试用例要足够明确和清晰，覆盖面广而精
3、实现：实现脚本，有两个要求一是断言，二是合理的运用参数化。
4、执行：执行脚本远远没有我们想象中那么简单。脚本执行过程中的异常需要我们仔细的去分析原因。 
5、总结：测试结果的分析，和测试过程的总结是自动化测试的关键。

6、维护：自动化测试脚本的维护是一个难以解决但又必须要解决的问题。 
7、分析：在自动化测试过程中深刻的分析自动化用例的覆盖风险和脚本维护的成本。

自动化测试需要了解的技能

了解被测试系统的基本业务
了解业务的技术框架
懂得功能测试
懂得一种编程语言
懂数据库、操作系统
了解常见的测试框架

selenium介绍

Selenium是web应用中基于UI的自动化测试框架，支持多平台、多浏览器、多语言。
 
早期的 selenium RC 已经被现在的webDriver所替代，可以简单的理解为 selenium1.0 + webdriver 构成现在的Selenium2.0。
现在我们说起selenium，一般指的是Selenium2.0。
它由Selenium IDE，Webdriver，Selenium Grid组成。
分别做一下介绍：
1，Selenium IDE

Selenium IDE一个用于Selenium测试的完成集成开发环境，可以直接录制在浏览器的用户操作，并且能回放，编辑和调试测试脚本。调试过程中可以逐步进行或调整执行的速度，并且可以在底部浏览日志出错信息。
录制的测试脚本可以以多种语言导出，比如java，C#，Python，Ruby等，方便掌握不同语言的测试人员操作。

2，Webdriver

Selenium RC 在浏览器中运行 JavaScript 应用，会存在环境沙箱问题，而 WebDriver 可以跳出 JavaScript 的沙箱，针对不同的浏览器创建更健壮的，分布式的，跨平台的自动化测试脚本。
基于特定语言（Java，C#，Python，Ruby，Perl，JavaScript等）绑定来驱动浏览器对Web元素进行操作和验证。
 
webdriver的工作原理：
启动浏览器后，selenium-webdriver会将目标浏览器绑定到特定的端口，启动后的浏览器则作为webdriver 的 remote serve【远程服务器】。
 
客户端【也就是测试脚本】，借助ComandExecutor发送HTTP请求给sever端。【通信协议：The WebDriver Wire Protocol，在HTTP request的body中，会以WebDriver Wire协议规定的JSON格式的字符串来告诉Selenium我们希望浏览器接下来做什么事情】
 
Sever端需要依赖原生的浏览器组件，转化Web Service的命令为浏览器native【本地的 / 原生】的调用来完成操作。

浏览器就好比是出租车，乘客的指令较好比是脚本， webdriver 就好比 司机。
司机（ webdriver）把乘客的“需求（脚本）”，“告诉 / 翻译（操作）” 出租车（浏览器）实现它。

3，selenium Grid

        selenium Grid是一个服务器，提供对浏览器实例访问的服务器列表，管理各个节点的注册和状态信息。可以实现在同一时刻不同服务器上执行不同的测试脚本。 

下载驱动 Chrome driver

安装谷歌浏览器【过程省略】，并且下载驱动 Chrome driver
下载地址：CNPM Binaries Mirror
下载解压，你会得到一个chromedriver.exe 文件 
只有安装了对应的driver才能运行对应的浏览器

禁止 Chrome 浏览器更新

selenium + Java 环境搭建

这个操作前面已经做了。记住 驱动的版本 一定要和 浏览器的版本一致，并且一定要进制 浏览器的自动更新服务！！！
不然，浏览器每更新一次，我们都需要去下载对应版本的驱动。
不同之处来了！！
我们需要将驱动，再拷贝一份放到 jdk 的 bin 的目录下。

2、下载selenium

这个我们直接在项目中使用 Maven 引入 就行了，无需关注！

那么驱动在其中又担当什么角色呢？
既然能够接收请求的，驱动应该是一个服务器，那么就需要知道它的IP 和 端口号，才能定位它。
下面我们来打开 Chrome 浏览器的驱动，看一下究竟是否像我们想象的那样。

通过上述的分析，我们确认是 驱动就是一个服务器。

接着我们继续分析：
当我们的脚本的代码生成一个HTTP请求 发送到 浏览器驱动（WebDrive）的时候，WebDrive 会对这个请求进行解析，然后再发送给我们的浏览器，让我们的浏览器以原生的方式去执行前端的一个命令。

在浏览器执行完成之后，会把执行的结果返回 驱动，驱动再把这个结果传递给我们的脚本代码