51Testing软件测试论坛

标题: QTP在敏捷的思想下,是否依然适合使用? [打印本页]

作者: 零测试    时间: 2011-10-28 12:36
标题: QTP在敏捷的思想下,是否依然适合使用?
QTP作为Mercury公司的一款自动化功能测试工具,有一定的优势;但是现今一直在谈论敏捷,华为内部也一直在做敏捷;敏捷需要不断地迭代,每一次迭代都需要做回归测试,对自动化的覆盖率要求非常高;但是每一次迭代都有一些功能被修改或者添加了一些功能上来,这样的情况下,QTP没有测试数据和测试脚本分离的情况下,该如何更好地做自动化测试呢?QTP下,每一次迭代基本上要修改很多脚本,该如何是好?放弃QTP去另外选择一门工具?
作者: 阳光下的橙子    时间: 2011-10-28 17:34
本帖最后由 阳光下的橙子 于 2011-10-28 17:36 编辑

适用,但适合在正式版本上线以后再用在正式版本上线以后再用
作者: wangyanzhao    时间: 2011-10-31 23:11
其实是要看你的 自动化团队的实力的;比如回归要5天时间,测试人员能在2天时间内把主要的脚本开发出来,那也行;能用最少的时间干最多的活,同理 能否节约成本也是关键
作者: javaweb2006    时间: 2011-11-1 14:44
qtp应该适用于变动不是很大,项目周期比较长的,如果需求经常改,那还是不要用qtp,维护脚本太麻烦了。
作者: 零测试    时间: 2011-11-3 10:51
适用,但适合在正式版本上线以后再用在正式版本上线以后再用
阳光下的橙子 发表于 2011-10-28 17:34



    如果适合在正式版本上线之后再使用的话,敏捷之中的迭代还有必要吗?
   既然是做自动化,就希望每一个迭代版本都能够自动化起来
   这样每次迭代添加上来的功能,可以采用手工测试;前面那些功能都可以使用自动化!
作者: 零测试    时间: 2011-11-3 10:54
其实是要看你的 自动化团队的实力的;比如回归要5天时间,测试人员能在2天时间内把主要的脚本开发出来,那也 ...
wangyanzhao 发表于 2011-10-31 23:11



    自动化团队实力,这个嘛,我们公司只有一个人在做专项的功能自动化测试。那位技术牛人还是很不错的,五六年的自动化经验。
   
   敏捷下,回归测试不是在五天内完成的,每一个迭代版本都要测试,每一两周就有一个迭代版本过来。
    所以敏捷下面,回归测试的机会特别多,为了保证每次迭代进去的代码对以前的功能没有影响,我们可以采用自动化回归测试!
    QTP 每次修改脚本很多,有一定难度哦!公司里本来使用QTP的,后来放弃了。好像说测试代码和测试数据以及逻辑层无法分离。导致每一次迭代过来,都需要改大量的脚本!
作者: 零测试    时间: 2011-11-3 10:55
qtp应该适用于变动不是很大,项目周期比较长的,如果需求经常改,那还是不要用qtp,维护脚本太麻烦了。
javaweb2006 发表于 2011-11-1 14:44



    我也这么觉得哦!改动太大了。每一个版本过来,看公司那个员工都需要改代码,后来直接放弃了!换了一个自动化测试工具testinNG。
   看来敏捷下不适合使用QTP来吧
作者: hsjzfling    时间: 2011-11-3 11:11
敏捷过程中自动化测试是必须的,但不一定是基于UI的自动化,个人倾向做单元测试与接口测试的自动化,开发效率高维护量小,UI逻辑方面人工测好了。
作者: 阳光下的橙子    时间: 2011-11-3 18:30
自动化脚本可以跟随敏捷一起迭代,前提是项目经理能够有效地控制需求变更
作者: 零测试    时间: 2011-11-3 21:36
自动化脚本可以跟随敏捷一起迭代,前提是项目经理能够有效地控制需求变更
阳光下的橙子 发表于 2011-11-3 18:30



      敏捷流程下,任何变更都是看客户的。做敏捷就是为了满足客户的需求,让软件能够尽最大努力满足客户的要求。所以变更是无法控制的了!也不强调控制变更。
    我天真的想法就是:测试代码都分开编写,一个一个类,然后调用,最后哪个地方改了,只改一处或几处就可以完成整个脚本的修改.bu zhida不知道是否行得通!
作者: 阳光下的橙子    时间: 2011-11-4 13:25
回复 10# 零测试


    你这个思路是错的,敏捷不是为了满足客户,而是为了更有效的控制项目进度
如果你们不能有效的控制需求,那就会被累死
作者: 零测试    时间: 2011-11-5 00:24
回复 11# 阳光下的橙子


    敏捷就像  一棵大树  从一颗种子落地,到萌芽,然后发芽,长成小树,长成中树,再到苍天大树。你看树从小到大,是不是变了很多呀?这就是敏捷。个人理解。呵呵!
作者: chh881005    时间: 2011-11-7 13:42
脚本的维护确实挺麻烦的,但是如果脚本按功能或流程划分成更小的脚本,多人维护,应该还是相对轻松的……,个人观点。
作者: 零测试    时间: 2011-11-7 21:17
脚本的维护确实挺麻烦的,但是如果脚本按功能或流程划分成更小的脚本,多人维护,应该还是相对轻松的……, ...
chh881005 发表于 2011-11-7 13:42



      呵呵,按功能或流程划分成更小的模块,多人维护,那么是不是要求很多测试人员都要懂自动化编程呢?
