51Testing软件测试论坛

标题: 一定不要把qtp神话了，所谓的框架是忽悠人的 [打印本页]

作者: volvoo 时间: 2009-7-7 14:06
标题: 一定不要把qtp神话了，所谓的框架是忽悠人的
qtp说白了就是一个界面搜索工具+编辑界面+vb脚本，其使用过程中，受限因素特别多，光维护脚本，就需要惊人的工作量，用在那里合适？
1 界面和开发用组件基本极少改变的情况
2 反复简单的压力测试
3 被测系统构造数据每个版本基本一样
4 动态构造界面少的情况
完全基于界面的测试是不合理的，qtp仅仅适合作为测试中一个补充，投入过多精力搞框架是得不偿失的。不要完全拒绝界面测试，更不要认为它是万能的

作者: shanxi 时间: 2009-7-7 14:11
标题: 回复 1# 的帖子
有见解哟

自动化的投入是非常昂贵的，另外ROI很多时候很难做到有说服力

作者: wuei9090 时间: 2009-7-7 14:34
顶言必称框架看起来特可笑...

QTP就是一工具有可能节约成本也有更大的可能浪费人力物力
一味赶时髦玩自动化有时候得不偿失

作者: lg1318617 时间: 2009-7-7 14:39
一切以人为本

作者: dreamever 时间: 2009-7-7 15:12
顶楼上的头象

作者: heqingbluesky 时间: 2009-7-7 15:21
最讨厌GUI改来该去。

作者: volvoo 时间: 2009-7-7 15:42
标题: 我基本抛弃的GUI测试
偶尔用用qtp作为测试的一个小补充，比如有的测试必须GUI,看看界面可用性。
其实本人也搞过框架的研究，但实施的时候，发现没有万能的框架可以方便的使用，
基本的东西不断被修改，框架就失去的应有的含义。

作者: lg1318617 时间: 2009-7-7 16:04

原帖由 dreamever 于 2009-7-7 15:12 发表
顶楼上的头象

很帅乎？

作者: wtucel 时间: 2009-7-7 20:13

原帖由 volvoo 于 2009-7-7 14:06 发表
qtp说白了就是一个界面搜索工具+编辑界面+vb脚本，其使用过程中，受限因素特别多，光维护脚本，就需要惊人的工作量，用在那里合适？
1 界面和开发用组件基本极少改变的情况
2 反复简单的压力测试
3 被测系统构造数 ...

楼主也在忽悠人，第一次听说用QTP做压力测试的

作者: lantianwei 时间: 2009-7-7 21:16
我相信致力于框架的大牛们也不会都是傻蛋。。。

作者: gaoyoumei 时间: 2009-7-7 23:00
标题: 回复 9# 的帖子

原帖由 wtucel 于 2009-7-7 20:13 发表

楼主也在忽悠人，第一次听说用QTP做压力测试的

这就不懂了吧，谁说QTP就不能做性能测试来着？自己不会使用，就不要断言不可以哦！你还得学习

作者: hsjzfling 时间: 2009-7-8 11:00

原帖由 volvoo 于 2009-7-7 14:06 发表
qtp说白了就是一个界面搜索工具+编辑界面+vb脚本，其使用过程中，受限因素特别多，光维护脚本，就需要惊人的工作量，用在那里合适？
1 界面和开发用组件基本极少改变的情况
2 反复简单的压力测试
3 被测系统构造数 ...

如你所说，QTP自动化的最大作用就在于替代繁杂的重复性劳动。比如有个产品需要在4个不同的操作系统，3种主流浏览器，10个操作流程的组合，15组操作数据的情况下进行测试，自动化的作用就非常明显了。再比如每次发布后的Smoking Testing，也可以考虑用自动化来实现。

而框架则可以帮助我们统一的管理自动化工作过程，让我们可以便捷的遵从框架规范来开发、维护自动化脚本，更大程度上去利用HP Mercury已经集成在QTP中的功能，使得自动化过程有条不紊，而并不在于自己写的核心代码有多么的深奥，那只会让维护框架的成本更大，风险更大。

QTP确实只是一个工具，我们既然选择了它，就应该多去发掘它的最大价值，思考如何能更有效率的使用它，而不是一味想着如何去自己写更好的东西，那样还不如自己去开发新工具。

作者: heqingbluesky 时间: 2009-7-8 11:56

原帖由 hsjzfling 于 2009-7-8 11:00 发表

如你所说，QTP自动化的最大作用就在于替代繁杂的重复性劳动。比如有个产品需要在4个不同的操作系统，3种主流浏览器，10个操作流程的组合，15组操作数据的情况下进行测试，自动化的作用就非常明显了。再比如每次发 ...

是的，用QTP主要是在测试软件的功能更改很小，界面更改很小的情况下使用。只能作为手工测试的一个补充。我们公司取消的专职的自动化职位，要求测试组基本都会操作这个软件。

框架的东西仁者见仁，智者见智。

作者: nbkhic 时间: 2009-7-8 12:05
框架代表一种测试的逻辑，而QTP测试代表的是测试的行为，尽管这个行为内也包含了一定的逻辑，但这种逻辑最多只是模块级并不能上升到系统级。
应用框架确实是个见仁见智的东西，系统级的测试不用框架还确实找不到什么好的方法去组织实施。
QTP确实是个局限性很大的工具，比如只能用在win平台，比如脚本的维护量的确惊人。不过对于一些特殊项目，用QTP来进行回归和冒烟测试还是一个不错的选择。特别是一些纯数据驱动，并且使用正交测试法来编写的自动化用例，QTP还是有一定的效果的。
最后QTP也能进行压力测试，不过用压力测试这个词不是很准确，确切应该说是负载测试。不过QTP进行分布式负载测试确实不方便，搭建环境会耗费极多的青春....

作者: jadeyu712 时间: 2009-7-8 13:15

原帖由 wtucel 于 2009-7-7 20:13 发表

楼主也在忽悠人，第一次听说用QTP做压力测试的

不能做压力测试。但是可以把功能脚本放到LR中当作压力来测试。

作者: jadeyu712 时间: 2009-7-8 13:16

原帖由 volvoo 于 2009-7-7 14:06 发表
qtp说白了就是一个界面搜索工具+编辑界面+vb脚本，其使用过程中，受限因素特别多，光维护脚本，就需要惊人的工作量，用在那里合适？
1 界面和开发用组件基本极少改变的情况
2 反复简单的压力测试
3 被测系统构造数 ...

有一定的道理。而且QTP对脚本的跟踪也要求很到位。如果测试人员在写脚本不负责的话，可以给你搞假的。

作者: hsjzfling 时间: 2009-7-8 13:21

原帖由 heqingbluesky 于 2009-7-8 11:56 发表

是的，用QTP主要是在测试软件的功能更改很小，界面更改很小的情况下使用。只能作为手工测试的一个补充。我们公司取消的专职的自动化职位，要求测试组基本都会操作这个软件。

