Danny R.Faught

摘要：一种在测试人员之间发生的有趣现象开始引起丹尼·法特先生的注意：世界各地的测试人员在完全按照自己的理解书写着关键字驱动测试脚本。但是，什么是关键字驱动测试？它是不是就比数据驱动测试要好呢？在本中周刊中，丹尼揭示出正是这种测试方法的简单的设计，使它在很多测试人员甚至是非测试人员中都很流行。

我已经注意到一种奇怪的现象在到处发生：测试人员总是在不停的按照自己的理解在发明着关键字驱动测试。如果有这么多测试人员觉得这样做是个好主意，那么也许这种现象值得认真研究。现在已经有了很多名词被用来指代一个相同的普遍概念，包括”action word“、”test frameworks“、和”third-generation test automation“。

这里有一个关键字驱动测试的测试用例的示范：

+—————————————————-+

Action Fixture                                    

+———————————————–+—-+

start Fitness.fixtures.CountFixture                

+——-+—————————————+—-+

check counter                               0

+——-+—————————————+—-+

press count                                    

+——-+—————————————+—-+

check counter                               1

+——-+—————————————+—-+

press count                                    

+——-+—————————————+—-+

check counter                               2

+——-+—————————————+—-+

enter counter                               5

+——-+—————————————+—-+

press count                                    

+——-+—————————————+—-+

check counter                               6

+——-+—————————————+—-+

from URL http://fitness.org/FitNesse.ActionFixture

+—————————————————-+

这个例子如果是自动测试脚本就太简略了，如果是手动测试脚本又太繁杂了。到底是什么？（到底怎么翻！

This looks too simple to be an automated test script, but too terse to be a manual test script. What’s up? ）

×　关键字驱动测试是怎么工作的？

你当然可以把一个基于关键字的测试用手工完成，但你也应该知道这项技术只有在自动化中才可以闪耀出它应有的光芒。流程是从一个测试设计师写一份测试用例开始的————就像上面一样。测试设计是完全没必要知道怎么编程，他也可以是一个业务分析员。而一个编程角度的刀具工会生成一个框架提供关键字，比如“开始”、“检查＂、”按键“和”回车“。在这个框架里有可能用一个完全不同的界面引擎，比如一个图形界面的测试工具来实现这些关键字（但是这些关键字都实现了）。

在这个层面进行的抽象最值得称道的是，这样就可以做到把界面和应用完全分开。虽然上面的示例脚本看起来要用一个图形界面，但是也可以是一个应用程序接口（API )，网页脚本，或者其他什么东西。在关键字脚本里，最好不要对用户界面做任何假设。因为框架可能在早期的时候用一个API接口，然后再晚一点又换成图形界面，却不修改测试脚本。测试人员也可以任意更换界面引擎而不用更换测试脚本，只要框架的关键字没有和任何界面引擎绑定在一起。

×　怎样改进？

你可能已经听说过了”数据驱动测试“：每一个脚本都基本上对应于一个关键字的实现。测试人员在完成脚本的同时也完成测试数据，然后用不同的测试数据反复运行脚本。关键字驱动测试和数据驱动测试的区别是，在关键字驱动测试里，脚本中的每一行数据都有一个关键字告诉框架怎么处理这一行的数据。

有些关键字框架的设计者喜欢写有多个关键字的测试用例，正如上例所示。结果脚本看起来像一种简单的编程语言。而另外一种相反的倾向使用一个关键字来完成整个测试用例，这样就模糊了数据驱动测试和关键字驱动测试之间的界限。

在阅读了关于这两种方法（KDT和DDT）的资料以后，我认为关键字驱动测试是一种大幅度改进了的数据驱动测试。但是我也注意到在FitNesse的用户中经常选择”列标志”的数据驱动测试，而不是“行动标志”的关键字驱动测试。所以可能很难说这两种测试方法哪种更好。虽然很少有人两种混用，但是你也可以选择多次运行多个关键字脚本，每次都输入不同的数据来实现两者的混用。

×　正确的原因

如果你不是一个程序员，你仍然可以写自动测试脚本————只要你的公司支持关键字驱动测试的自动化要求。我和一些用关键字驱动测试但是觉得指望非技术人员来写关键字脚本不现实的人有过交流，不过也有很多人说这样是没问题的。非技术人员是否适合写脚本，仍然有待时间的考量。经理们也应该知道团队是需要程序员投入到创建和维护框架的工作中去的。

真正的好处是提高了测试脚本的可维护性。关键字方法只不过遵从了一个久已有之的模块化自动测试的传统而已，这样它就可以在用户界面修改中更快的适应过来。仅仅这一点，就足以证明关键字驱动测试的地位了，即使所有的测试人员都是专家级别的程序员。

原文链接：Keyword-Driven Testing

[原文在百度空间已经关闭]