自动化测试工具QTP和SilkTest横向PK（转）

转自:http://www.uml.org.cn/Test/201405212.asp?artid=1686

  众所周知，自动化测试工具曾几什么时候三足鼎立，Mercury QTP/WinRunner系、IBM RobotJ (RFT)系、Borland Segue SilkTest系，可是几年下来，QTP在国内和国外都将同类工具远远甩在身后几条街。即便后起之秀Web界翘楚Selenium也只能将超越QTP做 为本身终身己任，以致于连名字上都要以 Selenium（硒） 克一下它的偶像 Mercury（汞，硒解汞毒）。

可是时过境迁，SilkTest 已经再也不是当年的那个SilkTest，QTP也再也不是当年的QTP。2013年的自动化测试工具由于QTP的裹足不前和SilkTest 的浴火重生变得有了味道。

好吧，必定有人要站出来讲QTP如今的市场份额在国内的仍然有 60%，SilkTest还远未成气候，而Selenium只能进行B/S的自动化，不可能取代之……我只想说，这几年以来QTP并没有太大建树，除了界面 更加华丽，兼容性更差，更耗资源，内核未作更新，就是多了一些华而不实噱头级别的功能特性和某几个小功能——真的一直没有太大变化，按照这样的趋 势，QTP颇有可能成为下一个WinRunner。

好吧，最近网站和论坛正在热捧 WinRunner，好多朋友连这个名字都没听过，跑个题，告诉你们 曾经的WinRunner就像今天的QTP同样统领自动化领域的武林，若是你们去看国外最大的SQAForum就会看到它的历史回帖数在今天仍然跻进 Top 3，可是若是你去 bbs.51testing.com 的论坛看看它目前的人气那真是使人嗟叹，整个季度的回帖数不足10篇！

QTP可能会变成下一个WinRunner，做为使用了QTP 十年之久的我从感情上有些舍不得，可是必须面对的要去面对，咱们应该拥抱变化。

好吧，闲话少说，如下横向PK两大商业级自动化测试工具：

（一）编程语言：

QTP一直以来都使用 VBScript. 做为本身的引擎，这在必定程度上下降了学习的成本，确实吸引了不少初学者来学习和使用QTP。

但 VBScript. 不是一个纯粹的面向对象编程语言，除了能够封装Class，是不能继承和多态的。直接一点说，这样天生缺陷使得QTP的重用性从骨子里就不好，执行效率还很低！

而 SilkTest呢，能够支持 .Net， C#， Java， 以及它自身的 4Test，这自己就能够吸引一大批编程基础扎实的开发人员参与到自动化的实施过程当中，而它强大的面向对象基因，强大的重用性，强大的维护性（甚至能够轻 而易举进行版本管理，学过QTP的同窗都知道，QTP所谓的简单只是入门简单，后期维护是很是恐怖的），极高的开发效率更是远超QTP。

（二）检查点（Checkpoint）

QTP 的检查点一贯不三不四，好像基于对象库（由于是在对象库中才能看属性），又好像脱离于对象库（由于不是全部的检查点均可以进行对象模式的维护管理，而 Checkpoints和Test Objects是并列节点不是归属关系），这在开发过程当中被不少朋友直接抛弃，改用其余手段作验证（好比经典的 GetRoProperty）。

而SilkTest呢，直接经过代码秀出本身要检查的对象的属性等信息，简单易懂不说，维护方便不少——毕竟，难道你喜欢一边在Expert View里编程一边在对象库里看对象吗？累不累啊？

（三）“录制/回放”

QTP的录制分为：标准录制模式、低级别录制模式（WinObject对象模式）、模拟录制模式（模拟鼠标运动轨迹）。在视图上采用了业务专家（SME）的 Keyword View和编程人员的 Expert View。

整体来讲还算不错，除了专家视图模式下的编程功能太坑爹。

而SilkTest呢，有 SilkWorkBench、Silk4J、Silk4Net、SilkClassic等一堆的IDE，支持VB.Net、C#、Java等IDE，真的以为假如你是团队化开发自动化测试脚本的话，SilkTest的优点要比 QTP明显不少。

