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取代。
這一大段話，頭都要暈掉了吧。OK，我們來看一個典型的BDD用例（用戶故事）：
你可以認為，這就是兩個測試用例！那他與普通的測試用例有什么不同呢？
用戶故事關聯了需求，是包含了需求的用例故事貫穿整個軟件生命周期，直到驗收故事是軟件的商業價值，是最“有效文檔”OK了！那如何把故事跟自動化關聯起來呢？ＢＤＤ框架提供了最簡單最直接的方式：正則關聯。
BDD就是如此神奇！他提供了最簡單的方式，就向膠水融合一樣可以把任意代碼與用戶故事關聯起來且不限于：單元測試，集成測試，UI自動化，接口驗證，安全等。
BDD框架，普遍自帶數據驅動，關鍵字驅動，參數化。
一個典型的ui automation例子(點擊圖片查看大圖）：
運行結果：
說幾點：
● BDD，只是一種思想，一種輕量級測試實踐；BDD注重有效文檔，注重用戶故事的拆分細化 。
● story可以使得黑盒與自動化人員分離；只要story控制的好，可以招廉價開發來實現自動化
● 就跟你可以用google guice， picocontainer替換spring一樣，BDD框架可以自由選擇，因為都是提供相同風格的功能
● 比如py里可以用lettuce，.net上有cuke4nuke，groovy有easyb， spock，sikuli也支持BDD等
● VBS受限于語言表達力，就別想BDD了。
● 如果你的企業愿意花幾十萬（不是為了只賣最貴），還不如只花幾萬來投在人力建設上，通過開源測試來提升團隊， 企業里沒有什么比人才更可貴的了。
● BDD對粘合自動化或者框架的唯一要求，支持代碼編寫并啟動，比如selenium watir等，而依賴特定GUI的不見得適合。
● 你不見得需要想開發QTP框架樣重復造輪子，合理的使用開源社區現有輪子即可。
● BDD可以與bromine/robotium一起，測試iphone/android。
● BDD工具完全可以與CI整合，方式多種多樣。
目前情況下，BDD缺少一個GUI界面的故事管理工具，你可以自己開發一個，或者買商業的，不過更多的人選擇把story帖在墻上。
隨著cucumber-jvm的火熱，到了該是BDD成為測試主流的時候了，畢竟BDD只是一種思想，一種表現形式，不是一種具體的思路，也不強制你購買某個廠商的工具（當然thoughtworks也有BDD工具twist）；現在企業都講究整合，作為廣大發展中測試人員，特別是在成長中公司的測試人員，拿起你的斧頭，把該砍的都砍掉，做輕量級測試吧！你會找到自己的樂趣的。
常用BDD框架：JBehave rspec cucumber cuke4nuke spock等等常見支持與BDD粘合的工具：watir selenium celerity white UIA3.0 robotium bromine(iphone) webaii soapui(core)等
常見與BDD一起使用的編程語言：ruby python groovy node.js java c# erlang lua，就是沒有VBSwebdriver，自動化（特指測試自動化）領域的hibernate；cucumber，自動化領域的spring。當冬眠的熊遇上春天……
讓廣大自動化人員在開源世界中熱起來吧！