框架的东西仁者见仁，智者见智。

自动化测试的存在可不仅仅只是作为手工测试的补充，它与手工测试的侧重点不太一样。手工侧重与对于程序业务功能上的测试，更多的倾向于发现程序新缺陷，这在测试活动中需要有想法有创造性的，具备自动化所没有的"联想"；而自动化侧重与重复性较高的回归测试，以及LS提到的正交法生成的用例的测试，一般这种情况下使用自动化会比手工去做效率要高。每天跑100个类似的用例，人会疲劳，机器可不太会。

所以你可以认为在你们公司自动化只是手工测试的补充，而不能一概而论。事实上，在一些产品成熟的企业，自动化的需求是很高的。

作者: shanxi 时间: 2009-7-8 14:15
标题: 回复 17# 的帖子
看你滔滔不绝了半天

把你公司用自动化界面测试产生的ROI能否简单的介绍一下
数据是不会说谎的。

作者: kings727 时间: 2009-7-8 14:34
一直就没搞明白自动化框架是啥？
QTP的自动化框架怎么做，更没搞明白?
模模糊糊的感觉是不是有点类似于开发中的设计。

作者: 小_麦 时间: 2009-7-8 14:48
请问什么叫ROI??

作者: shanxi 时间: 2009-7-8 14:53
标题: ROI = Return on Investment
通俗点说就是投入产出比

作者: hsjzfling 时间: 2009-7-8 16:03
标题: 回复 18# 的帖子
这个就无可奉告了，你是否认可我所说的这些那也与我无关痛痒，你完全可以提出你的观点让大家来讨论，没必要给你说这些统计数据。

再说了，我若是随口说个数据，谁能证明是还是不是？有说服力么？数据是不会说谎，但人可能会。

如果你有兴趣给大家做个你们公司的报告，我想大家也很乐于看到吧。

作者: shanxi 时间: 2009-7-8 16:39
标题: 回复 22# 的帖子
我这边的数据是ROI非常低自动化测试比不上手工测试重要跑几百次才有可能发现1个bug，而且bug还是手工已经报过的。

要你给的数据也是个大概描述，你们的boss难道不会考虑这个？
我这也不缺你一个人的数据，起个头大家交流一下有什么不好的？遮遮掩掩的干嘛？这里大部分人的水平本来就低，弄点有技术含量的话题大家讨论一下为何某些人就那么逃避？很想不通。
关于自动化你公司的技术并不会高去哪，我对贵公司的界面自动化测试技术也根本没兴趣，没多少公司能开发自己的工具来做这个。

[ 本帖最后由 shanxi 于 2009-7-8 16:54 编辑 ]

作者: hsjzfling 时间: 2009-7-8 17:18

原帖由 shanxi 于 2009-7-8 16:39 发表
我这边的数据是ROI非常低自动化测试比不上手工测试重要跑几百次才有可能发现1个bug，而且bug还是手工已经报过的。

要你给的数据也是个大概描述，你们的boss难道不会考虑这个？
我这也不缺你一个人的数据，起个 ...

ROI不是这么算的，你说的那个叫自动化测试用例的缺陷率。
自动化投入与产出的比应该是：以"用人工来完成某个测试任务需要花费的成本"来做为产出记做M，这个是可以根据测试管理的统计数据来计算出来，"自动化来完成同样的测试任务花费掉的总成本"做为投入记做A，这部分实打实花费掉了的成本。
A和M完成同样的测试任务，只是完成的方式不同，这样才会有可比性，A/M才是你所想要知道的投入产出比，A/M越大，那么该自动化过程实施的效益就越大。并且在M的开销中还包括了可以复用的产出，比如可复用的脚本、公用函数等，比如期间产生的自动化测试规范文档等等，这些都是可以在下一个自动化过程中节省下来的。
这些数据对企业来说或许重要，但是对于这里的技术人员来说就不见得有多大意义了，这话题也并没有什么技术含量，常识倒是包含了一点。
至于你的最后一句话，就真的有点不知所云了。
跟你交流次数也不少了，貌似实在跟你没什么共同语言

作者: shanxi 时间: 2009-7-8 17:23
标题: 回复 25# 的帖子
你总喜欢抬杠，挑刺的一些东西我感觉也不在点上

你所说是我计算错误其实不然，我没说几百次是耗费了多少人力写并维护，产生出了这么少的bug
要说ROI没技术含量，我感觉你们的自动化评估就没做好

作者: hsjzfling 时间: 2009-7-8 17:30

原帖由 shanxi 于 2009-7-8 17:12 发表
以前碰到过一帮人，写了一个JS库能支持web自动化。我去问这帮人，此库同Selenium有何不同，当时没人正面回答我。当时很怀疑它们的库中有部分是抄袭得来的。

我这里想说
UI 自动化测试并没大家想象中的技术含量那 ...

真的很好笑啊，不告诉你我们公司的统计数据，这就叫遮掩技术了啊？还盖上阻挡技术为广大人民所掌握的大帽子。。。呵呵，逻辑思维还真是天马行空啊。。。

真的不想做人身攻击。前两天看你在peimzh招募出书作者的帖子中说你就小学文化，当时还觉得你很幽默，现在看来。。。这不会是真的吧。。。

作者: hsjzfling 时间: 2009-7-8 17:34

原帖由 shanxi 于 2009-7-8 17:23 发表
你总喜欢抬杠，挑刺的一些东西我感觉也不在点上

你所说是我计算错误其实不然，我没说几百次是耗费了多少人力写并维护，产生出了这么少的bug
要说ROI没技术含量，我感觉你们的自动化评估就没做好

此技术非彼技术，你要说项目管理是技术，那扫大街也是一技术活啊。

还好意思跟我说抬杠？要不要我把你以前跟我胡搅蛮缠还口吐恶言抬杠的几篇帖子在这里贴出来？看看是谁前几次都说的无话可说然后灰溜溜的删掉自己的所有回复装作没发生过一样？

唉，无视掉你的所有发言好了，跟你真没什么好说的。

作者: hsjzfling 时间: 2009-7-8 17:37
扶一下楼，LZ抱歉啊，真不是有意在你的帖子中说上这么多跟你主题完全不相干的回复。

作者: shanxi 时间: 2009-7-8 17:49
标题: ROI在自动化测试中的作用并不是楼上一个人能抹杀的
路过的无视楼上的发言就行了

原帖由 hsjzfling 于 2009-7-8 17:30 发表
真的不想做人身攻击。前两天看你在peimzh招募出书作者的帖子中说你就小学文化

我就小学文化，也没觉得丢人！中国的学历教育流毒甚广啊：
平等、博爱等美好的品格在中国现在的教育中被忽视
，造成了许多人格不健全的。

[ 本帖最后由 shanxi 于 2009-7-8 18:09 编辑 ]

作者: 天高地远 时间: 2009-7-8 18:33
不懂qtp的人来学习。

