CN102420727A - 一种基于分布式的协议测试***及方法 - Google Patents

Abstract

本发明是为了克服现有的协议测试过程中出现的多节点测试协调性不强、不便集中控制、数据的组织和管理混乱、自动化测试效率低下等复杂难题，并提出一套完整的分布式协议测试***和方法。本发明实现了查询类、执行类、文件操作类和解析类四部分功能。为了实现其功能解决其技术问题所采取的技术方案主要分为框架设计、传输设计、协议设计、命令设计、安全设计、规则设计。采用服务器/客户机模式，控制节点是客户机，测试节点是服务器。控制节点作为测试逻辑和测试的管理方，将具体的任务进行实际的调配，依照逻辑和需求进行实际任务的分发。测试节点完成相应工作并对主控端有所回应。

Description

一种基于分布式的协议测试***及方法

技术领域

本发明设计通信协议领域特别涉及一种基于分布式的协议测试***及方法。 

背景技术

随着互联网技术的高速发展，由此带来的网络安全问题也随之而来。网络协议对于网络通信的安全性尤为重要，一个安全的网络协议往往是一个网络安全问题最核心也是最重要的部分。为了保证网络协议运行的质量和可靠性，需要对协议进行一系列的测试工作，从性能，健壮性，互联性等多方面考察协议实现的规范性和正确性以此来保证网络通信应用的安全发展。 

协议测试不同于一般的软件测试，其中多节点的参与性是通信协议测试区别于其他测试的主要特点。因为协议测试的多节点性，为实际的操作带来了很多的困难：(1)多节点不宜协调，部署不方便；(2)自动化测试难度较大，测试效率低；(3)数据组织不便，数据管理混乱；(4)专业化测试工具成本高，使用不够灵活。 

为了解决现有协议测试的以上不足，本套***方法通过引入分布式***框架和自动化测方式。首先，分布式测试框架的***思想契合了多点测试的环境条，通过主从模式的方式做到了作业任务的分散和控制的集中，对测试的过程有了较好的控制；其次，自动化的支持在提高效率解放人力的同时，也是得测试的方式更加灵活；再次整套***摆脱了传统分布式模型如CORBA等方案以及 TTCN测试工具的笨重和通用性，根据协议特点量身定制的一套轻量级的分布式***平台。 

发明内容

本发明是为了克服现有的协议测试过程中出现的多节点测试协调性不强、不便集中控制、数据的组织和管理混乱、自动化测试效率低下等复杂难题，并提出一套完整的分布式协议测试***和方法。为了克服以上种种不足，本发明实现的主要功能如下。 

所述的分布式协议测试***平台的功能包括查询类、执行类、文件操作类和解析类四部分功能，其中； 

查询类的主要功能包括： 

a)查询类测试节点连接情况查询，显示当前与控制节点的所有测试节点的信息列表，包括对方IP、端口等信息。 

b)测试节点测试用例查询，显示指定测试节点所拥有的测试用例文件列表。 

c)测试节点特定测试用例属性信息查询，显示测试用例的所有人、用例的功能描述、运行所需要的参数信息(包括参数类型和参数介绍)、返回测试结果的相关信息。 

d)测试节点当前运行测试用例的情况，显示测试节点现在运行程序的程序名称、运行状态(包括运行中、暂停和无程序运行状态) 

e)测试结果的查询，显示指定测试所产生测试结果信息，包括测试时间、测试人员、执行的测试用例、测试状态(成功/失败)，测试备注信息，测试输出信息显示。 

f)本地控制端节点的测试用例查询，显示本地测试用例拥有情况。 

g)任务执行情况查询：查询任务的运行状态。 

执行类的主要功能包括： 

a)测试启动，指定某个测试节点运行指定的测试用例，指定测试运行的时间、测试运行的次数、测试运行的模式(等待模式/并行模式)。可扩展其他的参数，进行控制。 

b)测试暂停，使某个指定的测试节点运行的程序处于暂停状态，可以指定操作执行的时间。可以扩展其他的参数进行控制。 

c)测试中止，使某个指定的测试节点运行的程序被中止，可以指定操作执行的时间。可以扩展其他的参数进行控制。 

