如何简单的理解TDD与DDT

TDD：TEST-DRIVEN Development

测试驱动开发到底是什么意思？如何理解测试驱动开发？

举个红绿条简单的例子：

1.编写测试代码

2.编译运行测试代码，确定会失败，由于实现代码尚未写

3.编写实现代码

4.运行测试观察测试结果，多是红色的。

5.开发修改代码使得测试经过

6.运行测试，观察测试结果，直到变绿

7.可进行重构，进行代码优化，删除冗余，继续运行测试直到变绿

 

DDT：DATA-DRIVEN TEST

数据驱动测试是什么意思？如何理解数据驱动测试？

数据驱动的自动化测试是针对上述开发与测试之间紧密耦合问题提出的测试方法。经过创建测试与开发定义的软件元数据的关联——元数据映射表，在测试与开发之间创建松耦合关系。不论测试人员修改测试脚本，仍是开发人员修改软件，只须要修改元数据映射表，既能够知足测试与开发同步进行。这样，能够减小测试脚本调试的工做量，更好的实现自动化测试

 

什么是数据驱动的自动化测试框架？

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

 

KDT：KEYWORD-DRIVEN TEST

关键字驱动测试是什么意思？如何理解关键字驱动测试？

关键字驱动的来源很是天然，从面向对象的思路出发，一样的业务逻辑会天然的编写成一个类或者函数做为关键字来被不一样的测试脚本所调用。当测试框架发展到全部的测试过程都已经能够被写好的函数和类所组合完成时，就进化到了关键字驱动的一个高级阶段，这个时候测试用例的开发就变成了测试数据和关键字的组合，并把这种组合工做简化为全部人都很熟悉的表格填写任务，从而最终达到一个由数据和关键字驱动整个测试的效果。

 

==============

初次接触自动化测试时，对数据驱动和关键字驱动不甚理解，以为有点故弄玄须，不就是参数和函数其嘛！其实其也体现了测试所不一样与开发的一些特色（主要指系统测试），以及和对技术发展的脉络的展示。

 

1.录制/回放的神话

      实际上能够理解为一种自动测试脚本和测试用例的紧耦合，既有测试脚本维护的难度，也与系统测试中面向用户的思路相抵制

　　每一家自动化测试工具厂商都会宣传，他们的工具很是容易使用，没有技术背景的测试人员只要简单录制测试的操做过程，而后播放录制好的测试脚本，就能够轻松自动化全部的测试。这样的说法是很是不负责的。

　　如今咱们来分析一下自动化测试不能单单只依靠录制/回放来完成的缘由。

　　经过录制创建的脚本，基本上都是用脚本语言以硬编码的方式编写的，当应用程序变更时，这些硬编码也随之须要更改。所以，维护这些录制好的脚本，成本是很是高的，高到几乎不能接受。

　　全部的测试脚本都必须是在应用程序能够正确执行时才能录制，若是在录制过程当中发现缺陷.测试人员必须向缺陷管理机制报告，等到该缺陷修正了，整个录制脚本的动做才能继续下去。在这样的状况下，若是仅仅依靠录制脚原本进行测试，效率是十分低下的。

　　同时，这些录制好的脚本不是很是可靠，甚至在应用程序彻底没有变更的状况下直接播放，也可能由于一些意外情况而没法执行。若是录制脚本时测试人员使用了错误的脚本语言，则脚本就必须从新录制。

　　综上所述，经过录制的方式来创建自动化测试脚本的方式看似容易，但实际上会遇到下列问题:①测试人员大多不具有技术背景，难以彻底掌握测试工具;②应用程序必须达到必定的稳定性，才能开始录制测试脚本;③录制的测试脚本与测试数据耦合得太紧密;④维护自动化测试脚本的成本很是高。

2.数据驱动的自动化测试框架

     “什么是数据驱动呢？很大一部分人确定认为数据驱动就是把须要参数化的东西写在EXCEL里，而后在跑脚本时调用。若是我告诉你，这其实不是数据驱动，而只是较高级的参数化，你确定会很惊讶！如今我来解释一下：首先为何叫数据驱动呢，那么它确定有驱动的含义，好比你用EXCEL能够控制测试的业务流吗？回答是不能的。那又如何做到驱动呢？因此说咱们将测试数据放在独立的文件里只是高级的参数话。而数据驱动，你必须有数据来控制测试的业务流。好比你测一个WEB程序，有不少页面，你能够经过一个数据来控制每次是在哪一个页面下工做的（即经过数据来导航到相应的页面）。它是关键字驱动的低级版本，他控制的是函数级的，而关键字是控制动做级的。因此数据驱动应该是能够控制整个测试的”。

         在一些复杂的测试用例中，同一个用例包含了不少的测试流程，其中不一样的测试流程采用不一样的测试输入数据，这个时候测试数据的输入不只仅是参数的输入，还有业务流程的控制字段的输入(能够理解为逻辑参数)，这种情形会更深刻的体现数据驱动的含义。

