• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

如何构建自动化测试框架?

发布: 2009-4-22 10:25 | 作者: 网络转载 | 来源: 测试时代采编 | 查看: 75次 | 进入软件测试论坛讨论

领测软件测试网

做软件测试一段时间后,对自动化测试技术开始产生兴趣,在工作过程中我整理了自己对自动化测试的理解。当时写这个文章的目的,是因为刚刚掌握QTP,又使用自动化测试参与公司一个大项目的测试,结果发现原来掌握QTP距离自动化测试还有很遥远的路要走,原来一直以为掌握了QTP的脚本编写、可以写出所有的测试方法脚本则自动化测试就可以大功告成了。但是现实是残酷的,实际和自己所想的相差太远了——实际的情况是需求变化快,甚至有段时间开发还没有需求变化快,自动化测试脚本的维护工作量就可想而知了。 因此我当时就咨询了一下其他的测试同行,他们都认为测试代码复用是很重要的问题,要搭建一个好的测试框架,这就是我当时写这篇文章的目的。

  但是在写了这篇文章后,因为工作原因没有用实践去验证文章里的思想,直到今天才有时间来温习以前的教训。今天来按实际来做时,发现了一个问题——用什么方式来划分test level service function 的颗粒呢?打个比方来说,我要写一个测试函数,实现以下功能:我要测试的是登录一个系统,打开一个页面,然后新建一条记录。因为还有其他的测试函数,肯定与这个函数有相同的代码部分,比如登录就是显而易见,但是还有一些代码肯定也是重复,而且是隐藏的,那么用什么方法把它们挖掘出来,细分的原则是什么?我实在想不清楚,需要大家的指点.文章里的一些内容取自别人的帖子或与同行的交流,所以只能算是半原创.

  以下只是测试框架的一点设想,需要以后修改;这套方案的最终结果是实现测试自动化,但是因为目前人力、实力有限,只能逐步完善设想中的功能;最终的目的是要实现define the driver——定义驱动测试。

  本文的自动化测试以MI公司的QuickTest professional 为例

  1定义: Services function :业务函数 TestCase(测试用例):是能够从头至尾独立执行的最小测试单元

  测试框架的设想

  1.1Services Function 的分类及分类原则 Service Function的颗粒大小需求不一,靠自己来掌握,总之应该是尽量少的Service Function满足所有Case Function的需要 Common level¬——所有项目测试都可以使用的函数,比如验证小数精度、写测试结果到报告等等。 Common level是公用的函数库,不需要经常修改,因此可以编成DLL文件,供所有的测试脚本使用。使用语法可以这样: ‘------------------------------------ Set object=createobject(“”) Call object.funciton “” ‘------------------------------------  High level¬——各项目专用的测试用例,是为专门的测试项目而设置的,但是这些Services Function不能单独作测试,必须配合更高一级的Test level才能使用 Test level¬¬——Test level可以这样理解:是对某一个用户来说,为了完成某项工作和业务,时间从头至尾相对连续的一组操作。 Test level并不是测试用例,但是它的颗粒大小却决定了其复用程度,因此需要仔细分析每个TestCase的业务逻辑,将相同的Test Level services function 总结出来。 Test level的组成: Function Step ‘测试所要进行的操作 Validation ‘验证测试的结果 Return result ‘返回测试的结果,validation的验证结果也应该通过这一部分的函数写入到result report中 End function

   1.2 Test case 和Test suite  Test Case:测试用例。可以这样理解:是一组人为了完成某项工作和业务,时间从头至尾相对连续的一组操作 Test suite: 是一个相同工作性质的工作部门人员,为了完成某项工作和业务,时间从头至尾相对连续的一组操作。

   Test case和Test suite的意义: 1、大量的Case,肯定是分模块存放的。否则就难以查询和维护、修改。 2、Test Case和Test level \high level service function的互相调用关系可以通过insight sources这个工具来查询。 3、Suite相当于一个Case模块,里面包含很多个Case;比如测试用户管理的,都放在一个Suite里,测试设备管理的,放在另一个suite里。

  1.3TestCase的分类原则 一般复杂Case,要牵扯到好多个模块的功能的,但是要看它的主要测试点是什么,然后按这个测试点所属模块,来确定这个Case归属哪个模块的。 有依赖关系的Case,是合并成一个Case,还是保留独立?运行起来有依赖关系,倾向于合并成一个Case,合并的好处是运行方便,但是出错时要再区分是那个小Case的错误;分开的话,就相反,运行不方便,但出错时比较明确哪个错了。 如果A是建10万个用户,要花1小时的时间,那你还会放在一块嘛,肯定是倾向分开成小Case,不然B出错了,你还得再重头跑ABCD,测试人员会气死的!所以运行麻烦、容易出错、时间较长的小case,还是保持独立,只要跟测试人员写好说明文档,让他们知道正确的运行方法,就可以了 如果合成一个case,我应该把它放到哪个suite里呢 因为它横跨了几个页面,都是测试点,不好划分啊。放在那个Suite里啊,那都可以啊,或者你想独立一个suite也可以啊,无所谓的,只要你运行结果有正确记录,不会漏掉丢失就可以了。 测试环境可以通过重新导入数据来恢复,这样就可以将一部分运行时间长、但是又有依赖关系的Test case分离出来,避免总是要从开头进行测试。 一个Test suite里的用到的lib和OR都是相同的。

  1.4测试用例和Services Function命名规则类型 名称 Test case 项目名_TC_name test level services function 项目名_TL_name high level services function 项目名_HL_name common level services function CL_name(不应包括项目名,因为此类函数是公用的)

  2工作方式并非所有的测试用例都可以用自动化来完成,因此需要对用例进行挑选,选择合适的用例作为自动化测试用例。记住!自动化测试的成本是巨大的,一般来说,一个脚本运行6~7次才算收回成本,因此不可寄予自动化测试过高期望。

  2.1选择自动化测试用例

  2.1.1不适合自动化测试用例的情况 定制型项目(一次性的)。为客户定制的项目,维护期由客户方承担的,甚至采用的开发语言、运行环境也是客户特别要求的,即公司在这方面的测试积累就少,这样的项目不适合作自动化测试。 项目周期很短的项目。项目周期很短,测试周期很短,就不值得花精力去投资自动化测试,好不容易建立起的测试脚本,不能得到重复的利用是不现实的。 业务规则复杂的对象。业务规则复杂的对象,有很多的逻辑关系、运算关系,工具就很难测试。 美观、声音、易用性测试。人的感观方面的:界面的美观、声音的体验、易用性的测试,也只有人来测试。 测试很少运行。测试很少运行,对自动化测试就是一种浪费。自动化测试就是让它不厌其烦的、反反复复的运行才有效率。 软件不稳定。软件不稳定,则会由于这些不稳定因素导致自动化测试失败。只有当软件达到相对的稳定,没有界面性严重错误和中断错误才能开始自动化测试。 涉及物理交互。工具很难完成与物理设备的交互,比如刷卡的测试等。

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: 构建 框架 自动化

21/212>

关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备2023014753号-2
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网