CN105634838A - 用于协议栈表管理的测试方法、装置及系统 - Google Patents

Abstract

本发明公开了一种用于协议栈表管理的测试方法、装置及系统，所述方法包括：依据接收的测试指令读取测试用例及触发协议数据的模拟打桩，等待一预设延迟时间后，下发模拟输出请求消息；获取响应得到的模拟输出请求结果，并将模拟输出请求结果与期望输出结果的内容作比对，并据此输出测试结果。采用本发明，能有效减少测试用时，提高测试效率，同时使得测试粒度更小，故障定位能力更强。

Description

用于协议栈表管理的测试方法、装置及系统

技术领域

本发明涉及通信技术领域，具体而言，涉及一种用于通信设备协议栈中表管理的测试方法、装置及系统。

背景技术

现代通信设备采用控制层面与转发层面相分离的架构，以路由器为例，控制层面主要负责路由的控制与计算，而转发层面主要负责报文流量的转发。在控制层面上，一方面其运行着各种协议，例如典型的有：路由协议、MPLS(Multi-ProtocolLabelSwitching，多协议标签交换)协议等；另一方面存在大量的表管理模块，典型的如：路由表、LSP(LabelSwitchedPath，标签交换路径)表、TE(TrafficEngineering，流量工程)表等，这些表管理模块接收协议计算得到的数据，整合后将表项下发给转发层面用于报文转发。

目前，常规的通信设备自动化测试方法主要为：通过自动化测试系统自动连接到被测设备，对被测设备进行自动配置，协议收敛完毕后通过PING或TRACE等方式对配置结果进行功能性校验。这种基于配置的自动化测试方法在实践中通常还存在以下问题：

1)在实际测试过程中需要利用多台通信设备来模拟测试场景，设备配置过程中需要检查协议收敛进度，待各通信设备收敛完毕后方可测试，单个测试用例用时较长。

2)若转发层面的实现机制有差异，表管理模块下发给转发层面的表项细节就会不同，同一套测试用例库需要针对每一种类型的转发层面测试一次，导致测试效率更为低下。

3)该现有的测试方法往往为功能级别的测试，测试粒度大，无法进一步校验表项中的细节，导致故障定位能力较低。

发明内容

为了解决上述的其中至少一个技术问题，本发明的目的在于提供一种用于协议栈表管理的测试方法、装置及系统。

本发明采用以下技术方案实现：

一种用于协议栈表管理的测试方法，包括：

依据接收的测试指令读取测试用例及触发协议数据的模拟打桩，等待一预设延迟时间后，下发模拟输出请求消息；

获取响应得到的模拟输出请求结果，并将模拟输出请求结果与期望输出结果的内容作比对，并据此输出测试结果。

优选地，所述测试用例内容包括：测试场景描述信息、模拟场景所需协议打桩数据以及对应表项的期望输出。

优选地，所述触发协议数据的模拟打桩包括：

根据从测试用例中读取的协议类型和打桩数据，通过发异步消息的方式调用对应表管理模块的打桩接口来模拟上游协议数据的下发。

优选地，所述延迟时间为表管理模块从接收协议数据到收敛完毕并达到稳定状态的时间。

优选地，所述模拟输出请求消息的内容包括：从测试用例中读取测试场景描述信息以及对应表项的关键字信息。

一种用于协议栈表管理的测试装置，其包括：

接收模块，用于接收测试指令；

读取模块，用于依据所述测试指令读取测试用例；

触发模块，用于依据接收的测试指令触发协议数据的模拟打桩；

请求模块，用于在触发模块完成触发协议数据的模拟打桩动作并等待一预设延迟时间后，下发模拟输出请求消息；

获取模块，用于获取响应得到的模拟输出请求结果；

处理模块，用于将模拟输出请求结果与期望输出结果的内容作比对，并据此输出测试结果。

优选地，所述测试用例内容包括：测试场景描述信息、模拟场景所需协议打桩数据以及对应表项的期望输出。