d)注入操作，启动注入器，指定测试报文的前缀名称和报文的数量，目标服务器的IP和端口，注入器自动进行报文的注入和结果报文的回收。可以指定运行的时间，可以扩展其他参数进行控制。 

e)文件操作，对测试节点的测试用例进行常规操作：重命名、删除。 

f)分析操作，对指定的测试任务进行结果的分析，根据所有节点的测试结果文件，显示本次任务的结果信息，并实现基本的分析统计。 

文件操作类的主要功能包括： 

a)上传测试用例，将指定的测试用例文件从控制节点上传至指定的测试节点，随之上传的有测试用例的说明信息。 

b)下载测试结果，将指定的测试结果文件下载至控制节点本地。 

c)文件操作，修改测试用例名称、删除测试用例文件、测试结果文件等。 

解析类的主要功能包括： 

测试人员通过编写符合一定规则的测试脚本，由控制节点解析执行其中的 测试任务。 

本发明为了实现其功能解决其技术问题所采取的技术方案主要分为框架设计、传输设计、协议设计、命令设计、安全设计、规则设计。其中： 

框架设计步骤中，框架基本结构是一个中心控制节点依靠连接控制多个分散的测试节点。采用服务器/客户机模式，控制节点是客户机，测试节点是服务器。 

传输层设计步骤中，***传输层采用TCP协议，具体程序采用Unix的socket套接字接口去实现传输层的设计。鉴于TCP可靠的消息通知机制，免除了上层应用层协议去处理报文延迟等问题，使***运行在一个可靠地通信平台上。 

协议设计步骤中，根据***需要实现的功能为驱动，自行设计的应用层协议使消息命令传输更加规范，增强了***的可维护性和可扩展能力，支撑整个***的功能实现和节点交流。 

命令设计步骤中，为了方便程序设计，作为脚本解析的最小元素，依据命令特点将不同的命令抽象成一种统一的格式；做到了语义完整，在一行命令中包含了所有必要信息；具有可扩展化，与命令设计的统一格式相关，可以为***功能的扩展提供支持。 

安全设计步骤中，***采取的安全策略是对于测试人员身份的准入验证，权限的控制落实于各节点，每个节点分别进行实际的用户身份检查。 

规则设计步骤中，此步骤中包括测试用例规则、测试脚本书写规则和测试用例结果输出规则。三种规则相互制约联系，可以有效组织整个协议测试过程。其中测试用例规则支持命令行参数和配置文件两种形式，拥有自己相应的文件，用以说明自己的属性信息及使用方法，在使用***过程中可以通过相应的命令查询其信息。测试脚本书写规则作为一种类似于批处理的方式，将需要执行的 命令依次写到脚本中，由***自动解析执行。 

本发明的有益效果：该分布式的协议测试***及方法解决了多节点协议测试的部署困难问题，协调各各节点，实现了对数据有序管理的同时实现了高效的多节点自动化协议测试工作。该***的是针对协议测试的针对性分布式测试***。 

附图说明

图1为示出了该分布式协议测试***的功能流程图。 

图2为示出了该分布式协议测试***的框架结构图。 

图3为示出了该分布式协议测试***的传输层构架图 

图4为示出了该分布式协议测试***控制节点及测试节点设计框图。 

图5为示出了该分布式协议测试***执行类命令时序图。 

图6为示出了该分布式协议测试***查询类命令时序图。 

具体实施方式

所述的基于分布式的测试***及方法，首先基于分布式的自动化协议测试***部署为控制节点部分和测试节点部分，依此功能实体分为控制节点程序和测试节点程序。控制节点部分负责整个***平台的命令发布与逻辑控制，具体说来，具有获得测试人员指令、解析测试脚本、分发命令消息、监控测试节点状态流程等功能，处于中央控制协调的角色。测试节点是实际测试任务的执行者和命令的接收者，负责监听来自控制节点的命令消息，作出相应的回应和执行相应的逻辑流程。 

