谁都是自己问题的答案

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

上一篇 / 下一篇  2010-05-25 17:06:55 / 个人分类:论坛活动

查看( 267 ) / 评论( 27 )

自动化测试之初,业界并无框架一说,某日,江湖传闻“自动化测试框架”,其为何物不得而知,只知其能助软件企业一臂之力。顿时,江湖掀起“框架”狂潮,“自动化测试框架”百花齐放,百家争鸣。尤以“测试模块化”,“业务流程测试”,“数据驱动”,“关键字驱动”,“智能测试自动化”等曝光率最高。江湖中人个个擦亮眼睛,欲窥其真谛,然框架始终以面纱罩之,亦朦胧亦神秘。
今欲邀天下测试之士,共商框架大事,如能聚天下之言,掀其神秘面纱,甚喜,甚幸!
参与讨论:http://bbs.51testing.com/thread-211647-1-1.html


TAG:

msnshow的个人空间 msnshow 发布于2010-05-25 08:48:24
先占位,关注中。。。。。
快乐人生 兰兰 发布于2010-05-25 10:55:50
qc与qtp结合的自动化测试框架构成
在公司尝试启用自动化测试已经有三年的时间了,但是一直似乎都是口号式的,年初计划的很好,但是在实际的操作过程中,遇到的技术难题较多,可值得交流人和借鉴的经验很少,在加上公司项目较多,测试人员较忙,几乎没有专门的时间去研究自动化测试,因此每年都是不了了之。如此反复两年,真的是浪费呀。
      年初研究出的自动化测试框架是:<qc的业务组件与qtp相结合的自动化测试框架>,具体操作时将被测系统中的模块按功能进行划分---将划分出的功能设计成组件---由qtp去实现组件的功能---qc测试计划中选择组件实现业务流程的覆盖并设置相关的测试数据--在qc测试集中选择业务流程进行自动执行进行自动化测试。
   在具体的实现过程中牵扯到很多的技术细节,在这里不再一一介绍,算是抛砖吧,希望大家能将自己使用的自动化框架共享出来了。
flying-kite的个人空间 flying-kite 发布于2010-05-25 11:11:44
QC与QTP结合得很好,可以把共同的功能模块设计好,调用就行了
吝立丽 linlili1985 发布于2010-05-25 15:24:23
关注中。。。
rojer521的个人空间 rojer521 发布于2010-05-25 20:39:08
推荐http://relevantcodes.com/category/automation-frameworks/,值得学习
JamesHao发布于2010-05-25 22:43:38
我这方面有些心的,但是落地纸面上没有时间。:)

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

[ 本帖最后由 JamesHao 于 2010-6-3 13:54 编辑 ]
xuzengle的个人空间 xuzengle 发布于2010-05-26 01:26:05
我qtp 学了一年多了,也没有搞出个所以然了,真是杯具。
TIB TIB 发布于2010-05-26 08:56:48
自动化测试工程师的开发水平和技术没有提高的话,谈框架是空谈!

http://www.cnblogs.com/testware/archive/2010/05/02/1726041.html
51mobile的个人空间 51mobile 发布于2010-05-27 12:37:27

QUOTE:

原帖由 TIB 于 2010-5-26 08:56 发表
自动化测试工程师的开发水平和技术没有提高的话,谈框架是空谈!
赞同这个,我现在就深有体会,还得继续努力啊
Smoke中转站 shanxi 发布于2010-05-27 13:16:09
说点不同的意见
对于大部分人来说,由于并没有机会开发界面自动化的核心组件,所以开发框架成为了自动化脚本开发人员的主要提升方式。

个人经验以为,界面自动化测试框架并不需要太高深的技术,它是一个逐步完善提高改善的过程。这里列举一些通用事例子:当你在脚本开发中,经常用到一些工具类方法时,你为了以后少写代码会集成成util类;当你使用核心组件识别对象发现比较困难时,你会在框架内封装该组件的属性、操作等;当你测试工具需要生成一个比较固定格式的报告时,你会在框架内集成report类;当你手工的测试流程已经证实了所有对一个对象的操作都类似时,你会在框架内体现该操作的逻辑。。。。所有的这些,都在项目做好手工测试充分掌握手工测试经验的前提下,为了提高测试效率而进行的过程改良和提高,所以不同的项目会用不同的框架。
san发布于2010-05-27 15:30:31
自动化测试知识分两个方面
1. 使用策略
2. 工具
我们自由学习和讨论时候更多的是讨论工具使用。但其实从工具演变的历史看,都是为了某个目的,且配合能在项目高效使用的具体策略服务。工具一直在发展在变,策略也是在变,但我们使用自动化的原因和目的不变。测试框架和工具的不同,是在工具本身提供的功能上,集成了相应部分策略的系统。为了了解他们的不同,要从工具发展和演变说起。
我们在这里先讨论GUI层面的自动化:
1). 最初的GUI自动化工具只提供了录制和回放的功能,记录底层鼠标和键盘的操作轨迹,并回放,但并不能以某种方式(例如某种语言/脚本)展现出来。
2). 而后大家发现这样做的不灵活和不稳定性,于是考虑不仅仅从底层的鼠标键盘模拟,而且从识别并控制GUI底层所采用的技术对象来模拟。并且把录制的结果以某种方式解析出来。这样做的好处显而易见,有了可展现且易于用编程语言展现的平台,直接为模块化,参数化提供了条件。于是有了大家通常看到的UI自动化工具:能识别和操作界面对象,提供录制回放功能,且通常提供某种过程化语言的展示和修改平台。
3). 在此之后进入类似百家争鸣时期,大批的商业和open source的UI自动化工具涌现。他们在对象识别方面各有偏向和优劣,提供的展现平台也各有差异。在工具选择上我们正是依据他们在这两方面的表现作出决策。但同样工具在不同公司使用上差异也很大。正如同样一门语言,做出来的东西和使用效果迥异一样。依据工具提供的展现平台/语言,具体公司在使用上定制出自己的代码规范,积累自己的函数库。于是在具体使用上出现了数据参数化/外部化,过程化和模块化,包括独立出环境初始化库/异常处理库/报告处理库等等。尔后在这些细节处理方法总结和实际目的上,萃取提炼出通用性和方向性的策略,如数据脚本分离,数据驱动,对象脚本分离,关键字驱动等等。一时风云涌动,依据需求而变的东西呼之欲出。
4). 某些工具提供商和使用工具的公司本身,于是考虑是否能把某些使用策略和思想集成到工具本身,从而提高易用性和效率。于是自动化测试框架被提出。这时候的自动化框架并不仅仅提供对象识别和控制,录制回放,脚本展示,且常常集成了test case的管理,对象库的管理,与CI系统集成等等。人们不仅仅追求对象捕捉的精准,更多的开始分析test case类型本身,更多的开始分析展现的其他更直观和易维护的形式,更多的开始分析系统在真实项目过程的需求。
Andy_wang122发布于2010-05-27 23:34:10
自动化测试的框架很重要,好的框架可以省下很多工作,比如用户名,密码, 日期都可以在框架中设定,现在都是数据驱动测试,当然通过框架可以定义很多默认值,只需要关注我们需要测试的情况。
小米啊的个人空间 小米啊 发布于2010-05-28 13:49:50
1.要考虑测试适不适自动化。
2.适合自动化的项目,有没有选择好自动化工具。
3.自动化不是口号,是能给自己或其它人带来效率。
4.自动化框架不能太单调,也不能限制成是某一种测试工具。
5.不要一来就要开发什么测试框架,其实“你想做的,别人早就开始了或做好了”。开发一个新的框架,大多数测试时间是浪费在框架本身上。至少我现在觉得是这样。


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

