关于数据驱动和关键字驱动的理解整理
关于数据驱动，以下这篇帖子还是给了很大的启发：http://bbs.51testing.com/viewthread.php?tid=113729&extra=&highlight=%CA%FD%BE%DD%C7%FD%B6%AF&page=1
摘录一些精妙的论点：
51testing论坛的phililschen：
“什么是数据驱动呢？很大一部分人肯定认为数据驱动就是把需要参数化的东西写在EXCEL里，然后在跑脚本时调用。如果我告诉你，这其实不是数据驱动，而只是较高级的参数化，你肯定会很惊讶！现在我来解释一下：首先为什么叫数据驱动呢，那么它肯定有驱动的含义，比如你用EXCEL可以控制测试的业务流吗？回答是不能的。那又如何作到驱动呢？所以说我们将测试数据放在独立的文件里只是高级的参数话。而数据驱动，你必须有数据来控制测试的业务流。比如你测一个WEB程序，有很多页面，你可以通过一个数据来控制每次是再哪个页面下工作的（即通过数据来导航到相应的页面）。它是关键字驱动的低级版本，他控制的是函数级的，而关键字是控制动作级的。所以数据驱动应该是可以控制整个测试的”
51testing论坛的dreamever：
“数据驱动本身不是一个工业级标准的概念，因此在不同的公司，都会有好几个解释版本。首先我同意楼主的关于数据驱动的观点，也就是说如果我们仅仅是把测试数据放在数据文件里，这只是一种比较高级的参数化而已。其实我更倾向于把数据驱动理解为一种模式或者一种思想
对于数据驱动的讨论，我们不妨先抛开QTP来进行。无论是进行自动化测试还是手工测试时，我们都需要设计测试用例，准备测试数据，并且把测试用例与数据分开，在一套测试用例上运行多套测试数据是比较有效率的。我相信这一点大家应该都认同吧。
那么我们不妨再看一下手工测试的场景：当一个手工测试人员A发现在测试数据存储目录下多了一套测试数据时，他就会意识到应该马上执行测试用例，并输入这套新的测试数据。其实是测试数据的变化触发了A的测试行为。（有人可能说了我们公司不是这么做的，注意，我们不是在讨论实际的测试管理，我们在对测试模型进行抽象）。如果我们更抽象一下，可以这样来看：当测试数据变化时，测试用例就会被执行（无论是A主动还是leader打电话通知），并且按照预先定义的规则去读取测试数据并执行测试用例。那么这种情况我们是不是可以理解为一种数据驱动呢？也就是说只要有了新的测试数据或者测试数据发生了变化，那么A就会去执行测试用例。这一过程的目的就是为了让所有的测试数据都得到输入并返回相应的输出结果。
如果大家同意上面的情景是一种数据驱动测试的例子，那么我们可以对自动化测试中的数据驱动进行同样的解释：由机器自动读取测试数据，然后测试用具运行测试脚本执行测试用例，并按照预先设置好的参数化字段读取测试数据，返回测试结果。目的就是使所有的测试数据都得到输入，并返回输出，验证数据的输入和输出是否符合预期值。这里的测试数据不仅包括业务数据，还包括一些动作关键字或决策关键字，以提供足够的信息，让测试工具知道该调用什么样的脚本，应该如何处理各种情况。相对于不同的测试工具，其表现形式有可能不同，QTP提供了关键字视图和数据表，robot提出了决策表的概念，Watir的话本身没有什么特殊的模式，完全看测试人员把框架设计成什么样了。其实本质上都是消息驱动的不同表现而已，例如刚才的手工测试的例子，测试数据发生变化我们可以把它看成一种消息，接收到这个消息A就开始执行测试。”
51testing论坛的jackmail：
“数据驱动中的 driven 一词，你可以简单的理解成导向，导向什么？结果。就是测试数据决定了测试结果，这就是所谓数据驱动，QTP实现了数据驱动的功能，模型，feature，特征，无非是个词汇而已，怎么说都没问题，用QTP你可以简单的完成你想实现的数据驱动方法的测试，他就是实现了xx功能。
还有关键字驱动，就是 关键字决定了结果。 在QTP里关键字就是step中的测试对象名称（对象方法属性，或者值（测试数据））。测试对象名称的改变，就决定了结果的变更。以前有些人写的所谓框架是把对象从Excel表格中导入导出的，他们实现的就是关键字驱动。
什么驱动，就是什么决定结果。本来结果是固定的，由于驱动数据的变更，导致了结果的不同，没那么复杂。其实概念都是人定的，少去钻牛角尖，理解个大概意思就行了。”
最后引用一下一篇关键字驱动的理解的文章，毕竟这是QTP主推的东西
最初用QTP就是简单的录制，然后修改脚本，缺点如下：
1. 应用软件必须具备一定的稳定性，并且在整个业务流程上都必须完整的实现了，否则顺序录制整能实现？
2. 自动化脚本的维护性成本非常的高
3. 自动化脚本的可重用性比较差
随之出现了关键字驱动的概念，一切都以对象为出发点，这有点像编程语言中从过程化向面向对象转化，在QTP中的具体实现方法是：
1. 在单个程序界面上将测试所涉及到的对象手工添加到对象库中
2. 在专家视图中基于对象库中的对象编写自动化测试脚本
以上这样做的明显的优点在于：
1. 脚本的可控性非常的强，模块化组织也比较好
2. 可以在开发完全实现所有的业务流程功能前就建立测试脚本，占据了比较大的主动性，为时间上的安排提供了更大的空间，一个词概括：“测试先行”