作者: onlonely 时间: 2009-7-8 19:10
这年头怎么都这么激动呢。

就我感觉来看,框架虽然不是所谓多高深的东西(装高深者令论)。不过要充分理解,设计一个很健壮的框架确实不容易
但是在使用QTP做自动化测试的时候(那些不使用或者不希望使用者令论)没有一定的框架思想来应用的话。
可以保证100%自动化是失败的。

当然,我们最初可以先使用些简单的,做些代码规范啊,公共函数库呀,脚本目录设计啊。
这些简单的还是非常必要的。

作者: shanxi 时间: 2009-7-8 19:18
标题: 回复 31# 的帖子
其实楼主的话题有两个意义：
对一般人来说，选择用QTP这个工具利用好它基于它的设计思路也即框架就算是到顶了；

但对那些不拘泥于QTP这个工具的人来说，所谓的框架不过是每个人对UI自动化测试组织理解的一种反应：需求是什么就开发出什么样的脚本！

所谓的"激动"仅仅是某人强行想把观点加载于另一个人身上的一种言辞反应，但某些不变的结论是不会以个人意志为转移的。

[ 本帖最后由 shanxi 于 2009-7-8 19:22 编辑 ]

作者: hsjzfling 时间: 2009-7-8 21:25
标题: 有人又要自取其辱了
shanxi能不能先将我的论述一一有理有据的反驳以后再来给出一些结论来？

在我的发言中，我没有一句话说ROI不重要，只是说这和我们测试工程师想要学习的测试技术关系不大，ROI应该是项目经理或者测试经理级别的人去关心的问题。你从哪里得到我要抹杀ROI在自动化过程中的作用？

我不鄙视小学文化的人，我鄙视的是连一点基本的逻辑思维能力的人都欠缺却还不停大放阙词的人，鄙视你每次都是莫名其妙的得出一些结论。所以我说跟你没话好说。

你若想再下什么结论，请先学会有条理的反驳掉我的论述，不然，敬请你闭嘴。

作者: hsjzfling 时间: 2009-7-8 21:38
标题: 顺便再驳斥下你的观点

原帖由 shanxi 于 2009-7-8 17:23 发表
你总喜欢抬杠，挑刺的一些东西我感觉也不在点上

你所说是我计算错误其实不然，我没说几百次是耗费了多少人力写并维护，产生出了这么少的bug
要说ROI没技术含量，我感觉你们的自动化评估就没做好

就当时你说了几百次是耗费了多少人力写并维护，产生出了这么少的bug，请问你如何来评估ROI高还是低了，标准是什么？多少个bug才算多?怎么来评估投入与产出的比例？
不管你花了多少代价去做这些事情，你用bug数量来评估，得到的还是自动化测试用例的缺陷率。

在我的论述中，只要A(自动化成本)/M(手工成本) <1 那么就可以认为自动化实施是成功的，即使等于1或者略大于1也可以认为它是成功的，因为第一在自动化实施的工程中有可以复用到其它自动化过程的产出，第二，我想没人愿意去天天做重复劳动吧。

[ 本帖最后由 hsjzfling 于 2009-7-8 21:40 编辑 ]

作者: dexterEar 时间: 2009-7-8 22:41
话说发现新缺陷不是自动化测试的任务，记的一本书上是这么说的

作者: lijinshui 时间: 2009-7-9 08:51
关注中,有意思赫赫
其实大家都挺有耐心的哈哈
一字一句挑对方的语病,

作者: dreamever 时间: 2009-7-9 09:24
我比较同意hsjzfling的观点。
首先，推广自动化测试是我们国内测试领域的大势所趋，对自动化测试的研究和应用也必然不会停留在录制/回放的层面上。自动化测试要做的事情就是用代码去测试代码，用软件去测试软件。那么必然涉及到一个代码如何组织的问题，资源如何整合的问题，流程如何规范的问题，这些其实都是“框架”要去解决的问题。对于自动化测试刚刚起步的团队，不必将过多的精力投入到框架的研究上来。但是如果自动化测试进行了很长时间，已经形成了几千个用例的规模甚至更多，如果说没有相对成熟的框架，那么测试脚本的维护和扩展是不可想象的。
框架不是万能的，但是我们不能因此就断定框架是忽悠人的；框架的概念也可大可小，不见得框架都是一些虚无缥缈的理论和复杂的东西。我非常同意楼主“不能把QTP神话了”的观点，同时我也认为不能因此而把“框架”也一并送上断头台

作者: loho1968 时间: 2009-7-9 09:41
自动化测试的引入阶段，本来就应该在软件开发基本完成，功能、界面已经稳定的情况了。
这个和楼主所说的是否使用“框架“无关。

作者: imlele 时间: 2009-7-9 10:11
支持 hsjzfling

观点，论据很清楚了~

谁无理取闹，一眼就能看出来了

作者: nbkhic 时间: 2009-7-9 10:18
ROI的问题没必要讨论了。记得某位大师说过
自动化测试最多只能找到20%的bug
80%以上的bug都是手工测试发现的。
因此自动化测试的ROI就是如何以最快最廉价的方式执行那能发现20%bug的测试用例。没有太大疑问，用自动化的方式去执行那部分重复性极高的测试是一个比较好的方案。
因此自动化测试还是有市场的。

作者: shanxi 时间: 2009-7-9 10:21
标题: 回复 33# 的帖子
请你闭嘴,停止无理取闹！
我不想把此贴的内容引向偏离主题太远的地方。我根本没兴趣对你的话一句一句评论，这对我来说并没有value。

这里大部分人的自动化仍然建立在QTP这一个工具之上，离开了这个工具，连造轮子的能力都没有。
对一个特定工具来说，它的设计思想决定了最适合它的框架总是集中在那几个方向上，但这并不否认其它方式设计的框架不行，只要你在点和面上完成统一，只要开发出的代码符合项目的实际需求并得到公司领导的认同即可。

回复 40# 的帖子
我想楼主当然还有我，并没有完全否定掉自动化测试的作用。却是在一定程度上放大了自动化的局限性。关于自动化还有一个比较高的数据：
单元自动化测试最高能达到70%的覆盖率。

[ 本帖最后由 shanxi 于 2009-7-9 10:49 编辑 ]

作者: mealready 时间: 2009-7-9 11:02
╮(╯▽╰)╭
一个人会玩他是神
但很多人都会了他就是人了