　　数据驱动的自动化测试是针对上述开发与测试之间紧密耦合问题提出的测试方法。经过创建测试与开发定义的软件元数据的关联——元数据映射表，在测试与开发之间创建松耦合关系。不论测试人员修改测试脚本，仍是开发人员修改软件，只须要修改元数据映射表，既能够知足测试与开发同步进行。这样，能够减小测试脚本调试的工做量，更好的实现自动化测试。

　　●什么是数据驱动的自动化测试框架

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

　　●数据驱动脚本

        数据驱动脚本就是那些和应用程序相关联的脚本。这些脚本经过录制或手工编写写进自动化工具私有的语言，而后对其中的变量赋予合适的数值，做为测试数据的输入。这些变量做为一些关键应用程序输入的媒介，使脚本能经过外部的数据来驱动应用程序。

　　1) 可变数据，硬编码组件标志

　　这些数据驱动的脚本常常包含硬编码的数据，有时是一些窗口组件中很是脆弱的识别字符串。出现这种状况时，脚本很容易因为程序的更改而失去做用。

　　2) 高度技术化的、重复的测试设计

　　数据驱动脚本的另外一个共同特色就是，全部在测试设计上所做的努力最终都体如今自动化工具的脚本语言中，或者复制到手工和自动化测试脚本中。这意味着每一个和自动化测试开发或执行有关的人必须对测试环境和自动化工具的编程语言很是精通。

　　●优势与缺点

　　1) 优势： ①在应用程序开发的同时就能够同步创建测试脚本，并且当应用功能变更时，只须要修改业务功能部分的脚本;②利用模型化的设计，避免重复的脚本，减小创建或维护脚本的成本;③测试输入数据，验证数据和预期的测试结果与脚本分开，存放在另外的数据文件里，利于测试人员修改和维护;④透过判断功能回传值是“True”或“False”，可做错误处理，增长了测试脚本的健壮性;⑤自动化测试开发人员建立数据驱动的测试过程，测试员建立测试数据;⑥在测试的过程当中收集测试结果，并在输入数据的语境中表示测试结果，这样能够简化手工结果分析。

　　2) 缺点： ①对自动化测试工具里的脚本语言必须很是精通;②每一个脚本都会对应多个数据文件，这些数据文件须要根据脚本的功能类别存放在各自的目录中，增长了使用的复杂性;③测试人员除了须要根据具体测试数据维护相应的测试计划，还要将这些数据写入各个需求不一样的数据文件中;④在编辑数据文件时，必须注意测试脚本所要求的传输格式，不然会在处理脚本时产生错误。如由专门的技术人员对其进行维护，依赖于数据驱动脚本的自动化测试框架实现起来更简单、快捷。可是，维护工做困难，并且还须要保持这种数据驱动的模式，这样，即使长时间的维持也会致使失败。

3.关键字驱动的自动化测试
       关键字驱动的来源很是天然，从面向对象的思路出发，一样的业务逻辑会天然的编写成一个类或者函数做为关键字来被不一样的测试脚本所调用。当测试框架发展到全部的测试过程都已经能够被写好的函数和类所组合完成时，就进化到了关键字驱动的一个高级阶段，这个时候测试用例的开发就变成了测试数据和关键字的组合，并把这种组合工做简化为全部人都很熟悉的表格填写任务，从而最终达到一个由数据和关键字驱动整个测试的效果。

       在关键字驱动框架里，你能够建立一些关键字以及相关联的一些方法和函数。而后你建立一个函数库，它里面包含一个读取关键字的逻辑，而后调用相关的动做。

　   关键字驱动的自动化测试(也称为表驱动测试自动化)，是数据驱动自动化测试的变种，可支持由不一样序列或多个不一样路径组成的测试。它是一种独立于应用程序的自动化框架，在处理自动化测试的同时也要适合手工测试。关键字驱动的自动化测试框架创建在数据驱动手段之上，表中包含指令(关键词)，而不仅是数据。这些测试被开发成使用关键字的数据表，它们独立于执行测试的自动化工具。关键字驱动的自动化测试是对数据驱动的自动化测试的有效改进和补充。

        这种自动化测试的模型主要由核心数据驱动引擎、组件函数、支持库和应用映射表组成。自动化测试首先由初始脚本开始执行，这个脚本把高层测试表传递给高层驱动器，高层驱动器在处理这些表的过程当中，遇到中层测试表后就调用中层驱动器，中层驱动器处理中层表时也做相似的处理。当低层驱动器处理低层表时，它尝试着使应用与测试保持同步。当低层驱动器遇到对某一个组件的低层关键字组件时，它判断这个组件的类型并调用相应的组件函数模块来处理这个指令操做。全部这些元素都要依靠映射表中的信息，它是自动化测试模型和被测应用程序的桥梁。支持库主要完成一些文件处理，日志记录和邮件发送等等的功能。