CN101770423A - 一种测试数据生成方法及测试系统 - Google Patents

Abstract

本发明公开了一种测试数据生成方法及测试系统，所述方法包括：测试系统通过加载用户选择的测试环境拓扑中包含的构成测试设备和被测设备的基础元件，生成包含所涉及基础元件的属性参数的测试脚本；其中，测试环境拓扑中包括被测设备和测试设备，且该测试设备和被测设备均由测试系统中保存的基础元件组成，每一基础元件均配置有属性参数。所述系统包括：测试环境拓扑单元、人机交互单元及测试参数生成单元。与现有技术相比，本发明不仅实现了测试数据与测试逻辑分离的问题，而且可自动生成测试数据，实现了测试数据的重用，这样简化了脚本编写难度，降低了脚本维护工作量，从而提高了自动化测试的效率。

Description

一种测试数据生成方法及测试系统

技术领域

本发明涉及通讯设备测试领域，尤其涉及一种测试数据生成方法及测试系统。

背景技术

在通讯设备的测试过程中，为了验证设备某项功能的稳定性，测试人员会人为搭建各种测试环境以模拟设备实际工作环境。因此在自动化测试过程中，开发人员在编写测试脚本时，通常会根据测试规程编写测试脚本，然后通过人工对测试内容进行分析，最后把某些可变化的参数定义为变量，形成一个测试数据配置文件，在脚本执行前配置这些参数，以达到在不同测试环境中运行同一个脚本的目的。

从目前公开的技术来看，都是采用以上类似方式来实现的，如申请号为CN200710176970.7的专利提供了一种数据驱动的单元测试方法，测试数据采用手工编写方式，增加了脚本编写的复杂度，同时面向的是大型网管软件测试领域。另外申请号为CN200510035197的专利提供了一种数据驱动的自动化测试系统及方法，其中包括一个运行参数生成模块，但该模块没有提及如何生成参数。

发明内容

本发明要解决的技术问题提供一种测试数据生成方法及测试系统，以克服现有技术中脚本编写复杂度高的缺陷。

为解决上述问题，本发明提供了一种测试数据生成方法，包括：测试系统通过加载用户选择的测试环境拓扑中包含的构成测试设备和被测设备的基础元件，生成包含所涉及基础元件的属性参数的测试脚本；其中，所述测试环境拓扑中包括所述被测设备和所述测试设备，且该测试设备和被测设备均由所述测试系统中保存的基础元件组成，每一基础元件均配置有属性参数。

进一步地，上述方法还可具有以下特征：

所述用户选择的测试环境拓扑为根据测试用例物理测试环境的要求，由相应的测试设备和被测设备组建而成的，且所述组建好的测试环境拓扑被保存到所述测试系统中的测试环境拓扑类库中。

进一步地，上述方法还可具有以下特征：

所述测试设备和被测设备为根据其各自的功能，分别由相应的基础元件组建而成的，并且组建好的被测设备和测试设备被保存到所述测试系统中的测试模块类库中。

进一步地，上述方法还可具有以下特征：

所述基础元件为对被测设备及测试设备分别进行功能抽象分解后得到的；

在得到所述基础元件后，对其进行封装，并确定各元件的属性参数，且将封装好的基础元件控件保存在所述测试系统中的基础测试元件类库中。

进一步地，上述方法还可具有以下特征：

所述测试系统通过加载用户选择的测试环境拓扑中包含的构成测试设备和被测设备的基础元件，生成包含所涉及基础元件的属性参数的测试脚本是指：当所述测试系统检测到用户发起的新建脚本命令后，加载用户选择的测试环境拓扑中包含的测试设备和被测设备中的基本元件，自动生成包含所涉及基本元件的属性参数的脚本。

本发明还提供了一种测试系统，包括：测试环境拓扑单元、人机交互单元及测试参数生成单元；

所述测试环境拓扑单元中保存有基础测试元件类库，该基础测试元件类库中保存有多个基础元件，每一基础元件均配置有属性参数；

所述人机交互单元用于为用户提供界面供用户从所述测试环境拓扑单元中选择相应的基础元件组成被测设备和测试设备，并将该组建好的测试设备和被测设备组成测试环境拓扑；

所述测试参数生成单元用于根据用户组建的测试环境拓扑中包含的构成测试设备和被测设备的基础元件，生成包含所涉及基础元件的属性参数的测试脚本。

进一步地，上述系统还可具有以下特征：

