| 深入探讨：数据驱动测试（DDT）与关键字驱动测试（KDT） | 您所在的位置：网站首页 › 数据驱动测试概念 › 深入探讨：数据驱动测试（DDT）与关键字驱动测试（KDT） |
深入探讨：数据驱动测试（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 {"name":"aaa","id":10001,"age":20} Case2 get userinfo User_id=10002 n/a n/a {"error":"age can't be null"} Case3 post User_update User_id=10001 Name=aaa Age=21 {"name":"aaa","id":10001,"age":20} Case4 post User_update User_id=10002 Name=bbb Age=null {"error":"age can't be null"} 更复杂的数据结构设计 Case_id step method api Param1 Param2 Param3 Need verification Expect Case1 1 post Create_user Name=aa Age=20 n/a N
Case1 2 get userinfo User_id=10001 n/a n/a Y {"name":"aaa","id":10001,"age":20} Case2 1 post Create_user Name=bb Age=22 n/a N
Case2 2 get userinfo User_id=10002 n/a n/a Y {"error":"age can't be null"} Case3 1 post User_update User_id=10001 Name=aaa Age=21 Y {"name":"aaa","id":10001,"age":20} Case3 2 post Delete_user User_id=10001 n/a n/a N
Case4 1 post User_update User_id=10002 Name=bbb Age=null Y {"error":"age can't be null"} Case4 2 post Delete_user User_id=10002 n/a n/a N
所谓的数据驱动，原本没有什么特别的，无非就是把hard code 在脚本中的数据参数化出来，之所以算是Robot、WinRunner甚至QTP时代测试工具的卖点，其实主要是因为那个年代大多数system tester 不懂开发，总需要有个功能来帮助自己完成参数抽取、数据维护、自动替换之类的功能。 而关键字驱动，则进一步在技术上把 tester 分成了完全不懂技术的和懂点技术的，前者只能根据格式填写一下 excel 表格，后者对工具/框架内置的所谓关键字库进行增补或二次开发。 关键字驱动测试 关键字驱动的自动化测试(也称为表驱动测试自动化)，是数据驱动自动化测试的变种，可支持由不同序列或多个不同路径组成的测试。它是一种独立于应 用程序的自动化框架，在处理自动化测试的同时也要适合手工测试。关键字驱动的自动化测试框架建立在数据驱动手段之上，表中包含指令(关键词)，而不只是数 据。这些测试被开发成使用关键字的数据表，它们独立于执行测试的自动化工具。关键字驱动的自动化测试是对数据驱动的自动化测试的有效改进和补充。 1. 关键字驱动测试是数据驱动测试的一种改进类型 2. 主要关键字包括三类：被操作对象（Item）、操作（Operation）和值（value），用面向对象形式可将其表现为Item.Operation(Value) 3. 将测试逻辑按照这些关键字进行分解，形成数据文件。 4. 测试框架低层负责解释这些关键字，并完成相应的指令操作
关键字驱动的同义词 Ø Action words / Action Based Testing™ (Hans Buwalda) Ø Test frameworks (Linda Hayes et al.) Ø Third-generation test automation (Ed Kit) Ø CSDDT – Control Synchronized Data Driven Testing Ø (Daniel Mosley) Ø Test Plan Driven Testing Framework (Keith Zambelich) Ø TestFrame Method (Hans Buwalda) Ø TestVerb™ technology (TestQuest) Ø Variable Capture / Variable Playback (Linda Hayes) Ø Table-driven testing
关键字驱动的工具 Ø SAFS（open source）http://safsdev.sourceforge.net/Default.htm Ø EMOS Framework（open source） Ø FIT/FitNesse（open source）http://en.wikipedia.org/wiki/FitNesse Ø Certify, Worksoft Ø Unified TestPro, SDT Ø TestFrame, LogicaCMG Ø TestArchitect, LogiGear Ø Tools with built-in keyword support: TestQuest Pro,QuickTest Professional
丹尼·法特（Danny R.Faught）举的例子： +----------------------------------------------------+ | Action Fixture | +-----------------------------------------------+----+ | start | Fitness.fixtures.CountFixture | | +-------+---------------------------------------+----+ | check | counter | 0 | +-------+---------------------------------------+----+ | press | count | | +-------+---------------------------------------+----+ | check | counter | 1 | +-------+---------------------------------------+----+ | press | count | | +-------+---------------------------------------+----+ | check | counter | 2 | +-------+---------------------------------------+----+ | enter | counter | 5 | +-------+---------------------------------------+----+ | press | count | | +-------+---------------------------------------+----+ | check | counter | 6 | +-------+---------------------------------------+----+ | from URL http://fitness.org/FitNesse.ActionFixture | +----------------------------------------------------+
关键字驱动测试和数据驱动测试的区别是，在关键字驱动测试里，脚本中的每一行不仅仅是数据，而是通过关键字告诉框架怎么处理这一行的数据。 有些关键字框架的设计者喜欢写有多个关键字的测试用例，正如上例所示。结果脚本看起来像一种简单的编程语言。而另外一种相反的倾向使用一个关键字来完成整个测试用例，这样就模糊了数据驱动测试和关键字驱动测试之间的界限。 关键字驱动测试框架是当前比较流行的一种框架之一，并且现在的自动化测试工具QuickTest已经将关键字驱动框架融入到工具中。在录制过程中自动化测试工具会将对象及操作属性保存到对象库中。 录制完成后的每个测试步骤主要有三个元素组成： Item：指对象名，可以是一个窗口、按钮等； Operation：指要执行的动作，如Select、Click等； Value：操作动作所输入的数据值；以QuickTest自带的飞机订票系统为例，录制其登录过程，生成的代码如下： Dialog("Login").WinEdit("Agent Name:").Set "test" Dialog("Login").WinEdit("Password:").SetSecure "4d410e55b694bada39e235f9896e6eb810ba0e60" Dialog("Login").WinButton("OK").Click 这是QuickTest以关键字驱动的方式生成的代码，当然也可以直接写代码来实现关键字驱动测试。 关键字驱动测试最核心的是关键字表格。以飞机订票系统的登录为例，其关键字表格见下表： 父对象 孩子对象 描述 事件 值 Dialog
text:=Login Launch D:\QuickTest Professional\samples\flight\app\flight4a.exe Dialog WinEdit attached text:=Agent Name: Set test Dialog WinEdit attached text:=Password: Set mercury Dialog WinButton text:=ok Click
关键字驱动的思路是将关键字表中的对象及数据提取出来并构造成每个测试步骤，如步骤： Dialog("Login").WinEdit("Agent Name:").Set "test" 更高级的关键字驱动：可以自定义关键字
自定义关键字是什么意思？就是自己写关键字的意思呗，是相对于系统关键字而言的，也很简单，例如Robot Framework，关键字说白了就是一个函数，实现了一些自定义的功能或过程。 总结（这一部分只是一家之言，每个人或许都有自己的理解和看法，这里抛砖引玉，欢迎探讨）：关键字驱动设计的越完美，越复杂，越来越像一种高级编程语言（当然，其不支持编程语言的逻辑操作），综合来看，关键字驱动的局限性已经越来越突出，为了打破局限性而做出的改进又使学习成本越来越高，甚至超越了学习一门编程语言！所以问题是：那么我们为什么不直接学习一门编程语言，而要去学习这些关键字呢？需要提醒大家思考的是：一门编程语言也是由有限的关键字组成的。 当然，学习编程语言和学习使用关键字驱动不是完全冲突的，二者也可以形成互补，并不是说只要你掌握了关键字驱动，就可以不用学习编程语言了。但是关键字驱动出现的目的，的确是为了降低自动化测试的门槛，使初学者更快速和容易的实现自动化测试用例。其实人都有懒惰心理，如果我能够通过关键字就能实现自动化测试，为什么还要学习编程语言呢？ 另外，有人可能会说，学习编程语言很难啊，还是学习关键字来的快一些。我想说的是，看看编程语言发展史：二进制，汇编，Fortran, c语言，C++, python，java，由低级到高级，由面向过程到面向对象，编程语言的进步，是逐步人性化的发展过程，是一个越来越简单易学的过程。 所以学习现在流行的高级编程语言难不难？不难，一点都不难！但是要写一段好的程序难不难？难！真的很难。 就好比说话与写文章：你说说话难不难？不难！那写文章难不难？那可就难喽！不是你学会了说话，你就是一个好的作家，同理，不是说你学会了一门编程语言，你就是一个好的程序员。不是你学会了使用关键字，就能写出好的自动化测试用例。通常我们说的编程很难，指的是编写一段好的程序很难。 其实所有的事情大都如此，你想做一件事情基本上都不难，但是要把一件事情做好，做到极致，却很难。所以无论是数据驱动也好，关键字驱动也好，各有自己的优劣，适合的才是最好的，会用不是目的，用好，能解决问题，提高效率才是目的。 什么才是好的自动化测试框架？如何选择测试框架？ 符合人性学习成本低灵活性高，支持各种各样的测试专而不困，不丧失通用性大而不乱，庞大但分层明确，易于管理关于测试数据的管理之我见： 基础数据人工维护，尽量少改动测试数据随测试用例而异，要区分环境动态数据动态获取
最后关于关键字驱动框架的评价，摘抄一段网友的说法： 传统的关键字驱动框架的时代在前几年就已经开始远去（是had been，不是have been），我们感谢上一代tester的努力探索和实践，但最终历史证明这是一个不算成功的尝试，一个框架如果不具备开放性，一切都自给自足，那么有一天这也会成为限制自己发展的最大原因。
来自 |
【本文地址】