CN102486749A

CN102486749A - 数据驱动测试方法及系统

Info

Publication number: CN102486749A
Application number: CN201010572563XA
Authority: CN
Inventors: 王志鹏
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2010-12-03
Filing date: 2010-12-03
Publication date: 2012-06-06
Anticipated expiration: 2030-12-03
Also published as: CN102486749B

Abstract

本发明公开了一种数据驱动测试方法及系统。在上述方法中，将编写好的测试数据文件与测试逻辑文件相关联形成脚本文件；将脚本文件中的测试数据文件复制多个，并设置全部测试数据文件中一个或多个测试数据文件的测试参数形成多个测试文件数据套件；对于每个测试文件数据套件，分别将该测试文件数据套件与测试逻辑文件生成可执行脚本并执行。根据本发明提供的技术方案，可以有效提高自动化脚本的运行效率。

Description

数据驱动测试方法及系统

技术领域

本发明涉及自动化测试领域，具体而言，涉及一种数据驱动测试方法及系统。

背景技术

自动化测试作为提高测试效率的有效测试手段，近几年来在测试领域得到了广泛的应用，由此也衍生出很多自动化框架。数据驱动技术便是其中的佼佼者，它的基本原理是：在脚本编写阶段，脚本开发人员将脚本中可变的测试数据提取出来作为单独的数据文件，在编写脚本时，再编写代码将数据从数据文件读取出来。在脚本执行阶段，执行人员只需填写测试数据文件，就可以驱动脚本的运行。IBM的测试套件Rational提供的数据池(Data Pool)便是其中的杰出代表。这种数据驱动的优点是将测试环境与测试逻辑相分离，提高了脚本的适用性；采用数据文件存储测试数据，使测试数据重用率高，并且便于管理。

但是，上述方案也有不足之处：脚本编写人员需要给每一个用到数据池技术的脚本编写相应的测试数据读取模块，脚本编写工作量和维护工作量呈几何增长。

并且，同一个脚本运行一次无法加载多套测试数据，也就是说脚本加载第一套测试数据运行完毕后，再由人工加载第二套测试数据。而在硬件测试中这种场景很普遍，由于制造工艺的问题，同样一个脚本需要在各种场景下运行，例如，不同的槽位、不同的端口等。因此，通过人工加载多套测试数据，大大降低了自动化测试效率。

发明内容

针对相关技术中在脚本运行过程中，通过人工加载多套测试数据，大大降低了自动化脚本的运行效率等问题，本发明提供了一种改进型的数据驱动测试方法及系统，以解决上述问题至少之一。

根据本发明的一个方面，提供了一种数据驱动测试方法。

根据本发明的数据驱动测试方法包括：将编写好的测试数据文件与测试逻辑文件相关联形成脚本文件；将脚本文件中的测试数据文件复制多个，并设置全部测试数据文件中一个或多个测试数据文件的测试参数形成多个测试文件数据套件；对于每个测试文件数据套件，分别将该测试文件数据套件与测试逻辑文件生成可执行脚本并执行。

根据本发明的另一方面，提供了一种数据驱动测试系统。

根据本发明的数据驱动测试系统包括：脚本文件生成装置，用于将编写好的测试数据文件与测试逻辑文件相关联形成脚本文件；测试文件数据套件生成装置，用于将脚本文件中的测试数据文件复制多个，并设置全部测试数据文件中一个或多个测试数据文件的测试参数形成多个测试文件数据套件；可执行脚本生成装置，用于分别将各个测试文件数据套件与测试逻辑文件生成可执行脚本；脚本解释装置，用于接收来自于可执行脚本生成装置生成的可执行脚本并执行。

通过本发明，脚本运行一次可以自动加载多套测试参数，解决了相关技术中在脚本运行过程中，通过人工加载多套测试数据，大大降低了自动化脚本的运行效率等问题，进而可以有效提高自动化脚本的运行效率。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的数据驱动测试方法的流程图；

图2是根据本发明实例的数据驱动的脚本开发流程图；

图3是根据本发明实例的数据驱动的脚本执行流程图；

图4是根据本发明实施例的数据驱动测试系统的结构框图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明的具体实施方式进行详细说明。

图1是根据本发明实施例的数据驱动测试方法的流程图。如图1所示，该数据驱动测试方法主要包括以下处理：

步骤S102：将编写好的测试数据文件与测试逻辑文件相关联形成脚本文件；

