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

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

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

零测试 · 发表于 2011-11-16 13:03:04

每个人都是框架说说什么是框架嘛一头雾水！

xiamen168 · 发表于 2011-11-16 09:15:27

回复 27# 零测试

不对，描述性编程有点难，但是如果做成框架了，就又变简单了啊，做好的话说不定比录制都简单

零测试 · 发表于 2011-11-15 12:49:44

描述性编程不是特别麻烦嘛？如果使用描述性编程的话，我们还不如放弃使用工具。直接自己开发代码算了。人之所以比动物聪明，是因为人会使用工具，会操控工具。就是因为自己开发代码太耗时，所以才会有工具出来，帮人节约时间。如果现在不用工具帮忙开发代码，转而又用描述性编程的话，又要工具做什么！

hsjzfling · 发表于 2011-11-14 15:54:33

本帖最后由 hsjzfling 于 2011-11-14 15:58 编辑

“脱离”是做不到的，只能做到“分离”，注意两者的区分，想要脱离对象库，除非不用QTP。分离就是将对象的识别机制单独拎出来设定规则维护和管理，如果能预见到可能变更的情况，那么就可以在设定规则的时候灵活覆盖这些可能的变更，比如使用描述性编程\正则表达式，或者更高明点的封装，这需要对产品的非常熟悉以及丰富自动化经验；否则，要么维护用例要么维护框架，该做的事情可不是一句轻飘飘的“使用框架”就能解决的

零测试 · 发表于 2011-11-11 13:10:14

回复 20# fisherlala
大家都是框架哦哇塞！不过这想法很不错。脱离他们！

xiamen168 · 发表于 2011-11-10 09:54:31

回复 23# 零测试

可以尝试使用框架(比如SAFFRON或者PAFAWEB)，脱离对象库，并且尝试把测试数据和测试脚本分离
他已经告诉你答案了呀

零测试 · 发表于 2011-11-9 23:15:15

回复 20# fisherlala

楼上，可以解释一下什么是框架吗？不是很懂哦！我也认为QTP有些不合适了。但是又觉得这工具还不错！

xiamen168 · 发表于 2011-11-9 19:45:38

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

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

对，看来所见略同喔

hsjzfling · 发表于 2011-11-9 16:10:24

回复 19# 零测试

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

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

自动化是保证敏捷过程产品质量的一个非常重要的必要手段，但不要拘泥于基于UI的自动化，项目前期评估出最适合最高效的方案才是可取的

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

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

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

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

回复 16# hsjzfling

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

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

回复 17# xiamen168

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

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

回复 16# hsjzfling

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

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

回复 15# xiamen168

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

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