51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 16978|回复: 27
打印 上一主题 下一主题

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

[复制链接]

该用户从未签到

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

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



获奖名单
奖项
获奖名单
奖励
答案链接
一等奖
san
50元话费充值卡
12#
二等奖
liaoxj
300论坛积分
21#
三等奖
dennyqiang
100论坛积分
22#
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

  • TA的每日心情
    奋斗
    2022-5-8 19:23
  • 签到天数: 137 天

    连续签到: 1 天

    [LV.7]测试师长

    2#
    发表于 2010-5-25 08:48:24 | 只看该作者
    先占位,关注中。。。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    3#
    发表于 2010-5-25 10:55:50 | 只看该作者

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

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

    使用道具 举报

    该用户从未签到

    4#
    发表于 2010-5-25 11:11:44 | 只看该作者
    QC与QTP结合得很好,可以把共同的功能模块设计好,调用就行了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2010-5-25 15:24:23 | 只看该作者
    关注中。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2010-5-25 20:39:08 | 只看该作者
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2010-5-25 22:43:38 | 只看该作者
    我这方面有些心的,但是落地纸面上没有时间。:)

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

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

    使用道具 举报

    该用户从未签到

    8#
    发表于 2010-5-26 01:26:05 | 只看该作者
    我qtp 学了一年多了,也没有搞出个所以然了,真是杯具。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2010-5-26 08:56:48 | 只看该作者
    自动化测试工程师的开发水平和技术没有提高的话,谈框架是空谈!

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

    使用道具 举报

    该用户从未签到

    10#
    发表于 2010-5-27 12:37:27 | 只看该作者
    原帖由 TIB 于 2010-5-26 08:56 发表
    自动化测试工程师的开发水平和技术没有提高的话,谈框架是空谈!


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

    使用道具 举报

    该用户从未签到

    11#
    发表于 2010-5-27 13:16:09 | 只看该作者

    说点不同的意见

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

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

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

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


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

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

    使用道具 举报

    该用户从未签到

    15#
    发表于 2010-5-28 14:24:45 | 只看该作者
    构建自动化测试框架

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

    使用道具 举报

    该用户从未签到

    16#
    发表于 2010-5-28 14:39:32 | 只看该作者
    持续关注中
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2010-5-28 16:14:06 | 只看该作者

    非常赞同

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

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




    非常赞同
    回复 支持 反对

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

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

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

    使用道具 举报

    该用户从未签到

    20#
    发表于 2010-5-28 18:11:01 | 只看该作者
    高效引入测试才是根本
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-6 09:32 , Processed in 0.091568 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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