其中，测试数据文件包括：变量标识(例如，变量名称)和变量数值，优选地，测试数据文件还可以包括变量说明。在具体实施过程中，变量的命名必须符合测试系统采用脚本语言的命名规范。

步骤S104：将脚本文件中的测试数据文件复制多个，并设置全部测试数据文件中一个或多个测试数据文件的测试参数形成多个测试文件数据套件；

步骤S106：对于每个测试文件数据套件，分别将该测试文件数据套件与测试逻辑文件生成可执行脚本并执行。

采用上述方法，将编写好的测试数据文件与测试逻辑文件相关联形成脚本文件，根据测试需要，用户繁衍(复制)多套测试数据文件，并设置测试参数数值，形成多个测试文件数据套件保存在脚本文件中，脚本运行一次可以自动加载多套测试文件数据套件，解决了相关技术中通过人工加载多套测试数据，大大降低了自动化测试效率等问题，进而可以有效提高自动化脚本的运行效率。

并且，在具体实施过程中，由于用户繁衍了多套测试数据文件，并且上述多套测试数据文件与测试逻辑文件相关联，而这种多测试数据必须将测试数据文件与测试逻辑文件分开存放，在执行脚本时，可以动态地将脚本文件中的各套测试文件数据套件与测试逻辑文件生成可执行脚本，因而无需为每一个用到数据池技术的脚本编写相应的测试数据读取模块，有效降低了脚本编写工作量和维护工作量。

优选地，在步骤S102中，可以通过变量标识将编写好的测试数据文件与测试逻辑文件相关联形成脚本文件。当然，在具体实施过程中，也可以采用其他形式将编写好的测试数据文件与测试逻辑文件相关联，例如，在脚本文件中设置关联索引。

其中，测试逻辑文件描述了测试步骤，它通过定义和默认的测试数据文件相同的变量标识(例如，变量名称)达到直接引用相关联的测试数据文件中同名变量的目的。

优选地，上述脚本文件包括但不限于：测试逻辑文件标识以及编写好的测试数据文件标识。

其中，本发明涉及的脚本文件不同于传统意义上的脚本，本发明涉及的脚本文件包括：测试逻辑文件标识和测试数据文件标识，将其直接传送给脚本解释器是不能执行的。

其中，上述复制的测试数据文件与上述编好的测试数据文件的文件标识不同。但是，变量名称和变量数值均相同，如果编好的测试数据文件包括变量说明，则变量说明也相同。

优选地，步骤S104中，在将编写好的测试数据文件复制多个之后，还可以包括以下处理：响应用户操作，删除一个或多个复制的测试数据文件。

在优选实施过程中，用户可删除繁衍的测试数据文件，但不能删除上述编好的测试数据文件。

优选地，步骤S104中，在将编写好的测试数据文件复制多个之后，还可以包括以下处理：响应用户操作，更改一个或多个全部测试数据文件的变量个数。

在优选实施过程中，用户可更改(增加或删除)测试数据文件中变量的个数。

在优选实施过程中，步骤S106中，执行脚本时，把脚本列表传递给执行线程，执行线程按照顺序动态把测试逻辑和测试数据合并成可执行的脚本，然后再把脚本传递给脚本解释器执行，直到把所有的测试数据套件执行完毕。

以下结合图2和图3的示例描述上述优选实施方式。

本实例实现一个单板复位的操作，脚本语言采用的是业内最为普遍的tcl语言。为了简单说明问题，本实施例所用到的所有文件都保存在文件中，当然也可以保存在数据库中。

图2是根据本发明实例的数据驱动的脚本开发流程图。如图2所示，主要包括以下处理：

步骤S202，编写测试数据：在具体实施过程中，可以根据测试的目的，抽象出可变的测试数据。

在本实施例中，可变的参数有机架号、子架号、槽位号、模块号。编写好的测试数据文件类似如下所示，文件名称命名为TestData0.txt：

<？xml version＝″1.0″encoding＝″gb2312″？>

</param List>

步骤S204，编写测试逻辑：在具体实施过程中，可以根据测试数据定义的变量名称编写测试逻辑。

在本实施例中，假设复位单板是由一个底层函数来实现的。编写好的测试逻辑类似如下所示，文件名称命名为TestLogic.txt：

set iRet[ResetBoard $rackNo $shelfNo $slotNo $moduleNo]

if{$iRet＝＝1}{

puts“复位$slotNo槽位成功”

}else{

puts“复位$slotNo槽位失败”

}

