文/秋之川
这是《落叶》文集里第 320 片落叶，希望你能喜欢，不为别的，只为这份坚持。
【背景】
在学习 Python 开发接口自动化工具的时候，有同学问过数据驱动和关键字驱动的区别，当时因为这个不属于课程本身的范畴，所以并未详细解答，今天正好放假，拿出来回答一下。
【你问】
数据驱动和关键字驱动有什么区别？
【我答】
数据驱动和关键字驱动都是面向自动化脚本设计而言的，就我的理解，它们的区别并不是两个平行事物的优劣区分，而是自动化脚本设计模式的一种演变，关键字驱动是数据驱动设计模式或思想的升级迭代。
为了更好地了解两者，我们就从最初级的脚本设计模式开始看起吧。
-
录制脚本，也可叫线性脚本，顾名思义，这种脚本设计模式就是通过某种自动化测试工具的录制功能，将一组测试用例按照手工执行的顺序，从头到尾一口气录制完成，执行测试时也就是将录制好的脚本回放一下。
优势：想了半天，不知道适合初学者接触自动化测试脚本算不算一个优势，其它的还真想不到了。
劣势：
（1）跟实际录制时操作和数据的耦合性太强，回放时的成功率不高；
（2）功能模块相对稳定时，才能录制完整的脚本；
（3）当功能发生改变时，需要重新录制脚本，直接修改难度较大，所以脚本维护成本非常高； -
程序化脚本，也叫结构化脚本，指的就是像写代码一样去设计和编写自动化测试脚本，它具有各种逻辑结构，包括循环、判断、函数方法调用、重用等等。
优势：
（1）能实现复杂功能模块的自动化测试场景；
（2）因为能够重用和函数调用，所以维护起来，成本较低；
劣势：
（1）对测试人员的技术要求较高，需要具备编程基础，需要学习自动化脚本开发；
（2）从开发效率角度，所需时间也比较长； -
数据驱动脚本，将程序化脚本里的测试数据从脚本中剥离出来，存储在独立于脚本之外的数据文件（XML，Excel等）或数据库里，使脚本中的操作指令和数据分离。
上面是我之前认知和理解的“什么是数据驱动脚本”，现在通过学习，又了解到一种新的关于数据驱动脚本的观点。
这种观点认为，数据驱动，就意味着数据决定了结果，自动化工具读取设计好的数据，运行脚本，通过设定好的参数读入不同的测试数据，验证数据，再跟设计好的期望测试结果做比对。
优势：
（1）操作指令和数据分离，一方面可以降低成本，另一方面也可灵活适应多套测试数据的执行；
（2）脚本编写可以与功能开发并行，提高效率；
（3）测试输入数据、验证数据和期望结果的彼此独立，也降低了测试人员维护测试用例的成本；
劣势：
（1）对测试人员的技术要求依然较高，仍然很难将测试工程师和自动化工具开发工程师完全分离开来；
（2）当业务功能发生改变时，维护脚本的工作量依然不小； -
关键字驱动脚本，是基于数据驱动脚本设计模式的一种进化，它其实是采用了面向对象的开发模式，将所有被测的东西都看作一个个对象，并建立一个对象关系表，通常习称之为 Object Map，再将跟每个对象相关的一组操作指令封装成一个关键字（Keyword），这种脚本从表面上看跟手工执行的脚本没有太大区别，就是针对某个对象，执行某个动作，再查看实际的结果和期望结果的比对结果。
优势：
（1）大大降低了测试人员编写脚本的门槛，只要是熟悉业务功能手工测试用例编写的测试人员，都可以很轻松的编写关键字驱动脚本，而且可以做到盲写，也就是测试先行；
（2）自动化测试开发人员可以专注于维护 Keyword 的封装和执行效率的优化；
（3）当某个业务操作逻辑需要改动时，只需要修改相应的 Keyword 即可，维护成本大大降低；
劣势：
（1）如果自动化测试开发人员没有提供一个相对智能化一点的 IDE，那编写脚本的测试人员，需要不断查看 Object Map、关键字关系表；
（2）测试脚本编写人员和关键字封装的测试开发人员，经常会因为某个 Keyword 的封装颗粒度产生争议，因为从测试开发人员的角度，封装颗粒度越小越便于维护，因为耦合性较低，而测试脚本编写人员一般希望封装颗粒度越大越好，那样会降低脚本的行数，也就是脚本量；
《测试路上你问我答》里的 Q&A 97，如果是你要的，甚好！如果不是，你问，我答！
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
