零测试 发表于 2011-10-28 12:36:58

QTP在敏捷的思想下，是否依然适合使用？

QTP作为Mercury公司的一款自动化功能测试工具，有一定的优势；但是现今一直在谈论敏捷，华为内部也一直在做敏捷；敏捷需要不断地迭代，每一次迭代都需要做回归测试，对自动化的覆盖率要求非常高；但是每一次迭代都有一些功能被修改或者添加了一些功能上来，这样的情况下，QTP没有测试数据和测试脚本分离的情况下，该如何更好地做自动化测试呢？QTP下，每一次迭代基本上要修改很多脚本，该如何是好？放弃QTP去另外选择一门工具？

阳光下的橙子 发表于 2011-10-28 17:34:16

本帖最后由 阳光下的橙子 于 2011-10-28 17:36 编辑

适用，但适合在正式版本上线以后再用在正式版本上线以后再用

wangyanzhao 发表于 2011-10-31 23:11:34

其实是要看你的 自动化团队的实力的；比如回归要5天时间，测试人员能在2天时间内把主要的脚本开发出来，那也行；能用最少的时间干最多的活，同理 能否节约成本也是关键

javaweb2006 发表于 2011-11-1 14:44:26

qtp应该适用于变动不是很大，项目周期比较长的，如果需求经常改，那还是不要用qtp，维护脚本太麻烦了。

零测试 发表于 2011-11-3 10:51:08

适用，但适合在正式版本上线以后再用在正式版本上线以后再用
阳光下的橙子 发表于 2011-10-28 17:34 http://bbs.51testing.com/images/common/back.gif


    如果适合在正式版本上线之后再使用的话，敏捷之中的迭代还有必要吗？
   既然是做自动化，就希望每一个迭代版本都能够自动化起来
   这样每次迭代添加上来的功能，可以采用手工测试；前面那些功能都可以使用自动化！

零测试 发表于 2011-11-3 10:54:41

其实是要看你的 自动化团队的实力的；比如回归要5天时间，测试人员能在2天时间内把主要的脚本开发出来，那也 ...
wangyanzhao 发表于 2011-10-31 23:11 http://bbs.51testing.com/images/common/back.gif


    自动化团队实力，这个嘛，我们公司只有一个人在做专项的功能自动化测试。那位技术牛人还是很不错的，五六年的自动化经验。
   
   敏捷下，回归测试不是在五天内完成的，每一个迭代版本都要测试，每一两周就有一个迭代版本过来。
    所以敏捷下面，回归测试的机会特别多，为了保证每次迭代进去的代码对以前的功能没有影响，我们可以采用自动化回归测试！
    QTP 每次修改脚本很多，有一定难度哦！公司里本来使用QTP的，后来放弃了。好像说测试代码和测试数据以及逻辑层无法分离。导致每一次迭代过来，都需要改大量的脚本！

零测试 发表于 2011-11-3 10:55:37

qtp应该适用于变动不是很大，项目周期比较长的，如果需求经常改，那还是不要用qtp，维护脚本太麻烦了。
javaweb2006 发表于 2011-11-1 14:44 http://bbs.51testing.com/images/common/back.gif


    我也这么觉得哦！改动太大了。每一个版本过来，看公司那个员工都需要改代码，后来直接放弃了！换了一个自动化测试工具testinNG。
   看来敏捷下不适合使用QTP来吧

hsjzfling 发表于 2011-11-3 11:11:48

敏捷过程中自动化测试是必须的，但不一定是基于UI的自动化，个人倾向做单元测试与接口测试的自动化，开发效率高维护量小，UI逻辑方面人工测好了。

阳光下的橙子 发表于 2011-11-3 18:30:49

自动化脚本可以跟随敏捷一起迭代，前提是项目经理能够有效地控制需求变更

零测试 发表于 2011-11-3 21:36:10

自动化脚本可以跟随敏捷一起迭代，前提是项目经理能够有效地控制需求变更
阳光下的橙子 发表于 2011-11-3 18:30 http://bbs.51testing.com/images/common/back.gif


      敏捷流程下，任何变更都是看客户的。做敏捷就是为了满足客户的需求，让软件能够尽最大努力满足客户的要求。所以变更是无法控制的了！也不强调控制变更。
    我天真的想法就是：测试代码都分开编写，一个一个类，然后调用，最后哪个地方改了，只改一处或几处就可以完成整个脚本的修改.bu zhida不知道是否行得通！

阳光下的橙子 发表于 2011-11-4 13:25:07

回复 10# 零测试


    你这个思路是错的，敏捷不是为了满足客户，而是为了更有效的控制项目进度
如果你们不能有效的控制需求，那就会被累死

零测试 发表于 2011-11-5 00:24:29

回复 11# 阳光下的橙子


    敏捷就像一棵大树从一颗种子落地，到萌芽，然后发芽，长成小树，长成中树，再到苍天大树。你看树从小到大，是不是变了很多呀？这就是敏捷。个人理解。呵呵！

chh881005 发表于 2011-11-7 13:42:31

脚本的维护确实挺麻烦的，但是如果脚本按功能或流程划分成更小的脚本，多人维护，应该还是相对轻松的……，个人观点。

零测试 发表于 2011-11-7 21:17:11

脚本的维护确实挺麻烦的，但是如果脚本按功能或流程划分成更小的脚本，多人维护，应该还是相对轻松的……， ...
chh881005 发表于 2011-11-7 13:42 http://bbs.51testing.com/images/common/back.gif


      呵呵，按功能或流程划分成更小的模块，多人维护，那么是不是要求很多测试人员都要懂自动化编程呢？

xiamen168 发表于 2011-11-7 21:33:02

我觉得用框架来开发脚本，就不怕频繁变更了，不知道对不对

hsjzfling 发表于 2011-11-8 15:58:02

回复 15# xiamen168

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

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

xiamen168 发表于 2011-11-8 19:46:41

回复 16# hsjzfling


    可是使用框架来开发脚本，可以省去录制以及避免对象找不到的问题，实现对象的快速定位，这样岂不是不怕频繁变更了吗，当然大变更的情况下基本需要重做可能不太适合。这是我的观点，欢迎大家讨论。

零测试 发表于 2011-11-9 12:29:28

回复 17# xiamen168


    框架，到底是一种什么样的框架哦？

零测试 发表于 2011-11-9 12:30:58

回复 16# hsjzfling


   需求不变更就不是需求了！需求分析人员都能了解客户的需求，那就是专家级的需求分析人员了。那样的人在行业里肯定很少呀！所以说，需求变更是难免的，我们做研发的，应该不仅仅让需求人员去控制需求，我们是否可以考虑在需求变更的情况下，我们做的更好呢？

fisherlala 发表于 2011-11-9 13:42:57

其实目前国内的公司，能把需求控好的不算多，需求频繁变更都变成家常便饭了

我觉得这种情况下，使用QTP录制、回放的方式已经不太适合敏捷思想了，而且每一次版本迭代的维护量也很大
可以尝试使用框架(比如SAFFRON或者PAFAWEB)，脱离对象库，并且尝试把测试数据和测试脚本分离
页: [1] 2
查看完整版本: QTP在敏捷的思想下，是否依然适合使用？