The test program will execute the same mini-scripts for each row.
测试程序将为每一行执行同样的小脚本。
In other words, your structure is:
换句话说，工作的流程如下：
Load the test case matrix
载入测试用例矩阵
For each row I (row = test case)
读每一行I(测试用例)
For each column J (column = parameter)
读每一列J(参数)
Execute the script for this parameter: 为该参数执行脚本：
· Navigate to the appropriate dialog box or menu 导航至合适的对话框或菜单。
· Set the variable to the value specified in test item (I,J) 把变量设置为测试项(I，J)指定的值
Run test I and evaluate the results
运行测试I并评估测试结果
If the program’s design changed, and the Caption Location was moved to a different dialog, you’d only have to change a few lines of code, in the one mini-script that handles the caption location. You would only have to change these lines once: this change will carry over to every test case in the spreadsheet. This separation of code from data is tremendously efficient compared to modifying the script for each test case.
如果改变程序的设计，把标题位置移动到一个不同的对话框，你只需在那个处理标题位置的小脚本中改变几行代码。并且，你只需改变这几行一次。这个改变将对电子表格中的每个测试用例都起作用。与修改每个测试用例的脚本相比，把代码从数据中剥离会非常有效率。
There are several other ways for setting up a data-driven approach. For example, Bret Pettichord (one of the LAWST participants) fills his spreadsheet with lists of commands. [7] Each row lists the sequence of commands required to execute a test (one cell per command). If the user interface changes in a way that changes a command sequence, the tester can fix the affected test cases by modifying the spreadsheet rather than by rewriting code. Other testers use sequences of simple test cases or of machine states.
还有其它几种建立数据驱动的方法。例如，Bret Pettichord(LAWST的成员之一)在他的电子表格中添加了命令行。每一行都列出执行一个测试所需的命令序列(一个单元格对应一个命令)。如果用户界面的一个命令序列发生了变化，那么测试人员可以通过修改电子表格，而不是重写代码来更正相关的测试用例。另外，还有其他测试人员使用简单测试用例序列或状态机序列来建立数据驱动。
Another way to drive testing with data uses previously created documents. Imagine testing a word processor by feeding it a thousand documents. For each document, the script makes the word processor load the document and perform a sequence of simple actions (such as printing).
另一种数据驱动的方法是使用预先创建的文档。假设通过输入一千份文档来测试一个文字处理器。对每一份文档，脚本都要使文字处理器载入文档并执行一系列简单动作(例如打印)。
A well-designed data-driven approach can make it easier for non-programming test planners to specify their test cases because they can simply write them into the matrix. Another by-product of this approach, if you do it well, is a set of tables that concisely show what test cases are being run by the automation tool.
一个设计良好的数据驱动方法能够使非编程测试规划人员更容易地说明他们的测试用例。因为，他们能把它们简洁地写到测试矩阵中。如果你做得好的话，这种方法会产生另一个作用，即通过自动化工具用一系列表格简明地显示出正在运行的测试用例。
文章来源于领测软件测试网 https://www.ltesting.net/
