假设编写100段脚本来测试仅仅100种这样的组合方式。如果某界面的一个元素改变，例如，标题字体从一个对话框转移到另外一个，那么你就可能不得不重新编写每一个脚本。
图2 某表格格式的测试矩阵的前几行
现在，假设根据一个测试矩阵来工作。我们用很多参数值的一种组合来确定一个测试用例。在矩阵中，每一行确定了一个测试用例，而每一列则代表一个参数。例如，第1列可以是标题位置，第2列可以是标题字体 ，而第3列则是标题风格。这样就会得到若干列。
接着，用一个电子表格制作软件来创建你的矩阵，比如Excel.
为了执行这些测试用例，我们编写一个读这个电子表格的脚本，一次读一行（测试用例），并执行这些小脚本来设置每个电子表格中指定的参数。假设我们正在处理图2矩阵中的第2行。第一段小脚本会读取第一列（标题位置）的值，并导航到合适的对话框和入口域，然后根据矩阵中的值把标题位置设置为右。一旦设置好所有的参数，你就能进行剩下的测试。这时，你可以打印出表格并对输出做出评估。
测试程序将为每一行执行同样的小脚本。
换句话说，工作的流程如下：
* 载入测试用例矩阵
*读每一行I（测试用例）
*读每一列J（参数）
*为该参数执行脚本：
· 导航至合适的对话框或菜单。
· 把变量设置为测试项(I,J)指定的值
*运行测试I并评估测试结果
如果改变程序的设计，把标题位置移动到一个不同的对话框，你只需在那个处理标题位置的小脚本中改变几行代码。并且，你只需改变这几行一次。这个改变将对电子表格中的每个测试用例都起作用。与修改每个测试用例的脚本相比，把代码从数据中剥离会非常有效率。
还有其它几种建立数据驱动的方法。例如，Bret Pettichord（LAWST的成员之一）在他的电子表格中添加了命令行。每一行都列出执行一个测试所需的命令序列（一个单元格对应一个命令）。如果用户界面的一个命令序列发生了变化，那么测试人员可以通过修改电子表格，而不是重写代码来更正相关的测试用例。另外，还有其他测试人员使用简单测试用例序列或状态机序列来建立数据驱动。
另一种数据驱动的方法是使用预先创建的文档。假设通过输入一千份文档来测试一个文字处理器。对每一份文档，脚本都要使文字处理器载入文档并执行一系列简单动作（例如打印）。
一个设计良好的数据驱动方法能够使非编程测试规划人员更容易地说明他们的测试用例。因为，他们能把它们简洁地写到测试矩阵中。如果你做得好的话，这种方法会产生另一个作用，即通过自动化工具用一系列表格简明地显示出正在运行的测试用例。
推荐阅读：
