数据驱动测试该怎么理解？真的像传说中的那么diao吗？

当第一次听说数据驱动测试这个叫法，觉的很高大上，深入了解了下，似乎逼格没有那么高。参考了很多网上的文章，发现大家对数据驱动测试理解的似乎有些偏，事实上并非所有的测试都适合数据驱动，数据驱动也并非是用csv记录测试数据那么简单。于是，发文一篇，把自己的理解分享给大家。

1. 数据驱动测试到底是什么

                                

左边是未采用数据驱动的，右边采用了数据驱动。

IBM很早就在Rational Functional Tester中引入了数据驱动的功能，上面图片就来源于RFT中data-driving的文档，https://www.ibm.com/support/knowledgecenter/ko/SSJMXE_8.3.0/com.ibm.rational.test.ft.doc/topics/dpaboutdatadrivingtscripts.html 。

看左边的图，测试脚本与测试数据杂糅在一起。看右边的图，测试脚本与测试数据分离。数据驱动测试就是这样，让测试数据独立于测试脚本单独存在，解除脚本与数据之间的强耦合。测试脚本不再负责管理测试数据，而测试数据在数据驱动测试中会以文件或者数据库的形式存在。脚本每次执行会机械的从数据文件或者数据库中读入测试数据，根据测试数据的不同走进不同的测试路径。在整个测试中，测试脚本是一成不变的，它一直机械的执行它本身的代码，而活着的是我们的测试数据集，我们通过不同的数据控制测试脚本中代码的走向。因此，才有了数据驱动的说法。

打个比方，数据驱动测试就像我们打游戏，测试脚本就是游戏机本身，放在桌上稳如泰山，而数据就是游戏手柄。我们使用手柄控制着游戏机，可以让画面上的游戏人物做出不同的动作（测试结果）。

所以，解除测试数据与脚本的强耦合，让数据控制脚本是数据驱动测试的一大特征。

另外，测试数据独立出来形成的那个东西，英文里面叫做data pool，这个叫法很形象，我姑且叫它数据池。“池”，这个字有两层意思，其一显示出资源丰富，其二显示出这是个存储的地方。如果诸位仅仅把它想象成是一个excel文件或者csv文件，那么就想得过于简单了。首先既然这是一个pool，可以存储资源，那么就需要有存储资源的逻辑。比如分类，如何让测试数据们对应上相应的测试脚本，这是在数据驱动中需要考虑的问题。再比如数据的存储形式，是逐个字段存储，还是以大json形式整体存储，也是要想到的问题。一般来说以数据库作为数据池来存储测试数据，要比文件的形式存储灵活的多，也是架构数据驱动测试平台的首选。

2. 解决了什么痛点

一种新技术的诞生，一定是基于新的业务需求的，同样一种测试方式的诞生也一定是为了解决某项痛点的。数据驱动测试也不例外。以下的例子依然来自IBM的RFT文档，翻译一段：

Problem: During recording, you create a personnel file for a new employee, using the employee's unique identification number. Each time the test is run without data-driving the test, there is an attempt to create the same personnel file and supply the same identification number. The application rejects the duplicate requests.

痛点：为新员工创建个人档案的时候，使用的是该员工的id号。如果不使用数据驱动测试，每次测试都会以相同的员工id创建相同的档案。而程序会拒绝重复的请求。

Solution: You can data-drive the test script to send different employee data, including identification numbers, to the server each time the test is run.

解决方案：使用数据驱动测试，这样每次运行测试脚本会发送不同的员工数据，包括不同的员工id，这样服务器每次会收到不同的参数。

这个例子要说明的是，测试数据杂糅在测试脚本中，测试数据的丰富程度会极大受到限制。因为脚本中不太可能维护上大量的测试数据（试想下在200行代码的脚本中再加上200行代码的数据，维护起来有多么恐怖），而在每个脚本中都为其对应的测试数据单独写一套更新的逻辑又会耗费太高的成本。所以，将测试数据从测试脚本中剥离，将方便于测试数据的扩展，毕竟在数据库里面插入一行要比在代码中加入一批变量省力的多。

再者，在自动化测试中，为了维持回归测试的稳定一致，测试脚本应当尽量避免更改。在非数据驱动的情况下，恰恰违背了这一原则。自动化测试中，随着项目的深入，测试脚本将会持续增多，测试数据和脚本揉在一起？维护起来将会是一件恐怖的事情，出错在所难免，所以这时不要这样做，让数据和脚本分离，坚持死的代码，活的数据，维护的大部分工作将只面向数据。

因此，数据和脚本分离、维护对象由脚本转向数据，这样的数据驱动测试将会缓解上述测试数据难扩展和测试项目维护难的痛点。

3. 不适宜数据驱动的情况

数据驱动测试并不适用于所有的测试。

首先，对于弱参数的测试，使用数据驱动，将会降低测试效率。所谓弱参数测试，就是测试用例对测试参数不敏感，具体表现在用例不需要传入参数的情况，或者难以参数化的情况等等。

举个例子，我们要测试一个接口，它的功能是返回当前系统时间的时间戳，它没有需要传入的参数，返回的数据也完全由当前时间决定。在这个例子中，我们几乎看不到需要参数化的东西，唯一有可能被参数化的是接口的返回参数，而这个返回参数还是随着当前时间动态变化的。如果要对这个接口实现数据驱动，那么我们需要在数据池中增加动态获取时间的逻辑，然而获取当前时间在测试脚本中，用一行代码就可以实现，所以，本例使用数据驱动得不偿失。

再者，对于非大规模的，或者非自动化的，或者非长期优化的测试，使用数据驱动通常没有必要。对于一个小的、临时的或者一次性的测试需求，整个测试过程讲究灵活变通，完全没有必要去花力气去建设一个专门的数据驱动的平台。总之，如何能够达到效率最高，就如何去安排测试的方法。

脱离了具体需求的测试方法或者技术，都是在耍流氓。