CN104426715A - 一种分布式测试工具控制方法 - Google Patents

Abstract

本发明提出一种分布式测试工具控制方法，该方法包括：特定区域内的测试工具端点包括多个客户端和多个服务端，所有测试功能的类型和版本相同的客户端和服务端通过协商控制过程相互感知，客户端的上层从所述感知得到的服务端中选择符合测试要求的服务端建立连接。本发明通过跨平台的通用信息传输，实现了多主机多实例并行测试端点的统一控制；测试端点的自动发现和鉴别无需人工记录和配置，仅选择适当的测试服务端资源即可，可灵活快速地实现测试环境的快速搭建和便捷测试。

Description

一种分布式测试工具控制方法

技术领域

本发明涉及通信和网络测试工具领域，尤其涉及一种分布式测试工具控制方法。

背景技术

通信和网络等行业各种产品的开发和测试过程中，测试工具的管理架构和使用方法种类繁多，基于各种控制协议的测试工具不计其数，测试工具的控制方式，是影响测试工作效率的重要因素之一。运行于通用计算机的各种测试工具（包括面向不同产品的通用测试工具和面向特定产品的专用测试工具），主要采用的控制方法如下：

按测试工具的管理架构比较：

1、单主机运行：即测试工具运行于单个主机，测试者通过在主机本地操作（如本地图形窗口界面）或远程访问操作（如telnet等或特定客户端）实现对该测试工具的控制。每个主机上的测试工具需要单独的操作界面实现控制。需要多个测试工具同时测试时，需要在不同主机上开启测试工具，分别独立地操作控制。如SIPP、QTP等。

2、多主机运行：即分布式运行，每个测试工具服务端（测试实例操作端）运行于不同主机，测试者通过在测试工具客户端（测试实例运行端）配置每个测试工具服务端地址，对每个主机上的测试工具服务端实现远程控制，如loadrunner等。

按测试工具的可重入性比较：

1、单线运行：每个主机上运行单个测试工具实例。

2、多线运行：每个主机上运行多个测试实例，分别操作控制。

对于单线运行的测试工具，在需要多点测试的场景（如模拟即时通讯软件多个客户端），需要开启多个主机，给测试者操作带来麻烦，同时增加测试环境成本；对于单主机运行的测试工具，在高性能要求的测试中，受限于单个测试主机的处理能力。因此，现有技术的测试工具通常采用多主机和多线程的控制方式。然而对于多线程运行测试工具，在资源分配（如通信端口）上，需要测试者手动规划协调，不便于快速建立测试环境；对于多主机运行的测试工具，需要测试者记录和手动配置每个测试工具服务器，测试网络环境变化（IP地址变化）或资源变化（如部分主机或被其他测试者征用）时，需要人工协调资源使用。

发明内容

本发明提出的多主机多实例的测试工具管理操作的控制方法，能够进行自主发现和弹性配置，可以解决现有技术中测试主机之间资源协调配置以及多线程之间资源协调规划等问题。该方法包括：

特定区域内的测试工具端点包括多个客户端和多个服务端，所有测试功能的类型和版本相同的客户端和服务端通过协商控制过程相互感知，客户端的上层从所述感知得到的服务端中选择符合测试要求的服务端建立连接，特定区域可以为局域网，测试要求可以包括地址要求、性能要求等。

优选的，测试功能的类型和版本相同的客户端和服务端可以按照以下方法相互感知：

端点启动时，向所述特定区域内所有端点发送协商控制消息进行初始化查询，获取所有端点的属性信息，并向所述特定区域内所有端点广播发送协商控制消息宣告本端点的属性信息，最后进入运行状态，所述属性信息包括本端点的控制协议版本、端点类型（客户端或服务端）、测试功能的类型和版本，服务端的属性还包含当前控制端信息、测试工具运行状态；

端点运行状态中，收到所述特定区域内其它端点发来的进行查询的协商控制消息，则通过协商消息响应告知本端点属性信息；收到所述特定区域内其它端点发来的宣告属性信息的协商控制消息，则进行相应更新；