作者: xiamen168    时间: 2011-11-7 21:33
我觉得用框架来开发脚本,就不怕频繁变更了,不知道对不对
作者: hsjzfling    时间: 2011-11-8 15:58
回复 15# xiamen168

不要迷信框架,框架只能提高开发效率,这个提高的程度在面临频繁变更的工作增量上依然显得杯水车薪。

需求的控制是一个关键。敏捷的优势在于可以最快速交付给客户可用的功能。客户可以尽早提出程序中不合心意的地方,但不意味着客户的每一个需求都是合理的且必须实现的,这就需要我们的需求分析人员来严格把关,搞需求不仅仅只是传递和翻译客户的意思,好的需求人员需要比客户更了解客户自己的需求,并能引导客户的需求,而不是一味被客户牵着兜圈。
作者: xiamen168    时间: 2011-11-8 19:46
回复 16# hsjzfling


    可是使用框架来开发脚本,可以省去录制以及避免对象找不到的问题,实现对象的快速定位,这样岂不是不怕频繁变更了吗,当然大变更的情况下基本需要重做可能不太适合。这是我的观点,欢迎大家讨论。
作者: 零测试    时间: 2011-11-9 12:29
回复 17# xiamen168


    框架,到底是一种什么样的框架哦?
作者: 零测试    时间: 2011-11-9 12:30
回复 16# hsjzfling


     需求不变更就不是需求了!需求分析人员都能了解客户的需求,那就是专家级的需求分析人员了。那样的人在行业里肯定很少呀!所以说,需求变更是难免的,我们做研发的,应该不仅仅让需求人员去控制需求,我们是否可以考虑在需求变更的情况下,我们做的更好呢?
作者: fisherlala    时间: 2011-11-9 13:42
其实目前国内的公司,能把需求控好的不算多,需求频繁变更都变成家常便饭了

我觉得这种情况下,使用QTP录制、回放的方式已经不太适合敏捷思想了,而且每一次版本迭代的维护量也很大
可以尝试使用框架(比如SAFFRON或者PAFAWEB),脱离对象库,并且尝试把测试数据和测试脚本分离
作者: hsjzfling    时间: 2011-11-9 16:10
回复 19# 零测试

需求变更是正常现象,但不说明频繁的需求变更就是正常的,这两者间区别还是很大的。需求如果能做到在一定程度一定范围内可控,那么自动化可以优先覆盖重要且可控的那部分功能点。如果只能完全顺着客户的思维打转,那么还是没必要再给“不可能的任务”增加难度了。

上次跟个四川的朋友聊到他们的QTP敏捷自动化,实施的基础就是每天14小时以上的工作。

自动化是保证敏捷过程产品质量的一个非常重要的必要手段,但不要拘泥于基于UI的自动化,项目前期评估出最适合最高效的方案才是可取的
作者: xiamen168    时间: 2011-11-9 19:45
其实目前国内的公司,能把需求控好的不算多,需求频繁变更都变成家常便饭了

我觉得这种情况下,使用QTP录 ...
fisherlala 发表于 2011-11-9 13:42



    对,看来所见略同喔
作者: 零测试    时间: 2011-11-9 23:15
回复 20# fisherlala

     楼上,可以解释一下什么是框架吗?不是很懂哦!我也认为QTP有些不合适了。但是又觉得这工具还不错!
作者: xiamen168    时间: 2011-11-10 09:54
回复 23# 零测试


    可以尝试使用框架(比如SAFFRON或者PAFAWEB),脱离对象库,并且尝试把测试数据和测试脚本分离
他已经告诉你答案了呀
作者: 零测试    时间: 2011-11-11 13:10
回复 20# fisherlala
大家都是框架哦  哇塞!不过这想法很不错。脱离他们!
作者: hsjzfling    时间: 2011-11-14 15:54
本帖最后由 hsjzfling 于 2011-11-14 15:58 编辑

“脱离”是做不到的,只能做到“分离”,注意两者的区分,想要脱离对象库,除非不用QTP。分离就是将对象的识别机制单独拎出来设定规则维护和管理,如果能预见到可能变更的情况,那么就可以在设定规则的时候灵活覆盖这些可能的变更,比如使用描述性编程\正则表达式,或者更高明点的封装,这需要对产品的非常熟悉以及丰富自动化经验;否则,要么维护用例要么维护框架,该做的事情可不是一句轻飘飘的“使用框架”就能解决的
作者: 零测试    时间: 2011-11-15 12:49
描述性编程不是特别麻烦嘛?如果使用描述性编程的话,我们还不如放弃使用工具。直接自己开发代码算了。人之所以比动物聪明,是因为人会使用工具,会操控工具。就是因为自己开发代码太耗时,所以才会有工具出来,帮人节约时间。如果现在不用工具帮忙开发代码,转而又用描述性编程的话,又要工具做什么!
作者: xiamen168    时间: 2011-11-16 09:15
回复 27# 零测试


    不对,描述性编程有点难,但是如果做成框架了,就又变简单了啊,做好的话说不定比录制都简单
作者: 零测试    时间: 2011-11-16 13:03
每个人都是框架 说说什么是框架嘛 一头雾水!




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2