转自: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吃一辈子饭的。自动化测试做到后面已经不仅仅只是工具了，还有流程、模式、管理等等一系列的配合。