CN1790957A - 设备测试方法 - Google Patents

Abstract

本发明公开了一种设备测试方法，所述方法包括：通过TCL脚本建立测试脚本库；建立被测设备的硬件配置表；根据测试脚本库及硬件配置表生成测试用例；根据测试用例对所述设备进行测试。利用本发明，可以简化测试用例的设计，增强测试脚本的通用性，方便地适应不同设备及设备不同版本的测试，提高测试效率。

Description

设备测试方法

技术领域

本发明涉及设备测试技术领域，具体涉及一种设备测试方法。

背景技术

目前，在测试中使用测试脚本来实现测试的自动化，已经是业界普遍采用的方法。该方法通过被测设备数据口的输入输出，编写测试用例脚本，通过执行测试用例脚本实现测试数据的自动输入和输出，以及数据正确性的自动判断。在这种实现方式下，每个测试脚本都需要对应一个具体的测试用例。这种测试脚本的实现方法，在测试规模小，测试用例少的时候有其优点：实现起来方便快捷。

然而对于复杂***的测试，测试脚本也变得越来越复杂，脚本规模动辄数千行，这样庞大的脚本规模为其正确性、可维护性、易用性带来较大问题，因而测试脚本设计的好坏直接关系到测试的质量及效率。一个设计较好的测试脚本，可以有效地提高测试效率，保证测试质量。测试脚本设计得不好则可能会对产品的测试产生重大的影响，甚至导致测试无法进行。

可见，当测试规模变得越来越大，产品版本层出不穷时，这种以具体的测试用例来编写测试脚本的方式的缺陷就更加突出，主要体现在以下几点：

1、测试脚本随着用例的增加而越来越大，没有层次，臃肿难懂，脚本的正确性不能得到较好的保证；

2、测试脚本的可维护性不好；

3、测试脚本通用性不高，移植性较差，当测试配置发生变化或者产品的配置命令改变时，测试脚本都面临着较大的改变。

发明内容

本发明的目的在于解决现有技术中由于测试脚本依赖具体的测试用例建立而使其维护性及通用性较差的问题，提供一种设备测试方法，以方便地适应不同设备及设备不同版本的测试，提高测试效率。

为此，本发明提供如下的技术方案：

一种设备测试方法，包括：

A、通过TCL脚本建立测试脚本库；

B、建立被测设备的硬件配置表；

C、根据所述测试脚本库及所述硬件配置表生成测试用例；

D、根据所述测试用例对所述设备进行测试。

所述步骤A包括：

A1、封装各种设备的人机语言接口命令及调试命令；

A2、建立基本功能测试脚本。

所述基本功能测试脚本包括：进入人机语言接口测试模式脚本、创建编解码通道、回波抵消通道脚本、创建时分多路复用连接脚本、释放时分多路复用连接脚本、查询设备工作状态脚本、查询设备主备状态脚本、设备复位脚本、设备下电脚本、设备倒换脚本。

所述测试脚本库以函数包的形式提供。

所述步骤B包括：

B1、利用所述被测设备的查询命令扫描被测设备并获取所述被测设备的硬件配置信息；

B2、根据所述获取的硬件配置信息生成硬件配置表。

所述硬件配置信息包括：单板框号、槽位号、板组号、单板类型、状态。

所述步骤B2具体为：通过递归的查找算法生成所述硬件配置表。

所述硬件配置表为文本文件。

由以上本发明提供的技术方案可以看出，本发明通过引入被测设备的硬件配置表，将硬件配置信息集中管理，在测试用例中不再涉及被测设备的具体配置信息，将测试用例和测试配置分离设计，大大拓展了测试用例的通用性，在设备的配置发生改变时，不必频繁地修改测试用例。并且利用TCL的自动执行特点，使硬件配置表由测试脚本自动生成，不会增加额外的工作量，提高了测试用例的实现效率。

