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

dreamever

顶楼上的头象

dreamever

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

dreamever

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

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

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

dreamever

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

这个说得好，顶

dreamever

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

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

dreamever

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