作者: xiaoyaoke 时间: 2009-7-9 11:26
首先：我是坚定的站在shanxi的这个阵营的
然后说说我的理解：自动化测试理论上相当于用软件测软件，这里面分为两个层次，如果你是是从产品的层次角度去考虑来写测试脚本，这就说明你基本上是在干研发的活，因为你要考虑代码复用，函数的性能，还有容错处理等等研发需要考虑的问题，如果只是单纯的将测试用例反映为脚本，你还只是普通的测试员工，也就是说：我们先行的所谓框架，不过就是在开发一款测试你产品的软件中所考虑的基本的编程事项，试想：你开发一款软件能叫开发一款“框架”吗？
嗯，那接下来说框架吧，我们公司一个10多年的研发写了一款页面开发的框架，PHP的，问题挺多，去年我们测试组的4个人想写一款测试用的框架，但由于时间，能力等原因没成型
从中我也思考一点问题：框架是什么？研发在给我们培训的时候说过：框架就是预先定义的各种接口，你按照接口的定义去编写一些简单或附件的代码就可以实现整个逻辑的实现，也就是说：“框架”的可重用性不能单纯的只是项目本身，而至少是同类软件或者更广阔的范围。
我们所谓的框架，封业务逻辑，业务逻辑的实现就已经注定这所谓的“框架”不要说应用到同类软件，就是换一个项目也已经无法使用了。。。试想，只是针对特定项目的测试代码能够叫框架吗？一点通用性都没有的

作者: hsjzfling 时间: 2009-7-9 11:45
谢谢37，39楼的支持
说话是要有根据要讲道理的，大家的眼睛是明亮的

回40楼，你说的没错，自动化的目的就是为了去解决那些重复度较高的工作，其目的不是为了发现新的bug，而是在于减轻部分手工测试的压力，主要是应用在冒烟测试等重复性很高的测试活动中。

想提高自动化的ROI那就需要把有限的自动化资源投入到重复度最高的工作中。在资源较充沛的情况下，再去考虑扩大自动化覆盖率，可以按手工测试的重复度及自动化实施的可行性来排优先级。

回37楼，每个人对于框架都有不同的理解，我以前也认为一个脚本的组织结构就是一个框架。当然也没有最好的框架，只有最适合的框架，适合各自企业各自项目各自产品的框架。框架这个概念确实比较虚，因此我们需要将它实体化，让它能够真正的很好的协助我们工作，框架的设计应该是与具体的公司环境、产品、项目环境密不可分的。

我现在认为框架可以这样来定义，一个广义的完整的自动化框架应该定义一个完整的自动化测试过程。它应该可以让一个公司或一个项目组很清楚的知道如果他们想要按照框架来实现自动化，那么具体应该要准备什么样的资源，并评估其可行性。
通过框架他们需要知道应该按照什么步骤来做些什么事情，如何来做这些事情，做的过程中需要注意些什么问题，每个过程的输入和输出又是什么，等等，这些与我们通常所提到的自动化测试技术关系不大。
然后框架中再包含我们通常提到的脚本组织结构的狭义框架，比如如何来分层，驱动的模式，数据文件的结构等等。

作者: hotcaoyong 时间: 2009-7-9 11:50
我认为框架是让编程人员更傻瓜让代码更规范

作者: wuei9090 时间: 2009-7-9 11:54
一部分测试人员觉的凭什么都是IT 我们就不能写代码于是自动化脚本出现了

又一部分测试人员觉的凭什么他们开发天天框架框架的 strus spring的我们也能于是自动化测试框架这一概念又出来了

作者: hsjzfling 时间: 2009-7-9 12:04

原帖由 xiaoyaoke 于 2009-7-9 11:26 发表
首先：我是坚定的站在shanxi的这个阵营的
然后说说我的理解：自动化测试理论上相当于用软件测软件，这里面分为两个层次，如果你是是从产品的层次角度去考虑来写测试脚本，这就说明你基本上是在干研发的活，因为你要 ...

你说的确实是一种比较失败的尝试运用框架的实例，这能够给我们探索出更有效更可行的框架提供可参考的经验。

建议你了解下HP BPT，它提供了一种使自动化工程师(不是自动化测试工程师)独立于业务之外的方案，部分思想值得我们去借鉴。

作者: xiaoyaoke 时间: 2009-7-9 12:23
标题: 回复 47# 的帖子
“建议你了解下HP BPT，它提供了一种使自动化工程师(不是自动化测试工程师)独立于业务之外的方案，部分思想值得我们去借鉴。” 我认为正是这种BPT使测试脚本增加了对QTP工具的依赖性，从而无法独立于被测试项目。

简单的说QTP是关键字驱动的框架，如果你的框架可以基本实现QTP的功能，那么可以说是框架了。

作者: dreamever 时间: 2009-7-9 13:43

原帖由 shanxi 于 2009-7-9 10:21 发表
请你闭嘴,停止无理取闹！
我不想把此贴的内容引向偏离主题太远的地方。我根本没兴趣对你的话一句一句评论，这对我来说并没有value。

这里大部分人的自动化仍然建立在QTP这一个工具之上，离开了这个工具，连造轮子 ...

那个……弱弱的说一下，可能你想说的是“并没有价值”，但是在英文里合适的翻译应该是worthless ，比如说：
Talent is worthless unless you persevere in developing it.除非你坚持不懈地发展天赋，否则它是没有价值的。
或者你用valueless也可以，但是不能把汉语的“没有”和英文的“value“加在一起，
刚才看到了就顺带一提，其实我英文也不好，都是从词典里搬来的。

作者: hsjzfling 时间: 2009-7-9 14:18
标题: 回复 48# 的帖子
我们讨论的就是QTP呀，既然QTP工具提供了这些很好的功能和特性，为什么我们不去尽可能的发掘它已有的价值呢？使用HP Mercury提供的QC+QTP的结构，已经能很好的帮助我们解决一些问题了，再加上BPT提供的组件功能和思想，我想这应该比我们自己去开发效率要高的多吧。

如果太多的去关注如何不依赖QTP提供的功能，如何去不依赖QTP这个工具，那这已经有违讨论QTP使用技术的初衷了。我想更多在这个QTP专区的朋友们也是希望能够更好的使用QTP来完成自动化任务吧。

BPT的思想之一是要将业务与自动化技术剥离，也就是说自动化工程师只需要专心让脚本跑通就好，并不用去研究业务逻辑到底是怎样的，测试逻辑测试验证点这些都是由业务专家、测试人员来指定。
这一套操作模式结合QTP+QC提供的功能就组成了一套很好的可以被复用的框架了。对于我们来说，只需要略微做些修改，让其符合本公司的模式即可。
实在复用不了那也没办法，因为它也不是万能的，不可能照顾到每个企业的情况。

如果自己能开发出比QTP更好用的同类工具，那就真的太牛啦。

作者: hsjzfling 时间: 2009-7-9 14:21
当然，我们也可以不用QC不用BPT，但QTP总还是要用的吧，结合企业一些特性，我们一样可以设计出适合自己企业使用的框架。

作者: 小_麦 时间: 2009-7-9 15:09
支持hsjzfling~!
做工作,就是尽量快速,有效...QTP可以实现我们的目的当然要用,及时我们站在QTP的平台上,做开发,写框架..那样都是很好的,毕竟工具为我们实现了很多方便的功能,我们不一定非要抛开QTP,从最底层做起...那样做怎么完成测试工作?

