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

dreamever · 发表于 2009-7-16 11:07:37

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

这个说得好，顶

xiaoyaoke · 发表于 2009-7-16 11:44:15

怎么感觉你这话说的不伦不类呢？

tongl0413 · 发表于 2009-7-21 00:05:38

xuexile

兰兰 · 发表于 2009-7-22 11:44:45

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

淡淡风轻 · 发表于 2009-7-22 14:22:02

看公司和项目的规划了，投入是不是能接受，值不值得了

fengxiaohong · 发表于 2009-7-23 09:07:08

QTP一直不用,最近公司要录入数据,觉得QTP不错录入速度挺快的就决定选他来录入
现在就是QTP不能重复选择上传的数据,这里有点麻烦

here556 · 发表于 2009-7-27 15:59:11

这是一个百家争鸣的好帖

dreamever · 发表于 2009-7-28 11:02:27

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

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

dreamever · 发表于 2009-7-28 11:15:33

补充一下，你前面三句话和第四句的前半部分我是坚决同意的

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

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

回复 80# 的帖子

通过QPT录入数据来练习使用QTP

站长推荐 /1