所述测试环境拓扑单元中保存有测试模块类库，所述测试模块类库用于保存用户通过所述人机交互单元组建好的测试设备和被测设备。

进一步地，上述系统还可具有以下特征：

所述测试环境拓扑单元中保存有测试环境拓扑类库，所述测试环境拓扑类库用于保存用户通过所述人机交互单元组建好的测试环境拓扑。

与现有技术相比，本发明不仅实现了测试数据与测试逻辑分离的问题，而且可自动生成测试数据，实现了测试数据的重用，这样简化了脚本编写难度，降低了脚本维护工作量，从而提高了自动化测试的效率。

附图说明

图1为本发明实施例中测试环境拓扑示意图；

图2为本发明应用实例中生成SDH告警自动化测试脚本的流程图。

具体实施方式

下面将结合附图及实施例对本发明的技术方案进行更详细的说明。

本发明所述方法的基本构思是：测试系统通过加载用户选择的测试环境拓扑中包含的构成测试设备和被测设备的基础元件，生成包含所涉及基础元件的属性参数的测试脚本；其中，测试环境拓扑中包括用户选择的被测设备和测试设备，且该测试设备和被测设备均由该测试系统中保存的基础元件组成，每一基础元件均配置有属性参数。

具体的，本发明所述方法包括以下步骤：

第一步：对被测设备及测试设备分别进行功能抽象分解，得到基础元件；

基础元件是对被测设备、测试设备进行功能颗粒单元的抽象分解后得到的产物。从编程的角度来看，一个基础元件就是一个封装好的可视化控件。通过这样抽象分解，可以达到测试环境的复用。

第二步：在测试系统中将基础元件封装为控件，确定各元件的属性参数及默认值(还可以确定元件的操作方法)，将封装好的基础元件控件保存在测试系统中的基础测试元件类库中；其中，基础测试元件类库可包括基础元件对象的导入、删除、修改、浏览、查询等维护管理功能；

第三步：根据被测设备功能及测试设备功能，在测试系统的基础测试元件类库中选择相应的基础元件组建被测设备及测试设备。通过此步骤，完成了测试设备和被测设备从物理实物到逻辑事物的映射。从编程的角度来看，将多个基础元件组建成一个测试设备或被测设备后，该设备就具有了其所包含的所有基础元件的属性；

此外，还可以将组建好的被测设备和测试设备保存到测试系统中的测试模块类库中，待下次对相同的设备进行测试时，用户可直接在测试模块类库中选择该设备即可，不用再重新选择相应基础原件进行组装；同理，该测试模块类库可包括测试设备和被测设备的新建、删除、修改、浏览、查询等维护管理功能。

第四步：根据测试用例物理测试环境的要求，将相应的组建好的测试设备和被测设备组建成测试环境拓扑；其中，测试环境拓扑是测试设备和被测设备之间的关系图，它描述了物理被测设备之间以及与测试设备之间的组网关系，完成了从物理测试环境到逻辑测试环境的映射。从编程的角度来看，测试设备和被测设备加上连线就能组成一个测试环境拓扑；

还可将该组建好的拓扑保存到测试环境拓扑类库中，待下次对相同的拓扑进行测试时，用户直接在测试环境拓扑类库中选择该拓扑即可，不用再重新选择相应的测试设备和被测设备进行组装；且该测试环境拓扑类库也具有测试环境拓扑对象的新建、删除、修改、浏览、查询等维护管理功能。

经过上述四个步骤后，即可生成测试环境拓扑供用户选择，该测试环境拓扑的结构如图1所示。

第五步：当测试系统检测到用户发起的测试命令后，根据用户选择的测试环境拓扑中包含的测试设备和被测设备中的基本元件，自动生成包含所涉及基本元件的属性参数的脚本。其中，生成的基本元件的属性参数即为测试数据。

在进行测试时，用户只需将测试逻辑添加到该脚本中，并为上述生成的测试数据赋值后，即可执行测试过程。

本发明所述系统包括：人机交互单元、测试环境拓扑单元和测试参数生成单元；

测试环境拓扑单元中保存有基础测试元件类库，该基础测试元件类库中保存有多个基础元件，每一基础元件均配置有属性参数；

人机交互单元用于为用户提供界面供用户从上述测试环境拓扑单元中选择相应的基础元件组成被测设备和测试设备，并将该组建好的测试设备和被测设备组成测试环境拓扑；