优选地，所述触发模块用于根据从测试用例中读取的协议类型和打桩数据，通过发异步消息的方式调用对应表管理模块的打桩接口来模拟上游协议数据的下发。

优选地，所述延迟时间为表管理模块从接收协议数据到收敛完毕并达到稳定状态的时间。

优选地，所述模拟输出请求消息的内容包括：从测试用例中读取测试场景描述信息以及对应表项的关键字信息。

一种用于协议栈表管理的测试系统，包括：

测试服务端，用于依据接收的测试指令读取测试用例及触发协议数据的模拟打桩，等待一预设延迟时间后，下发模拟输出请求消息；以及进一步用于获取响应得到的模拟输出请求结果，并将模拟输出请求结果与期望输出结果的内容作比对，并据此输出测试结果；

测试客户端，用于依据接收的模拟输出请求消息得到模拟输出请求结果，并将其返回给测试服务端。

优选地，所述测试用例内容包括：测试场景描述信息、模拟场景所需协议打桩数据以及对应表项的期望输出。

优选地，所述测试服务端触发协议数据的模拟打桩包括：

根据从测试用例中读取的协议类型和打桩数据，通过发异步消息的方式调用对应表管理模块的打桩接口来模拟上游协议数据的下发。

优选地，所述延迟时间为表管理模块从接收协议数据到收敛完毕并达到稳定状态的时间。

优选地，所述模拟输出请求消息的内容包括：从测试用例中读取测试场景描述信息以及对应表项的关键字信息。

优选地，所述测试客户端包括：

收发模块，用于获取模拟输出请求消息，以及进一步用于将调用模块得到的模拟输出请求结果返回给测试服务端；

提取模块，用于从所述模拟输出请求消息中获取期望输出表项的对应表项的关键字信息；

调用模块，用于依据所述对应表项的关键字信息调用对应表项的查询接口，得到模拟输出请求结果。

通过上述本发明提供的技术方案可以看出，相较于现有技术，本发明的有益效果在于：

1、现有技术需要多台设备模拟测试场景，而本发明基于协议打桩的方法，无论场景多么复杂，仅需一台测试设备即可。

2、现有技术需要等待多个通讯设备上各种协议均交互完成且收敛完毕后才能进行测试，而本发明不需要进行协议交互，表管理模块只需收到协议打桩数据并且收敛完毕后即可测试，因此测试效率大大提高。

3、现有技术为功能级别的测试，即使测试不通过，也很难对故障进行精确定位，而本发明可以实现对表项的细节进行一一校验，并给出相应的具体测试内容，其测试粒度更小，从而更为有利于进行故障定位。

附图说明

图1是本发明实施例提供的用于协议栈表管理的测试方法流程示意图；

图2是本发明实施例1中测试服务端触发测试的流程图；

图3是本发明实施例1中测试客户端收到模拟输出请求消息时的流程图；

图4是本发明实施例1中测试服务端收到模拟输出响应消息时的流程图；

图5是本发明实施例提供的用于协议栈表管理的测试装置结构示意图；

图6是本发明实施例提供的用于协议栈表管理的测试系统架构示意图；

图7是本发明实施例提供的测试客户端的结构示意图。

本发明的实现、功能特点及优异效果，下面将结合具体实施例以及附图做进一步的说明。

具体实施方式

下面结合附图和具体实施例对本发明所述技术方案作进一步的详细描述，以使本领域的技术人员可以更好的理解本发明并能予以实施，但所举实施例不作为对本发明的限定。

本发明提供了一种用于协议栈表管理的测试方法，如图1所示，本实施例提供的该方法的实施流程包括步骤：

S10、依据接收的测试指令读取测试用例及触发协议数据的模拟打桩，等待一预设延迟时间后，下发模拟输出请求消息；

S20、获取响应得到的模拟输出请求结果，并将模拟输出请求结果与期望输出结果的内容作比对，并据此输出测试结果。

