CN103793326A

CN103793326A - 组件测试方法及装置

Info

Publication number: CN103793326A
Application number: CN201410054826.6A
Authority: CN
Inventors: 贺宏达; 郭伟
Original assignee: Fujian Star Net Communication Co Ltd
Current assignee: Ruijie Networks Co Ltd
Priority date: 2014-01-28
Filing date: 2014-02-18
Publication date: 2014-05-14
Anticipated expiration: 2034-02-18
Also published as: CN103793326B

Abstract

本发明提供一种组件测试方法及装置。其中，组件测试方法包括：根据被测组件的测试用例编号，从预设的测试用例库中获取与测试用例编号对应的测试用例，测试用例包含：测试用例TCL脚本、测试输入数据、测试用例预期输出以及测试用例执行配置文件；将测试输入数据输入至测试用例TCL脚本，完成测试用例执行配置文件的配置；根据配置后的测试用例执行配置文件，判断测试用例是否满足预设的测试条件；若满足，则将测试输入数据发送至被测组件，以使被测组件根据测试输入数据执行逻辑处理并输出处理结果；将处理结果与测试用例预期输出进行比较，并根据比较结果生成相应的测试日志。

Description

组件测试方法及装置

技术领域

本发明涉及一种计算机技术，尤其涉及一种组件测试方法及装置。

背景技术

在计算机编程过程中，单元测试是针对程序模块的最小单元进行正确性检测的测试工作，其具有独立的规格，故也称之为组件测试。传统应用程序的组成部分是分立的文件、模块或类，这些组成部分经过编译并链接之后才形成应用程序。要想推出应用程序的新版本，就需要将这些组成部分重新编译，既费时又费力。有了组件的概念，就可以将改进后的新组建插入到应用程序中，并替换掉原有的旧组件，从而赋予应用程序新的活力。

目前，业界组件测试主流的解决方案，是基于嵌入式的自动化测试系统来实现。主要有以下几种方法：

第一种，通过硬件工具实现。利用逻辑分析仪通过对某一段时间的总线上的指令进行捕获，并以一定的频率捕获这些信号，通过对其进行分析对比，了解其运行的情况。

第二种，通过软件实现。即通过插装技术和预处理任务，在被测组件中插入操作，来实现测试目的的方法，例如向源程序中添加一些语句，实现对程序语句的执行、变量的变化等情况进行检查。

上述第一种基于硬件实现的方案，系统只能通过抽样的方法来进行测试，对有限的函数作出分析，无法灵活的满足测试的需求。第二种基于软件来实现的方案，针对源码的开发涉及到底层的封装语言，譬如C、C++等，对人员技能要求高，对被测代码编译操作繁琐，测试效率低。

发明内容

本发明提供一种组件测试方法及装置，以提高测试效率，简化测试过程。

本发明提供一种组件测试方法，包括：

根据被测组件的测试用例编号，从预设的测试用例库中获取与所述测试用例编号对应的测试用例，所述测试用例包含：测试用例工具命令语言TCL脚本、测试输入数据、测试用例预期输出以及测试用例执行配置文件；

将所述测试输入数据输入至所述测试用例TCL脚本，完成所述测试用例执行配置文件的配置；

根据配置后的所述测试用例执行配置文件，判断所述测试用例是否满足预设的测试条件；

若满足，则将所述测试输入数据发送至被测组件，以使所述被测组件根据所述测试输入数据执行逻辑处理并输出处理结果；

将所述处理结果与所述测试用例预期输出进行比较，并根据比较结果生成相应的测试日志。

本发明提供一种组件测试裝置，包括：

获取模块，用于根据被测组件的测试用例编号，从预设的测试用例库中获取与所述测试用例编号对应的测试用例，所述测试用例包含：测试用例工具命令语言TCL脚本、测试输入数据、测试用例预期输出以及测试用例执行配置文件；

输入模块，用于将所述测试输入数据输入至所述测试用例TCL脚本，完成所述测试用例执行配置文件的配置；