本发明还通过建立测试脚本库，将脚本库集中管理。在测试脚本库中，不涉及具体的测试操作，即实现用例和测试设计分离，保证了测试设计的通用性。通过对脚本库的维护，极大地提高了测试脚本的可移植性，并保证在产品型号、版本及配置命令经常变化的情况下使测试脚本的变动最小，有效地实现了测试脚本的重用，降低了脚本的规模，进而提高了测试效率。

附图说明

图1是本发明方法的流程图；

图2是本发明方法中测试脚本架构示意图；

图3是本发明方法中自动生成硬件配置表的实现流程图；

图4是本发明方法中使用递归算法生成硬件配置表的详细流程图；

图5是单板上下电可靠性测试用例的实现流程图；

图6是测试脚本库中的ShutBoardPowerTest函数的实现流程图；

图7是时分多路复用交换配置功能测试用例的实现流程图；

图8是利用本发明方法进行设备测试的组网图；

图9是图8所示通过测试仪器对设备进行监测时测试过程实现的流程图。

具体实施方式

本发明的核心在于根据测试配置经常发生变化的特点，将测试用例和测试配置分离设计，并利用TCL自动执行的特点，通过脚本扫描被测设备，从而生成被测设备的硬件配置表；将测试用例编写时需要的各种基本功能通过测试脚本库的方式进行封装，在建立实际被测设备的测试用例时，只需将硬件配置表中的配置信息作为输入参数调用测试脚本库中的这些基本功能函数，即可建立相应的测试用例，然后通过建立的测试用例完成相应的测试。

为了使本技术领域的人员更好地理解本发明方案，下面结合附图和实施方式对本发明作进一步的详细说明。

参照图1，图1是本发明方法的流程图，包括以下步骤：

步骤101：通过TCL脚本建立测试脚本库。

在测试脚本库的建立中，需要封装各种设备的人机语言命令及调试命令；同时，还要建立基本功能测试脚本。比如：进入人机语言测试模式脚本、创建TC、EC通道脚本、创建TDM(时分多路复用)连接脚本、释放TDM连接脚本、查询设备工作状态脚本、查询设备主备状态脚本、设备复位脚本、设备下电脚本、设备倒换脚本等。

测试脚本库实际上是一个测试函数封装的集合，每一个函数定义了输入和输出参数，提供给测试用例调用。从形式上，测试脚本库分为两层，底层是将产品所有常用的MML(人机语言)命令以及调试命令封装在一起，供其他的测试函数调用；上层是各种基本功能的测试函数，如进入MML测试模式；创建TC(编解码通道)、EC(回波抵消通道)；创建TDM连接配置；释放TDM连接配置；查询设备工作状态；查询设备主备状态；设备复位；设备下电；设备倒换等，这种测试函数就是一个个的基本功能的集合。在测试脚本库中，封装了测试用例编写时需要的各种基本功能。这样，当设备的MML命令格式频繁变动时，在测试脚本库中只需修改相应的底层封装函数即可，不必修改很多的地方。

步骤102：利用被测设备的查询命令(即封装到测试脚本库中的MML命令)扫描被测设备并获取被测设备的硬件配置信息，包括：单板框号、槽位号、板组号、单板类型、状态。

步骤103：根据获取的硬件配置信息生成硬件配置表。

本技术领域人员知道，对于硬件测试而言，有时经常需要判断具体的硬件配置，比如在测试用例中需要建立一个TDM的连接，这样会涉及到具体的两个TDM连接单板的框号，槽位号，板组号等信息，而这些信息在硬件测试过程中，经常需要变动，因此，为了保证硬件测试用例的稳定性，本发明方法设计了使用硬件配置表的方法。在测试用例中仅仅使用一个虚拟的单板名称来代替实际单板，这块单板的具体硬件配置信息，使用硬件配置表中来保存。这样在测试用例中，可以屏蔽掉具体的硬件配置信息，保证配置经常改变时，只要虚拟单板名称不变，测试用例就不需要修改。

在本发明中，可以自动生成被测设备的硬件配置表，并将自动生成硬件配置表的函数同样封装在测试脚本库中。

