在学习了一些WebDriver中的API之后，又学习和了解了自动化测试的模型，觉得受益匪浅，认为很有必要对其中了解到的Point进行一个整理。
在聊自动化测试模型之前，有几个概念同样重要：测试库、测试框架、测试工具。
测试库
库英文单词叫Library，库是由代码集合成的一个产品，供使用者调用。面向对象的代码组织形成的库叫类库，
面向过程的代码组织形成的库叫函数库，
WebDriver就属于库的范畴。
测试框架
框架英文单词叫Framework，框架是为解决一个或一类问题而开发的产品，用户一般只需要使用框架提供的类或函数，即可实现全部功能。
如unittest框架，它主要业内关于实现测试用例的组织和执行，以及测试结果的生成。
测试工具
工具英文单词叫Tools，和框架做的事情类似，但是是经过封装，提供了单独的操作界面，如Selenium IDE。
总结一下，自动化模型可以看作自动化框架和工具设计的思想。
线性测试模型
一种早期的自动化测试形式，单纯的模拟用户完整的操作场景，一般通过录制或者编写对应程序的操作步骤产生对应的线性脚本。
这种模型的优势是每个测试脚本都是完整且独立的，不产生其他依赖和调用，任何一个测试用例脚本都可以拿出来单独执行。但是缺点也相当明显，开发和维护的成本很高：
- 开发成本很高，用例之间可能存在重复的操作，不得不为每一个用例去录制或编写重复的操作，如：登录或退出等操作。
- 维护成本很高，正是因为用例之间存在重复的操作，每次当这些重复的操作发生改变时，就需要逐一对它们进行修改，如：登录输入框的定位发生了变化，就需要对每一个包含登录的用例进行调整。
模块化驱动测试模型
由于线性测试的弊端，所以有了新的测试模型取代。做法也很简单，借鉴了编程语言中模块化的思想，把重复的操作独立成公共模块，当用例执行到这一模块操作时则被调用，这样就最大限度的消除了重复，从而提高测试用例的可维护性。
模块化的结构很好地解决了线性结构的两个问题：
- 提高了开发效率，不用重复编写相同的操作脚本，如：已经写好一个登陆模块，后续测试用例在需要登录的地方调用即可。
- 简化了维护的复杂性，如：登录按钮的定位发生了变化，那么只需要修改登录模块的脚本，对于所有调用的地方不需要任何修改。
数据驱动测试模型
即使有了模块化驱动测试，但是在实际的脚本开发中还是会有许多不便，如：我要测试不同用户登录，首先用的“Test001”用户名登录；下一个测试用例要换成“Test002”用户名登录。在这种情况下，还是需要重复地编写登陆脚本，因为虽然步骤相同，但是数据不同，囧TL。
于是，数据驱动测试也应运而生，数据驱动直白的说其实就是数据的参数化，因为输入数据的不同从而引起输出结果的不同。
这样做的好处显而易见，进一步增强了脚本的复用性。不管我们读取的是txt 文件，还是csv、excel之类的文件，又或者是数组、字典函数，我们扔一千条数据，通过脚本的执行，可以返回一千条结果出来。
关键字驱动测试模型
理解了数据驱动，无非是把“数据”换成“关键字”，关键字的改变引起测试结果的改变，或者可以理解成以“填表格”的形式免除测试人员对写代码的恐惧，从而降低脚本的编写难度。如：Selenium IDE也可以看作是一种传统的关键字驱动的自动化工具。
转化成表格如下：
Command Target Value open http://www.baidu.com click id=kw type id=kw 未迟数字 click id=su
可以看出IDE的录制产生其实是把每一个动作分为三部分：
- 做什么？例如打开、输入、点击等动作。
- 对谁做？通过定位方式找到要操作的对象。
- 如何做？例如输入框输入的内容为“未迟数字”等。