端点退出时，通知有业务关系的端点，并广播通知其他端点，使其他端点也得知本端点的退出。

优选的，客户端的上层从所述感知得到的服务端中选择符合测试要求的服务端建立连接可以具体为：

客户端将所述特定区域内的所有与其测试功能的类型和版本相同的客户端和服务端展示给客户端上层，客户端上层根据测试要求从中选择本客户端连接或断开哪些服务端；

客户端上层选择本客户端要连接的服务端后，本客户端向服务端发送协商消息进行建立连接申请，服务端收到客户端发来的建立连接申请，根据特定策略决定接受或拒绝申请，如果申请成功，客户端与服务端建立数据连接，所述特定策略可以由客户端的控制协议版本、测试功能的类型和版本、本端空闲状态、任务权限限制决定；

单个服务端在同一时间段仅接受单个客户端的申请，并被单个客户端控制使用，直到客户端主动释放控制或网络中断。

优选的，客户端与服务端通过协商控制消息进行客户端对服务端测试任务的控制；客户端还通过向客户端发送协商控制消息来释放控制。客户端释放控制后，服务端的测试任务可以依旧运行，客户端通过再次申请，或由其他有权限的客户端申请，可以继续对测试任务的控制。

优选的，客户端和服务端之间的端口采用以下约定：临时端口段用于发送端点启动时初始化查询的协商控制消息，协商端口段用于发送端点启动后的协商控制消息；传输端口段用于传输客户端与服务端之间的工具业务数据。其中，协商控制消息可以基于UDP协议或其它可用于广播的非连接协议；协商控制消息中还可以含有校验信息，用于过滤网路杂包的干扰；工具业务数据可以基于TCP或SCTP等基于连接的可靠传输协议。

基于上述端口约定，测试功能的类型和版本相同的客户端和服务端可以具体按照以下方法相互感知：

端点启动时，在临时端口段申请临时端口，通过临时端口向所述特定区域内所有端点的协商端口段广播发送协商控制消息进行初始化查询，获取所有端点的属性信息，然后申请协商端口和传输端口，通过协商端口向所述特定区域内所有端点的协商端口广播发送协商控制消息宣告本端点的属性信息，最后进入运行状态，所述属性信息包括本端点的控制协议版本、端点类型、测试功能的类型和版本、本端协商端口地址、本端传输端口地址，服务端的属性还包含当前控制端信息、测试工具运行状态；

端点运行状态中，收到所述特定区域内其它端点的临时端口段或协商端口段发来的进行查询的协商控制消息，则通过协商消息响应告知本端点属性信息；收到所述特定区域内其它端点的协商端口段发来的宣告属性信息的协商控制消息，则进行相应更新；

端点退出时，通知有业务关系的端点，并广播通知其他端点，使其他端点也得知本端点的退出。

基于上述端口约定，所述客户端的上层从所述感知得到的服务端中选择符合测试要求的服务端建立连接可以具体为：

客户端根据上层定义的方法，将所述特定区域内的所有与其测试功能的类型和版本相同的客户端和服务端展示给客户端上层，客户端上层根据测试要求从中选择本客户端连接或断开哪些服务端；

客户端上层选择本客户端要连接的服务端后，通过本客户端协商端口向服务端协商端口发送协商消息进行建立连接申请，服务端收到客户端发来的建立连接申请，根据特定策略决定接受或拒绝申请，如果申请成功，客户端与服务端建立数据连接；

单个服务端在同一时间端仅接受单个客户端的申请，并被单个客户端控制使用，直到客户端主动释放控制或网络中断。

优选的，每个主机可以运行多个客户端或服务端的程序。单个程序中也可以包括多个客户端或服务端的实例。

优选的，可以基于插件或动态库实现测试工具的控制协议，使不同的测试工具仅需加载该库即可实现本发明所设计的功能，与测试业务数据无依赖关系，可以灵活部署于各种测试工具，并互不干扰。