获取产品硬件配置的基本思路是先利用产品的查询命令扫描被测设备，获取设备的硬件配置信息，然后根据该硬件配置信息建立被测设备的硬件配置表，并以文本的形式输出。

在生成硬件配置表时可以采用递归的查找算法。具体过程如下：

首先，扫描被测设备，获取当前设备的硬件配置信息，包括各个框、各个槽位配置的单板类型、是否安装以及工作状态等信息。

然后，根据获取的物理硬件配置，归纳各槽位的单板状态，即对各槽位的单板建立索引和排序，按照单板名称先后顺序保存为文本文件，即硬件配置表。每一个单板对应一个虚拟板名，自动生成的硬件配置表中可以按照以下原则设置虚拟板名：

板类型_序号，如TCU_0，TCU_1等，序号的排序原则为框号槽位号越小，序号越小，序号从0开始。

虚拟板名可以由用户直接在硬件配置表中修改，只要保持测试用例中的虚拟板名和硬件配置表中的虚拟板名一致即可。

这样，在生成测试用例需要使用产品的硬件配置信息时，就可以采用虚拟板名的方法来查询硬件配置表，得到具体的硬件配置信息。

通过上述方式就可以使测试用例不涉及具体产品的调试和配置命令，可以在一种更高层次上描述测试过程，从而使测试用例具有较强的扩展性，适应于各种不同设备的测试。

步骤104：根据测试脚本库及硬件配置表生成测试用例。

在生成测试用例时，测试脚本库以函数包的形式提供，也就是说，根据被测设备的硬件配置表，将实际配置信息转换为入口参数，然后以函数包的形式调用测试脚本库中相应功能的测试脚本，生成所需的测试用例，进行设备测试，通过测试脚本的执行结果获得设备的测试结果。

步骤105：根据测试用例对设备进行测试。

图2示出了本发明中测试脚本架构：

由该图可见，本发明使用测试脚本库，将测试设计集中管理，该测试脚本库提供通用的测试脚本，不涉及具体的测试操作，保证了测试设计的通用性，即实现测试用例和测试设计分离。同时，通过硬件配置表实现测试用例和测试配置的分离设计。测试用例中使用的虚拟板名通过硬件配置表得到具体的配置，并通过调用测试脚本库中的函数生成具体的测试用例。

本发明的测试脚本的设计方法，可以使用TCL脚本语言来实现。

本技术领域人员知道，TCL(Tool Command Language)是一种解释执行的脚本语言。它提供了通用的编程能力：支持变量、过程和控制结构；同时TCL还拥有一个功能强大的固有的核心命令集。TCL具有良好的可扩展性，可以很好地适应产品测试的需要。因此，通过TCL脚本实现本发明的核心思想，使本发明方法的设计可以用在各种不同设备的测试上。

TCL自动测试工具可以有多种，其实现是在基本TCL解释器的基础上，扩充了一些测试中常用功能，如发送信息到测试端口上等功能来实现。因为基本TCL的解释器都是一样的，对TCL的标准命令都能支持，因此通过简单的修改测试脚本库，可以将不同工具中常用的扩展命令形式修改一下即可方便的实现测试工具平台的移植，而测试用例的实现基本是不需要修改的。

图3是本发明方法中自动生成硬件配置表的实现流程，包括以下步骤：

步骤301：利用设备提供的查询命令对设备的所有硬件配置进行查询，并将查询到的信息以一定的数据结构存储在一个TCL的列表umgcfg中。

Umgcfg列表的结构可以设置为{单板1的板类型，硬件配置，单板2的板类型，硬件配置，......}。

步骤302：使用TCL的llength命令获取Umgcfg列表的长度umgbrdnumber，以便在后面利用递归算法生成硬件配置表时使用。

步骤303：进行文件操作，利用TCL的info命令获取当前脚本目录，并将其设置为当前目录。

步骤304：在当前目录下建立硬件配置文件UMG_CFG.TXT，也就是说，将该配置文件与测试脚本库中的脚本放在同一目录下。

