在自动化测试历史中，有很多人讲关键字驱动是由数字驱动发展而来，也许历史看起来如此，就像也可以说数据驱动，由按键录制由来一样。
但数字驱动本质上，和关键字驱动要解决的测试设计问题并不一样，所以特意放在后面，更多应该是并列的关系。
综述：数据驱动是 自动化测试脚本开发最有别于 程序设计的地方。数据驱动更像是源于参数化。但测试数据应该是最优别于开发的思维模式的地方。开发一段代码 考虑的事逻辑与数据对象并参数化。即以参数代表所有的数据可能性
比如：加法程序 a+b=c print（c）。
而测试脚本的目标，就是要以一段自动化的程序，调用 待测程序的所以 典型数据和可能性。即需要列出所有的参数的具体输入。如上面需要：正数+正数、负数+正数、小数等等。也就是说，自动化用例离不开，测试数据。而且是明确的测试数据，不同的数据就是不同的用例和场景。
从“数据驱动”到“关键字驱动”
所谓的数据驱动，原本没有什么特别的，无非就是把hard code 在脚本中的数据参数化出来，之所以算是Robot、WinRunner甚至QTP时代测试工具的卖点，其实主要是因为那个年代大多数system tester 不懂开发，总需要有个功能来帮助自己完成参数抽取、数据维护、自动替换之类的功能。
而关键字驱动，则进一步在技术上把 tester 分成了完全不懂技术的和懂点技术的，前者只能根据格式填写一下 excel 表格，后者对工具/框架内置的所谓关键字库进行增补或二次开发。
找些例子来看看吧。
（****1****）简单的数据驱动。
如下面代码，定义了一个class并实例化了几个对象，用来存放不同的用户登录信息；而在负责完成登录操作的 do_login_as() 方法中，把 send_keys 原来向表单中填充的数据参数化，根据每次调用 do_login_as() 方法时传入的不同对象来实现用不同帐号登录的效果——虽然我对以“登录”为样例介绍自动化测试脚本深恶痛绝，不过这里为了表述简单，还是用了。（下面的代码只是一个示例，不是直接用来运行的。）
其实数据驱动本来也没有什么技术含量，写过代码的谁还不知道什么是变量啊？不过在早期的商业工具中，的确把这个作为了一个卖点，毕竟10年前的测试工具设计思路也与现在不同。早期的工具始终都假设”系统测试工程师不懂开发“，所以他们在开发测试脚本时需要借助类似录制回放+编辑调试的模式；另外，对于数据驱动所需要的测试数据，最好也是通过工具内置的data pool 管理，通过表格编辑，甚至读取 csv、excel 文件之类的。如果我们依照这个思路去实现自己的测试框架，那肯定是商业工具很有价值，毕竟自己实现data pool管理、外部数据文件读取之类的功能，代码量也不小，要处理好那些数据格式和内容校验之类的，貌似跟我们所需要完成的自动化也没啥太大关系。
可问题在于，为什么一定要有****data pool+****外部数据文件来实现”数据驱动“呢？
.数据驱动的自动化测试框架
** “什 么是数据驱动呢？很大一部分人肯定认为数据驱动就是把需要参数化的东西写在EXCEL里，然后在跑脚本时调用。如果我告诉你，这其实不是数据驱动，而只是 较高级的参数化，你肯定会很惊讶！现在我来解释一下：首先为什么叫数据驱动呢，那么它肯定有驱动的含义，比如你用EXCEL可以控制测试的业务流吗？回答 是不能的。那又如何作到驱动呢？所以说我们将测试数据放在独立的文件里只是高级的参数话。而数据驱动，你必须有数据来控制测试的业务流。比如你测一个 WEB程序，有很多页面，你可以通过一个数据来控制每次是在哪个页面下工作的（即通过数据来导航到相应的页面）。它是关键字驱动的低级版本，他控制的是函 数级的，而关键字是控制动作级的。所以数据驱动应该是可以控制整个测试的**”。
在一些复杂的测试用例中，同一个用例包含了很多的测试流程，其中不同的测试流程采用不同的测试输入数据，这个时候测试数据的输入不仅仅是参数的输入，还有业务流程的控制字段的输入(可以理解为逻辑参数)，这种情形会更深入的体现数据驱动的含义。
数据驱动的自动化测试是针对上述开发与测试之间紧密耦合问题提出的测试方法。通过建立测试与开发定义的软件元数据的关联——元数据映射表，在测试与开 发之间建立松耦合关系。不论测试人员修改测试脚本，还是开发人员修改软件，只需要修改元数据映射表，既可以满足测试与开发同步进行。这样，可以减少测试脚 本调试的工作量，更好的实现自动化测试。
●什么是数据驱动的自动化测试框架
数据驱动的自动化测试框架是这样的一个框架，从某个数据文件(例如ODBC源文件、Excel文件、Csv文件、ADO对象文件等)中读取输入、输出 的测试数据，然后通过变量传入事先录制好的或手工编写的测试脚本中。其中，这些变量被用作传递(输入/输出)用来验证应用程序的测试数据。在这个过程中， 数据文件的读取、测试状态和所有测试信息都被编写进测试脚本里;测试数据只包含在数据文件中，而不是脚本里，测试脚本只是一个“驱动”，或者说是一个传送 数据的机制。
●数据驱动脚本
数据驱动脚本就是那些和应用程序相关联的脚本。这些脚本通过录制或手工编写写进自动化工具私有的语言，然后对其中的变量赋予合适的数值，作为测试数据的输入。这些变量作为一些关键应用程序输入的媒介，使脚本能通过外部的数据来驱动应用程序。
1) 可变数据，硬编码组件标志
这些数据驱动的脚本经常包含硬编码的数据，有时是一些窗口组件中非常脆弱的识别字符串。出现这种情况时，脚本很容易由于程序的更改而失去作用。
2) 高度技术化的、重复的测试设计
数据驱动脚本的另一个共同特点就是，所有在测试设计上所作的努力最终都体现在自动化工具的脚本语言中，或者复制到手工和自动化测试脚本中。这意味着每个和自动化测试开发或执行有关的人必须对测试环境和自动化工具的编程语言非常精通。
●优点与缺点
1) 优点： ①在应用程序开发的同时就可以同步建立测试脚本，而且当应用功能变动时，只需要修改业务功能部分的脚本;②利用模型化的设计，避免重复的脚本，减少建立或 维护脚本的成本;③测试输入数据，验证数据和预期的测试结果与脚本分开，存放在另外的数据文件里，利于测试人员修改和维护;④透过判断功能回传值是 “True”或“False”，可作错误处理，增加了测试脚本的健壮性;⑤自动化测试开发人员创建数据驱动的测试过程，测试员创建测试数据;⑥在测试的过 程中收集测试结果，并在输入数据的语境中表示测试结果，这样可以简化手工结果分析。
2) 缺点： ①对自动化测试工具里的脚本语言必须非常精通;②每个脚本都会对应多个数据文件，这些数据文件需要根据脚本的功能类别存放在各自的目录中，增加了使用的复 杂性;③测试人员除了需要根据具体测试数据维护相应的测试计划，还要将这些数据写入各个需求不同的数据文件中;④在编辑数据文件时，必须注意测试脚本所要 求的传输格式，否则会在处理脚本时产生错误。如由专门的技术人员对其进行维护，依赖于数据驱动脚本的自动化测试框架实现起来更简单、快捷。但是，维护工作 困难，而且还需要保持这种数据驱动的模式，这样，即便长时间的维持也会导致失败。
