51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

测试开发精英班,通向高级软件测试工程师论坛测试积点免费获取渠道攻略什么样的人才需要实战项目?横扫BAT,Python全栈测试开发技能大全
【113期】:Web安全测试你来问我来答!中国软件测试行业现状调查报告新鲜出炉! 【杂志】做测试行业不偏科的尖子生! 自学软件测试那点事
查看: 14547|回复: 27

如何构建自动化测试框架?(10-05-24)(获奖名单已公布)

[复制链接]

该用户从未签到

发表于 2010-5-24 14:47:19 | 显示全部楼层 |阅读模式
自动化测试之初,业界并无框架一说,某日,江湖传闻“自动化测试框架”,其为何物不得而知,只知其能助软件企业一臂之力。顿时,江湖掀起“框架”狂潮,“自动化测试框架”百花齐放,百家争鸣。尤以“测试模块化”,“业务流程测试”,“数据驱动”,“关键字驱动”,“智能测试自动化”等曝光率最高。江湖中人个个擦亮眼睛,欲窥其真谛,然框架始终以面纱罩之,亦朦胧亦神秘。
今欲邀天下测试之士,共商框架大事,如能聚天下之言,掀其神秘面纱,甚喜,甚幸!

如果你也有问题想提出来和大家一起讨论,请点击此处>>
说不定下期讨论的问题就是由你提出的哦,请快快参与吧!



获奖名单
奖项
获奖名单
奖励
答案链接
一等奖
san
50元话费充值卡
12#
二等奖
liaoxj
300论坛积分
21#
三等奖
dennyqiang
100论坛积分
22#
回复