在该文件中，可先打印必要的注释信息，包括文件建立的时间、被测设备型号等。

步骤305：使用递归算法实现umgcfg中单板的索引和排序，使用虚拟板名一一对应物理单板的配置，并将虚拟板名和具体的物理配置的对应关系以一定的格式打印到UMG_CFG.TXT文件中，生成硬件配置表。

上述使用递归算法生成硬件配置表的详细流程如图4所示，包括以下步骤：

步骤401：将设备所有可支持的单板类型定义在列表umgbrd中，并设置代表列表umgbrd中元素位置的变量i＝0。

步骤402：取出列表umgbrd中的第i个元素。

步骤403：定义列表umgcfgtemp1，并将该列表赋值为umgcfg，设置变量k＝0。

步骤404：定义while{1}循环。

步骤405：用TCL的列表搜索命令进行列表中单板类型匹配。

比如，使用如下的语句进行列表中单板类型的匹配：set result[lsearch$umgcfgtemp1 $umgboardname]。

如果返回值result为-1，即没有匹配到，则进到步骤406：跳出while循环。

然后，进到步骤407：将i加1。

步骤408：判断i是否大于umgbrd的长度。

如果i大于umgbrd的长度，表明对umgbrd中的所有内容都已检查完毕，此时，进到步骤409：退出。

否则，返回步骤402：取出列表umgbrd中的第i个元素继续进行整理，直到整理完umgbrd中的所有单板类型。

如果返回值result为0，即匹配到板类型，则进到步骤410：根据返回值获取单板的类型及硬件配置信息，并以一定的格式输出到文件UMG_CFG.TXT中。

从umgcfg列表中result位置开始依次取出板类型、框号、槽位号、前后插特性、板组号等所有的具体硬件配置信息，并打印到UMG_CFG.TXT文件中，格式如下：

BoardName＝$myboardname

FrameNo＝$myframe

SlotNo＝$myslot

Bp＝$mybp

BN＝$myBN

其中，myboardname为板名_k的形式，即虚拟板名。在测试用例中使用该虚拟板名来索引具体的单板，框号、槽位号等的值直接从umgcfg中读取。

然后，进到步骤411：定义temp为列表umgbrd中当前查找操作的单板的后一个单板起始位置。同时，定义umgcfgtemp2，赋值为umgcfgtemp1列表中从temp到结尾的部分，并将k加1。

进到步骤412：将umgcfgtemp1赋值为umgcfgtemp2。

然后，返回步骤404：重新开始while循环。

下面以一具体实例详细说明上述递归整理过程：

假设umgbrd为{E32 ECU OMU}，

umgcfg为{E32  0  12  1  1

         OMU  1  7  0  0

         E32  1  3  1  0}。

定义一个循环，开始将umgcfgtemp1赋为umgcfg，即umgcfgtemp1为{E32 012 1 1 OMU 1 7 0 0 E32 1 3 1 0}。

此时，从umgbrd中取出第一个元素，即E32，然后在umgcfgtemp1中从头开始搜索E32，搜索结果赋给result。由于umgcfg中也有E32元素，位于umgcfg的第0个位置，所以result返回值为0，则从umgcfg的第0个位置开始，依次读出E32，0，12，1，1，共5个元素，则在UMG_CFG.TXT文件中打印如下内容：

BoardName＝E32_0

FrameNo＝0

SlotNo＝12

Bp＝1

BN＝1

然后，设置umgcfgtemp2为umgcfgtemp1中result后的板名开始的一个列表，本例中umgcfgtemp2为{OMU  1  7  0  0

                E32  1  3  1  0}。

另外，设置umgcfgtemp1为umgcfgtemp2的内容，即umgcfgtemp1为{OMU 17 0 0 E32 1 3 1 0}，然后，回到开始，重复上述的查找过程，对umgcfgtemp1仍然查找E32，又可以查找到E32的result为5，依次读出E32 1 3 1 0，在UMG_CFG.TXT中打印如下的内容：

BoardName＝E32_1

FrameNo＝1

SlotNo＝3

