深入探讨：数据驱动测试（DDT）与关键字驱动测试（KDT）

 

关键字驱动测试框架是当前比较流行的一种框架之一，并且现在的自动化测试工具QuickTestProfessional已经将关键字驱动框架融入到工具中。那么究竟什么是关键字驱动测试，它与数据驱动测试有何区别？让我们来深入探讨一下这个话题

 

数据驱动测试

数据驱动的自动化测试框架是这样的一个框架，从某个数据文件(例如ODBC源文件、Excel文件、Csv文件、ADO对象文件等)中读取输入、输出 的测试数据，然后通过变量传入事先录制好的或手工编写的测试脚本中。其中，这些变量被用作传递(输入/输出)用来验证应用程序的测试数据。在这个过程中， 数据文件的读取、测试状态和所有测试信息都被编写进测试脚本里;测试数据只包含在数据文件中，而不是脚本里，测试脚本只是一个“驱动”，或者说是一个传送 数据的机制。

 

特点：

1) 可变数据

2) 高度抽象化的、重复的测试设计

 

优点：

减少重复劳动

解耦，降低准入门槛，易于测试人员修改和维护：测试开发负责开发测试脚本，手工测试人员负责准备测试数据

 

缺点：

灵活性低，扩展受限，一组脚本只能处理特定格式的数据

通过数据控制（驱动）逻辑处理是短板

开发不同类型的脚本或增强脚本的处理逻辑，会增加复杂度，维护成本高

测试范围的扩大，会导致测试数据的数量和类别都非常多，维护这些数据成本会增大

增加学习成本

增加沟通成本

 

数据驱动测试：多行测试数据对应一个测试脚本（或者说对应于一个关键字的实现），然后用不同的测试数据反复运行脚本（即每一行数据的处理逻辑是一样的）。如果需要做不同类型的测试，需要新增测试脚本（往往意味着新的测试数据格式）或者沿用同一个测试脚本，但是要做逻辑判断来确定执行哪一种测试

举例：

获取用户信息接口测试：

Case_id	用户id	Expect
Case1	10001	{ "name":"aa","id":10001,"age":20}
Case2	10002	{ "name":"bb","id":10002,"age":22}

更新用户信息接口：

Case_id	用户id	Name	age	Expect
Case1	10001	aaa	21	{ "name":"aaa","id":10001,"age":20}
Case2	10002	bbb	null	{"error":"age can't be null"}

融合的数据：

Case_id	method	api	Param1	Param2	Param3	Expect
Case1	get	userinfo	User_id=10001	n/a	n/a