（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作为参照，很容易把它的一些实践也一起融合进来。
一切看起来都很美好，不过问题也还是有。
表格化的test case毕竟不同于编写代码，调试就变成了一个问题，如果写错了关键字的一个字母，要及时发现并定位到问题就不那么容易。当然，可以再开发一个web平台，让编写case的人仅能从一个list中选择已经定义好的keyword，不过这个成本恐怕就不是一般研发团队能承受的了。
作为一个软件，易用性和复杂度总是成反比的，当框架提供了方便的表格化编写case功能时，也相对的增加了底层的复杂度（虽然没看过robot framework的代码，但是相信底层代码的分层也应该比较复杂），对于想要真的掌握框架的团队来说，无形中增加了一道门槛。另外，复杂度与可扩展性也是成反比的，就像我可以用木头做一辆车，也可以把木头车拆了做些别的东西，但是我没法把一辆汽车拆了弄成别的东西——前两年广东美院那位把解放卡车拆了做成关公像的牛人除外。当然，最终实施自动化时到底如何进行框架选型，就要团队自己在易用性/复杂度/可扩展性上进行评估了。
把excel里面的manual test case通过新的关键字驱动直接变成可执行的脚本是最好的方法吗？这似乎只是一个传统system test 的惯性思维在作怪，为什么没看过开发人员把unit test 也写到一个个表格里面？为什么manual test case 就一定要先写在excel里面，而不是一开始就是代码？
如果仅仅是考虑把 step组装起来，再把case组织成suite执行，其实代码实现上可以说毫无技术含量，但是对于一个没有开发经验的tester来说，这毕竟是一个跟coding简单亲密接触的机会，可以让tester从低难度的代码开始培养兴趣和信息。而keyword，无论新的还是旧的，却剥夺了这个机会；当tester希望学习框架的时候，会发现表格的层面跟下层框架之间的不是楼梯，而是一道沟。
3. “关键字驱动”的未来
我们如今所处的环境总是在变化着，今天与10年前相比，最大的变化就是测试行业获得了极大的发展，大多数企业都认可了测试工作的重要性，并且开始思考如何提升测试工作自身的质量和效率，而且不同规模的企业都在探索着合适自己的研发流程和技术；而tester们的技术能力也在不断增强，至少能写代码的人比5年前多了很多。当然，还要感谢开源世界带来的众多框架、组件，让自动化的门槛不断降低。
就像传统的关键字驱动已经远去一样，新的关键字驱动未来会如何，大家讨论吧。:-)
