关键字驱动的过去和未来

　　鉴于这个系列写的内容是希望帮助“大多数2-3年工作经验、急切盼望提升自身能力的 tester找到捅破‘测试自动化’窗户纸的办法”，所以木有高深内容，高手们请直接飘过，呵呵。

　　1.“关键字驱动”的由来

　　说到“关键字驱动”和“测试自动化”，就不能不提到 Mosley Daniel 的《软件测试自动化》一书，这本书03年引入国内，04年市面上开始有卖，书中有两个相信能吸引到很多 tester 的话题：

　　(1)脚本应该录制还是编写?——想知道答案的自己下载电子书看吧：)

　　(2)“数据驱动”和“关键字驱动”。

　　彼时的我，刚刚经历了一次不成功的自动化实践，虽然 Rational Robot 提供了类似UI库管理，数据池管理之类的强大功能，但是痛苦依然。对测试自动化理解的不够深入，不知道该如何应对RAD模式下UI和业务快速调整，以及对 C/S下非标准控件的识别等问题，导致了无法快速维护脚本、replay 次数不够，回放通过率不够，最后的结果是ROI无法满足要求，自动化项目宣告结束。

　　带着很多疑问的我原本想从那本书中找到些答案，遗憾的是那时功力实在太差，居然没有看懂，唯一留下印象的就是作者在80年代就开始探索自动化回归的技术，并且在90年代已经尝试了“数据驱动”和“关键字驱动”的技术，想来当时 Robot framework 之类的都还没有出现，所以我相信“关键字驱动”的技术源自这书的作者和他的朋友们。

　　2. 从“数据驱动”到“关键字驱动”

　　所谓的数据驱动，原本没有什么特别的，无非就是把hard code 在脚本中的数据参数化出来，之所以算是Robot、WinRunner甚至QTP时代测试工具的卖点，其实主要是因为那个年代大多数system tester 不懂开发，总需要有个功能来帮助自己完成参数抽取、数据维护、自动替换之类的功能。

　　而关键字驱动，则进一步在技术上把 tester 分成了完全不懂技术的和懂点技术的，前者只能根据格式填写一下 excel 表格，后者对工具/框架内置的所谓关键字库进行增补或二次开发。

　　找些例子来看看吧。

　　(1)简单的数据驱动。

　　如下面代码，定义了一个class并实例化了几个对象，用来存放不同的用户登录信息;而在负责完成登录操作的 do_login_as() 方法中，把 send_keys 原来向表单中填充的数据参数化，根据每次调用 do_login_as() 方法时传入的不同对象来实现用不同帐号登录的效果——虽然我对以“登录”为样例介绍自动化测试脚本深恶痛绝，不过这里为了表述简单，还是用了。(下面的代码只是一个示例，不是直接用来运行的。)

　　其实数据驱动本来也没有什么技术含量，写过代码的谁还不知道什么是变量啊?不过在早期的商业工具中，的确把这个作为了一个卖点，毕竟10年前的测试工具设计思路也与现在不同。早期的工具始终都假设”系统测试工程师不懂开发“，所以他们在开发测试脚本时需要借助类似录制回放+编辑调试的模式;另外，对于数据驱动所需要的测试数据，最好也是通过工具内置的data pool 管理，通过表格编辑，甚至读取 csv、excel 文件之类的。如果我们依照这个思路去实现自己的测试框架，那肯定是商业工具很有价值，毕竟自己实现data pool管理、外部数据文件读取之类的功能，代码量也不小，要处理好那些数据格式和内容校验之类的，貌似跟我们所需要完成的自动化也没啥太大关系。

　　可问题在于，为什么一定要有data pool+外部数据文件来实现”数据驱动“呢?

　　(2)传统的“关键字驱动”

　　还是先用个例子来看看传统的“关键字驱动”长什么样子。

　　上面是一个 Selenium 0.x 时代Core模式下(什么是selenium的core模式和RC模式请自行google，不过话说现在已经全民webdriver时代了，不知道也就不知道吧)的例子(QTP的实现效果也类似)，简单说就是第一行是 test case name，下面3列开始进入正题，第一列表示你想干啥，第二列是被操作对象是谁，第三列是你对它干了啥。06年刚刚开始尝试web测试自动化的时候，我们一度认为这是一个比之前的测试工具要智能的多的东东，不过在尝试了很长一段时间之后，还是发现了这种模式下的问题，又逐渐转回了编写脚本的方式。

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