判断模块，用于根据配置后的所述测试用例执行配置文件，判断所述测试用例是否满足预设的测试条件；

发送模块，用于若所述判断模块判断为满足，则将所述测试输入数据发送至被测组件，以使所述被测组件根据所述测试输入数据执行逻辑处理并输出处理结果；

比较模块，用于将所述处理结果与所述测试用例预期输出进行比较，并根据比较结果生成相应的测试日志。

由上述技术方案可知，本发明提供的组件测试方法及装置，基于TCL脚本语言工具，实时向被测组件发送测试输入数据，动态地进行软件测试，灵活的满足测试的需求，不需要对被测组件进行代码编译等繁琐的操作，简化了测试过程，并较好的提升了测试执行效率。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明组件测试方法实施例一的流程图；

图2为本发明组件测试方法实施例二的流程图；

图3为本发明组件测试裝置实施例的结构示意图；

图4为本发明组件测试方法的逻辑架构图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1为本发明组件测试方法实施例一的流程图。如图1所示，本实施例提供的组件测试方法具体可以由组件测试装置执行，本实施例提供的方法具体可以包括：

步骤101、根据被测组件的测试用例编号，从预设的测试用例库中获取与所述测试用例编号对应的测试用例，所述测试用例包含：测试用例工具命令语言（Tool Command Language，简称：TCL）脚本、测试输入数据、测试用例预期输出以及测试用例执行配置文件。

步骤102、将所述测试输入数据输入至所述测试用例TCL脚本，完成所述测试用例执行配置文件的配置。

步骤103、根据配置后的所述测试用例执行配置文件，判断所述测试用例是否满足预设的测试条件。

具体的，所述测试用例执行配置文件中可以包括测试记录信息；相应的，本步骤中，组件测试装置可以查询所述测试用例执行配置文件中是否存在所述测试记录信息；若存在所述测试记录信息，则根据预设的判断规则，判断所述测试用例是否满足所述预设的测试条件。

可以理解的是，若组件测试装置查询出所述测试用例执行配置文件中不存在所述测试记录信息，则不执行后续步骤。

需要说明的是，在实际应用中，所述测试用例执行配置文件中还可以包括逻辑接口信息和逻辑拓扑信息，则所述组件测试装置在根据预设的判断规则，判断所述测试用例是否满足所述预设的测试条件时，具体可以通过获取所述被测组件的物理接口信息，判断所述物理接口信息与所述逻辑接口信息是否一致；获取所述被测组件的物理拓扑信息，判断所述物理拓扑信息与所述逻辑拓扑信息是否一致；若所述物理接口信息与所述逻辑接口信息一致，且所述物理拓扑信息与所述逻辑拓扑信息一致，则所述测试用例满足所述预设的测试条件，否则，所述测试用例不满足所述预设的测试条件。

步骤104、若满足，则将所述测试输入数据发送至被测组件，以使所述被测组件根据所述测试输入数据执行逻辑处理并输出处理结果。

步骤105、将所述处理结果与所述测试用例预期输出进行比较，并根据比较结果生成相应的测试日志。

本实施例的技术方案，通过组件测试装置根据被测组件的测试用例编号，从预设的测试用例库中获取与所述测试用例编号对应的测试用例，将所述测试输入数据输入至所述测试用例TCL脚本，完成所述测试用例执行配置文件的配置，根据配置后的所述测试用例执行配置文件，判断所述测试用例是否满足预设的测试条件，若满足，则将所述测试输入数据发送至被测组件，以使所述被测组件根据所述测试输入数据执行逻辑处理并输出处理结果，将所述处理结果与所述测试用例预期输出进行比较，并根据比较结果生成相应的测试日志。本实施例基于TCL脚本语言工具，可以实时向被测组件发送测试输入数据，动态地进行软件测试，灵活的满足测试的需求，不需要对被测组件进行代码编译等繁琐的操作，简化了测试过程，并较好的提升了测试执行效率。