本实施例中，所述测试指令可以定制生成，也可以由用户或其他第三方主动输入，来触发测试服务端的测试流程。

本实施例中，所述测试用例内容包括：测试场景描述信息、模拟场景所需协议打桩数据以及对应表项的期望输出。

本实施例中，所述触发协议数据的模拟打桩包括：根据从测试用例中读取的协议类型和打桩数据，通过发异步消息的方式调用对应表管理模块的打桩接口来模拟上游协议数据的下发。

本实施例中，所述桩是指用来代替关联代码或者未实现代码的代码。所述打桩就是编写或生成桩代码。打桩的目的主要有：隔离、补齐、控制。在本实施例中，打桩是为了模拟协议数据的生成与下发，这样就不需要多台通信设备协议交互了。

本实施例中，所述延迟时间为表管理模块从接收协议数据到收敛完毕并达到稳定状态的时间，或者在某些实施例中，也可以将所述延迟时间设置为一经验值。

本实施例中，所述模拟输出请求消息的内容包括：从测试用例中读取测试场景描述信息以及对应表项的关键字信息。所述模拟输出请求消息的接收者为测试客户端。测试客户端在收到测试服务端的模拟输出请求消息后，从中获取对应表项的关键字信息，并根据该关键字信息调用表查询接口得到模拟输出请求结果，之后测试客户端将得到的所述模拟输出请求结果以及所述模拟输出请求消息中包含的测试场景描述信息等内容作为消息主体，向测试服务端发送回传消息。

本实施例中，测试服务端在收到测试客户端的模拟输出请求结果后，将所述模拟输出请求结果与期望输出中的内容一一进行比较，若比较结果完全一致，则给出测试场景描述，测试场景通过标志；若比较结果不完全一致，则给出测试场景描述，测试场景不通过标志以及具体的不一致内容，从而方便故障定位。

本实施例中，所述期望输出结果是测试用例内容的一部分，期望输出的获取时间点可以是在步骤S10中获得也可以是在步骤S20中获得，下面对该两种不同的实施方式分别进行阐述。

实施例1

在该实施例中，从测试用例中获取所述期望输出的时机是：从测试服务端收到模拟输出响应消息后再从测试用例中读取期望输出，并将其与真实得到的模拟输出进行比较。

如图2所示，触发测试后，测试服务端处理流程如下：

步骤201：对测试用例的载体(如XML文件)进行解析，获取第一个测试用例。具体实施时，所述测试用例的载体还可以是其他格式的文本文件。

其中，测试用例的内容一般包括测试场景描述信息、模拟测试场景所需的协议打桩数据以及对应表项的期望输出。

步骤202：获取当前测试用例中模拟测试场景所需的协议打桩数据。

步骤203：通过发异步消息的方式，调用对应表管理模块的打桩接口来模拟上游协议数据的下发。

步骤204：延时一段时间，获取当前测试用例中测试场景描述信息以及期望输出表项的关键字。延时时间为表管理模块从接收协议数据到收敛完毕达到稳定状态的时间，一般为经验值。

步骤205：以获取的测试场景描述信息以及期望输出表项的关键字为消息主体，向测试客户端发送模拟输出请求消息。其中，所述模拟输出请求包括但不局限于面向转发面的表查询请求和面向控制面的表查询请求。

步骤206：通过发异步消息的方式，调用对应表管理模块的打桩接口来删除模拟测试场景。

步骤207：获取位于当前测试用例的下一个测试用例。若成功，跳至步骤202；若失败，流程结束。

如图3所示，当测试客户端收到模拟输出请求消息时，处理流程如下：

步骤301：从消息中获取期望输出表项的关键字。

步骤302：以关键字为输入，调用对应表项的查询接口，得到模拟输出结果。值得注意的是，这里有可能调用查询接口时返回失败，这种结果也应该成为模拟输出的一种可能。另外，模拟输出请求包括但不局限于面向转发面的表查询请求和面向控制面的表查询请求。

