UI自动化测试模型

所谓的自动化测试模型，可以理解为自动化测试框架+工具设计的一种思想产物。

先说说库、框架、工具之间的区别：

库：英文名Library，由代码集成的一个产品，供用户调用。面向对象的库叫做类库，面向过程的库叫做函数库，webdriver就属于库的范畴。

框架：英文名Framework，为解决一个或一类问题而开发的产品，一般只需要使用框架提供的类或函数，即可实现全部功能。前面的博客中提到的unittest框架，

     主要用于实现测试用例的组织和执行，以及测试结果的生成，因此通常称它为单元测试框架。

工具：英文名Tools，相对框架来说更抽象，屏蔽底层代码，一般提供单独的操作界面供用户使用，像QTP、selenium IDE就是自动化测试工具。

 

自动化测试发展至今，常见的测试模型有以下几种类型：

一、线性测试

早期的自动化测试，就是通过录制或者编写应用程序的操作步骤产生响应的线性脚本，来模拟用户完整的操作场景。

优点：单个脚本相对完整，且独立，可拿出来单独执行；

缺点：开发成本很高，测试用例之间可能存在重复操作，每次都要录制或编写重复的操作，比如用户登录；

     维护成本很高，因为存在重复操作，因此如重复操作发生变更，就需要包含重复操作的用例都需要进行修改；

 

二、模块驱动化测试

将重复的操作独立封装为公共模块，用例执行过程中需要用到时调用该公共模块，最大限度的消除重复操作；

优点：提高开发效率，不用重复编写相同的脚本；

     简化了维护的复杂性，如果某个地方发生变化，只需要修改变更内容即可；

 

三、数据驱动测试

即根据数据的改变去驱动自动化测试的执行，最终引起测试结果的改变，简单来说，数据驱动就是数据的参数化，因为输入的不同而引起输出的不同。

数据驱动的方式很多，无论读取的是定义的数组、字典，或是外部文件（excel、csv、txt、xml等），都可以看做数据驱动，目的都是实现数据与脚本分离。

优点：增强脚本的复用性，比如用户登录模块，使用不同的数据进行登录，这样可以很好的适用于相同操作不同数据的情况。

 

四、关键字驱动测试

关键字驱动和数据驱动很相似，通过关键字的改变引起测试结果的改变，也称之为表格驱动测试或基于动作字的测试。

关键字驱动基本上将测试用例分为4个不同的部分，分别是：

测试步骤（Test Step）、测试步骤中的对象（Test Object）、测试对象执行的动作(Action)、测试对象需要的数据（Test Data）。

目前典型的关键字驱动工具以QTP（最新版本叫做UTF）和Robot Framework为主，前者为商业工具，后者开源。

这类工具皆封装了底层代码，提供独立的图形界面，只需使用工具所提供的关键字，以“填表格”的方式来编写用例即可。

缺点：个人认为，这种傻瓜式的测试模型对个人的技术和经验提升，没有太大帮助，我本人还是比较倾向于写代码去实现自动化测试，毕竟，“代码改变世界！”

     不过话说回来，无论是工具还是测试模型，都是辅助我们更好的工作，提升效率；这一点，仁者见仁智者见智，观点不同而已。。。

 

五、综合自动化测试

上面的几种自动化测试模型，有各自的适用场景和优缺点，但实际来说，真实的场景往往比我们预估的更复杂，所以，根据实际情况选择合适的测试模型，综合使用不失为一种比较合理的做法。

个人认为，成功的自动化测试模型，通常都融合了“模块驱动”+“数据驱动/关键字驱动”，优点如下：

1、即拥有脚本与测试数据相互分离的优点，又结合了模块驱动的架构，这样会使得测试脚本更加简洁，并减少运行时意外失败的可能性；

2、该架构可以实现一些纯粹的“数据/关键字驱动测试”难以实现的自动化测试任务；

3、大大减少了测试用例的维护复杂性，提升了脚本开发效率，测试脚本的可复用性、移植性较强；

 

关于具体的测试模型使用实例，后续后不断更新介绍。。。