Bp＝1

BN＝0

然后，设置umgcfgtemp2为umgcfgtemp1中result后的板名开始的一个列表，由于刚才已经到了最后，所以此时umgcfgtemp2为空列表。然后将umgcfgtemp1赋为umgcfgtemp2，即空列表，在此列表中查找E32，查找不到，返回result为-1，此时，跳出循环。

从umgbrd中取出第二个元素，即ECU，又定义一个循环，umgcfgtemp1被赋值为umgcfg列表，然后在umgcfgtemp1中查找ECU，查找不到，返回result为-1，跳出循环。

依照上述查找方式，直到将umgbrd中的所有元素都查找一遍。

最后，生成的UMG_CFG.TXT文件为如下所示：

####################################################

#Auto creat this file time：2004-10-08 15:42:24

#this file is used by umg8900 test！

#You can modify this file with your need

#begin

#UMG8900 hardware config is：

BoardName＝E32_0

FrameNo＝0

SlotNo＝12

Bp＝1

BN＝1

BoardName＝E32_1

FrameNo＝1

SlotNo＝3

Bp＝1

BN＝0

BoardName＝OMU_0

FrameNo＝1

SlotNo＝7

Bp＝0

BN＝0

#end

####################################################

有了测试脚本库以及硬件配置表，测试用例设计就变得比较简单了。下面将举例详细描述单板上下电可靠性测试和TDM交换功能测试的两个测试用例实现流程。

参照图5，图5是本发明方法中单板上下电可靠性测试用例的实现流程：

步骤501：利用标准TCL的包获取命令package，声明使用测试脚本库。

步骤502：调用测试脚本库中的ShutBoardPowerTest函数，输入参数为需要测试单板的虚拟板名及测试次数等。

步骤503：根据函数的返回值获得测试结果。

如果返回值为0，则表明上下电测试成功，打印成功信息，测试结束；否则，打印测试成功失败信息。

在测试用例文件中首先获取测试脚本库的包，在调用脚本库中的函数时，使用名字空间的方式调用。上面测试用例的例子是上下电测试，调用脚本库中的ShutBoardPowerTest函数，使测试用例变得很简洁，一目了然，整个测试脚本的分层结构也很清晰。ShutBoardPowerTest函数可以同时支持***中各种单板的测试使用，有效地提高测试设计的可重用性及可维护性等。

ShutBoardPowerTest函数的实现流程如图6所示：

首先，在步骤601：调用名字转换函数将输入的虚拟板名转换为实际的配置信息，获取单板的槽位号、框号、板组号等。

步骤602：调用获取单板状态函数，判断当前设备的主控制板的操作状态和主备状态。

步骤603：调用进入单板虚拟串口的函数，进入主用的主控板的虚拟串口。

步骤604：在主控板的虚拟串口上调用调试命令，控制被测试单板的下电和上电。根据实际设备的不同，可能通过主用主控板的虚拟串口调用调试命令，也可能通过设备的实际串口调用调试命令。

步骤605：调用获取单板状态的函数，获取被测试单板在上电后运行状态是否正常，正常则返回0，否则返回其他的值。

参照图7，图7是本发明方法中TDM(时分多路复用)交换配置功能测试用例的实现流程：

步骤701：利用标准TCL的包获取命令package，声明使用测试脚本库。

步骤702：利用设备提供的MML(人机语言)操作维护接口，通过脚本下发命令进入MML操作维护模式。

步骤703：通过脚本下发命令建立一个中继的TDM交换连接配置。

在该交换连接配置的建立中，需要设置一个0至30的循环，分别建立TDM交换连接配置。

建立中继交换连接配置使用测试脚本库中的函数ConnetTdmToTdm。ConnetTdmToTdm的输入参数为建立连接的虚拟板名和连接的中继号等，该函数实际上是调用了设备MML操作维护接口下提供的配置TDM连接的操作命令。

步骤704：在上述每个循环中分别判断每一次交换连接配置的返回值，如果为1，则表示TDM连接配置失败，停止执行测试用例；否则，显示TDM交换配置成功的信息。

