（原创）Robot和QTP的缺点对比：

jdragon

（原创）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比较合适做我们项目的测试工具，主要因为其灵活，不知道大家如何看？
欢迎补充！

sincky

如此说来，robot的确比qtp强大一些！
不过个人觉得，ibm的robot是和mercury的winrunner是相同档次的工具，qtp是简化版，当然有很多不足，可以说是针对web程序的功能测试，相当于ibm的xde tester！
楼主对提到的两款工具感受颇深，可以多多交流！

－－－－－－－－－－－－－－－
欢迎加入sincky的软件测试qq群:1387661

小生有礼了

我现在正在学QTP,但进度很慢,不知道怎么学,谁能帮我提点好的意见和建议?

jackei

如果只考虑引入自动化测试工具，还不如引入MI公司的产品。因为rational的工具体系过于庞大，各个工具之间的关系也错综复杂，CQ无疑是维护成本最小的一个工具。如果考虑将REQ+TM+ROBOT+CQ联合使用，那么维护就是一件很头痛的事情。另外就是ROBOT的启动和运行效率都比较低下，并且必须要先建立一个Rational Project才能使用，反而不如MI的工具方便和灵活。
再就是如果多个工具同时使用，就等着rational把内存吃光吧 ^_^

jackei

ROBOT对于C/S的系统测试效果比较好，因为对对象的识别要优于MI公司的产品。

songfun

这篇文章很棒，受益匪浅。

tomzhang

建议加精!!good!

weiping2000

原帖由 jackei 于 2005-5-13 17:24 发表
ROBOT对于C/S的系统测试效果比较好，因为对对象的识别要优于MI公司的产品。

那如果是B/S结果的产品,是不是使用robot不是很好的选择.

xingcyx

说一下个人看法：
QTP的设计初衷主要是针对非技术性的人员，所以它的可编程性显得差了一些，但是它的易用性真是没话说。并且，MI的产品都是可以和TestDirect做关联的。至于IBM的产品我没有试用过，不做评论。