步骤303：以消息中包含的测试场景描述信息以及调用查询接口得到的模拟输出结果为消息主体，向测试服务端发送模拟输出响应消息。

如图4所示，当测试服务端收到模拟输出响应消息时，处理流程如下：

步骤401：从消息中获取测试场景描述信息以及模拟输出结果。

步骤402：通过测试场景描述信息，重新搜索得到对应的测试用例。然后获取测试用例中包含的对应表项的期望输出结果。

步骤403：将模拟输出结果与期望输出结果的内容进行比对，并记录内容不一致的地方。

步骤404：对比较结果作判断。若内容一致，跳至步骤405；否则，跳至步骤406。

步骤405：内容一致，测试通过。给出测试场景描述信息，并且给出测试用例测试通过标志。

步骤406：内容不一致，测试不通过。给出测试场景描述信息，给出测试用例测试通过标志，并且给出不一致的具体内容，方便用户定位故障。

实施例2

在该实施例中，从测试用例中获取所述期望输出的时机是：在测试服务端向测试客户端发送模拟输出请求消息时或之前，即已经从测试用例中读取出了期望输出，在收到模拟输出响应消息之后，不用再次从测试用例中读取期望输出。

具体地，在本实施例中，触发测试后，测试服务端处理流程如下：

步骤201：对测试用例的载体(如XML文件)进行解析，获取第一个测试用例。同样地，具体实施时，所述测试用例的载体还可以是其他格式的文本文件。

其中，测试用例的内容一般包括测试场景描述信息、模拟测试场景所需的协议打桩数据以及对应表项的期望输出。

步骤202：获取当前测试用例中模拟测试场景所需的协议打桩数据。

步骤203：通过发异步消息的方式，调用对应表管理模块的打桩接口来模拟上游协议数据的下发。

步骤204：延时一段时间，获取当前测试用例中测试场景描述信息、期望输出表项的关键字以及对应的期望输出。延时时间为表管理模块从接收协议数据到收敛完毕达到稳定状态的时间，一般为经验值。

步骤205：以获取的测试场景描述信息、期望输出表项的关键字以及对应的期望输出为消息主体，向测试客户端发送模拟输出请求消息。同样地，所述模拟输出请求包括但不局限于面向转发面的表查询请求和面向控制面的表查询请求。

步骤206：通过发异步消息的方式，调用对应表管理模块的打桩接口来删除模拟测试场景。

步骤207：获取位于当前测试用例的下一个测试用例。若成功，跳至步骤202；若失败，流程结束。

当测试客户端收到模拟输出请求消息时，处理流程如下：

步骤301：从消息中获取期望输出表项的关键字。

步骤302：以关键字为输入，调用对应表项的查询接口，得到模拟输出结果。值得注意的是，这里有可能调用查询接口时返回失败，这种结果也应该成为模拟输出的一种可能。另外，模拟输出请求包括但不局限于面向转发面的表查询请求和面向控制面的表查询请求。

步骤303：以消息中包含的测试场景描述信息、对应表项的期望输出以及调用查询接口得到的模拟输出结果为消息主体，向测试服务端发送模拟输出响应消息。

当测试服务端收到模拟输出响应消息时，处理流程如下：

步骤401：从消息中获取测试场景描述信息、对应表项的期望输出以及模拟输出结果。

步骤402：将模拟输出结果与期望输出结果的内容进行比对，并记录内容不一致的地方。

步骤403：对比较结果作判断。若内容一致，跳至步骤404；否则，跳至步骤405。

步骤404：内容一致，测试通过。给出测试场景描述信息，并且给出测试用例测试通过标志。

步骤405：内容不一致，测试不通过。给出测试场景描述信息，给出测试用例测试通过标志，并且给出不一致的具体内容，方便用户定位故障。

如图5所示，本发明还相应地提供了一种用于实施上述方法的用于协议栈表管理的测试装置，其包括：

接收模块101，用于接收测试指令；