步骤S206，测试逻辑与测试数据相关联形成脚本：将测试逻辑文件标识(ID)和测试数据文件标识(ID)保存在脚本文件中。关联的测试数据称为默认的测试数据文件。

在本实施例中，生成的脚本内容如下所示，脚本名称命名为ResetBoard.xml：

<？xml version＝″1.0″encoding＝″gb2312″？>

</TestData>

</TestLogic>

需要注意的是，上述脚本和传统意义上的脚本不同，它直接交给脚本解释器是不能执行的。

至此脚本编写完毕，假如脚本调试通过，正式发布后，下面进入脚本执行阶段，需要说明的是，通常情况下脚本开发和脚本执行是两个独立的过程，所以其测试环境可能不相同。以下结合图3描述数据驱动的脚本执行流程。

图3是根据本发明实例的数据驱动的脚本执行流程图。如图3所示，主要包括以下处理：

步骤S302，繁衍测试数据：根据测试需求，在默认的测试数据上繁衍测试数据，形成测试数据套件。

在本实施例中，假定根据测试要求，需要完成10个槽位的测试。可以通过测试数据繁衍模块，复制了另外9套测试数据，并把繁衍的测试数据文件标识(ID)保存在脚本文件中。繁衍后的脚本内容如下：

<？xml version＝″1.0″encoding＝″gb2312″？>

......

</TestData>

</TestLogic>

步骤S304，配置测试数据套件参数：根据测试需求，响应用户操作，配置测试数据参数，并保存到测试数据文件中。

在本实施例中，假定要分别复位1至10号机架的1至10号槽位，其他参数不变。

步骤S306，传递脚本给执行控制线程：系统将要执行的脚本列表传递给控制线程。

在本实施例中，系统把一个脚本ResetBoard.xml传递给系统执行控制线程。

步骤S308中，动态生成可执行的脚本：系统执行控制线程从脚本中依次获取测试数据文件和测试逻辑传递给脚本生成器动态生成脚本。

在本实施例中，脚本解释器将先动态生成1号槽位的脚本，然后执行步骤S310，执行完毕后，然后，重复步骤S308，步骤S310，直至将10个槽位都复位，测试完成。

在本实施例中，第一个测试数据文件和测试逻辑生成的可执行的脚本内容如下：

#机架号

set rackNo 1；

#子架号

set shelfNo 1；

#槽位号

set slotNo 1；

#模块号

set module 1；

set iRet[ResetBoard $rackNo $shelfNo $slotNo $moduleNo]

if{$iRet＝＝1}{

puts“复位$slotNo槽位成功”

}else{

puts“复位$slotNo槽位失败”

}

其他测试数据文件和测试逻辑文件的合并结果类同。

步骤S310，执行脚本：系统把动态生成的脚本交给脚本解释器执行。

在具体实施过程中，脚本解释器需要对脚本生成器生成的脚本执行完毕后，还需要判断是否还有其他需要执行的脚本，如果有，需要继续接收来自于脚本生成器生成的脚本并执行，直至全部执行完毕。因此在执行过程中，无需人工加载测试参数，提高了运行测试效率。

图4是根据本发明实施例的数据驱动测试系统的结构框图。如图4所示，该数据驱动测试系统包括：脚本文件生成装置40、测试文件数据套件生成装置42、可执行脚本生成装置44以及脚本解释装置46。

脚本文件生成装置40，用于将编写好的测试数据文件与测试逻辑文件相关联形成脚本文件；

测试文件数据套件生成装置42，用于将脚本文件中的测试数据文件复制多个，并设置全部测试数据文件中一个或多个测试数据文件的测试参数形成多个测试文件数据套件；

可执行脚本生成装置44，用于分别将各个测试文件数据套件与测试逻辑文件生成可执行脚本；

脚本解释装置46，用于接收来自于可执行脚本生成装置生成的可执行脚本并执行。

上述数据驱动测试系统中，脚本文件生成装置40将编写好的测试数据文件与测试逻辑文件相关联形成脚本文件，测试文件数据套件生成装置42可以根据测试需要，繁衍(复制)多套测试数据文件，并设置测试参数数值，形成多个测试文件数据套件保存在脚本文件中，可执行脚本生成装置44和脚本解释装置46相互结合，使得脚本运行一次可以自动加载多套测试文件数据套件，解决了相关技术中通过人工加载多套测试数据，大大降低了自动化测试效率等问题，进而可以有效提高自动化脚本的运行效率。