本发明的优点在于：（1）通过跨平台的通用信息传输，实现了多主机多实例并行测试端点的统一控制；（2）测试端点（包括不同主机间和相同主机内）的自动发现和鉴别，无需人工记录和配置，仅选择适当的测试服务端资源即可，可灵活快速地实现测试环境的快速搭建和便捷测试；（3）将多主机上的多线程的测试端点平等协商方式对待，测试者可随时根据地址要求、性能要求灵活选择不同的测试节点组网规模和方式；（4）通过测试工具的远程后台运行、选择型监控、客户端对服务端的灵活控制释放、运行中切换控制端等便利操作来提高测试工作效率；（5）不依赖测试工具业务协议，一次控制协议的编码实现可适用于多种通用计算机操作系统上的测试工具，降低了开发成本。

附图说明

图1是本发明实施例二中的测试工具的分布式管理架构示意图。

具体实施方式

下面结合附图对本发明的具体实施方式作详细的说明。

实施例一

本实施例设计了一种测试工具控制协议Extensiable Test Tool Protocal（以下简称XTTP），该协议具体定义了测试工具的客户端和服务端之间协商消息的数据包封装格式、端口段规划、校验和加密算法、鉴权定义等，在一个包括多个客户端和多个服务端的局域网内，客户端和服务端分别注入XTTP代码模块，则所有具有相同测试功能和版本的客户端和服务端都可以通过本XTTP协议的协商控制过程实现相互感知。

本实施例假设局域网内现有5块单板a、b、c、d、e上运行了版本为V1.0的CCTest测试工具的服务端，CCTest测试工具用于CC呼叫测试。下面为客户端选择相同测试功能和相同版本的服务端的过程：

（1）测试工程师A和B经常使用版本为V1.0的CCTest客户端操作单板a、b、c、d、e进行测试。

（2）测试工程师B在测试过程中发现版本为V1.0的CCTest测试工具存在BUG，修改其代码，并在单板a上停止了版本为V1.0的CCTest服务端、开启了版本为V2.0的CCTest服务端。

（3）测试工程师A开启版本为V1.0的CCTest客户端后，发现列表中显示的单板a上的CCTest服务端版本为V2.0，且提示版本不兼容，于是不使用单板a，而是暂时使用相同版本的单板b、c、d、e进行测试。

（4）测试工程师B开启版本为V2.0的CCTest客户端，连接单板a上版本为V2.0的CCTest的服务端，验证了BUG已修复。

（5）测试工程师A完成一次测试任务后，A、B更换了所有单板上的CCTest服务端版本为V2.0。

（6）测试工程师A和B开始使用版本为V2.0的CCTest客户端操作单板a、b、c、d、e进行测试。

实施例二

本实施例以SMPP短信测试工具SMGen为例，采用实施例一中的XTTP控制协议实现测试工具的分布式管理架构。如图1所示，SMGen客户端运行于WINDOWS，使用MFC控件框界面，C++开发；SMGen服务端可运行于WINDOWS或LINUX服务器，C语言开发。SMGen客户端和服务端分别注入XTTP代码模块，实现XTTP远程控制。下面描述客户端对服务端的具体控制操作：

（1）测试工程师A在自己办公电脑上打开SMGen客户端，测试工具自动探测到实验室网络上可用的SMGen服务端资源x、y、z，并提示SMGen服务端资源信息，展示在界面上。

（2）测试工程师A选择服务端x，连接、填写测试参数，开始1000条/秒的短信压力测试。

（3）测试工程师A连接服务端y，填写参数，开始2000条/秒的压力测试。

（4）测试工程师B在自己的办公电脑上也打开SMGen客户端，发现SMGen服务端x、y已被占用，于是连接SMGen服务端资源z，并填写参数开始测试。

（5）测试工程师A关闭SMGen客户端（即释放对服务端的控制），服务端x、y还在继续测试中。

（6）半小时后、测试工程师A重新打开SMGen客户端，连接SMGen服务端x，停止测试任务，打印报表，退出SMGen客户端。