个人意见。有错必改
nanice发布于2010-05-28 14:24:45
构建自动化测试框架

[ 本帖最后由 nanice 于 2010-7-9 13:04 编辑 ]
0o夜星o0来测试 0o夜星o0 发布于2010-05-28 14:39:32
持续关注中
kakamissyou的测试小栈 kakamissyou 发布于2010-05-28 16:14:06
非常赞同

QUOTE:

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

个人经验以为,界面自动化测试框架并不需要太高深的技术,它是一个逐步完善提高改善的过程。 ...
非常赞同
健歌的个人空间 健歌 发布于2010-05-28 17:40:09
去某公司面试过,被那测试经理说他们的什么开源自动化框架说得头晕转向大为惊叹,其实不好意思揭破他们就是开源的QC+QTP!
jiangdl发布于2010-05-28 18:09:50
框架只是解决一类问题的一个通用的模型,只是起一个支撑作用
做了多年的我还是回到行业业务上去了
要做什么,才是关键的

好比建座大厦,也都是先做框架,
而这个大厦到底要做成什么样,是开发商决定的
也就是测试需求决定的
jiangdl发布于2010-05-28 18:11:01
高效引入测试才是根本
大傻测试空间! liaoxj 发布于2010-05-31 15:26:36
不可否认,随着系统架构越来越复杂,带来测试技术的冲击是越来越大,公司测试架构形成对提高测试效率和质量,一定会是行之有效的手段。
     做测试架构前期需投入很大成本和时间,问:在很多公司连程序架构的思路都没有很好理清的情况下,我们如何去做测试架构。
     我是从公司只有两个测试人员的基础上,通过6年的努力发展到12人,我深有感触,测试架构形成要分三分走,首先人员架构,知识库架构,技术架构。
     人员架构建立是整个测试架构形成基础,当公司只有两个人做测试,何谈测试技术架构。记得我们两个人测试的时候,我们没有分工所有产品大家一起来。发展到四个人的时候,我按大产品线分两小组,当我们发展到7个人的时候我们按项目分组,发展到10个人的时候我们又回归产品线,今年我们发展到12个人时候,我们组建了自动化测试小组。
     知识库架构的建立是整个测试架构形成的资源的方向,并需要不断积累的完善。记得刚开始的时候我们所有测试都是功能测试而且全墨盒,但是我们积累了详细的业务知识,并整理了详尽的测试案例,后面根据产品线进行分类,并且获取了公用测试用例,并配合开发组形成了界面规范,数据库规范,代码规范等。后面由测试业务需要我们进行性能测试,尝试使用很多测试工具,jmeter,loadrunner, JProfile等,我们整理了工具的特性,什么时候应该使用工具,并且顺便整理了一些监控工具,有操作系统的OmniPeek、Aports等,网络监控工具TCPMonitor等,网页监控工具HttpWatch,Xenu等,也顺便整理了一个测试辅助工具如DataFactory, jsunit。形成了自己公司独有知识库体系和知识库管理流程。
      技术架构需要根据公司的测试团队规模和测试技术实力,目前还没有到哪家公司的测试技术框架能够照搬,参照也很难,做到借鉴已经不错,现在只通过自己公司知识库积累,搭建符合自己测试技术框架。小公司现阶段不适宜搭建什么测度技术框架平台,那很不务实的,但是小公司我们整理自己的“公用类库”,如QTP的公用类库,jsunit的公用类和方法。并在项目中执行,结束后,然后不断不完善。最后时机成熟了,就可以很好嵌入到所谓的平台

    自己看了一遍,好像没有回答问题似的,大家看看,只是我一些想法和现在做的事!

[ 本帖最后由 liaoxj 于 2010-5-31 15:27 编辑 ]
我来说两句

(可选)

Open Toolbar