QTP作为测试自动化的主流，已经很长时间了：以前的主流测试是window GUI应用，和普通WEB应用；没有那些复杂的其他环境，如flex silverlight wpf 手机等。

　　以前良好协作的自动化用例管理平台，是TD（qc），能够实现用例与自动化关联。

　　以至于：QC/QTP甚至成了自动化测试招聘的标准……现在呢？

　　随着WEB2.0+，移动互联网的兴起，QTP/QC还能胜任吗？

　　数年之前，EJB也是标准，但是EJB造成了一些招致IT人员反感的问题：开发调试维护困难，方案太重与应用服务器紧密绑定（昂贵）性能低下……

　　我们回过头来看看，QTP/QC也不是与这个很类似吗？

　　QTP成也对象仓库败也对象仓库，录制的东西不比手写，手写的是自己的孩子自己认识，可维护性强；

　　QTP如果你不与QC关联，很难关联用例与需求QTP实际运行性能低下，特别是插件（先不考虑插件的价格）QTP做测试，必须有框架……这里不想讨论LR。

　　如果我们不用QTP/QC，开源世界里能否有东西胜任呢？

　　答案是肯定的。回头看看EJB：Hibernate取代了EntityBeanSpring成了粘合剂这二者联手将java世界的标准，送进了博物馆。

　　那么QTP/QC中，开源世界的对位应该是哪些呢？

　　我认为：QTP的取代者，会是webdriver，webdriver就像hibernate的地位；当然，你也可以不用webdriver，就你可以不用hibernate而用myBatis/dbutil等取代一样，你也可以用watir/htmlunit/seleniumRC/webaii/white/sikuli/bromine等任何来代替webdriver的地位；就跟你想在写原生sql一样，你也可以写（win32ole）win32api， linux xdotool来完成自动化。

　　Hibernate这头熊是如何被唤醒的？我们来回忆一下，当时hibernate的问题是sessionfactory获取datasource，依赖jndi查找，而Spring用了依赖注入解决了这个问题；Sring成了真正意义上的企业级粘合剂，更关键的是spring所带来的一种务实的思想。

　　那谁来把QTP从QC上解耦，并能提供良好的用例组织和管理呢？

　　答案就是BDD目前的事实标准：Cucumber！！

　　引用维基百科：行为驱动开发（缩写BDD）是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。BDD最初是由Dan North在2003年命名[1]，它包括验收测试和客户测试驱动等的极限编程的实践，作为对测试驱动开发的回应。在过去数年里，它得到了很大的发展[2]。

　　2009年，在伦敦发表的“敏捷规格，BDD和极限测试交流”[3]中，Dan North对BDD给出了如下定义：BDD是第二代的、由外及内的、基于拉（pull）的、多方利益相关者的（stakeholder）、多种可扩展的、高自动化的敏捷方法。它描述了一个交互循环，可以具有带有良好定义的输出（即工作中交付的结果）：已测试过的软件。

　　BDD的重点是通过与利益相关者的讨论取得对预期的软件行为的清醒认识。它通过用自然语言书写非程序员可读的测试用例扩展了测试驱动开发方法。行为驱动开发人员使用混合了领域中统一的语言的母语语言来描述他们的代码的目的。这让开发着得以把精力集中在代码应该怎么写，而不是技术细节上，而且也最大程度的减少了将代码编写者的技术语言与商业客户、用户、利益相关者、项目管理者等的领域语言之间来回翻译的代价。

　　Dan North创造了首个BDD框架：JBehave[1]；之后是Ruby语言的基于故事的RBehave[4]，后来被纳入了RSpec项目[5]。他还与大卫赫利姆斯基、Aslak Helles？y及其他人开发了RSpec，并一起编写了《The RSpec Book： Behaviour Driven Development with RSpec， Cucumber， and Friends》。RSpec中第一个基于故事的框架，后来被主要由Aslak Helles？y开发的Cucumber取代。