测试参数生成单元用于根据用户组建的测试环境拓扑中包含的构成测试设备和被测设备的基础元件，生成包含所涉及基础元件的属性参数的测试脚本。

进一步地，测试环境拓扑单元中还可保存测试模块类库和/或测试环境拓扑类库；其中测试模块类库用于保存用户通过人机交互单元组建好的测试设备和被测设备，测试环境拓扑类库用于保存用户通过人机交互单元组建好的测试环境拓扑。

下面用本发明的一应用实例进一步加以说明。

图2是本发明的优选实施例的SDH(Synchronous Digital Hierarchy，同步数字系列)光板告警自动化测试脚本的实现流程图，其具体实施步骤如下：

步骤201：工具开发人员根据被测设备和测试设备的形态、功能，对被测设备和测试设备进行抽象分析。

对于SDH设备来说，基础元件一般可分为机架、子架、网元控制板、时钟板、电源板、交叉板、业务板。而对于数据产品，如路由器、交换机等一体设备来说，一般不可再分。

对于SDH仪表来说，基础元件一般有仪表机框、功能测试板卡等。

在本实施例SDH光板告警测试中，用到的基础元件有机架、子架、网元控制板、光板(业务板的一种)、SDH功能测试板卡。

步骤202：工具开发人员根据测试设备的形态、功能，抽象出各种父基础元件类。

在本实例中，根据SDH设备的外观特点，抽象出机架类，其物理环境参数有机架号RackNo、容纳子架个数ShelfNum。子架类，其物理环境参数有子架号，容纳插板的个数BoardNum。

在本实例中，根据SDH设备的插板特点，抽象出单板父类，物理环境属性参数有单板槽位号SlotNo、CPU(Central Processing Unit，中央处理单元)号CpuNo、模块号ModuleNo、软件版本ProgVer、逻辑版本FpgaVer、PCB版本PCBVer、单板描述Description，操作方法有查询单板版本getVersion、复位单板resetBoard。

在本实例中，抽象出仪表机框父类，物理环境属性参数有通讯类型ComType，通讯参数ComParam。

在本实例中，抽象出仪表板卡类，物理环境属性参数有板卡描述Description，操作方法有查询板卡版本getVersion、复位板卡resetBoard、配置恢复缺省cfgDefault。

步骤203：根据测试需要，在父测试设备上封装子测试设备，并根据需要增加新的参数以及方法。

在继承单板父类的基础上封装了网元控制板类，物理环境参数增加网元IP的属性参数。

在继承单板父类的基础上封装光板类，物理环境参数增加光端口个数PortNum、光口速率PortSpeed属性参数。逻辑参数增加了Aug号、Au号、Tug3号、Tug2号、TU号、路径类型PathType以及映射类型MapMode。

在继承仪表板卡类的基础上封装了SDH光测试卡类，物理环境参数增加板卡类型BoardType、光口速率PortSpeed、激光波长WaveLength，逻辑参数增加了Aug号、Au号、Tug3号、Tug2号、TU号、路径类型PathType以及映射类型MapMode。

按照以上抽象方法，将所有的基础元件封装完毕，保存到基础测试元件类库中。

步骤204中，根据测试规程的需要，使用基础元件组成测试模块类。

在测试系统中，一个基础元件就是一个封装好的可视化控件，因此用户可以通过测试系统提供的人机交互界面对各基础元件进行随意调用。在本实施例中，对于被测设备，可先从基础测试元件类库中调用机架元件，再往机架元件上拖入子架元件，最后往子架上插入网元控制板、光板，最终组成被测对象-SDH设备，命名，保存。

在本实施例中，对于测试仪表，先从基础测试元件类库中拖入仪表机框，再往机框上拖入SDH光测试卡，最终形成SDH测试仪表，命名，保存。

按照以上方法，将测试模块组装完毕，保存到测试模块类库中。

步骤205：根据测试用例的物理测试环境的要求，从测试模块类库选择测试设备和被测设备，并使用连线，将测试设备和被测设备连接形成测试环境拓扑对象。

在本实例中，用到一个SDH设备，一个SDH测试仪，其中测试仪采用光端口，通过光纤与光板相连，命名，保存至测试环境拓扑库。

步骤206：用户选择新建脚本后，测试系统从测试环境拓扑库加载已有的拓扑，供用户选择相应的拓扑对象；