步骤705：全部交换完成后，显示测试用例执行成功，完成配置。

TDM交换测试主要调用脚本库中的ConnectTdmToTdm函数。ConnectTdmToTdm函数同样可以支持***中各种TDM单板之间TDM交换的测试使用，有效地提高了测试设计的可重用性及可维护性等。ConnectTdmToTdm主要通过调用设备提供的建立TDM连接的MML命令实现，方法和上面的测试函数ShutBoardPowerTest的实现类似，在此不再赘述。

其他功能测试用例，比如，进入MML测试模式、创建TC、EC通道、释放TDM连接、查询设备工作状态、查询设备主备状态、设备复位、设备倒换等，其实现过程与上述类似，在此也不再赘述。

在对产品进行测试时，业务层面的监控可以通过测试仪器监控，目前常用测试仪器如网络测试仪等，都支持TCL控制，提供相应的TCL软件包和说明文档，因此可以将仪器控制和测试结合起来，实现在测试时对业务的监控。

测试组网图如图8所示：计算机通过TCL实现对网络测试仪的监控。

测试一般流程如图9所示，这个过程可以全部通过TCL脚本实现，实现测试的自动化。

步骤901：计算机下发配置命令到被测设备，将被测设备配置为需要测试的状态。

步骤902：计算机下发配置命令到网络测试仪，将测试仪配置为需要的测试配置状态。

步骤903：计算机下发配置命令到被测设备，启动测试过程并控制设备进行相应的操作。

步骤904：计算机下发配置命令到网络测试仪，读取设备操作时引起的业务状态变化信息。

TCL良好的可扩展性使得它能很好地适应产品测试的需要，测试任务常常会由于设计和需求的改变而迅速改变，往往让测试人员疲于应付。本发明利用TCL的可扩展性，通过测试脚本库对不涉及具体操作的通用测试脚本统一管理，将测试配置与测试用例分离设计，简单方便地生成不同环境下的测试用例，使本发明具有很强的扩展性，稍加变化即可将本发明应用于不同设备的测试，进而提高设备开发效率，节省人力成本。

虽然通过实施例描绘了本发明，本领域普通技术人员知道，本发明有许多变形和变化而不脱离本发明的精神，希望所附的权利要求包括这些变形和变化而不脱离本发明的精神。

Claims (8)

1、一种设备测试方法，其特征在于，所述方法包括：

A、通过TCL脚本建立测试脚本库；

B、建立被测设备的硬件配置表；

C、根据所述测试脚本库及所述硬件配置表生成测试用例；

D、根据所述测试用例对所述设备进行测试。

2、根据权利要求1所述的设备测试方法，其特征在于，所述步骤A包括：

A1、封装各种设备的人机语言接口命令及调试命令；

A2、建立基本功能测试脚本。

3、根据权利要求2所述的设备测试方法，其特征在于，所述基本功能测试脚本包括：进入人机语言接口测试模式脚本、创建编解码通道、回波抵消通道脚本、创建时分多路复用连接脚本、释放时分多路复用连接脚本、查询设备工作状态脚本、查询设备主备状态脚本、设备复位脚本、设备下电脚本、设备倒换脚本。

4、根据权利要求1所述的设备测试方法，其特征在于，所述测试脚本库以函数包的形式提供。

5、根据权利要求1所述的设备测试方法，其特征在于，所述步骤B包括：

B1、利用所述被测设备的查询命令扫描被测设备并获取所述被测设备的硬件配置信息；

B2、根据所述获取的硬件配置信息生成硬件配置表。

6、根据权利要求5所述的设备测试方法，其特征在于，所述硬件配置信息包括：单板框号、槽位号、板组号、单板类型、状态。

7、根据权利要求6所述的设备测试方法，其特征在于，所述步骤B2具体为：通过递归的查找算法生成所述硬件配置表。

8、根据权利要求1所述的设备测试方法，其特征在于，所述硬件配置表为文本文件。

Images