部署成功后的控制节点拥有三个文件夹：CN_Case、CN_Result、CN_Record和CN_Script。CN_Case负责装载测试用例，CN_Result负责装载测试结果文件、CN_Script负责装载测试脚本。测试用例和测试脚本在启动测试节点程序之前由测试人员装入自己测试需要的各类文件，作为***执行相应测试的文件源。当使用***中的下载测试结果功能时，***则自动装入CN_Result文件夹。 CN_Record文件夹存放着每次测试任务的相关配置信息。CN_Case文件夹中包含Schema子文件夹：用来装载测试用例的Schema文件。 

部署成功后的测试节点拥有TN_Case、TN_Result和TN_Config三个文件夹。TN_Case测试用例负责装载测试用例文件，作为测试节点测试能力的体现，可由控制节点上传至指定的测试节点。TN_Reusult文件夹装载测试结果文件，由于实际测试在测试节点端执行，因此测试用例输出的测试结果文件首先存入测试节点本地，当需要时可下载至控制节点。TN_Config文件夹装载了测试节点的配置文件，其中包含用户权限文件：记录了本节点授权的用户名以及相应的执行权限。TN_Case文件夹中包含Schema子文件夹：用来装载测试用例的Schema文件。 

所述的分布式测试***及方法，分为框架设计、传输设计、协议设计、命令设计、安全设计、规则设计。 

框架设计步骤中，采用的客户机/服务器模式。其中控制节点程序采用多线程并发控制模式。初始化中记录每一个参与到其中的测试节点的信息，并赋予每一个节点一个id号，用于之后的通信联系。这个id也作为测试人员制定控制节点的方式。整个测试节点程序维护着唯一一个命令队列，其上的每个命令消息维护着命令接收方的id，各个线程监视着这个命令队列是否有命令消息，当有消息时则对id加以判断是否是自身线程所对应的id，若符合便取出命令加以发送。测试节点在测试中处于1对1状态，只需要与唯一的控制节点交互，但由于其“服务器”的角色，需要开启一个后台线程用于监控来自控制节点的消息。当有消息来到时，监听线程就将消息结构体放入消息队列中，而主线程循环读取消息队列的情况，如有有消息则进行解析判断，调用相应的执行函数，完成任务后继续观察消息队列的情况。 

传输设计步骤中，所有节点通过TCP协议进行消息的传递，因此测试节点也通过IP地址和端口作为生成唯一ID的依据。需要特别说明的是，由于***应用层设计为控制通路和文件通路并存，而***的应用层协议依附于传输层的服务，所以实际上，控制节点与测试节点最多同时进行两个socket对话，一个负责控制协议的传输，另一个负责文件流的传输。***设计为控制socket通路的双方端口不特别指定，由测试用户启动***时自己设定。但文件socket通路的双方端口事先规定，即控制节点和测试节点双方需要知道对方的相应端口。 

协议设计步骤中，由于考虑到协议承担的任务既有一般的请求/应答，也有文件的传输。从结构上分为两条通道，一条是控制通道，进行一般的请求应答；另一条是文件通道，进行实际的文件通信。报文传输时序逻辑关系在见附图。 

请求报文结构 

请求行：Method SP Sub-Method SP URL SP Version CRLF
	消息头：【Item：Value】属性为Map结构形式
消息体：传输内容

应答报文结构 

应答行：Status_Code SP Status Description Version CRLF
	消息头：【Item：Value】属性Map结构形式
消息体：传输内容

【Sub-Method】：子方法类型 

命令设计步骤中，基于语义的完整性和扩展的需要，设计抽象成统一格式的命令格式如下：ACTI0N：Item/Filename sp_Case para # Time $ Times^Cmd_para  ID。其字段解释如下：ACTION(命令名称)，Item(子命令名 称)，Filename(操作的相关文件名)，Case_para(测试执行的输入参数)，Time(预计命令执行的时间，为空则是立即运行)，Times(执行次数)，Cmd_para(命令执行的模式参数)，ID(标识命令的宿主节点ID，这个ID在启动时给出，用来作为测试节点在控制节点的身份标识)，：\sp\#\$\^(命令参数0分隔符)。依据命令规则，本发明的命令实例如下表： 

安全设计步骤中，通过修改在测试节点TN_Config文件夹中的相关配置文件中配置。当测试人员登陆***时，需要输入用户名(密码)，作为自己身份的 证明，当控制节点向测试节点连接后需要向测试节点进行认证。 