（7）测试工程师C在自己办公电脑上打开SMGen客户端，根据测试工程师A提供的验证码，连接SMGen服务端y，打印报表，然后修改短信压力测试任务为5000条/秒，继续观察。

实施例三：

本实例以信威通用线性消息发生器callsim软件为例，采用实施例一中的XTTP控制协议实现测试工具的分布式管理架构，通过加载tcoder编解码组件，实现对广义TLV模式协议接口的压力测试。

本实施例中，Callsim软件包括客户端和服务端，客户端和服务端之间的端口分为三种：临时端口段、协商端口段和传输端口段。临时端口段用于发送端点启动时初始化查询的协商控制消息，仅查询其他端点信息，而不发布自身端点信息，临时端口段的设计用于在不依赖操作系统API和实现的条件下，从协议层规避端口冲突协商等问题；协商端口段用于发送端点启动后的协商控制消息；传输端口段用于传输客户端与服务端之间的工具业务数据，工具业务数据用于客户端对服务端的操作，数据格式由上层业务定义，客户端和服务端的测试功能和版本相同就可以保证两者的工具业务数据格式相同。

下面描述callsim软件的客户端对服务端的具体控制操作：

（1）测试工程师开启客户端软件后，客户端软件在临时端口段申请临时端口，通过临时端口向所有端点的协商端口段广播发送协商控制消息自动查询到网络内所有与其测试功能的类型和版本相同的客户端和服务端，将所有可用服务端在客户端软件界面展示，同时后台在特定端口段（根据不同组网环境和应用需求而由网络管理者规划的特定端口段）上，申请协商端口和传输端口，在申请到的协商端口上向所有端点的协商端口广播发送协商控制消息宣告本端点的属性信息，最后进入运行状态。

（2）测试工程师在客户端软件上，选取几个空闲的服务端，执行“连接”操作，操作端软件通过协商端口和传输端口，发送建立连接请求和接收响应，确认对几个代理端的控制。单个服务端在同一时间段仅接受单个客户端的申请，并被单个客户端控制使用，直到客户端主动释放控制或网络中断。

（3）测试工程师在客户端软件上编辑tcoder消息脚本和流程脚本，然后执行“开始”操作。客户端软件通过传输端口将脚本命令发送至服务端，所有服务端接到脚本命令后，开始对目标网络设备进行持续压力测试。

（4）测试进行过程中，服务端定时通过传输端口向客户端软件报告测试进度和统计信息，操作端软件在界面展示信息，测试工程师可随时查看。

（5）测试工程师在客户端软件上，执行“停止”操作。客户端软件通过传输端口向各服务端发送停止命令。各服务端应答并传送最终压力测试统计信息。客户端汇总各服务端压力测试统计信息，生成报告，并在界面展示。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (17)

1.一种分布式测试工具控制方法，其特征在于，所述方法包括：

特定区域内的测试工具端点包括多个客户端和多个服务端，所有测试功能的类型和版本相同的客户端和服务端通过协商控制过程相互感知，客户端的上层从所述感知得到的服务端中选择符合测试要求的服务端建立连接。

2.根据权利要求1的方法，其特征在于，所述相互感知具体为：

端点启动时，向所述特定区域内所有端点发送协商控制消息进行初始化查询，获取所有端点的属性信息，并向所述特定区域内所有端点广播发送协商控制消息宣告本端点的属性信息，最后进入运行状态，所述属性信息包括本端点的控制协议版本、端点类型、测试功能的类型和版本，服务端的属性还包含当前控制端信息、测试工具运行状态；

端点运行状态中，收到所述特定区域内其它端点发来的进行查询的协商控制消息，则通过协商消息响应告知本端点属性信息；收到所述特定区域内其它端点发来的宣告属性信息的协商控制消息，则进行相应更新；

端点退出时，通知有业务关系的端点，并广播通知其他端点，使其他端点也得知本端点的退出。

3.根据权利要求1的方法，其特征在于，所述客户端的上层从所述感知得到的服务端中选择符合测试要求的服务端建立连接具体为：