图2为本发明组件测试方法实施例二的流程图。如图2所示，本实施例提供的方法具体可以包括：

步骤201、运行测试驱动模块中的主要程序。

其中，测试驱动模块中的主要程序为Main.tcl。

步骤202、加载TCL自动化公共库。

其中，TCL自动化公共库即为TCL公共函数的集合，该TCL公共函数的集合包含：命令配置函数、结果判断函数、测试框架设置及判断函数等。

步骤203、从测试用例库中读取所有相关数据库并初始化所读取的所有相关数据库。

其中，所有相关数据库可以包括物理拓扑数据库，即测试用例执行配置文件库、测试脚本信息数据库、产品差异指标数据库。

初始化所读取的所有相关数据库可以保持在进行组件测试的过程中，被测环境的干净，先后执行的测试用例不会被干扰，从而保证测试的准确性。

由于在组件测试过程中，针对不同的产品，即针对不同的被测组件，组件测试装置需要准备的测试环境、配置以及应用的全局变量都不同，因此，在实际应用过程中，初始化所读取的所有相关数据库时，主要是针对被测组件的测试环境、被测试设备的测试配置以及在对被测组件进行测试时需要应用的全局变量等进行初始化操作，以区分不同产品的测试环境、拓扑信息以及应用的全局变量。

步骤204、连接被测组件（Device Unit Test，简称：DUT）。

具体的，TCL自动化公共库完成所有相关数据库的加载后，需要对被测组件进行连接并判断连通性；通过调用系统内部相应的命令，如，通过创建套接字（create socket），并根据测试用例执行配置文件中的配置参数，即，被测组件以及辅测组件的拓扑信息、产品名称和相关功能的开关等，来实现对被测组件的连接。

步骤205、初始化DUT。

具体地，在完成与被测组件的连接后，可以通过向被测组件发送初始化指示信息指示被测组件进行初始化，被测组件在接收到初始化指示信息后，可以根据预期的产品形态，对全局变量配置、接口配置进行初始化设置。

步骤206、查询测试用例执行配置文件中是否存在测试记录信息。

若查询结果为是，则进入步骤207；否则，进入步骤208.

其中，测试记录信息具体可以为测试用例编号，亦即需要进行测试的测试用例。

步骤207、判断是否满足测试条件，若是，完成测试；若否，返回步骤206。

具体的，若判断结果为是，则加载测试对象文件，即测试用例执行配置文件；进行设备检查，即，判断物理接口信息与逻辑接口信息是否一致；进行变量初始化，即对全局变量，如产品的指标参数、差异性参数的应用；进行拓扑检查，即判断物理拓扑信息与逻辑拓扑信息是否一致；进行配置初始化，即，由被测组件的测试用例执行初始化配置；进行测试执行，即，根据相应的测试用例TCL脚本中的测试内容，实现配置DUT、设置测试仪端口的帧格式、控制测试仪收发帧、检测测试仪端口的帧收发情况、对结果进行判断等功能，并输出测试记录信息，并生成相应的测试日志；进行配置还原，即，将配置还原为初始配置，避免在多个测试执行时，因配置未清空而导致的测试失败。

具体的，本步骤中检查的测试条件包含：用例的名称、测试用例的编号、测试描述、测试top、产品形态、全局变量使用情况等；若有一项参数与预期不符，将视为不满足，退出执行。

步骤208、断开DUT关联，还原初始化测试环境，结束。

下面结合图4，以进行A功能的全局使能开关功能测试为例对本发明提供的组件测试方法的实现过程和原理作进一步的说明，以帮助理解本发明。

首先，为功能测试创建测试用例，例如：

创建的测试用例TCL脚本为：tc_mode_a_enable.tcl；

创建的测试用例编号为：TC_MODE_A_ENABLE_001。

创建的测试输入数据为：input_param=true/false。

创建的测试用例预期输出为：output_param=true/false。

创建的测试用例执行配置文件为：cfg_A.tcl

