自动化测试框架与模型
一个自动化测试框架就是一个集成体系，在这一体系中包含测试功能的函数库、测试数据源、测试对象识别标准，以及种可重用的模块。
自动化测试框架在发展的过程中经历了几个阶段，模块驱动测试、数据驱动测试、对象驱动测试。
自动化测试模型是自动化测试架构的基础。
自动化测试的发展过程中，不断有新的模型（概念）被提出，了解和使用这些自动化模型将有助构建一个灵活可维护性的自动化架构。
自动化测试的几种不同的模型，并非后者淘汰前者的关系；
在实施自动化更多的是以需求为出发点，混合使用，目的是解决问题，使脚本更易于开发与维护；
线性测试 --- 早期自动化测试的一种形式
- 通过录制或编写脚本，一个脚本完成一个场景（一组完整功能操作） ，通过对脚本的回放来进行自动化测试；
- 优势就是每一个脚本都是独立的，任何一个脚本文件拿出来就能单独运行；
- 缺点也很明显，数据和脚本是混在一起，脚本无法重复使用，导致用例的开发与维护成本很高；
模块化与类库
- 把脚本中重复使用的部分代码独立出来，形成公共的模块或库，需要的时候进行调用；
- 优点：提高了开发效率，不用重复的编写相同的脚本，方便了代码的维护，代码的更改限制在模块之内；
数据驱动
- 数据的改变（更新）驱动测试自动化的执行，从而引起测试结果的改变；
- 可以直白地理解成“输入数据的不同从而引起输出结果的变化”；
- 优点是实现了数据与脚本的分离（参数化），增强的脚本的复用性，在开发层面，易于实现；
关键字驱动
- 理解了数据驱动，无非是把“数据”换成“关键字”，通过关键字的改变引起测试结果的改变；
- 独立以编程方式实现关键字驱动似乎不太容易，一般是利用现有工具和框架；
- 在QTP、robot framework 等此类型的测试工具中， “填表格”式的关键字驱动封装了很多底层的东西，易用性强；
- 测试人员只要考虑三个问题：要做什么？ 对谁做？怎么做？
简要对比手工测试用例与自动化测试用例
- 较好的异常处理能力，能通过人为的逻辑判断校验当前步骤的功能实现正确与否。
- 人工执行用例具有一定的步骤跳跃性。
- 人工测试步步跟踪，能够细致的定位问题。
- 主要用来发现功能缺陷
自动化测试用例
- 执行对象是脚本，任何一个判断都需要编码定义。
- 用例步骤之间关联性强。
- 主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工作中解脱出来。
- 目前自动化测试阶段定位在冒烟测试和回归测试
两者之间的关系
自动化测试替代不了手工测试，目的仅仅在于让测试人员从繁琐重复的机械式测试过程解脱出来，把时间和精力突入到更有价值的地方，从而挖掘更多的产品缺陷。
目前自动化测试更多的时候是定位在冒烟测试和回归测试；
- 冒烟测试执行的是主体功能点的用例
- 回归测试执行全部或部分的测试用例
自动化测试用例选型注意事项
1、 不是所有的手工用例都要转为自动化测试用例。
2、 考虑到脚本开发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分多个用例来实现脚本。
3、 选择的用例最好可以构建成场景。例如一个功能模块，分 n 个用例，这 n 个用例使用同一个场景。这样的好处在于方便构建关键字测试模型。
4、 选择的用例可以带有目的性，例如这部分用例是用例做冒烟测试，那部分是回归测试等，当然会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求。
5、 选取的用例可以是你认为是重复执行，很繁琐的部分，例如字段验证，提示信息验证这类。这部分适用回归测试。
6、 选取的用例可以是主体流程，这部分适用冒烟测试。
7、 自动化测试也可以用来做配置检查，数据库检查。这些可能超越了手工用例，但是也算用例拓展的一部分。项目负责人可以有选择地增加。
8、 如果平时在手工测试时，需要构造一些复杂数据，或重复一些简单机械式动作，告诉自动化脚本，让他来帮你。或许你的效率因此又提高了
编写自动化测试用例的几个原则
1、一个脚本是一个完整的场景
2、一个脚本脚本只验证一个功能点
3、尽量只做功能中正向逻辑的验证，不要考虑太多逆向逻辑的验证，
逆向逻辑的情况很多，验证一方面比较复杂，需要编写大量的脚本，
另一方面自动化脚本本身比较脆弱，很多非正常的逻辑的验证能力不强。 （遵循用户正常使用原则编写脚本即可）
4、脚本之间不要产生关联性，也就是说编写的每一个脚本都是独立的，不能依赖或影响其他脚本。
5、如果对数据进行了修改，需要对数据进行还原。
6、在整个脚本中只对验证点进行验证，不要对整个脚本每一步都做验证。