客户端将所述特定区域内的所有与其测试功能的类型和版本相同的客户端和服务端展示给客户端上层，客户端上层根据测试要求从中选择本客户端连接或断开哪些服务端；

客户端上层选择本客户端要连接的服务端后，本客户端向服务端发送协商消息进行建立连接申请，服务端收到客户端发来的建立连接申请，根据特定策略决定接受或拒绝申请，如果申请成功，客户端与服务端建立数据连接；

单个服务端在同一时间段仅接受单个客户端的申请，并被单个客户端控制使用，直到客户端主动释放控制或网络中断。

4.根据权利要求3的方法，其特征在于：所述特定策略由客户端的控制协议版本、测试功能的类型和版本、本端空闲状态、任务权限限制决定。

5.根据权利要求1的方法，其特征在于：客户端与服务端通过协商控制消息进行客户端对服务端测试任务的控制；客户端还通过向客户端发送协商控制消息来释放控制。

6.根据权利要求5的方法，其特征在于：客户端释放控制后，服务端的测试任务依旧运行，客户端通过再次申请，或由其他有权限的客户端申请，继续对测试任务的控制。

7.根据权利要求1的方法，其特征在于，客户端和服务端之间的端口采用以下约定：

临时端口段用于发送端点启动时初始化查询的协商控制消息，协商端口段用于发送端点启动后的协商控制消息；传输端口段用于传输客户端与服务端之间的工具业务数据。

8.根据权利要求7的方法，其特征在于：所述协商控制消息基于UDP协议。

9.根据权利要求7的方法，其特征在于：所述协商控制消息中含有校验信息，用于过滤网路杂包的干扰。

10.根据权利要求7的方法，其特征在于：所述工具业务数据基于TCP或SCTP协议。

11.根据权利要求7～10的方法之一，其特征在于，所述相互感知具体为：

端点启动时，在临时端口段申请临时端口，通过临时端口向所述特定区域内所有端点的协商端口段广播发送协商控制消息进行初始化查询，获取所有端点的属性信息，然后申请协商端口和传输端口，通过协商端口向所述特定区域内所有端点的协商端口广播发送协商控制消息宣告本端点的属性信息，最后进入运行状态，所述属性信息包括本端点的控制协议版本、端点类型、测试功能的类型和版本、本端协商端口地址、本端传输端口地址，服务端的属性还包含当前控制端信息、测试工具运行状态；

端点运行状态中，收到所述特定区域内其它端点的临时端口段或协商端口段发来的进行查询的协商控制消息，则通过协商消息响应告知本端点属性信息；收到所述特定区域内其它端点的协商端口段发来的宣告属性信息的协商控制消息，则进行相应更新；

端点退出时，通知有业务关系的端点，并广播通知其他端点，使其他端点也得知本端点的退出。

12.根据权利要求7～10的方法之一，其特征在于，所述客户端的上层从所述感知得到的服务端中选择符合测试要求的服务端建立连接具体为：

客户端根据上层定义的方法，将所述特定区域内的所有与其测试功能的类型和版本相同的客户端和服务端展示给客户端上层，客户端上层根据测试要求从中选择本客户端连接或断开哪些服务端；

客户端上层选择本客户端要连接的服务端后，通过本客户端协商端口向服务端协商端口发送协商消息进行建立连接申请，服务端收到客户端发来的建立连接申请，根据特定策略决定接受或拒绝申请，如果申请成功，客户端与服务端建立数据连接；

单个服务端在同一时间端仅接受单个客户端的申请，并被单个客户端控制使用，直到客户端主动释放控制或网络中断。

13.根据权利要求1的方法，其特征在于：所述特定区域为局域网。

14.根据权利要求1的方法，其特征在于：所述测试要求包括地址要求、性能要求。

15.根据权利要求1的方法，其特征在于：每个主机运行多个客户端或服务端的程序。

16.根据权利要求1的方法，其特征在于：单个程序中包括多个客户端或服务端的实例。

17.根据权利要求1的方法，其特征在于：基于插件或动态库实现测试工具的控制协议。