何谓 Keyword-Driven Testing？
Mercury 的 QuickTest Professional 8.0 中，又出现了一个新的名词 (对我来说是新的名辞啦) - Keyword-Driven Testing。到底什么是 Keyword-Driven Testing 呢？
以录制方式建立测试的问题
一般来说，自动化测试通常是透过录制的方式建立测试脚本的，这样的方式看似容易，但是实际上会遇到下列的问题：
1. 测试人员大多不具技术背景，难以完全掌握测试工具
2. 应用软件必须达到一定的稳定性，才能开始录制测试脚本
3. 自动化测试脚本与文件是分开的
4. 维护自动化测试脚本的成本非常高
关键词驱动 (Keyword-driven )
在 QuickTest 8 的「关键词驱动 (Keyword-driven )」测试架构，主要是为了解决上述「透过录制产生测试脚本」的问题的。
透过「关键词驱动 (Keyword-driven )」测试架构，测试人员不需要「录制测试脚本」，进而改成「设计测试脚本」。
建立 Object Repository
在之前的文章有提到，通常测试工具都是「Object Base」的。在 QuickTest 储存 Object 的地方称为「Object Repository」。
所以一开始，要先将应用软件的 GUI Object，先记录在「Object Repository」中。所以会先开启「Object Repository」，按下「Add Objects」按钮，将应用软件的 GUI Object 加入「Object Repository」中。
接下来点选应用软件窗口的标题列，会出现对话窗口问您是不是要把您刚刚点选的窗口加入「Object Repository」，点选「OK」。
由于您选择的 Object 是一个窗口，所以 QuickTest 还会进一步问您，是不是连窗口内的所有 Object 都要加入「Object Repository」，选取「Selected object and all its descendants」后点选「OK」。
之后，您就会看到 「Object Repository」中会出现这个窗口内的所有 GUI Object。
接下来，建议您将那些 Object 名称很奇怪，或是看不出代表哪一个 Object 的 Object 名称作个修改。例如我将原本名为「Button_5」的 object，改名成为「NewOrder」。
在使用测试工具时，这是非常重要的一个动作，为您测试脚本中的 object 名称，订定一个统一的规范，可以替日后的维护，减少非常多的成本喔！
可以开始设计测试脚本了
接下来，您可以开始设计测试脚本的工作了！注意我使用的是「设计」而不是「录制」，因为建立测试脚本的过程，就像是您在一个 Excel 文件上设计测试个案一样。
您将会设计每个测试步骤，每个测试步骤主要有三个元素：
· Item：这个测试步骤是作用在哪个 object 上，可能是个窗口、按钮、或是输入字段。
· Operation：在这个 object 上，您要执行什么动作，如Click、Type、Select。
· Value：有些动作，会需要输入数据，如从一个清单 (list) 上选择某个选项，或是在输入字段 (edit box) 中输入某些值，您必须告诉 QuickTest 要用什么数据。
而且当您设计好一个测试步骤后，在 Documentation 字段，会自动以英文句子显示这个步骤的说明，这也是 QuickTest 的另一个新功能「Auto-documentation」，您在设计测试步骤的同时，文件也自动产生了。
接下来，我将以在 Flight ( QuickTest 内建的范例程序 )，建立一个「新增订单」的测试个案。
这个测试个案的第一个步骤就是先 Active Flight Reservation 的主窗口。要建立这一个测试步骤，以要在 Keyword View 上的 Action1 下方点一下，就会出现 Object 的清单，供我选择要作用的 object。我只要选择「Flight Reservation」这个窗口 object 就行啦。
接下来，因为我要让这个 Flight Reservation 窗口 Active，所以我只要在 「Operation」字段选取 Active 。因为这个 Active 不需要任何的数据，所以我不用在 「Value」字段中输入任何数据。
所以我的第一个测试步骤就完成了。同时也可以看到在 「Documentation」字段中自动出现「Make the "Flight Reservation" window active.」的说明。
第二个测试步骤，我需要在主窗口上的「Data of Flight:」中输入出发日期，我同样也按照上面的方式，在「Item」字段选择「Data of Flight:」，在「Operation」字段选择「Type」，然后在「Value」字段输入我要出发的日期「12/12/04」，到这里我已经完成我的第二个测试步骤。
至于其余的步骤，我也是以同样的方式去完成，你可以看到整个测试脚本其实和你透过录制的方式所建立的测试脚本一样，这个测试脚本已经是一个可以执行的测试脚本。
结论
所以，您可以看到整个测试脚本建立的过程，完全不需要去执行整个「新增订单」的操作流程，只要先完成应用软件的使用接口 (UI) ，就可以建立一个已经准备好可以执行的测试脚本。
这也表示您的应用软件只要有使用接口 (UI) 就可以了，并不需要真的可以运作。所以测试人员不需要等到应用软件已经开发得差不多，才开始建立测试脚本。测试人员可以更早就开始建立测试脚本了。
听起来是不是有点像 XP 所说的「测试先行」的概念呀！
同时在建立测试脚本的过程中，测试步骤的文件也同时产生。
至于测试脚本的维护，也与建立的过程一样简单，不管是使用接口 (UI) 还是操作流程的变动，都可以轻松改变测试脚本。
对于技术背景不深的测试人员、系统分析师、使用者，建立测试脚本就像是在一个 Excel 中撰写测试个案一样简单。
以上就是我目前所了解的 Keyword-Driven Testing!