并且，在具体实施过程中，由于测试文件数据套件生成装置42繁衍了多套测试数据文件，并且上述多套测试数据文件与测试逻辑文件相关联，而这种多测试数据必须将测试数据文件与测试逻辑文件分开存放，在执行脚本时，可执行脚本生成装置44可以动态地将脚本文件中的各套测试文件数据套件与测试逻辑文件生成可执行脚本，因而无需为每一个用到数据池技术的脚本编写相应的测试数据读取模块，有效降低了脚本编写工作量和维护工作量。

优选地，脚本文件生成装置40可以通过变量标识将编写好的测试数据文件与测试逻辑文件相关联形成脚本文件。

优选地，测试文件数据套件生成装置42，还用于响应用户操作，删除一个或多个复制的测试数据文件。

优选地，测试文件数据套件生成装置42，还用于响应用户操作，更改一个或多个全部测试数据文件的变量个数。

上述可执行脚本生成装置44，可以把把脚本生成真正可执行的脚本文件。可以用于以下场景：

(1)在打开脚本时，该装置把该脚本对应的测试逻辑以及相关联的测试数据合并为一个脚本文件，展现给用户。编辑保存后，还是保存为独立的两个文件。

(2)在运行脚本时，该装置被执行线程调用把该脚本对应的测试逻辑以及相关联的测试数据合并为一个可执行的脚本文件，传递给脚本解释装置46执行。

需要说明的是，上述系统中各装置相互结合的优选工作方式具体可以参见图2至图3的描述，此处不再赘述。

综上所述，借助本发明提供的上述实施例，通过变量名称将测试数据和测试逻辑相关联，简化了脚本编写复杂度。将脚本文件内容定义为保存测试数据文件标识和测试逻辑文件标识的文件，并通过引入默认的测试数据文件以及测试数据繁衍(复制)机制，给一个脚本在多个测试场景下运行提供了框架基础。在执行时，通过可执行脚本生成装置动态把测试数据和测试逻辑生成脚本，脚本运行一次可以在多个测试场景测试，进而有效提高了自动化脚本的运行效率。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种数据驱动测试方法，其特征在于，包括：

将编写好的测试数据文件与测试逻辑文件相关联形成脚本文件；

将所述脚本文件中的测试数据文件复制多个，并设置全部测试数据文件中一个或多个测试数据文件的测试参数形成多个测试文件数据套件；

对于每个所述测试文件数据套件，分别将该测试文件数据套件与所述测试逻辑文件生成可执行脚本并执行。

2.根据权利要求1所述的方法，其特征在于，所述将编写好的测试数据文件与测试逻辑文件相关联形成脚本文件包括：通过变量标识将所述编写好的测试数据文件与测试逻辑文件相关联形成脚本文件。

3.根据权利要求1所述的方法，其特征在于，所述脚本文件包括：所述测试逻辑文件标识以及所述编写好的测试数据文件标识。

4.根据权利要求1所述的方法，其特征在于，所述复制的测试数据文件与所述编好的测试数据文件的文件标识不同。

5.根据权利要求1至4中任一项所述的方法，其特征在于，在将所述编写好的测试数据文件复制多个之后，所述方法还包括：响应用户操作，删除一个或多个所述复制的测试数据文件。

6.根据权利要求1至4中任一项所述的方法，其特征在于，在将所述编写好的测试数据文件复制多个之后，所述方法还包括：响应用户操作，更改一个或多个所述全部测试数据文件的变量个数。

7.一种数据驱动测试系统，其特征在于，包括：

脚本文件生成装置，用于将编写好的测试数据文件与测试逻辑文件相关联形成脚本文件；

测试文件数据套件生成装置，用于将所述脚本文件中的测试数据文件复制多个，并设置全部测试数据文件中一个或多个测试数据文件的测试参数形成多个测试文件数据套件；

可执行脚本生成装置，用于分别将各个所述测试文件数据套件与所述测试逻辑文件生成可执行脚本；

脚本解释装置，用于接收来自于所述可执行脚本生成装置生成的所述可执行脚本并执行。

8.根据权利要求7所述的系统，其特征在于，

所述脚本文件生成装置，用于通过变量标识将所述编写好的测试数据文件与测试逻辑文件相关联形成脚本文件。

9.根据权利要求7或8所述的系统，其特征在于，

所述测试文件数据套件生成装置，还用于响应用户操作，删除一个或多个所述复制的测试数据文件。

10.根据权利要求7或8所述的系统，其特征在于，

所述测试文件数据套件生成装置，还用于响应用户操作，更改一个或多个所述全部测试数据文件的变量个数。