一、线性脚本 线性脚本的优点：
1. 线性脚本不需要深入的工作或计划，只需坐在计算机前利用自动化测试工具录制手工测试任务即可。
2. 线性脚本可以快速开始自动化，测试工程师只需理解测试流程即可开展自动化测试工作，同时也是树立测试工程师开始对自动化感兴趣最快速的方法和技术。
3. 线性脚本对实际执行操作可以进行审计跟踪。
4. 使用线性脚本技术，用户不必是编程人员（假设不需修改脚本，用户不必关心脚本本身）。
5. 线性脚本提供良好的演示效果。
线性脚本的缺点：
1. 过程繁琐：产生可行的自动化测试（包括比较）的时间比运行手工测试要长2到10倍。
2. 一切都依赖于每次测试所捕获的内容。
3. 测试输入和比较，以及测试的数据和业务都是‘捆绑’在脚本中的，不便于修改测试数据和测试步骤。
4. 脚本不能共享和重用。
5. 由于线性脚本要求测试的对象相对比较的固定，因此容易受软件变化的影响。
6. 线性脚本修改代价大（维护成本高）。
7. 如果回放脚本时发生了录制脚本时没有发生的事情，如来自网络的意外错误消息，脚本很容易与被测试软件发生冲突，引起整个测试失败。
线性脚本的适用范围：
1. 当测试事例只使用一次时，则无需对将要丢弃的脚本花费太多的功夫，线性脚本便非常方便使用。
2. 线性脚本适合在做培训或演示时，可以回放录制好的脚本来代替击键动作。
3. 线性脚本可以用于转换。如系统的某一部分发生变化，但从用户的角度不能影响系统的工作，可以录制有用数据，替换软件或硬件，然后回放录制过程可以使新系统恢复到初始状态。
4. 线性脚本可以用自动编辑来修改自动测试，任何特定的修改只做一次，因此一次性的脚本足以满足需求。
5. 线性脚本可用于设置和清除测试，通过回放输入序列操作文件或数据库进行相应的记录的设置和清除。
二、结构化脚本
目前所有测试脚本支持三种基本控制结构如下：
顺序结构（即前面的线性脚本，依次执行每行的指令）。
选择结构：使脚本具有判断功能，即加入类似“if，switch”类型的语句来使脚本的执行具有跳跃能力，按照判断条件执行相关的指令。
叠代/循环结构：可以根据需要重复执行一个或多个指令序列如加入像“for，while”等语句。
结构化脚本类似于结构化程序设计，脚本中含有控制脚本执行的指令，这些指令或为控制结构或为调用结构。结构化脚本可以进行嵌套调用另一个脚本，执行完后在返回到当前脚本。
结构化脚本的优点：
1. 结构化脚本健壮性更好，对一些容易导致测试失败的特殊情况和测试中出现的异常情况可以进行相应的处理。
2. 结构化脚本可以像函数一样作为模块被其他脚本调用或使用。
3. 结构化脚本可以提高脚本的重用性和灵活性，使得代码易于维护，可以更好的支持自动化测试。
结构化脚本的缺点：
1. 脚本变得非常复杂，在一定程度上增加了另外的维护工作量。
2. 脚本还是在录/播的基础上实现的，因此脚本内仍然捆绑着测试的数据和逻辑，即键盘、鼠标动作表示的输入被固化在脚本中，测试修改和定制非常复杂困难。
三、共享脚本
共享脚本意味着脚本可以被多个测试事例使用，即脚本语言允许一个脚本被另一个脚本调用，这样可以节省生成脚本的时间。当重复任务发生变化时，只需修改一个脚本。共享脚本可以是在不同主机、不同系统之间共享脚本，也可以是在同一主机、同一系统之间共享脚本。此脚本开发的思路是产生一个执行某种任务的脚本，而不同的测试要重复这个任务，当要执行这个任务时只要在适当的地方调用这个脚本便可以了。
共享脚本的优点：
1. 共享脚本使得实现类似的测试花费的开销较少。
2. 共享脚本的维护开销低于线性和结构化脚本。
3. 共享脚本中删除明显的重复代码，这样代码更加简洁易懂。
4. 可以在共享脚本中增加更智能的功能，如认为的等待一定时间再次运行某个功能。
共享脚本的缺点：
1. 需要跟踪更多的脚本、文档、名字以及存储。如果管理不好，很难找出适合的脚本。
2. 对于每个测试用例仍需一个特定的测试脚本，因此维护成本比较高。
3. 共享脚本通常是针对测试软件的某一部分，不能实现真正意义上的共享。
共享脚本的编写需要更高的编程技能，提高了对测试工程师的要求数据驱动脚本是当前广泛应用的自动化测试脚本技术，它是将测试输入数据存储在数据文件里，而不是继续放在脚本本身里面。脚本里只存放控制信息，执行测试时，从文件中而不是从脚本中读取数据输入，从而使得同一个脚本可以执行不同的测试，实现了数据与脚本的分离，但测试逻辑依然与脚本捆绑在一起。
四、数据驱动脚本
数据驱动脚本的优点：
1. 在数据驱动脚本的层次上，自动化测试可以真正从中获益，可以以较小的额外开销实现很多测试事例的自动化，不需要编写更多的脚本。
2. 在数据驱动脚本中，数据文件的格式对于测试者而言非常易于处理，甚至可以在数据配置文件里添加很多方便维护的注释来增加数据的可理解性。
3. 数据驱动脚本技术使得测试工程师可以将更多的时间和精力放在自动化测试和维护测试上。
4. 数据驱动脚本技术对于测试事例的数据输入和维护带来了极大的方便。
5. 在数据驱动脚本中，甚至连期望结果都可以从脚本中提取出来，使得脚本的维护工作变得更为简单。
6. 对于一组功能强大灵活的数据驱动脚本，测试者本人甚至不需具有脚本编程技能，而只需掌握数据文件的配置方法，便可轻松的使用脚本完成自己的测试
数据驱动脚本的缺点：
1. 需要具有一定编程背景知识的人员加入到脚本编写里面。
2. 因为脚本变得逻辑性更强，引入更多的控制指令，初始脚本建立时间和开销较大。
3. 如果开发出的脚本不规范，则后期的管理和维护会带来巨大的工作量，对于测试工程本人来说需要的技能也更高。
五、关键字驱动脚本
关键字驱动脚本实际上是较复杂的数据驱动脚本的逻辑扩展。数据驱动脚
本的限制是每个测试事例执行的导航和操作必须一样，测试的逻辑知识建立在数据文件和控制脚本中。关键字驱动脚本将数据文件变为测试事例的描述，用一系列关键字指定要执行的任务。关键字驱动脚本的一个特点是它看起来更像描述一个测试事例做什么，而不是如何做。前面四种脚本是说明性方法的脚本，只有关键字驱动脚本是描述性方法，因而它更容易理解。描述性方法是将被测软件的知识建立在测试自动化环境中，相关的知识包含在支持脚本中，这些支持脚本了解被测软件，但是不需要了解测试事例。
核心思想为三个分离
1）界面元素名与测试内部对象名的分离在被测应用程序和录制生成的测试脚本之间增加一个抽象层，它可以将界面上的所有元素映射成相对应的一个逻辑对象，测试针对这些逻辑对象进行，界面元素的改变只会影响映射表，而不会影响测试。
2）测试描述与具体实现细节的分离
把测试描述和测试的具体实现细节分离开来。测试描述只说明软件测试要做什么以及期待什么样的结果，而不管怎样执行测试或怎样证实结果。这样做是因为测试的实现细节通常与特定的平台以及特定的测试执行工具有着密切的联系。这种分离使得测试描述对于应用实现细节是不敏感的，而且有利于测试在工具和平台间的移植。
3）脚本与数据的分离 最后，可以把测试执行过程中所
需的测试数据从脚本中提取出来，在运行时测试脚本再从数据存放处读取预先定制好的数据，这样脚本和数据可以独立维护。
以上这三个分离各司其职、互相独立，最大程度地减少相互之间的影响。从关键字驱动的思想可以看出，该种测试框架不仅实现了将数据和脚本相分离，而且实现了测试逻辑和数据的分离，大大提高了脚本的复用度和维护性，从而更大限度地实现了测试工具的自动化
根据测试用例得出自动化测试框架的典型要素
1）公用的环境
不同测试用例也会用到相同的测试环境，将该测试环境独立封装，在各个测试用例中灵活调用，可以增强脚本的可维护性。
2）公用的对象
成功的框架开发需要确定领域专用的“热点”（Hot spot）。所以在开发过程中必然存在大量相同的对象（如窗口、按钮、页面等）。将对象抽取出来形成一个独立的可重用强的个体，当对象的属性需要变更时做到只需修改对象属性而无需修改脚本。
3）公用的方法
将方法封装成独立的函数，通过参数的形式调用，尽量做到和数据无关。
