QTP将死——开源测试登上舞台

　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。当冬眠的熊遇上春天……

　　让广大自动化人员在开源世界中热起来吧！

====================================分割线================================

最新内容请见作者的GitHub页：http://qaseven.github.io/