一定不要把qtp神话了，所谓的框架是忽悠人的

volvoo · 发表于 2009-7-7 14:06:26

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

shanxi · 发表于 2009-7-7 14:11:25

有见解哟

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

wuei9090 · 发表于 2009-7-7 14:34:01

顶言必称框架看起来特可笑...

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

lg1318617 · 发表于 2009-7-7 14:39:41

一切以人为本

dreamever · 发表于 2009-7-7 15:12:51

顶楼上的头象

heqingbluesky · 发表于 2009-7-7 15:21:20

最讨厌GUI改来该去。

volvoo · 发表于 2009-7-7 15:42:34

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

lg1318617 · 发表于 2009-7-7 16:04:07

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

很帅乎？

wtucel · 发表于 2009-7-7 20:13:26

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

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

lantianwei · 发表于 2009-7-7 21:16:21

我相信致力于框架的大牛们也不会都是傻蛋。。。

gaoyoumei · 发表于 2009-7-7 23:00:38

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

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

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

hsjzfling · 发表于 2009-7-8 11:00:56

原帖由 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:19

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

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

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

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

nbkhic · 发表于 2009-7-8 12:05:16

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

jadeyu712 · 发表于 2009-7-8 13:15:32

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

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

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

jadeyu712 · 发表于 2009-7-8 13:16:48

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

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

hsjzfling · 发表于 2009-7-8 13:21:39

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

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

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

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

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

shanxi · 发表于 2009-7-8 14:15:06

看你滔滔不绝了半天

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

kings727 · 发表于 2009-7-8 14:34:32

一直就没搞明白自动化框架是啥？
QTP的自动化框架怎么做，更没搞明白?
模模糊糊的感觉是不是有点类似于开发中的设计。

小_麦 · 发表于 2009-7-8 14:48:09

请问什么叫ROI??

		自动登录	找回密码
密码			(注-册)加入51Testing

[讨论] 一定不要把qtp神话了，所谓的框架是忽悠人的

相关帖子

回复 1# 的帖子

我基本抛弃的GUI测试

回复 9# 的帖子

回复 17# 的帖子

站长推荐 /1