关键字驱动的过去和未来(3)

　　下面是一个在 keyword 表格里面实现的 FOR 循环：

　　这是获取时间，当然也是写在表格里面的：

　　import 外部的库:

　　读取外部文件:

　　正则表达式:

　　重复执行5次 goto pre page 操作:

　　执行一个 keyword 然后期待能捕获一个异常:

　　有人可能会说“你看，关键字驱动框架也可以扩展的很强大啊!”。是，在programming 的世界中，没有什么不能做的，不过都弄到这个份儿上了，学习这一套东西跟学习一个标准的编程语言还有什么差别吗?先不说这样的框架越扩展越难维护，可靠性也就越差，单单这些关键字的用途被局限在自己的框架中，你所积累的知识和经验无法重用到其他测试代码的编写中这一个理由，就应该彻底放弃这种方式了。

　　如果要说的直白一些，传统的关键字驱动框架的时代在前几年就已经开始远去(是had been，不是have been)，我们感谢上一代tester的努力探索和实践，但最终历史证明这是一个不算成功的尝试，一个框架如果不具备开放性，一切都自给自足，那么有一天这也会成为限制自己发展的最大原因。

　　(3)穿马甲的“关键字驱动”

　　时代在进步，关键字驱动也在进步，这个领域中的代表 robot framework(此robot非rational robot) 也在进步，于是，test case 变成了下面这个样子。

　　依旧不变的是“表格”，改变的是填写方式——其实这背后的，是关键字定义终于被开放出来，tester可以自己定义keyword然后“注册”到框架中，而那些依然没有学会基本编程技能的tester，继续用这些keyword重复上个时代的事情——填写表格。

　　其实相对于最初对关键字驱动的定义，这个真的已经不是关键字驱动了，如果非说它是，那么只能说上个时代的关键字驱动中，test case 表格的每行都是一个页面操作，而“新的”关键字驱动中，test case 的每行都已经是一个完整的业务操作，以上面的“Create Valid User” step 为例，robot framework希望的实现方式是tester通过python等4GL实现一个同名的function，这个function接受两个参数，分别是 “fred”和“P4ssw0rd”，再把这个function注册到robot framework中。而“Create Valid User”内部的实现，可以类似于一开始“数据驱动”中的那个例子，充分利用4GL的特性和已有的其他第三方组件(例如webdriver)，来实现各种复杂的基于UI的操作，这样也就解决了刚刚“传统的关键字驱动”所遇到的问题。

　　最后，当完成了这个function的开发并在robot framework中注册后，做手工测试的system tester就可以很容易的把原本excel中的一个个case转变为自动化脚本了。

　　其实这个思路有它的优点，例如：通过分工协作降低实施门槛，可以一开始就编写符合robot所需格式的manual test case，等到keyword开完全了以后这些case就可以直接导入执行了;不再自给自足，而是保持一定的开放，并利用其他第三方组件的特性。这样很大程度上解决了自动化项目实施遇到的人员能力问题和可维护性、可扩展性的问题。

　　另外，新的关键字驱动还有一个更加先进的“近亲”BDD作为参照，很容易把它的一些实践也一起融合进来。

　　一切看起来都很美好，不过问题也还是有。

　　1.表格化的test case毕竟不同于编写代码，调试就变成了一个问题，如果写错了关键字的一个字母，要及时发现并定位到问题就不那么容易。当然，可以再开发一个web平台，让编写case的人仅能从一个list中选择已经定义好的keyword，不过这个成本恐怕就不是一般研发团队能承受的了。

原文转自：http://www.uml.org.cn/Test/201501065.asp