规则设计步骤中，包括测试用例规则、测试脚本书写规则和测试用例结果输出规则。测试用例中的报文用例需要命名为[Prefix_X]形式，其中X为编号，用以标识这一组报文用例。可执行程序需要能够在Unix及类Unix平台上直接可执行，支持命令行参数和配置文件两种形式，若使用配置文件，则需要将配置文件也传至其将被执行的测试节点的TN_Case中。测试用例拥有自己相应的Schema文件，用以说明自己的属性信息及使用方法，在使用***过程中可以通过相应的命令查询其信息。Schema文件放置在TN_Case和CN_Case文件夹下的Schema下；测试脚本规则的设定，将需要执行的命令依次写到脚本中，由***自动解析执行，测试脚本的书写逻辑为顺序方式，将需要执行的命令写入脚本内，每个命令步骤为一行，每条命令步骤就是命令行模式的命令格式，可以使用脚本特殊关键字，使测试流程表达更简易；测试用例输出文件结果规则，其格式基本内容包括测试用例名称XXX、测试时间XXXX-XX-XX-XX-XX、测试结果、XX(五种测试结果枚举)、测试备注。 

Claims (7)

1.一种基于分布式的协议测试方法，其特征在于，包括：

框架设计步骤，用于部署控制节点和测试节点，其中所述控制节点依逻辑和需求分配任务，所述测试节点监控接收所述任务，测试节点完成工作向控制节点返回测试报告；

传输层设计步骤，用于发送测试用例的接口和通道，其中在设计中是采用Unix的Socket套接字接口技术，以免除应用层协议处理报文延迟问题；

协议设计步骤，用于规范传输消息命令，增强***的可维护性，协议方式从结构上设计为既有请求/应答的控制通道，也有实际通信内容的文件传输的通道；

命令设计步骤，用于设计抽象出统一格式的命令，命令语句具有语义完整性和可扩展性，形成有效的命令实例；

安全设计步骤，用于测试人员身份准入的验证，通过修改配置文件夹中的相关配置文件中配置，当控制节点向测试节点连接后向测试节点进行认证。

规则设计步骤，用于规范测试过程，通过对测试用例规则、测试脚本书写规则和测试用例结果输出规则的设计，形成有效的规则规范。

2.根据权利要求1所述的基于分布式的协议测试方法，其特征在于，在框架设计步骤中，控制节点采用多线程并发控制模式；在测试节点上具备后台监控线程，其用于辅助控制节点进行进行任务协调。

3.根据权利要求1所述的基于分布式的协议测试方法，其特征在于，在传输层设计步骤中，***设计为控制socket通路的双方端口不特别指定，但文件socket通路的双方端口事先规定。

4.根据权利要求1所述的基于分布式的协议测试方法，其特征在于，在协议设计步骤中，协议结构设计包括；请求报文结构设计，应答报文结构设计。

5.根据权利要求1所述的基于分布式的协议测试方法，其特征在于，在命令设计步骤中，基于语义的完整性和扩展的需要，设计抽象成统一格式的命令格式，所述命令格式如下：ACTION：Item/Filename sp Case_para#Time$Times^Cmd_paraID。其中各字段的解释如下表所示：

6.根据权利要求1所述的基于分布式的协议测试方法，其特征在于在规则设计步骤中，测试用例拥有自己相应的Schema文件，Schema是测试用例的格式描述。控制测试流程测试脚本规则的设定，将需要执行的命令依次写到脚本中，由***自动解析执行。测试用例输出文件结果规则，其格式基本内容包括测试用例名称、测试时间、测试结果、测试备注。

7.一种基于分布式的协议测试***，其特征在于，包括；

查询类功能设计步骤，其功能包括查询类测试节点连接情况查询、测试节点测试用例查询、测试用例属性信息查询、测试节点当前运行测试用例情况查询、测试结果查询、本地控制端节点的测试用例查询、任务执行情况查询；

执行类功能设计步骤，其功能主要包括测试启动功能、测试暂停功能、测试中止功能、注入操作功能、分析操作功能；

执行类功能设计步骤中，通过对脚本的规则编写，控制节点解析执行其中的测试任务。

Images