作者: heqingbluesky 时间: 2009-7-9 15:49

原帖由 xiaoyaoke 于 2009-7-9 11:26 发表
首先：我是坚定的站在shanxi的这个阵营的
然后说说我的理解：自动化测试理论上相当于用软件测软件，这里面分为两个层次，如果你是是从产品的层次角度去考虑来写测试脚本，这就说明你基本上是在干研发的活，因为你要 ...

可能你说的框架是为了实现某个C/S或者B/S结构的软件来说的。对于QTP而言，我们要说的框架，业务的逻辑不在框架内实现，是在每个脚本中实现的。只有这样，你框架的通用型才强，不会每个软件一个框架。

作者: xiaoyaoke 时间: 2009-7-9 16:30
标题: 回复 53# 的帖子
请问你所说的框架主要包含的功能有哪些?

作者: f84248860 时间: 2009-7-9 17:31
我说两句~

中国人的习惯，先抄再改。(TAOBAO. XIAONEI..etc)

所以在我们准备想改之前，最好问问自己，你抄全了没有？

作者: billhu 时间: 2009-7-10 12:12
我们公司是大公司不用盗版软件，另外调研时发现QTP太大，有时死机不太稳定，不能脱离QTP运行造成部署不便等原因，自己开发了测试工具，是针对特定产品开发的，实现了测试业务逻辑和实现分离。相当小，程序加上测试业务逻辑（大约实现了1、2千个测试用例的自动化）不过10M多。运行时间大约20小时。产生的效益我认为象小马过河，既不能神化，也不会一无是处。回过头看看，QTP还是很了不起的工具，做的那么通用，能够适应多种情况，可用性很强。现在，我们的兴趣在计算机辅助进行测试设计。

作者: xiaoyaoke 时间: 2009-7-10 13:12
标题: 回复 56# 的帖子
未来之路

作者: heqingbluesky 时间: 2009-7-10 13:45

原帖由 xiaoyaoke 于 2009-7-9 16:30 发表
请问你所说的框架主要包含的功能有哪些?

就是可以让QTP在不同的架构的软件下运行，有入口，输入/输出，错误处理，日志，数据比对等等。

具体业务的实现在不同的case中。不知道这个是否可以称为框架？

作者: xiaoyaoke 时间: 2009-7-10 14:18
标题: 回复 58# 的帖子
就是可以让QTP在不同的架构的软件下运行，有入口，输入/输出，错误处理，日志，数据比对等等。

QTP不是都实现了吗？

作者: wtucel 时间: 2009-7-10 16:55

原帖由 jadeyu712 于 2009-7-8 13:15 发表

不能做压力测试。但是可以把功能脚本放到LR中当作压力来测试。

还有这个功能？不是吧，QTP是依靠对象库的，我还不知道LR也有对象库的概念。

作者: wtucel 时间: 2009-7-10 17:09
讨论框架有没有用，根本毫无意义，事实胜于雄辩
QTP本身就是基于关键字驱动的自动化测试框架。
感觉很多人都没理解什么是框架，建议大家去了解一下HP BTO的思想
框架的目标在于统一管理，质量可控，所以HP推出了质量中心的概念Quality Center + QTP
通过质量中心，就能对脚本、对象库等进行统一管理和度量，这就是很好的框架。
同样，HP还推出了性能中心的概念Performance Center +LoadRunner
还有安全性中心的概念Application Security Center

作者: Robel.Yi 时间: 2009-7-10 18:32
楼主肯怕是不明白什么叫框架，如果框架就是用QTP的话，我只能说很遗憾，你还没到谈论框架的这个阶段，等你做两年自动化以后再回过头来看吧。

作者: lvguobin 时间: 2009-7-11 12:49
框架很大程度依赖于,该工具支持的语言。
没类，没封装、没派生、没重载、没继承等等利于框架实现的因素
的语言来支架。框架！No way！

作者: shanxi 时间: 2009-7-11 13:34

原帖由 lvguobin 于 2009-7-11 12:49 发表
没类，没封装、没派生、没重载、没继承等等利于框架实现的因素
的语言来支架。框架！No way！

虽然我对QTP这个工具很是不屑（虽然它比较丰富的插件弥补了VBS语言的不足），但我很不赞同你把框架提升到神仙才能触及的理念。
我觉得能解决实际问题用起来OK能提高效率的都能称为框架！

不可否认支持OO语言的框架有着原生优越的可扩展性，但这是语言所带来的便利，即使支持OO语言框架的设计者起初把方法封装地支离破碎，后来者如果有兴趣也可以利用OO语言的优势去修复或者重写它。但这并不是说采用像VBS这样对OO支持不好的语言的工具所采取的提高效率的写法所生成的脚本合集就不能算作框架，因为不要忘了对大部分公司来说测试的投入并不多，VBS这样的语言能快速地上手节省雇人的成本（国内D版的成本相当低），而且VBS的开发效率也非常高（HP QTP得感谢微软，猩猩会VB不会Java

）。

PS:我用C++、C#做过框架类的开发，也看过不少C#、Perl等脚本语言开发的框架。

[ 本帖最后由 shanxi 于 2009-7-11 14:36 编辑 ]

作者: volvoo 时间: 2009-7-12 09:49
标题: qtp 严重点说
有点象玩具，怎么玩都可，就是不能玩大了

作者: poworse 时间: 2009-7-12 10:34
额。。。对楼主的观点不予置评，说说本人公司用QTP的情况吧：
有一套完整的框架（楼主要鄙视了？）
测试对象是一个安装包3个G的产品（不算小了?）
升级维护该产品十几年了（算有年头了吧？）
耗时9个月采用QTP开发出2000个case（虽然case覆盖率仅有20%）
在统一框架的管理下可在windows2003各版本、windows2008个版本下运行（至少4个环境，有强大的平台兼容性）
并且可向下兼容一到二个版本（即该case可用于该产品前一到两个release）

而这一切，和一个强大的框架密切相关的。
PS：不知道楼主用的是正版还是盗版，你要相信，没有公司会花几百万去买一个软件就给你当个小工具偶尔用用的。

作者: tidy_wwwww 时间: 2009-7-12 13:20
mark一下，吵架挺有意思的！楼主呢？~

作者: huipingzhai 时间: 2009-7-13 11:08
标题: 这个帖子要顶，支持技术讨论！
这个帖子要顶，支持技术讨论！

作者: volvoo 时间: 2009-7-13 15:12
标题: 回66楼
1 如果不算泄密，你可以说说你们是如何框架的
2 你们的被测程序界面是否经常发生变化？
3 有多少人在维护这些脚本
4 全部执行完毕，需要多长时间？是否需要人工干预？
5 20%是需求覆盖率吗？还是占总用例数的20%
6 是b/s结构的web程序还是c/s结构的程序？