（四）脚本

QTP 的脚本我一直不喜欢，由于不是纯文本。它在建立工程的时候 （QTP中的工程叫Test，而不叫 Project），会生成一堆的资源文件，好比ObjectRepository.bdb、Resource.mtr，还有截图目录SnpaShots目 录，而脚本代码放在 Script.mts 中，还恰恰在代码行后附着了 Active Screen关联的图片信息。这样致使的直接结果就是版本管理工具无法进行代码的冲突管理，好比merge操做。

另外启动信息非要整在 Action0 这个目录里面，这种规划思路很很差，过分分离的结果是你维护的时候不得不关注一大堆地方。

而SilkTest呢，就是单一的脚本文件，我即便不开工具也能够直接修改。简单即美，难道不是么？

（五）异常捕获、场景恢复

QTP 的场景设计也很复杂，又是独立于脚本（脚本里看不到），在脚本外进行配置（相似resource），须要开发者思路很清晰的规划它可能在什么地方出现什么 错误、怎么处理，最糟糕的是可读性极差，假如你在场景里面还有Function Call还得再配一个外部qfl或vbs文件，而若是引起了迭代还要在另外一个Settings中作迭代设置，不然你场景恢复的时候可能莫名其妙的调起了好 几遍本身的应用。一句话，真的很坑爹，不是通常的高手搞不定它。

而SilkTest呢，本身编程实现，开箱即用，真正的 7*24小时支持。

（六）插件支持（Add-ins）

QTP每一个编程语言都须要一个插件，经过插件来识别对象。而有时候这种插件加载显得很不灵活，好比你勾选插件进去之后竟然无法再添加，这什么易用性啊？

而SilkTest呢，不须要安装这个那个插件。一句话：哪儿那么多麻烦啊。

（七）Web 2.0支持

QTP 对于 Web 2.0 的支持，我连写的欲望都没有，由于实在太差了！ 什么Ajax/DHTML，什么Flex，所有都不认（或者干脆整个窗口认为ActiveX），……你真的想用是吧，好，激活object，经过 native object调用HTML DOM对象。那么这样一来就很强大了吗？NO，NO，NO，穿上了钢铁侠盔甲的QTP顶多跟 Selenium RC（也就是Selenium 1.0）打个平手，由于原理都是经过 JavaScript注入HTML DOM来实现的（同样的能够采用innerHTML赋值，能够RunScript），跟WebDriver（Selenium 2.0）就无法比了。

能够说，QTP曾几什么时候战胜 WinRunner的 关键就是Web 1.0 的支持超强，可现在死在了本身的最强绝学上。这也是为何后来给了 Selenium 以可趁之机的地方！

可是 Selenium 的强项在于纯HTML/JS应用，对于 Flex基本无能为力。

而反观 SilkTest，全面支持 Ajax/DHTML，Flex/Adobe Air，全面支持 .Net 4.0，即便 Adobe公司本身也是选择SilkTest做为它的自动化测试工具哦！

（八）参数化、数据驱动

QTP 号称本身采用 Keyword-Driven，一种在Data-Driven基础上派生的更高级的扩展驱动理念，而事实上是QTP 直接把数据驱动的框架内嵌在本身的DataTable上，以 DataTable Object的内核结合Action迭代驱动脚本运行。这意味着号称本身是共产主义社会，但其实在封建主义社会。这么说已经很客气了，事实上 DataTable并很差用，在实际项目中应用很少，通常每每采用外部文件（文本、csv/excel格式、数据库、XML）作配置，扩展性比 DataTable好多了。

并且坑爹的是，我还要爆料一下，QTP从诞生到如今，DataTable对象的SetNextRow 一直都有指针重置的Bug，我通常都推荐用SetCurrentRow。

而SilkTest呢，有本身的Data Driven向导，直接操做、快速完成，还支持直接从数据库里面查询测试数据。是否是很霸气侧漏呢？！

（九）平台支持

QTP只能运行在 Windows上，并且对于不一样Windows的兼容也有问题，好比我几年前说起的OCR识别验证码技术，如今已经没落了。

