51Testing软件测试论坛

标题: （原创）Robot和QTP的缺点对比： [打印本页]

作者: jdragon 时间: 2005-3-24 15:06
标题: （原创）Robot和QTP的缺点对比：
（原创）Robot和QTP的缺点对比：
Robot：
缺点：
1、 DataPool使用麻烦，一定要在Script中，只能利用界面定义一个DataPool对象。如果能够让DataPool函数直接读取一个CSV，而不是通过DataPool的名字，可能会更方便。
2、 VP使用麻烦，大部分的对比，都只能采用VP对象来进行对比，而VP对象必须依赖录制来完成，而且当测试过程比较大的时候，录制很多VP是一件繁琐的事情。
3、 Current Context存在一点问题。当点击一个按钮，弹开一个新IE窗口，而该IE窗口和现有的某个IE窗口同名的时候，没有一个非常合适的方法设置新弹开的窗口为Current Context。
4、 Robot录制的脚本，其RecMethod名字查找部分，都是使用FullRec的名字方式，使用起来非常的不方便，特别是有FRAME存在的时候，路径可能有四、五层。其实，利用Current Context的概念，合适的修改Current Context，可以大量的简化脚本，论坛上很多人问的问题，都和找不到对象有关，那么长的FullRec名字，看看都头晕了！

虽然Robot有这么多的缺点，但是QTP的缺点我觉得更多：
QTP：
缺点：
1、必须要在Object Repository库中建立Test Object对象，而且该库还没有办法手工建立，必须使用SPY来抓取，或者在录制的过程中自动建立。有的时候，当你在页面中跳转过去，再跳转过来，虽然是同样的一个页面，但是你会发现QTP会自动帮你建立很多的Test Object对象，大量的Test Object，只能在界面中进行维护，让QTP的测试脚本可修改性很差。基本上你无法通过修改脚本来驱动被测试程序往新路径运行。
2、测试脚本非常庞大，因为要记录大量的录制内容，导致测试脚本非常的庞大，除了一个Script文件外，附带了大量的Test Object。我简单的测试了8个步骤，总共三个页面，就建立了10左右的Test Object，如果要做一个集成测试用例，关联多个模块的，估计没有100多个Test Object是不能完成的。由于脚本庞大，尽管QTP把Test Object都记录为XML的文本格式，但是如果要进行配置管理，还是非常的不方便。
3、无法和需求、缺陷直接关联，由于MI公司的DirectTest没有调查，所以没有发言权，不过利用IBM的RequisitePro和ClearQuest，可以比较方便来进行跟踪管理，公司的需求管理准备利用RequisitePro，所以测试工具能够直接集成，当然更好了。

由于以上理由，我觉得还是Robot比较合适做我们项目的测试工具，主要因为其灵活，不知道大家如何看？
欢迎补充！

作者: 司空公子 时间: 2005-3-24 16:23
呵呵，很多刚接触自动化测试工具的同行，一上来就问哪种工具比较好用，robot，winrunner还是QTP。各有各的好处，各有各的缺点。主要还是看各人所测试的软件的情况，公司对工具的态度，以及自己掌握的语言的情况来定吧。有兴趣的话，先精通一门，然后慢慢再学习其它的工具。
有了问题，大家在论坛里互相讨论，希望51论坛越来越好。

作者: guirongb 时间: 2005-3-25 08:33
DataPool使用麻烦

自己可以开发用Excel文档来替代Datapool,我已经不使用Datapool了,的确麻烦.

作者: jdragon 时间: 2005-3-25 11:20
标题: 更正一下！
VP的建立可以通过编写脚本来自动完成。
Robot中大量的比较函数都是基于VP的，
如果没有VP，感觉是缺少那么一点东西。

谢谢guirongb的帖子，我们也准备放弃DataPool了。
不知道您是否能够发布一些 Excel文件处理的经验。

另外SQA中有一套SQL*的函数，可以很方便的实现从数据库库中读取数据，
譬如Access数据库，当然，如果利用ODBC，则是可以直接读取Excel了：）

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