读取模块102，用于依据所述测试指令读取测试用例，具体实施时，所述测试用例的载体可以是具有一定格式的文本文件,如XML文件等；

触发模块103，用于依据接收的测试指令触发协议数据的模拟打桩；

请求模块104，用于在触发模块完成触发协议数据的模拟打桩动作并等待一预设延迟时间后，下发模拟输出请求消息，其中，所述模拟输出请求包括但不局限于面向转发面的表查询请求和面向控制面的表查询请求；

获取模块105，用于获取响应得到的模拟输出请求结果；

处理模块106，用于将模拟输出请求结果与期望输出结果的内容作比对，并据此输出测试结果。

本实施例中，所述测试用例内容包括：测试场景描述信息、模拟场景所需协议打桩数据以及对应表项的期望输出。

本实施例中，所述触发模块103用于根据从测试用例中读取的协议类型和打桩数据，通过发异步消息的方式调用对应表管理模块的打桩接口来模拟上游协议数据的下发。

本实施例中，所述延迟时间为表管理模块从接收协议数据到收敛完毕并达到稳定状态的时间。

本实施例中，所述模拟输出请求消息的内容包括：从测试用例中读取测试场景描述信息以及对应表项的关键字信息。

本发明还相应地提供了一种用于协议栈表管理的测试系统，参考图6所示，所述测试系统采用C/S(客户端/服务器)模型，包括测试服务端10和测试客户端20，其中，测试服务端10负责测试用例的读取、触发协议数据的模拟打桩、触发测试客户端20模拟输出、以及将期望输出与模拟输出对比校验；测试客户端20负责响应测试服务端10的模拟输出请求，回传模拟输出结果；测试服务端10与测试客户端20采用异步消息进行通信。

具体地，继续参考图6所示，所述用于协议栈表管理的测试系统，包括：

测试服务端10，用于依据接收的测试指令读取测试用例及触发协议数据的模拟打桩，等待一预设延迟时间后，下发模拟输出请求消息；以及进一步用于获取响应得到的模拟输出请求结果，并将模拟输出请求结果与期望输出结果的内容作比对，并据此输出测试结果；

测试客户端20，用于依据接收的模拟输出请求消息得到模拟输出请求结果，并将其返回给测试服务端10。

本实施例中，所述测试用例的载体可以是具有一定格式的文本文件，如XML文件等。

本实施例中，所述测试用例内容包括：测试场景描述信息、模拟场景所需协议打桩数据以及对应表项的期望输出。

本实施例中，所述测试服务端10触发协议数据的模拟打桩包括：

根据从测试用例中读取的协议类型和打桩数据，通过发异步消息的方式调用对应表管理模块的打桩接口来模拟上游协议数据的下发。

本实施例中，所述延迟时间为表管理模块从接收协议数据到收敛完毕并达到稳定状态的时间。

本实施例中，所述模拟输出请求消息的内容包括：从测试用例中读取测试场景描述信息以及对应表项的关键字信息。

本实施例中，所述模拟输出请求包括但不局限于面向转发面的表查询请求和面向控制面的表查询请求。

本实施例中，参考图7所示，所述测试客户端20包括：

收发模块201，用于获取模拟输出请求消息，以及进一步用于将调用模块得到的模拟输出请求结果返回给测试服务端10；

提取模块202，用于从所述模拟输出请求消息中获取期望输出表项的对应表项的关键字信息；

调用模块203，用于依据所述对应表项的关键字信息调用对应表项的查询接口，得到模拟输出请求结果。

以上所述仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (16)

1.一种用于协议栈表管理的测试方法，其特征在于，包括：

依据接收的测试指令读取测试用例及触发协议数据的模拟打桩，等待一预设延迟时间后，下发模拟输出请求消息；

获取响应得到的模拟输出请求结果，并将模拟输出请求结果与期望输出结果的内容作比对，并据此输出测试结果。

2.如权利要求1所述的用于协议栈表管理的测试方法，其特征在于，所述测试用例内容包括：测试场景描述信息、模拟场景所需协议打桩数据以及对应表项的期望输出。

