软件开发的过程是一个持续集成和改进的过程，而每一次的改进都可能引进新bug,因此当软件的一部，或者全部修改时，都需要对软件产品重新进行测试。
其目的是要验证修改后的产品是符合需求的，而当没有自动化测试代码时，往往会由于各种各样的原因，回归不充分，导致bug遗漏。
自动化测试模型
一个自动化测试框架就是一个集成体系，在这一体系中包含测试功能的函数库、测试数据源、测试对象识别标准，以及种可重用的模块。
自动化测试框架在发展的过程中，不断有新的模型（概念）被提出，目前经历了几个阶段:模块驱动测试、数据驱动测试、对象驱动测试。
自动化测试模型是自动化测试架构的基础。
线性测试
通过录制或编写脚本，一个脚本完成一个场景（一组完整功能操作） ，通过对脚本的回放来进行自动化测试；
优势就是每一个脚本都是独立的，任何一个脚本文件拿出来就能单独运行；
缺点也很明显，用例的开发与维护成本很高；
这种模式下数据和脚本是混在一起的，如果数据发生变也需要对脚本进行修改。这种模式下的脚本没有可重复使用的概念；
模块化与类库
把脚本中重复使用的部分代码独立出来，形成公共的模块或库，需要的时候进行调用；
优点：提高了开发效率，不用重复的编写相同的脚本；方便了代码的维护，代码的更改限制在模块之内；
数据驱动
数据的改变（更新）驱动测试自动化的执行，从而引起测试结果的改变；
可以直白地理解成“输入数据的不同从而引起输出结果的变化”；
优点是实现了数据与脚本的分离（参数化），增强的脚本的复用性；
在开发层面，易于实现；
关键字驱动
理解了数据驱动，无非是把“数据”换成“关键字”，通过关键字的改变引起测试结果的改变；
独立以编程方式实现关键字驱动似乎不太容易，一般是利用现有工具和框架；
在QTP、robot framework 等此类型的测试工具中， “填表格”式的关键字驱动封装了很多底层的东西，易用性强；
测试人员只要考虑三个问题：要做什么？ 对谁做？怎么做？
自动化测试用例
| 自动化测试用例 | 手工测试用例 |
|---|---|
| 执行对象是脚本，任何一个判断都需要编码定义。 | 较好的异常处理能力，能通过人为的逻辑判断校验当前步骤的功能实现正确与否 |
| 用例步骤之间关联性强。 | 人工执行用例具有一定的步骤跳跃性。 |
| 主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工作中解脱出来。 | 人工测试步步跟踪，能够细致的定位问题。 |
| 主要定位在冒烟测试和回归测试 | 主要用来发现功能缺陷 |
自动化测试替代不了手工测试，目的仅仅在于让测试人员从繁琐重复的机械式测试过程解脱出来，把时间和精力突入到更有价值的地方，从而挖掘更多的产品缺陷。
- 冒烟测试执行的是主体功能点的用例。
- 回归测试执行全部或部分的测试用例。
自动化测试用例设计
一些注意事项：
- 不是所有的手工用例都要转为自动化测试用例。
- 考虑到脚本开发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分多个用例来实现脚本。
- 选择的用例最好可以构建成场景。例如一个功能模块，分 n 个用例，这 n 个用例使用同一个场景。这样的好处在于方便构建关键字测试模型。
- 选择的用例可以带有目的性，例如这部分用例是用例做冒烟测试，那部分是回归测试等，当然会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求。
- 选取的用例可以是你认为是重复执行，很繁琐的部分，例如字段验证，提示信息验证这类。这部分适用回归测试。
- 选取的用例可以是主体流程，这部分适用冒烟测试。
- 自动化测试也可以用来做配置检查，数据库检查。这些可能超越了手工用例，但是也算用例拓展的一部分。项目负责人可以有选择地增加。
- 如果平时在手工测试时，需要构造一些复杂数据，或重复一些简单机械式动作，告诉自动化脚本，让他来帮你。或许你的效率因此又提高了
一些原则：
- 一个脚本是一个完整的场景
- 一个脚本只验证一个功能点
- 遵循用户正常使用原则编写脚本，尽量只做功能中正向逻辑的验证。不要考虑太多逆向逻辑的验证（逆向逻辑的情况会很多，需要编写大量的脚本，而且非正常的逻辑难以被自动化脚本所验证）
- 在整个脚本中只对验证点进行验证，不要对整个脚本每一步都做验证。
- 如果对数据进行了修改，需要对数据进行还原。
- 脚本之间不产生关联性，也就是说编写的每一个脚本都是独立的，不能依赖或影响其他脚本。
软件过程自动化
- 构建自动化：自动化从各个模块的源码构建组装成一个完整的产品
- 测试自动化：构建前自动完成相应的测试工作
- 部署自动化：对于通过测试的构建好的产品，做好成品测试后，自动化部署到生产服务器
- 自动化场合选取：尽量对稳定的对象做自动化，如API接口；GUI不建议使用自动化，投资回报比太低，变更大
- 自动化比例：基于稳定的测试环境和测试计划；在效率和质量上寻求平衡点
自动化测试的实施
适合做自动化测试的项目
-
软件需求变动不频繁
测试脚本的稳定性决定了自动化测试的维护成本。
如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本。
而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。
项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。 -
项目周期较长
自动化测试需求的确定、框架的设计、脚本的编写与调试，这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。
如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。 -
自动化测试脚本可重复使用
所测试的项目之间是否很大的差异性（如C/S系统和B/S系统的差异）；
所选择的测试工具是否适应这种差异；
测试人员是否有能力开发出适应这种差异的自动化测试框架。
不同阶段对应的自动化测试
-
单元测试
关注代码的实现逻辑，例如一个if 分支或一个for循环的实现；
利用相应的单元测试框架，几乎所有的主流语言，都会有其对应的单元测试框架。 -
集成、接口测试
关注函数、类（方法）所提供的接口是否可靠。 -
UI层的功能测试
通过相应的自动化测试工具来模拟UI层的功能测试，从而解放重复的劳动。
自动化测试应该侧重于单元测试与接口测试。然后有选择有必要地通过自动化方式“部分解放”UI层的重复劳动。
三种测试的比例要根据实际的项目需求来划分。
以google为例，70%的投入为单元测试，20%为集成、接口测试，10% 为UI层的自动化测试（《google 测试之道》）。