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