（五）异常捕获、场景恢复
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呢，可以直接通过编辑器编辑，是不是灰常的爽？！