测试驱动模块根据被测组件的测试用例编号，从测试用例库中获取与测试用例编号对应的测试用例，即，获取到测试用例编号为TC_MODE_A_ENABLE_001的测试用例中的测试输入数据，将从测试输入数据输入至测试用例TCL脚本tc_mode_a_enable.tcl，完成测试用例执行配置文件cfg_A.tcl的配置和更新。

其中，cfg_A.tcl是物理拓扑配置文件，cfg_A.tcl中可以包括产品信息、接口定义、测试记录信息（Testcase）等。在执行本实施例提供的组件测试方法的过程中，需要对cfg_A.tcl进行配置；若之前已经存在cfg_A.tcl，则可以根据实际的测试需求，更新此文件，进行新一轮的测试。该文件可以通过外部的简单文件传输协议（Trivial File Transfer Protocol，简称：TFTP），安全外壳协议（Secure Shell，简称：SSH），异步文件传输协议（xmodem）等方式进行用例管理，亦可以在系统内部通过文本编译器（vi）进行更新。

接着，通过tclsh执行tclsh main.tcl，完成TCL自动化测试框架调用，包含：公共库的调用、环境检查、测试记录信息检查、读取cfg文件等，继而将测试输入数据通过domain_client消息的方式发送给进程通讯模块。

其中，对环境和测试用例的检查，由公共库中的公共函数来完成。测试环境包含了物理拓扑信息和逻辑拓扑信息。

进程通讯模块收到测试输入数据后，与A功能模块内的socket库进行通讯，实现TCL与A功能的数据通讯，所有的测试输入数据送往被测组件的命令解析模块进行解析。

命令解析模块通过swing工具将测试输入数据转换为源代码内部的数据结构，并将转换后的数据传输到被测组件的命令处理模块进行逻辑处理，并将测试结果转换成测试输入数据的数据格式，并将测试结果输出至结果判断模块，结果判断模块基于测试用例TCL脚本运行环境，将接收到的测试结果与测试用例库中存储的测试用例预期输出进行比较，得出判断结果。

若测试用例预期输出为全局开关开启（true）,测试结果也是true，则结果判断模块的判断结果为通过；若测试用例预期输出为true，而测试结果为全局开关关闭（false），则结果判断模块的判断结果为未通过。

结果判断模块得出判断结果后，将A功能的测试结果输出到测试用例TCL脚本tc_mode_a_enable.tcl中，TCL自动化框架将测试结果输出到相应的测试目录下，并生成相应的测试日志，完成A功能的测试。

本实施例的技术方案，可以提高测试效率，简化测试过程。

图3为本发明组件测试裝置实施例的结构示意图。参照图3及图4，本实施例提供的组件测试装置10可以包括：获取模块11、输入模块12、判断模块13、发送模块14以及比较模块15。

其中，获取模块11用于根据被测组件的测试用例编号，从预设的测试用例库中获取与所述测试用例编号对应的测试用例，所述测试用例包含：测试用例TCL脚本、测试输入数据、测试用例预期输出以及测试用例执行配置文件；输入模块12用于将所述测试输入数据输入至所述测试用例TCL脚本，完成所述测试用例执行配置文件的配置；判断模块13用于根据配置后的所述测试用例执行配置文件，判断所述测试用例是否满足预设的测试条件；发送模块14用于若所述判断模块13判断为满足，则将所述测试输入数据发送至被测组件，以使所述被测组件根据所述测试输入数据执行逻辑处理并输出处理结果；比较模块15用于将所述处理结果与所述测试用例预期输出进行比较，并根据比较结果生成相应的测试日志。

具体的，所述测试用例执行配置文件中可以包括测试记录信息；相应的，所述判断模块13具体可以用于查询所述测试用例执行配置文件中是否存在所述测试记录信息；若存在所述测试记录信息，则根据预设的判断规则，判断所述测试用例是否满足所述预设的测试条件。

