Webdriver工作原理

·     启动脚本时，Webdriver会启动一个新的线程去启动浏览器，这里启动浏览器有两种方式：带用户信息、不带用户信息。

·     启动了浏览器之后，Webdriver会把这个浏览器绑定在一个特定的端口上面（此时可将浏览器理解为服务端，脚本是一个客户端），此时通过脚本来操纵浏览器（如发送一个请求），浏览器就会做相应的处理并将结果返回给客户端。

·      

常见的自动化测试架构
       一个自动化测试架构就是一个集成体系，其中定义了一个特殊软件产品的自动化测试规则。这一体系中包含测试功能函数库、测试数据源、测试对象识别标准，以及各种可重用的模块。这些组件作为小的构建模块，被组合起来代表某种商业流程。自动化测试架构提供了自动化测试的基础，降低了自动化测试的难度。

常见的自动化架构包括如下：
1、数据驱动测试
       数据驱动测试将测试脚本与测试数据放在同一个测试架构中。该测试架构提供可重用的测试逻辑，目的是减少测试维护工作量和改善测试覆盖率。测试输入数据和测试结果数据都会被存储在一个或者 多个数据源、数据库中，数据存储格式和数据组织方式依赖于具体实现。测试数据与测试逻辑分离，当测试数据发生改变时，不会影响测试逻辑。同一个测试逻辑可以针对不同数据来进行测试，提高了 测试逻辑的使用效率和可维护性。

2、模块驱动测试
       模块驱动测试使用独立的小脚本来对应待测试的模块、零件和子功能。这些不同层级的小脚本按照一定规则组合成更大级别的测试，如此就实现了一个特定功能的自动化测试案例。在所有自动化测试架构中，他应该是最容易领会和控制的一种。有这样一种编程策略，他的应用非常广泛，即屏蔽组件的内部实现，仅提供组件的对外抽象接口。如此下层的测试组件发生变动时，对上层自动化测试案例来说是透明的。模块驱动测试引入了抽象和封装的原则，目的是提升自动化测试的可维护性和可扩展性。

3、关键字驱动测试
       关键字驱动测试也被称为“表格驱动测试”或“操作名测试”，它是一种软件自动化测试的方法论。它将自动化测试的创建过程分为两个不同的阶段：设计阶段和实现阶段。
（1）设计阶段的一个简单例子：
Object Action Data
Textfield(username) Enter text <username>
一个更复杂的例子如下
Object Action Data
Textfield(domain) Enter text <domain>
Textfield(usrname) Enter text <usrname>
Textfield(password) Enter text <password>
Button(Login) Click <left click>
(2)实现阶段依赖于具体使用的测试工具，通常自动化测试引擎会提供设计阶段定义的关键字，类似于“check”或“enter”。测试人员基于这些关键字来编写测试案例。测试案例执行时会有一个驱动程序来读取这些关键字，并执行相应的代码。
优点：
A、在一个较长软件维护周期内，显著减少维护工作量，使得：
测试案例简洁
测试案列可读性高
测试案列易于修改
新的测试案列可以很方便地复用已经存在的关键字
B、关键字可以跨越多个测试案例进行复用。
C、不依赖与某种语言或者某个工具。
D、让员工集中精力在自己所擅长的地方，如
测试案列的构建需要专业领域知识-而不需要太多编程测试工具知识
关键字的实现需要丰富的测试工具、编程-而不需要太多的专业领域知识。
E、可以对自动化测试划分抽象层级
缺点：
创建自动化测试需要更长的时间（相比于手工测试和录制-回放技术）
需要更长的学习、掌握周期。

4、混合自动化测试
       混合自动化测试是由其他自动化测试框架综合发展起来的。成功的自动化测试框架通常融合了“关键字驱动测试”和“数据驱动测试”。他们即拥有测试逻辑与测试数据相互分离的优点，又集成了关键字驱动的先进架构。这一架构会使得数据驱动脚本更加简洁，并减少运行时意外失败的可能性。另一方面，该架构可以实现一些纯粹的“关键字驱动测试”难以实现的自动化测试任务。该架构由核心数据驱动引擎、功能函数组件，以及支持库所构成。

5、基于模型测试
       基于模型测试适合于采用“基于模型设计”的软件系统。在这种架构下，会有一个成熟的测试模型来描述测试数据的所有方面，以及测试案例和案例执行环境。通常这一测试模型是全部或者部分从待测试系统功能模型中提取出来的。测试模型描述了待测试系统的抽象行为，因此从测试模型中可以派生出功能测试案例。这些测试案例构成了抽象测试案例集，不过抽象测试案例集不能直接在待测试系统上执行。真正可以执行的测试案例集（可以与待测试系统进行交互），是从抽象测试案例集派生出来的。有些基于模型测试的测试工具，支持从模型（包含足够信息）产生可执行测试案例集，
       从模型派生出案例，可以有很多种方式，因此测试很多时候是依靠经验去尝试，并没有固定的最佳方法。你需要事先收集“测试需求、测试目标，用户用例"因为他们包含待测试系统模型的信息。测试案例集是从模型而非代码派生出来的，因此基于模型测试可以被视为某种黑盒测试。事实上，基于模型测试目前只适合于功能不太负责的软件系统，复杂商业软件系统的基于模型测试，还处于探索阶段。

