qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

简单说说自动化测试框架

 什么是框架framework?

  ● 整个或部分系统的可重用设计,表现为一组抽象构件以及构件实例间交互的方法;

  ● 可被开发者定制的应用骨架。

  前者是从应用方面、而后者是从目的方面给出的定义。测试框架也是如此,测试框架出现的最终目的是花少量的资源来完成尽可能多的测试任务,所以测试框架的建立以及框架的重用性方面是最值得测试人员深入探究的地方。

  什么是测试框架?

  测试框架是一组自动化测试的规范、测试脚本的基础代码,以及测试思想、惯例的集合。

  测试框架的好处在于:

  ● 减少冗余代码、提高代码生产率、提高代码重用性和可维护性。提高开发速度,提升测试代码的执行效率;

  ● 提高软件代码质量,同时引入重构概念,让代码更干净和富有弹性;

  ● 提升系统的可信赖度,作为回归测试的一种实现方法支持修复后“再测试”,确保代码的正确性。

  自动化测试框架介绍

  自动化测试框架一般可以分为上下两个层次,上层是管理整个自动化测试的开发,执行以及维护,在比较庞大的项目中,它体现重要的作用,它可以管理整个自动测试,包括自动化测试用例执行的次序、测试脚本的维护、以及集中管理测试用例、测试报告和测试任务等。下层主要是测试脚本的开发,充分的使用相关的测试工具,构建测试驱动,并完成测试业务逻辑。

  测试驱动_A

  测试驱动是一个自动化测试框架的核心,其决定整个自动化脚本设计。当前比较流行的测试驱动有数据驱动和关键字驱动。

  ● 数据驱动

  测试驱动引擎从数据源获取测试数据,然后将数据以参数的形式传递给测试脚本,最后通过执行测试脚本,验证测试结果,并将测试结果输出。一般数据源与测试结果存储在数据库、Excel文件、CSV文件等。数据驱动主要优点是:测试脚本与测试数据的分离,当应用功能变更时,只需要修改该功能部分的脚本;执行测试用例的人员不需要了解测试脚本的实现,只关注测试数据表与测试报告表。而且测试脚本的执行是离散的,即非线性的,测试人员可以有选择的执行测试用例。

  测试驱动_B

  ● 关键字驱动

  关键字驱动的自动化测试框架是在数据驱动的基础上进行改进,数据源里包含的不只是数据,还有关键字,一个测试用例由一个或若干个关键字组成。每个关键字对应个不同的业务逻辑,例如,登录、注销等。数据表通过关键字,查找映射表,执行相关的脚本。

  驱动引擎是对数据表的数据进行分析,根据不同的测试数据或关键字调用相应测试脚本。驱动引擎还需完成一些测试环境初始化、全局参数设置、测试用例是否执行的判断,以及测试报告的处理等。

  测试脚本开发_A

  ● 脚本划分

  为了方便以后脚本的维护问题,必须对脚本进行有效的分层,同时,提高了脚本的复用率。

  → 公共类库

  公共类库包括所有模块都可能用户的操作方法,其抽象了不同模块同性,比如操作excel表的方法、读写测试报告、驱动引擎等。

  → 模块特定类库

  在模块内部将可以为该模块共享使用的方法抽象出来,作为一个公共类。它可以是一个单的逻辑操作,也比较独立。比如客户端登录操作、控制台登录操作、控制台更新操作等。

  → 测试用例脚本

  测试用例脚在最上层,它根据测试点进行设计,面向具体的应用。它可直接调用公共类库或模块特定类库的方法,即调单个逻辑操作。它是单个或多个逻辑操作的集合,即一个测试用户脚本。

 测试脚本开发_B

  ● 脚本规范

  测试脚本的开发也要遵循编程的规则与标准,应该统一规划,所有开发脚本的人员按照统一的规定进行编码。除了编程本身规范,还考虑测试用例与库函数名的命名。

  例如,项目M4.1客户端登录测试用例可命名为:TC_M4.1_client_login;读取excel表的函数可命名为:read_excel。

  测试用例

  ● 测试用例粒度

  测试用例的粒度决定了用例模型级的复杂度,也决定了每一个用例内部的复杂度。应该根据每个系统的具体情况来把握各个层次的复杂度,在尽可能保证整个用例模型的易理解性前提下决定用例的大小和数目。用例不能太大,这样一旦出执行测试用例出错,不利于定位问题;但也不能太细化,太小则不方便执行。

  ● 测试用例与测试套件

  一个大型的项目有许功能模块,必然会产生大量的测试用例,怎样才能有效的管理这些测试用例呢?这就需要创建测试套件,通过测试套件将测试某一个模块或功能点的测试用例集合起来,方便运行与管理。例如,只验证“用户管理”模块功能,则只需要执行“用户管理”模块套件即可。

  选择适合自动化测试的用例

  通常适合自动化测试的用例有:

  ● 产品型项目

  产品型的项目,新版本是在旧版本的基础上进行改进,功能变不大的项目,但项目的新老功能都必须重复的测试。

  ● 回归测试

  回归测试是自动化测试的强项,它能够很好的验证你是否引入了新的缺陷,老的缺陷是否修改过来了。在某种程度上可以把自动化测试工具叫做回归测试工具。

  ● 机械并频繁的测试

  每次需要输入相同、大量的一些数据,并且在一个项目中运行的周期比较长。

  有一些交互性比较强,需要人工干预的操作,就不要指望通过自动化测试来完成了。例如,用户使用U-Key登录。

  软件自动化框架的发展

  基于界面的软件自动化测试框架和工具的发展大致经历了三个阶段

  1.简单的录制/回放:由工具录制并记录操作的过程和数据形成脚本,通过回放来重复人工操作的过程。在这种模式下数据和脚本混在一起,几乎一个测试用例对应一个脚本,维护成本很高。而且即使界面的简单变化也需要重新录制,脚本可重复使用的效率低。

  2.数据驱动 (data_driven)的自动化测试:从数据文件读取输入数据,通过变量的参数化,将测试数据传入测试脚本,不同的数据文件对应不同的测试用例。在这种模式下数据和脚本分离,脚本的利用率、可维护性大大提高,但受界面变化的影响仍然很大。

  3.关键字驱动(keyword_driven)的自动化测试:关键字驱动测试是数据驱动测试的一种改进类型,它将测试逻辑按照关键字进行分解,形成数据文件,关键字对应封装的业务逻辑。 主要关键字包括三类:被操作对象(Item),操作(Operation)和值(value),用面向对象形式可将其表现为 Item.Operation(Value)。关键字驱动的主要思想是:脚本与数据分离、界面元素名与测试内部对象名分离、测试描述与具体实现细节分离。

  从上面可以看到,自动化测试框架和脚本的发展是和软件工程思想的发展一脉相承的。软件开发的模式从面向机器、到面向过程、再到面向对象、面向服务,是一个从底层到高层、从具体到抽象、复用的粒度从细到粗的发展过程。而软件开发中的模块化、层次化、松耦合等思想对自动化测试框架的设计都具有借鉴意义。



posted on 2013-06-21 15:38 顺其自然EVO 阅读(571) 评论(0)  编辑  收藏


只有注册用户登录后才能发表评论。


网站导航:
 
<2013年6月>
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