步骤207：测试参数生成单元根据用户选择的拓扑对象自动加载该拓扑所拥有的测试模块(即测试设备和被测设备)、进而加载测试模块所拥有的基础元件，并在界面上显示所有的参数名字、参数取值以及参数描述。

在本实例中，和本测试规程相关的设备物理环境参数有：机架号RackNo、子架号ShelfNo，光板槽位号SlotNo、光板Cpu号CpuNo、光板模块号ModuleNo、光板软件版本ProgVer、光板逻辑版本FpgaVer、光板PCB版本PCBVer、光板端口号PortNo、光口速率PortSpeed。

在本实例中，和本测试规程相关的仪表物理环境参数有：通讯类型ComType，通讯参数ComParam、光口速率PortSpeed、激光波长WaveLength。和本测试规程相关的设备逻辑参数有：Aug号、Au号、路径类型PathType以及映射类型MapMode。和本测试规程相关的仪表逻辑参数有：Aug号、Au号、路径类型PathType以及映射类型MapMode。

进一步的，为了达到复用的目的，界面显示所有的参数，但是有些参数是和本测试规程无关的，用户根本不关心，不用输入，所以每个参数都提供了默认值，不影响后续的参数保存和读取。

步骤208中，在脚本执行过程中，根据传入的测试拓扑对象获取相关的测试参数，然后执行测试逻辑对象。

进一步的，如果想运行一个脚本，达到同一个测试逻辑对象在不同的测试环境下的目的，只要传递不同的测试拓扑就可以了。

进一步的，如果多个脚本是在同一个测试环境下运行，只需要配置一次，可以大大节省人力。

当然，本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。

Claims (8)

1.一种测试数据生成方法，其特征在于，

测试系统通过加载用户选择的测试环境拓扑中包含的构成测试设备和被测设备的基础元件，生成包含所涉及所述基础元件的属性参数的测试脚本；其中，所述测试环境拓扑中包括所述被测设备和所述测试设备，且该测试设备和被测设备均由所述测试系统中保存的基础元件组成，每一基础元件均配置有属性参数。

2.如权利要求1所述的方法，其特征在于：

所述用户选择的测试环境拓扑为根据测试用例物理测试环境的要求，由相应的测试设备和被测设备组建而成的，且所述组建好的测试环境拓扑被保存到所述测试系统中的测试环境拓扑类库中。

3.如权利要求1所述的方法，其特征在于，

所述测试设备和被测设备为根据其各自的功能，分别由相应的基础元件组建而成的，并且组建好的被测设备和测试设备被保存到所述测试系统中的测试模块类库中。

4.如权利要求1或3所述的方法，其特征在于，

所述基础元件为对被测设备及测试设备分别进行功能抽象分解后得到的；

在得到所述基础元件后，对其进行封装，并确定各元件的属性参数，且将封装好的基础元件控件保存在所述测试系统中的基础测试元件类库中。

5.如权利要求4所述的方法，其特征在于，

所述测试系统通过加载用户选择的测试环境拓扑中包含的构成测试设备和被测设备的基础元件，生成包含所涉及基础元件的属性参数的测试脚本是指：当所述测试系统检测到用户发起的新建脚本命令后，加载用户选择的测试环境拓扑中包含的测试设备和被测设备中的基本元件，自动生成包含所涉及基本元件的属性参数的脚本。

6.一种测试系统，其特征在于，包括：测试环境拓扑单元、人机交互单元及测试参数生成单元；

所述测试环境拓扑单元中保存有基础测试元件类库，该基础测试元件类库中保存有多个基础元件，每一基础元件均配置有属性参数；

所述人机交互单元用于为用户提供界面供用户从所述测试环境拓扑单元中选择相应的基础元件组成被测设备和测试设备，并将该组建好的测试设备和被测设备组成测试环境拓扑；

所述测试参数生成单元用于根据用户组建的测试环境拓扑中包含的构成测试设备和被测设备的基础元件，生成包含所涉及基础元件的属性参数的测试脚本。

7.如权利要求6所述的系统，其特征在于，

所述测试环境拓扑单元中保存有测试模块类库，所述测试模块类库用于保存用户通过所述人机交互单元组建好的测试设备和被测设备。

8.如权利要求6或7所述的系统，其特征在于，

所述测试环境拓扑单元中保存有测试环境拓扑类库，所述测试环境拓扑类库用于保存用户通过所述人机交互单元组建好的测试环境拓扑。

Images