UI自动化测试模型

服务器

浏览数:33

2019-10-7

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

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

库:英文名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、大大减少了测试用例的维护复杂性,提升了脚本开发效率,测试脚本的可复用性、移植性较强;

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

 

作者:老_张