Webdriver工作原理

·     启动脚本时，Webdriver会启动一个新的线程去启动浏览器，这里启动浏览器有两种方式：带用户信息、不带用户信息。

·     启动了浏览器之后，Webdriver会把这个浏览器绑定在一个特定的端口上面（此时可将浏览器理解为服务端，脚本是一个客户端），此时通过脚本来操纵浏览器（如发送一个请求），浏览器就会做相应的处理并将结果返回给客户端。

·      

常见的自动化测试架构
       一个自动化测试架构就是一个集成体系，其中定义了一个特殊软件产品的自动化测试规则。这一体系中包含测试功能函数库、测试数据源、测试对象识别标准，以及各种可重用的模块。这些组件作为小的构建模块，被组合起来代表某种商业流程。自动化测试架构提供了自动化测试的基础，降低了自动化测试的难度。

常见的自动化架构包括如下：
1、数据驱动测试
       数据驱动测试将测试脚本与测试数据放在同一个测试架构中。该测试架构提供可重用的测试逻辑，目的是减少测试维护工作量和改善测试覆盖率。测试输入数据和测试结果数据都会被存储在一个或者 多个数据源、数据库中，数据存储格式和数据组织方式依赖于具体实现。测试数据与测试逻辑分离，当测试数据发生改变时，不会影响测试逻辑。同一个测试逻辑可以针对不同数据来进行测试，提高了 测试逻辑的使用效率和可维护性。

2、模块驱动测试
       模块驱动测试使用独立的小脚本来对应待测试的模块、零件和子功能。这些不同层级的小脚本按照一定规则组合成更大级别的测试，如此就实现了一个特定功能的自动化测试案例。在所有自动化测试架构中，他应该是最容易领会和控制的一种。有这样一种编程策略，他的应用非常广泛，即屏蔽组件的内部实现，仅提供组件的对外抽象接口。如此下层的测试组件发生变动时，对上层自动化测试案例来说是透明的。模块驱动测试引入了抽象和封装的原则，目的是提升自动化测试的可维护性和可扩展性。

3、关键字驱动测试
       关键字驱动测试也被称为“表格驱动测试”或“操作名测试”，它是一种软件自动化测试的方法论。它将自动化测试的创建过程分为两个不同的阶段：设计阶段和实现阶段。
（1）设计阶段的一个简单例子：
Object Action Data
Textfield(username) Enter text <username>
一个更复杂的例子如下
Object Action Data
Textfield(domain) Enter text <domain>
Textfield(usrname) Enter text <usrname>
Textfield(password) Enter text <password>
Button(Login) Click <left click>
(2)实现阶段依赖于具体使用的测试工具，通常自动化测试引擎会提供设计阶段定义的关键字，类似于“check”或“enter”。测试人员基于这些关键字来编写测试案例。测试案例执行时会有一个驱动程序来读取这些关键字，并执行相应的代码。
优点：
A、在一个较长软件维护周期内，显著减少维护工作量，使得：
测试案例简洁
测试案列可读性高
测试案列易于修改
新的测试案列可以很方便地复用已经存在的关键字
B、关键字可以跨越多个测试案例进行复用。
C、不依赖与某种语言或者某个工具。
D、让员工集中精力在自己所擅长的地方，如
测试案列的构建需要专业领域知识-而不需要太多编程测试工具知识
关键字的实现需要丰富的测试工具、编程-而不需要太多的专业领域知识。
E、可以对自动化测试划分抽象层级
缺点：
创建自动化测试需要更长的时间（相比于手工测试和录制-回放技术）
需要更长的学习、掌握周期。

4、混合自动化测试
       混合自动化测试是由其他自动化测试框架综合发展起来的。成功的自动化测试框架通常融合了“关键字驱动测试”和“数据驱动测试”。他们即拥有测试逻辑与测试数据相互分离的优点，又集成了关键字驱动的先进架构。这一架构会使得数据驱动脚本更加简洁，并减少运行时意外失败的可能性。另一方面，该架构可以实现一些纯粹的“关键字驱动测试”难以实现的自动化测试任务。该架构由核心数据驱动引擎、功能函数组件，以及支持库所构成。

5、基于模型测试
       基于模型测试适合于采用“基于模型设计”的软件系统。在这种架构下，会有一个成熟的测试模型来描述测试数据的所有方面，以及测试案例和案例执行环境。通常这一测试模型是全部或者部分从待测试系统功能模型中提取出来的。测试模型描述了待测试系统的抽象行为，因此从测试模型中可以派生出功能测试案例。这些测试案例构成了抽象测试案例集，不过抽象测试案例集不能直接在待测试系统上执行。真正可以执行的测试案例集（可以与待测试系统进行交互），是从抽象测试案例集派生出来的。有些基于模型测试的测试工具，支持从模型（包含足够信息）产生可执行测试案例集，
       从模型派生出案例，可以有很多种方式，因此测试很多时候是依靠经验去尝试，并没有固定的最佳方法。你需要事先收集“测试需求、测试目标，用户用例"因为他们包含待测试系统模型的信息。测试案例集是从模型而非代码派生出来的，因此基于模型测试可以被视为某种黑盒测试。事实上，基于模型测试目前只适合于功能不太负责的软件系统，复杂商业软件系统的基于模型测试，还处于探索阶段。