进一步，所述测试用例执行配置文件中还可以包括逻辑接口信息和逻辑拓扑信息；相应的，所述判断模块13具体可以用于获取所述被测组件的物理接口信息，判断所述物理接口信息与所述逻辑接口信息是否一致；获取所述被测组件的物理拓扑信息，判断所述物理拓扑信息与所述逻辑拓扑信息是否一致；若所述物理接口信息与所述逻辑接口信息一致，且所述物理拓扑信息与所述逻辑拓扑信息一致，则所述测试用例满足所述预设的测试条件，否则，所述测试用例不满足所述预设的测试条件。

可以理解的是，本实施例的获取模块11可以对应于上述实施例中的测试驱动模块，输入模块12可以对应于上述实施例中的进程通讯模块，判断模块13以及发送模块14可以对应于上述实施例中的命令解析模块，比较模块15可以对应于上述实施例中的结果判断模块。即，通过本实施例的组件测试装置实现组件测试时，也可以通过测试驱动模块从预设的测试用例库中获取与测试用例编号对应的测试用例，再由进程通讯模块将测试输入数据输入至测试用例TCL脚本，完成测试用例执行配置文件的配置，被测组件中的命令解析模块根据配置后的测试用例执行配置文件，判断测试用例是否满足预设测试条件，若满足，则根据测试输入数据执行逻辑处理并输出处理结果至结果判断模块，结果判断模块将接收到的处理结果与测试时用例预期输出进行比较，根据比较结果生成相应的测试日志，保存至测试用例库中。

本实施例的组件测试装置，可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

在本发明所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或处理器（processor）执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（Read-Only Memory，ROM）、随机存取存储器（Random Access Memory，RAM）、磁碟或者光盘等各种可以存储程序代码的介质。

本领域技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims

1.一种组件测试方法，其特征在于，包括：

2.根据权利要求1所述的方法，其特征在于，所述测试用例执行配置文件中包括测试记录信息；

相应的，所述根据配置后的所述测试用例执行配置文件，判断所述从测试用例是否满足预设的测试条件，包括：

查询所述测试用例执行配置文件中是否存在所述测试记录信息；

若存在所述测试记录信息，则根据预设的判断规则，判断所述测试用例是否满足所述预设的测试条件。

3.根据权利要求2所述的方法，其特征在于，所述测试用例执行配置文件中还包括：逻辑接口信息和逻辑拓扑信息；

相应的，所述根据预设的判断规则，判断所述测试用例是否满足所述预设的测试条件，包括：

获取所述被测组件的物理接口信息，判断所述物理接口信息与所述逻辑接口信息是否一致；

获取所述被测组件的物理拓扑信息，判断所述物理拓扑信息与所述逻辑拓扑信息是否一致；

若所述物理接口信息与所述逻辑接口信息一致，且所述物理拓扑信息与所述逻辑拓扑信息一致，则所述测试用例满足所述预设的测试条件，否则，所述测试用例不满足所述预设的测试条件。

4.一种组件测试裝置，其特征在于，包括：

5.根据权利要求4所述的装置，其特征在于，所述测试用例执行配置文件中包括测试记录信息；

相应的，所述判断模块具体用于查询所述测试用例执行配置文件中是否存在所述测试记录信息；若存在所述测试记录信息，则根据预设的判断规则，判断所述测试用例是否满足所述预设的测试条件。

6.根据权利要求5所述的装置，其特征在于，所述测试用例执行配置文件中还包括：逻辑接口信息和逻辑拓扑信息；

相应的，所述判断模块具体用于获取所述被测组件的物理接口信息，判断所述物理接口信息与所述逻辑接口信息是否一致；获取所述被测组件的物理拓扑信息，判断所述物理拓扑信息与所述逻辑拓扑信息是否一致；若所述物理接口信息与所述逻辑接口信息一致，且所述物理拓扑信息与所述逻辑拓扑信息一致，则所述测试用例满足所述预设的测试条件，否则，所述测试用例不满足所述预设的测试条件。