作者: newsun 时间: 2009-7-13 15:54
我喜欢看人吵架，很有趣哎

俗话说得好：话不说不明，理不辩不透。
不过加上人身攻击的话，就是另一回事了

作者: volvoo 时间: 2009-7-13 19:52
标题: 关于qtp
如果说qtp是一个强大的工具，我很赞成，
如果你说你用qtp自动化接口，开发了一个万能的框架，投入很少的维护工时，就能顺利在每个版本执行，这我只能说忽悠了。

作者: volvoo 时间: 2009-7-13 20:11
标题: http://www.ibm.com/developerworks/cn/rational/r-cn-rftwindows1/
使用 IBM Rational Functional Tester（RFT）测试 Windows 应用程序: 如何构建结构良好的测试框架

  文档选项
  打印本页

将此页作为电子邮件发送

级别：中级

陈昱旻, 测试工程师, IBM
祝天光, 测试工程师, IBM
张捷, 测试工程师, IBM

2009 年 3 月 27 日

在进行 IBM Rational Functional Tester（RFT）自动化测试脚本开发时，我们往往需要首先创建一个测试框架，然后基于此进行测试脚本的开发。一个设计良好的测试框架会给以后的脚本开发带来很多便利。在这篇文章里，我们结合一个实际的项目来介绍一下如何使用 RFT 构建一个结构合理、可扩展的，用于测试 Windows .Net 应用程序的测试框架。
测试框架设计的几点原则

本系列从如何构建结构良好的测试框架、高效的对象缓存机制，以及测试 Windows 应用程序的技巧和方法等方面，介绍如何运用 RFT 测试 Windows/.NET 应用程序。

一种高效的对象缓存机制在测试框架中的应用
利用 Windows Domain 测试 Windows 控件
对 TestObject.find() 方法的扩展与改进

一个好的测试框架需要具备哪些元素呢？虽然对不同的项目而言，答案可能有所不同。但总的来说，一个好的测试框架通常具有以下的共同特点：

分层结构
关注分离
代码重用
结构清晰
易于维护
方便调试
可扩展性好
除了以上所述的几点外，一个好的框架还应该提供相应的通用服务，以使得脚本开发者可以很容易而且快速地基于它来开发脚本。比如象错误处理，本地化版本支持，日志服务等。

回页首

定义良好的层次结构

如何定义一个良好的层次结构，是我们在构建测试框架首先需要考虑的问题。通常我们会把最基本的一些原子操作放在最底层，而在较上层封装这些操作，并开放相应的接口供最终的脚本开发者进行调用。这样往往会使得 Case 更加简洁易读。

根据面向对象基本理论，我们首先要定义一些基础的控件类，用来代表那些需要在测试中进行操作的基本界面元素，象按钮，输入框等。如果你使用 RFT 测试 Java 或 Web 应用，那么你可以直接使用 IBM Package，在这个包里封装了所有的在 Java 和 Web 这两个 Domain 下的基本控件。通过在你的脚本中调用这些类，你就可以很方便地实现对被测应用的操纵。但是，我们所测试的应用是基于 Windows .Net 的，在这个包里没有对应的控件类可以利用，因此，第一步，我们要开发自己的控件类。

其实，我们也可以不定义基础类，而直接使用 GUITestObject 来操纵每一个界面对象，但这样做的代价是显而易见的，会有很多重复且不易读的代码充斥在我们的脚本中。这显然不是我们所想要的。好在虽然各种控件的种类繁多，但对于每一个控件而言，需要封装的主要是一些我们在测试中经常需要调用的简单方法，比如说 Click()，或 SetText()，因此工作量并不太大。

在实现了这一层之后，理论上说，我们可以直接在 Case 脚本里调用这些方法来实现对测试对象的操作。但这样做也有一个问题是，如果以后你对这些方法的名称进行了修改，或者因为程序实现的改变，原来的 A 类控件被 B 类代替，这时，势必会对所有已经编写好的 Case 脚本造成很大的影响，带来很大的代码维护量。因此为了隔离下层代码对上层 Case 的影响，我们在其中又加入了新的一层。最后的层次结构如下：

图 1. 层次结构

以下是对每一层的具体解释：

NetWidgets：这一层封装了所有的基本 Windows 控件，它与具体的应用无关，可以看作是测试 .Net 应用的基础类库。对应于 Windows 的每一个控件，在这一层里，都有一个对应的 Class，其中包括对该控件的基本操作，以及一些在测试过程需要使用的验证方法，比如验证某个属性的值。
AppLib：所有与当前测试应用相关的方法及对象在这一层定义。它包括 2 部分：
Dialogs：正如名称所示，在这一部分中，主要保存所有的对话框或其他窗口对象，以及对这些窗口上控件的操作方法。他们通过调用下一层的基本控件函数来实现。与 NetWidgets 不同，在这一层定义的方法，是与应用中具体的控件名称所绑定的，具有明确的含义，如 SetPassword()；而在 NetWidgets 层中，仅仅是某一类控件的一个通用的方法而已，如 SetText()。除了窗口对象外，一些其他的经常需要乃至的对象，如应用中的菜单，工具栏等，也在这一部分定义。
Wizards：在这一部分所定义的方法，他们包含是一些基本操作的组合，用来完成某项具体的功能，如 Login()。这些功能都是大部分 Cases 需要经常调用，或者是特定的测试步骤组合。通过将它们纳入这一层统一管理，可以很方便地起到代码重用的目的。通常这些 Wizard 是对同一个 Dialog 上的操作组合，但这并不是必须的。有时候跨多个 Dialog 的组合操作在测试用例中也是很常见的，因此也需要归纳从而提高重用性。
TestCases：很明显，这是最上一层，也就是保存所有测试脚本的地方。通过调用中间 AppLib 层的方法来实现所有测试功能，包括执行操作，检查状态并记录测试结果。
在描述完整个框架的大致结构后，我们来看看这种结构的优点：

代码隔离。通过引入 AppLib 中间层，对最上层 TestCases 屏蔽最底层实现，也就是将测试逻辑与具体功能实现逻辑分开。TestCasse 层只关注具体的测试步骤，而 NetWidgets 完成最终的功能实现。通过这种方式，使得 TestCases 层的代码简单明了，可读性好；另外未来对 NetWidgets 的改变将不会对 TestCases 层造成任何影响，也就是提高的程序的可维护性。
结构清晰。各层所定义的方法及功能也十分明确。每一层仅通过调用其直接下层来实现功能，禁止跨层调用保证代码之间的多重依赖。这对编码调试或测试运行时对问题的快速定位很有帮忙。
可扩展性好。软件产品总是在不断地发展，新功能不断地引入。在使用这种三层结构的框架以后，当需要增加新的 Cases 时，只需先加入对应的对话框及窗口对象到 AppLib，然后再通过调用它们来完成代码编写。新加的 AppLib 对象不会对原有的对象造成任何影响，因为每个对象都有仅属于自己的代码文件。而原有的 AppLib 对象则可以简单地在新的 Case 中重用。
采用这样的框架，只开放相应的接口供最终的脚本开发者进行调用，会使 Case 更加简洁易读。在 GUI 界面发生变化时，也不需要对 TestCase 做任何修改，大大提高了程序的可维护性和可扩展性。