3.如权利要求1所述的用于协议栈表管理的测试方法，其特征在于，所述触发协议数据的模拟打桩包括：

根据从测试用例中读取的协议类型和打桩数据，通过发异步消息的方式调用对应表管理模块的打桩接口来模拟上游协议数据的下发。

4.如权利要求1所述的用于协议栈表管理的测试方法，其特征在于，所述延迟时间为表管理模块从接收协议数据到收敛完毕并达到稳定状态的时间。

5.如权利要求1所述的用于协议栈表管理的测试方法，其特征在于，所述模拟输出请求消息的内容包括：从测试用例中读取测试场景描述信息以及对应表项的关键字信息。

6.一种用于协议栈表管理的测试装置，其特征在于，包括：

接收模块，用于接收测试指令；

读取模块，用于依据所述测试指令读取测试用例；

触发模块，用于依据接收的测试指令触发协议数据的模拟打桩；

请求模块，用于在触发模块完成触发协议数据的模拟打桩动作并等待一预设延迟时间后，下发模拟输出请求消息；

获取模块，用于获取响应得到的模拟输出请求结果；

处理模块，用于将模拟输出请求结果与期望输出结果的内容作比对，并据此输出测试结果。

7.如权利要求6所述的用于协议栈表管理的测试装置，其特征在于，所述测试用例内容包括：测试场景描述信息、模拟场景所需协议打桩数据以及对应表项的期望输出。

8.如权利要求6所述的用于协议栈表管理的测试装置，其特征在于，所述触发模块用于根据从测试用例中读取的协议类型和打桩数据，通过发异步消息的方式调用对应表管理模块的打桩接口来模拟上游协议数据的下发。

9.如权利要求6所述的用于协议栈表管理的测试装置，其特征在于，所述延迟时间为表管理模块从接收协议数据到收敛完毕并达到稳定状态的时间。

10.如权利要求6所述的用于协议栈表管理的测试装置，其特征在于，所述模拟输出请求消息的内容包括：从测试用例中读取测试场景描述信息以及对应表项的关键字信息。

11.一种用于协议栈表管理的测试系统，其特征在于，包括：

测试服务端，用于依据接收的测试指令读取测试用例及触发协议数据的模拟打桩，等待一预设延迟时间后，下发模拟输出请求消息；以及进一步用于获取响应得到的模拟输出请求结果，并将模拟输出请求结果与期望输出结果的内容作比对，并据此输出测试结果；

测试客户端，用于依据接收的模拟输出请求消息得到模拟输出请求结果，并将其返回给测试服务端。

12.如权利要求11所述的用于协议栈表管理的测试系统，其特征在于，所述测试用例内容包括：测试场景描述信息、模拟场景所需协议打桩数据以及对应表项的期望输出。

13.如权利要求11所述的用于协议栈表管理的测试系统，其特征在于，所述测试服务端触发协议数据的模拟打桩包括：

根据从测试用例中读取的协议类型和打桩数据，通过发异步消息的方式调用对应表管理模块的打桩接口来模拟上游协议数据的下发。

14.如权利要求11所述的用于协议栈表管理的测试系统，其特征在于，所述延迟时间为表管理模块从接收协议数据到收敛完毕并达到稳定状态的时间。

15.如权利要求11所述的用于协议栈表管理的测试系统，其特征在于，所述模拟输出请求消息的内容包括：从测试用例中读取测试场景描述信息以及对应表项的关键字信息。

16.如权利要求15所述的用于协议栈表管理的测试系统，其特征在于，所述测试客户端包括：

收发模块，用于获取模拟输出请求消息，以及进一步用于将调用模块得到的模拟输出请求结果返回给测试服务端；

提取模块，用于从所述模拟输出请求消息中获取期望输出表项的对应表项的关键字信息；

调用模块，用于依据所述对应表项的关键字信息调用对应表项的查询接口，得到模拟输出请求结果。