（原创）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比较合适做我们项目的测试工具，主要因为其灵活，不知道大家如何看？
欢迎补充！
ding 一下
对我们新人理解工具挺有用的[ Last edited by jacobs on 2005-3-24 at 16:38 ] Robot没有用过，QTP感觉还不错。 Originally posted by jacobs at 2005-3-24 04:27 PM:
对我们新人理解工具挺有用的
[ Last edited by jacobs on 2005-3-24 at 16:38 ]
谢谢支持，其实我也是新手，本周刚开始调查，
现在已经规划，准备在项目组启动robot工具了，如果成功，
下一步，会在整个Group内部推广。 robot对datagrid支持不要，没有用过QTP，不知道QTP对这方面支持如何？
还有QTP的序列号好难找啊，8888-8888888888这个根本就不型
现在论坛里有破解的最新版
补充1QTP中TEST OBject 过多无用完全可以删除 重复也是
2可以与TD建立关联
3QTP的脚本大小还是可以的不是很大，做配置管理还是什么太大问题的
4ROBOT可以从ACCESS、excel中读取数据也很方便的 hehe,maybe you need study more about it. Then you will have more clear point about them.
One point: They are all outstanding. 对QTP的第一个缺点：
估计你测的是web应用吧，如果是，那么这个和设置有关。你可以修改一下QTP对page对象的识别方式在试一试。
谢谢指导！
Originally posted by theSeaHeart at 2005-3-25 10:14 AM:hehe,maybe you need study more about it. Then you will have more clear point about them.
One point: They are all outstanding.
能不能提供进一步的方法！
主要问题试直接写代码点击某个按钮，如果该按钮在对应
的Object Repository中没有定义对象的Test Object，则无法进行！
所有的测试的工具都要先抓取测试对象才能进行操作
哈哈，各有所长，各有所短。比较是有点不合适。 看了楼主的对比以后 觉得楼主是个善于思考的人！个人有点愚见，楼主能否把每个问题在深入的考虑一下！也许会发现这些对比的缺点其实有它的特点！或者不是。。。。
希望楼主在下次 给我们 共享 更加精辟的见解！
再次感谢楼主！
个人觉得qtp测试WEB比ROBOT方便了很多
个人觉得qtp测试WEB比ROBOT方便了很多，一个Active Screen就已经比ROBOT强了，最讨厌的就是代码必须要依赖于Object Repository,还有碰到异常处理时没有很好的方法来处理后续的脚本。谢谢斑竹的意见
Originally posted by pcl2004_27 at 2005-3-28 10:39 AM:看了楼主的对比以后 觉得楼主是个善于思考的人！
个人有点愚见，楼主能否把每个问题在深入的考虑一下！也许会发现这些对比的缺点其实有它的特点！或者不是。。。。
希望楼主在下次 给我们 共享 更加精辟的见 ...
谢谢斑竹的意见，项目组正在Robot的基础上编写自己的框架：
基本方案是：
1、先设计好测试用例框架，覆盖重要的场景的路径。
2、设计好测试数据，数据存放在Excel中。
3、在Robot中利用Excel的对象来读取测试数据和正确结果，与
robot运行时候的数据进行对比。
4、测试计划和结果利用TestManager来进行管理，同时正在调查
报告的自动发送和多机器的共通测试。
近期比较忙，测试的工作由项目组的另外TS在进行，不过有新的
进展我会定期汇报。
可能的话，搭建好的框架我会整理称为一个文档，再共享给大家。
：） 解决方法：首先你需要在Tools/Object Identification 中配置好页面里面能碰到的所有对象的属性，比如说对于Webedit 来说，你需要将它的Name 和Type 属性添加进去，然后你可以只录页面，至于页面里面的对象可以通过Change active screen的方法加进去。这样就避免了重复录入页面和对象。这样产生出拉的脚本就很小了，如果自己再编辑一下，写一些通用的循环或者选择语句，脚本就很通用了。 根据楼主的描述，你们项目组的测试框架做到了测试数据和测试脚本的分离，应该在自动化测试的第二个层次，也就是可以做到数据驱动测试，不过还没看到你们最后的测试框架的实现，希望可以达到第三个层次！
如果做到第三个层次，真的很吸引人！
我的msn
piaocl_scott@hotmail.com
什么时候 楼主有时间 大家可以探讨一下！ 晕死,今天看到这人贴了尽然是一年之后,顶起来,大家继续探讨!
不要惊讶
楼上的，不要惊讶，这个帖子以后以后还有人在讨论这个话题，说明斑竹的帖子有价值呀，我看这要比某些动不动就说 什么“救命.." 的帖子 强多了！ 这样的帖子越来越多的话才说明论坛的水平和测试人员的水平越来越高呀。 can Robot test flash objects? 对于楼主说的第一点： " 必须要在Object Repository库中建立Test Object对象，而且该库还没有办法手工建立，必须使用SPY来抓取，或者在录制的过程中自动建立。" 不是很理解，QTP不是有Descriptive programming么，虽然我没有实际的用过，但是通过descriptive programming描述对象的一些属性来确定对象，不是可以不用抓取对象来添加test object么？
页:
[1]
2