回页首

在 RFT 里的具体实现

在定义完整个测试架构以后，接下来是在测试工具中用代码加以实现。在本项目中，我们使用的是 RFT，现在，让我们来看看在 RFT 里的具体实现。

图 2. 在 RFT 里的实现

从上图可以看到，我们使用 3 个 Project 来对应 3 个不同的层，而不是象通常的项目一样，将所有的代码放在一起，层次结构通过不同的包结构来体现。这样做的主要原因是让各层之间更加独立，而且更易于管理。另一个好处是，多个 Project 的设计可以让复制和共享更加灵活。例如，当其他 Team 也想要利用 NetWidgets 时，只需要简单地将对应的 Project 共享给他们即可；而另一个 Team 如果需要某一个 Suite 来验证某项具体功能，则可以将 3 层所对应的 Project 都共享给他。

Dialogs 和 Wizards 目录中定义了所有与具体被测应用相关的方法，而位于 Suite Project 中的 Test Case 则调用他们来进行测试。在这里我们列出一些代码以便大家能够更清楚地了解它们之间的调用关系。

这是一段摘自 LoginDlg.java 的代码（Dialog）：

图 3. LoginDlg.java 代码片断（Dialog）

这是一段摘自 Login.java 的代码（Wizard）：

图 4. Login.java 代码片断 (wizard）

从上面的代码可以看出，在 Dialog 对象中，所定义的方法都是对该 Dialog 中控件的基本操作方法，象点击一个按钮，在编辑框里输入字串等。但在 Wizard 中，则通过将这些 Dialog 中的基本操作串联起来完成一个简单任务，如登录。相类似的功能则放入同一个 Wizard。

回页首

框架中的其他公用服务

通过在框架中提供一些公用服务，可以使得该框架更加易于使用，并且功能强大。在前面的图 2 中，可以看到在 Utils 目录下有 3 个 Class。它们分别提供不同的功能，让我们做一下简单的介绍。

对于自动化测试而言，有一个很重要的环节是用一种统一的方式来记录测试的结果，从而可以方便地进行统计或生成报表。所以第一个要提到的是 TestResult。

TestResult

这个 Class 用来记录每个 Case 的名称和执行结果。它读取一个 Xml 模板文件，这个文件定义了哪些内容需要在测试结果中显示。在自动执行完成后，包括 Suite 名称，测试环境，Case 信息，测试结果等这些数据将会被写入，生成结果文件。最后通过一个事先定义好的样式表文件进行格式化，用网页的形式呈现。

另外，对于失败的 Case，最主要的错误信息及屏幕截图也会一并记录下来，以方便进行分析查错。

LibException

这个 Class 作为所有运行时异常的基类。这个父类里增加了以下功能：

当有错误发生时，抓取屏幕截图，保存到本地文件，同时将文件路径写入一字符串属性中。
当有错误发生时，保存错误的 Stack trace 到文件中，同时将文件路径写入一字符串属性中。
通过这些功能，结合使用上述的 TestResult 类，就可以很方便地保存每个错误发生时的详细信息，而不仅仅是一个简单的错误消息。

ObjectFinder

一般来说，在 RFT 测试中，通常使用 Object Map 来在回放中定位界面对象。Object Map 是在测试脚本录制中自动生成的，因此使用起来较为方便。但它有一个缺点是，它记录了所有对象的层次结构，并据此进行查找。一旦对象的关键属性或层次发生改变，则必须重新录制以更新 Object Map。当项目里 Case 比较多的时候，这就变成了一项费时费力的工作。因此，RFT 还提供了另一种动态查找的方法 TestObject.Find()，在编写脚本时可以即时地调用该函数，通过给定的属性值进行查找定位。目前它的效率已经与通过 Object Map 定位不相上下。

ObjectFinder 类是一个用来动态查找对象的工具类，它通过调用 TestObject.Find() 来实现，并提供多种不同的查找方法。最常见的是指定对象的 .class 和 .text 属性来在某个窗口中进行查找。这个类主要在 AppLib 层中的 Dialog 对象中使用，在那些对窗口中对象进行操作的函数中，第一条语句很可能就是调用 ObjectFinder.getObject(className, captionText, parent) 来找到所要操作的界面对象。

另一个使用动态查找的好处是，可以将那些用于识别界面元素的关键属性保存到一个配置文件中。当有属性值变化时，就可以很简单地通过修改配置文件实现，而无需修改脚本。同时，如果需要进行其他语言版本的测试，也可以直接将配置文件替换为其他语言版本的文件来实现对多语言版本测试的支持。在我们这个项目中，我们还有另外一个工具可以直接从源码的资源文件中提取界面上的文本资源，自动生成我们所需的属性识别配置文件中，从而大大简化了手工编写的工作量，同时也可以轻松应对因界面文本改变而带来的查找修改的困扰。

回页首

结束语

开发一个适合自己项目的 RFT 自动化框架，需要了解架构设计方面的基础知识，以及清楚地知道一个好的测试框架所需要提供的功能。但这并不很困难，因为有很多这方面的文章和经验可供参考，同时也有很多成熟的框架可资借鉴。

除了结构清晰，关注分离，易于扩展之外，一些通用服务也是一个好的测试框架不可或缺的部分。通过利用这些服务，RFT 的脚本开发人员可以更方便、快捷地开发出自动化脚本，同时保证使用统一的方法，生成格式一致的测试结果。这些也是使用框架的意义所在。

http://www.ibm.com/developerworks/cn/rational/r-cn-rftwindows1/

[ 本帖最后由 volvoo 于 2009-7-13 20:12 编辑 ]

作者: volvoo 时间: 2009-7-13 20:13
标题: 再牛，你有ibm牛吗
请参照上篇

作者: poworse 时间: 2009-7-14 00:16

原帖由 volvoo 于 2009-7-13 15:12 发表
1 如果不算泄密，你可以说说你们是如何框架的
2 你们的被测程序界面是否经常发生变化？
3 有多少人在维护这些脚本
4 全部执行完毕，需要多长时间？是否需要人工干预？
5 20%是需求覆盖率吗？还是占总用例数 ...

可以稍微回答一下。。。
1. 这个无可奉告。。。
2. 恩，作为一个十几年的产品了，一年一个release，总是难免有些变化的。花在这方面的effort是在所难免，不过，花费的时间不太多。
3. 十个左右的automation QA在开发cases和维护脚本。
4. 这个不太确定。根据不同的模块写的测试用例，效率是不同的，有的300个case5个小时就够，有的复杂的50个case就要12个小时。
5. 20%是占所有用例的比例，其实可能还不到20%，总的测试用例过万是肯定的。需要做的事情还很多。

其实无意进行争吵，只是想用平常心进行一下讨论。我们的框架也有很多的不足，还有待于改进，但是至少，它有序的支撑起了上千个case的运转。
关于QTP这样一个产品，license卖的如此只贵，却还能每年给HP带来不小的收益，说明它的市场还是很大的。如果只是作为测试工作中的辅助工具，难免暴殄天物了。
由于QTP本身的一些不足之处，需要设计框架对case进行管理，让开发人员更方便、高效的进行分模块的测试，个人认为也是不可缺少的。
一个健壮的框架并不是说可以消除你在各个方面繁琐的花销，相反的，有时候也会带来一些负面影响。但是，它带来的是很好的维护性，移植性，以及在某些方面可以减少一些不必要的effort。
框架的存在，目的是为了让QTP更好的发挥左右而已，它确实不神奇，但是很重要。

自动化测试需要公司下大功夫投入，需要有经验的研发工程师参与，而这些确实很多公司没有办法做到的。和微软比起来，大多数公司的自动化测试还有很多的路要走。。。不要抱怨，多从自己找原因，大家一起努力吧。

作者: poworse 时间: 2009-7-14 00:17

原帖由 volvoo 于 2009-7-13 20:13 发表
请参照上篇

如果我告诉你，我是IBM的，不知道你会怎么想？呵呵。。。

作者: heqingbluesky 时间: 2009-7-14 16:57

原帖由 volvoo 于 2009-7-13 20:11 发表
使用 IBM Rational Functional Tester（RFT）测试 Windows 应用程序: 如何构建结构良好的测试框架

  文档选项
  打印本页

将此页作为电子邮件发送

级别：中级

陈昱旻, 测试工程师,  ...

是的，框架就是这些东西了，我们公司的也有自定义的testresult,不需要qtp自带的。我们也有error handling,自己写的，我们也有自己的log日志，可以轻易知道脚本运行时候的错误。

框架就是这样一种东西而已，没有什么过多的api定义，重载，继承..........................，过于复杂的东西你也不想用，也不愿意去弄，毕竟qtp是一个回归测试工具而已。

作者: ziheng198688 时间: 2009-7-14 17:33

原帖由 wtucel 于 2009-7-7 20:13 发表

楼主也在忽悠人，第一次听说用QTP做压力测试的

其实QTP是可以做压力测试的哦呵呵

作者: volvoo 时间: 2009-7-15 14:52
标题: 是ibm还是ibm的外包
如果你是ibm的正式员工,而不用本公司开发的RFT作为界面测试工具,我只能无语了.

作者: volvoo 时间: 2009-7-15 14:57
标题: 所谓的框架
我们也有一个所谓的框架，通过调用qtp自动化接口执行用例，通过框架管理多个用例执行和参数传递，作了一个公共脚本库。

作者: 47385024 时间: 2009-7-16 11:04
楼主的话貌似太偏激了吧即使是王麻子菜刀也不一定会适合所有的厨子你用他来切生鱼片效果就不一定好对吧呵呵适合自己的才是最好的一切工具皆为我所用才是正道

作者: dreamever 时间: 2009-7-16 11:07

原帖由 47385024 于 2009-7-16 11:04 发表
楼主的话貌似太偏激了吧即使是王麻子菜刀也不一定会适合所有的厨子你用他来切生鱼片效果就不一定好对吧呵呵适合自己的才是最好的一切工具皆为我所用才是正道

这个说得好，顶

作者: xiaoyaoke 时间: 2009-7-16 11:44
标题: 回复 80# 的帖子
怎么感觉你这话说的不伦不类呢？

作者: tongl0413 时间: 2009-7-21 00:05
xuexile

作者: 兰兰 时间: 2009-7-22 11:44
部门也在评估实施自动化测试的代价以及必要性。
   就我自己最近一段时间的研究来说，此工具有一定的可用性，但是前提条件要在适合的产品类软件或者在周期交长的项目中才可以试用；
   在前期引入代价太高，最好能成立一个专门的研究小组来研究自动化测试；
   不能指望让QTP工具来给你发现缺陷，因为他只能发现一些旧的缺陷；
   在实施自动化测试之前，要对具体的框架以及用例做很好的规划，并不一定所有类型的测试都适合QTP测试，在具体的实施过程总，一些正向类的验证可以来利用工具，但是一些反向的测试（例如校验类，流程回退类的测试等）这样的测试如果也用QTP来测试，那真的是代码设计以及维护量就不可预估了。

作者: 淡淡风轻 时间: 2009-7-22 14:22
看公司和项目的规划了，投入是不是能接受，值不值得了

作者: fengxiaohong 时间: 2009-7-23 09:07
标题: 通过QPT录入数据来练习使用QTP
QTP一直不用,最近公司要录入数据,觉得QTP不错录入速度挺快的就决定选他来录入
现在就是QTP不能重复选择上传的数据,这里有点麻烦

作者: here556 时间: 2009-7-27 15:59
这是一个百家争鸣的好帖

作者: dreamever 时间: 2009-7-28 11:02

原帖由兰兰于 2009-7-22 11:44 发表
部门也在评估实施自动化测试的代价以及必要性。
就我自己最近一段时间的研究来说，此工具有一定的可用性，但是前提条件要在适合的产品类软件或者在周期交长的项目中才可以试用；
在前期引入代价太高， ...

最后一句不太同意，就是关于反向用例维护起来代价太高的观点，纯学术讨论，没有其他意思。
无论是什么工具，自动化测试贯彻的基本思想是一样的，那就是数据驱动测试。具体到测试实现上，那就是我们要用不同的数据作为输入，驱动脚本去执行测试。举一个简单的例子，用户登录，正向用例成功登录没问题，但是反向用例登录失败时的操作会与正向用例不同，有的人因此把正向反向分别录成了两个脚本，这样维护的代价肯定就高了。而我们采用的做法是，写一个通用的方法login,然后在该方法中用if else来判断登录是否成功，这样自动化测试的数据就与相关的操作分离了。操作是可以重用的，不同的数据对应着不同的测试结果。当然这个例子很简单，它只说明了一种最常见的情况，但是我相信这个理论是通用的，就是说我们要将测试过程中不变的东西抽像出来，形成通用的方法或者组件，这样一来维护的工作量自然也就小了。
到现在我一直都有这样的结论：如果自动化测试失败了，原因会很多，但是肯定跟工具无关；同样，楼主说的反向用例的设计和维护代价高，我相信这也应该和工具是没关系的，而是和你们进行自动化测试的方式有关（直言，请见谅），不然我们可以提另外一个问题：如果你们换一套其他的工具，那么代码维护的工作量就一定能减少吗？我想答案是显而易见的

作者: dreamever 时间: 2009-7-28 11:15
补充一下，你前面三句话和第四句的前半部分我是坚决同意的

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)