而SilkTest呢，经过SilkBean支持 Java的应用，能够在Linux平台上回放哦！

（十）分布式、云计算

QTP自己带有Remote Agent，能够远程调度，可是它的商业意图过分明显，由于这个远程调用是经过Quality Center/ALM来完成的，哥们你知道意味着什么吗？意味着你要去迪拜旅游得本身买个直升机，我擦。。。

Selenium 有 Grid，而SilkTest原生支持，它经过Runtime&Agent技术实现。都明显强过QTP！

（十一）对象库、对象存储

QTP 能够说是成也对象库，败也对象库。QTP用单独的文件存储 对象库，本地对象库放在ObjectRepository.bdb文件里，共享对象库放在 XXXX.tsr 文件里。管理起来很复杂，有些人看我介绍太高阶的对象库管理，一致都表示很晕。由于对象库的比较、合并、参数化所有都得额外的对象库管理器里去实现，并且 实现参数化还要作映射，弄完以后满身的汗。。。

而SilkTest呢，能够直接经过编辑器编辑，是否是灰常的爽？！

（十二）采购成本、ROI

得说“ROI（投资回报率）”的问题了。

QTP之前根据插件收费，后来整合起来销售，美其名曰打包赠送。等于你就是先买个铁钉，人家卖你一套家具让你本身拔出来。

SilkTest不同，提供了 RunTime的 License模式，下降了采购成本，什么意思呢，就是你买的时候能够分的，看你是编写脚本，仍是只是运行脚本，等于说你买个套餐，竟然还能够单点套餐里的东西——靠，这还叫套餐吗？没见过这么好的销售啊，哈哈。

（十三）自动化框架

QTP的天生劣势使得它的自动化框架部署很是困难和麻烦，这也是几年前不少人在网上争论不休的缘由，你们都说不出一个真正被承认的很实用能够大面积推广的成熟框架。

这点上，跟 Selenium、SilkTest 这种工具自己的设计理念就有很大差别。

试想，你把本身的工具捆绑在QC上、本身的工具上，你怎么拥抱开源？没有开源，你本身的东西怎么集成别人的东西？没有集成，你的自动化能叫框架吗？这不搞笑吗？撑死了就是个半自动化框架。

（十四）成功案例

QTP名气至关大，国内外都是！可是真正成功实施的用户不多，给客户带来的收益很低。

为何？由于它虽然上手很是快，可是管理维护很是麻烦，没有成熟的 framework 。好比建设银行2007年就开始使用QTP作自动化，迄今没有造成成熟成型的自动化测试体系，一直在经过外部程序控制QTP执行仍是QC控制QTP之间徘徊。

而 SilkTest呢，它的不足在于不支持 VBScript，哈哈，不够简单，这直接形成了门槛偏高，等于作测试的人必定、必须精通编程，而不能只是能改改脚本那么初级。可是，只要你迈过了前期这 个槛，就会发现它的精妙和强大之处。它内置的设计框架，管理比QTP简单很是多，后期收益大，试想，连 Adobe/SAP/Oracle这样的大公司都在拥抱 SilkTest，你以为它们都是傻瓜吗？而 国际上有几个巨头在使用QTP呢？呵呵，Google用吗？微软用吗？Facebook用吗？呵呵呵……

所 以啊，玩QTP其实就是一场空，你玩QTP顶多只是QTP（因 为你会VBScript仍是作不了JUnit/TestNG/HTMLUnit/Selenium/JMeter等测试，而你会Java之后就能作全部的 测试包括SilkTest和Selenium了），用它抢抢票、灌灌水仍是能够的，但是，你既然都要花那么多时间学一个工具，为何不顺便在学自动化工具 的同时把编程学会了，一箭双雕，顺便还拿到了高薪，对不？

好了，说了这么多，你们以为要不要让QTP走下神坛呢？

固然，我并非让你们停下本身手中的QTP项目，特别是大家团队若是已经作的比较成熟，这时候就暂时没有必要更换其余工具。可是，要作到心中有数，你不可能靠QTP吃一生饭的。自动化测试作到后面已经不只仅只是工具了，还有流程、模式、管理等等一系列的配合。