使用道具 举报

  • TA的每日心情
    奋斗
    4 小时前
  • 签到天数: 132 天

    连续签到: 1 天

    [LV.7]测试师长

    发表于 2010-5-25 08:48:24 | 显示全部楼层
    先占位,关注中。。。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2010-5-25 10:55:50 | 显示全部楼层

    qc与qtp结合的自动化测试框架构成

    在公司尝试启用自动化测试已经有三年的时间了,但是一直似乎都是口号式的,年初计划的很好,但是在实际的操作过程中,遇到的技术难题较多,可值得交流人和借鉴的经验很少,在加上公司项目较多,测试人员较忙,几乎没有专门的时间去研究自动化测试,因此每年都是不了了之。如此反复两年,真的是浪费呀。
          年初研究出的自动化测试框架是:<qc的业务组件与qtp相结合的自动化测试框架>,具体操作时将被测系统中的模块按功能进行划分---将划分出的功能设计成组件---由qtp去实现组件的功能---qc测试计划中选择组件实现业务流程的覆盖并设置相关的测试数据--在qc测试集中选择业务流程进行自动执行进行自动化测试。
       在具体的实现过程中牵扯到很多的技术细节,在这里不再一一介绍,算是抛砖吧,希望大家能将自己使用的自动化框架共享出来了。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2010-5-25 11:11:44 | 显示全部楼层
    QC与QTP结合得很好,可以把共同的功能模块设计好,调用就行了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2010-5-25 15:24:23 | 显示全部楼层
    关注中。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2010-5-25 20:39:08 | 显示全部楼层
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2010-5-25 22:43:38 | 显示全部楼层
    我这方面有些心的,但是落地纸面上没有时间。:)

    PS:我的部门项目里已经做到60%是自动化,其中引擎类接近100%,UI相对低一些。自动化用例数量大概在10000+
    如果大家很关心这个问题,我们可以安排一个讨论,因本人在上海,以及工作原因,可以安排在周末。
    如果大家不关心,那就算了,就当我没有说。

    [ 本帖最后由 JamesHao 于 2010-6-3 13:54 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2010-5-26 01:26:05 | 显示全部楼层
    我qtp 学了一年多了,也没有搞出个所以然了,真是杯具。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2010-5-26 08:56:48 | 显示全部楼层
    自动化测试工程师的开发水平和技术没有提高的话,谈框架是空谈!

    http://www.cnblogs.com/testware/archive/2010/05/02/1726041.html
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2010-5-27 12:37:27 | 显示全部楼层
    原帖由 TIB 于 2010-5-26 08:56 发表
    自动化测试工程师的开发水平和技术没有提高的话,谈框架是空谈!


    赞同这个,我现在就深有体会,还得继续努力啊
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2010-5-27 13:16:09 | 显示全部楼层

    说点不同的意见

    对于大部分人来说,由于并没有机会开发界面自动化的核心组件,所以开发框架成为了自动化脚本开发人员的主要提升方式。

    个人经验以为,界面自动化测试框架并不需要太高深的技术,它是一个逐步完善提高改善的过程。这里列举一些通用事例子:当你在脚本开发中,经常用到一些工具类方法时,你为了以后少写代码会集成成util类;当你使用核心组件识别对象发现比较困难时,你会在框架内封装该组件的属性、操作等;当你测试工具需要生成一个比较固定格式的报告时,你会在框架内集成report类;当你手工的测试流程已经证实了所有对一个对象的操作都类似时,你会在框架内体现该操作的逻辑。。。。所有的这些,都在项目做好手工测试充分掌握手工测试经验的前提下,为了提高测试效率而进行的过程改良和提高,所以不同的项目会用不同的框架。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2010-5-27 15:30:31 | 显示全部楼层
    自动化测试知识分两个方面
    1. 使用策略
    2. 工具
    我们自由学习和讨论时候更多的是讨论工具使用。但其实从工具演变的历史看,都是为了某个目的,且配合能在项目高效使用的具体策略服务。工具一直在发展在变,策略也是在变,但我们使用自动化的原因和目的不变。测试框架和工具的不同,是在工具本身提供的功能上,集成了相应部分策略的系统。为了了解他们的不同,要从工具发展和演变说起。
    我们在这里先讨论GUI层面的自动化:
    1). 最初的GUI自动化工具只提供了录制和回放的功能,记录底层鼠标和键盘的操作轨迹,并回放,但并不能以某种方式(例如某种语言/脚本)展现出来。
    2). 而后大家发现这样做的不灵活和不稳定性,于是考虑不仅仅从底层的鼠标键盘模拟,而且从识别并控制GUI底层所采用的技术对象来模拟。并且把录制的结果以某种方式解析出来。这样做的好处显而易见,有了可展现且易于用编程语言展现的平台,直接为模块化,参数化提供了条件。于是有了大家通常看到的UI自动化工具:能识别和操作界面对象,提供录制回放功能,且通常提供某种过程化语言的展示和修改平台。
    3). 在此之后进入类似百家争鸣时期,大批的商业和open source的UI自动化工具涌现。他们在对象识别方面各有偏向和优劣,提供的展现平台也各有差异。在工具选择上我们正是依据他们在这两方面的表现作出决策。但同样工具在不同公司使用上差异也很大。正如同样一门语言,做出来的东西和使用效果迥异一样。依据工具提供的展现平台/语言,具体公司在使用上定制出自己的代码规范,积累自己的函数库。于是在具体使用上出现了数据参数化/外部化,过程化和模块化,包括独立出环境初始化库/异常处理库/报告处理库等等。尔后在这些细节处理方法总结和实际目的上,萃取提炼出通用性和方向性的策略,如数据脚本分离,数据驱动,对象脚本分离,关键字驱动等等。一时风云涌动,依据需求而变的东西呼之欲出。
    4). 某些工具提供商和使用工具的公司本身,于是考虑是否能把某些使用策略和思想集成到工具本身,从而提高易用性和效率。于是自动化测试框架被提出。这时候的自动化框架并不仅仅提供对象识别和控制,录制回放,脚本展示,且常常集成了test case的管理,对象库的管理,与CI系统集成等等。人们不仅仅追求对象捕捉的精准,更多的开始分析test case类型本身,更多的开始分析展现的其他更直观和易维护的形式,更多的开始分析系统在真实项目过程的需求。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2010-5-27 23:34:10 | 显示全部楼层
    自动化测试的框架很重要,好的框架可以省下很多工作,比如用户名,密码, 日期都可以在框架中设定,现在都是数据驱动测试,当然通过框架可以定义很多默认值,只需要关注我们需要测试的情况。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2010-5-28 13:49:50 | 显示全部楼层
    1.要考虑测试适不适自动化。
    2.适合自动化的项目,有没有选择好自动化工具。
    3.自动化不是口号,是能给自己或其它人带来效率。
    4.自动化框架不能太单调,也不能限制成是某一种测试工具。
    5.不要一来就要开发什么测试框架,其实“你想做的,别人早就开始了或做好了”。开发一个新的框架,大多数测试时间是浪费在框架本身上。至少我现在觉得是这样。


    以前也参加过框架的开发。开发出来自己都不想用,更何况其它同事呢?(就是本着测试人员很傻瓜,不用写代码,只要拖拉就可以完成)。把简单的事想的太复杂了,一直想着写代码是测试人员的大山。现在觉得测试人员,写代码都不是问题。
    最近看到开源的东西SHE,随便组合下,也能达到以前的几个人开发了一年的框架的效果,开源的还更加有扩展性。也达到了自己的需求。

    个人意见。有错必改
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2010-5-28 14:24:45 | 显示全部楼层
    构建自动化测试框架

    [ 本帖最后由 nanice 于 2010-7-9 13:04 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2010-5-28 14:39:32 | 显示全部楼层
    持续关注中
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2010-5-28 16:14:06 | 显示全部楼层

    非常赞同

    原帖由 shanxi 于 2010-5-27 13:16 发表
    对于大部分人来说,由于并没有机会开发界面自动化的核心组件,所以开发框架成为了自动化脚本开发人员的主要提升方式。

    个人经验以为,界面自动化测试框架并不需要太高深的技术,它是一个逐步完善提高改善的过程。 ...




    非常赞同
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2010-5-28 17:40:09 | 显示全部楼层
    去某公司面试过,被那测试经理说他们的什么开源自动化框架说得头晕转向大为惊叹,其实不好意思揭破他们就是开源的QC+QTP!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2010-5-28 18:09:50 | 显示全部楼层
    框架只是解决一类问题的一个通用的模型,只是起一个支撑作用
    做了多年的我还是回到行业业务上去了
    要做什么,才是关键的

    好比建座大厦,也都是先做框架,
    而这个大厦到底要做成什么样,是开发商决定的
    也就是测试需求决定的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2010-5-28 18:11:01 | 显示全部楼层
    高效引入测试才是根本
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2020-7-5 18:11 , Processed in 0.079775 second(s), 30 queries .

    Powered by Discuz! X3.2

    © 2001-2020 Comsenz Inc.

    快速回复 返回顶部 返回列表