CN102355384A - 一种用于监控***的自动化测试的通信规范 - Google Patents
一种用于监控***的自动化测试的通信规范 Download PDFInfo
- Publication number
- CN102355384A CN102355384A CN2011103098525A CN201110309852A CN102355384A CN 102355384 A CN102355384 A CN 102355384A CN 2011103098525 A CN2011103098525 A CN 2011103098525A CN 201110309852 A CN201110309852 A CN 201110309852A CN 102355384 A CN102355384 A CN 102355384A
- Authority
- CN
- China
- Prior art keywords
- control module
- central control
- testing tool
- tcp
- xml
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种用于监控***的自动化测试的通信规范,测试工具与中心控制模块进行通信,首先经过注册,然后与中心控制模块建立TCP通信,最后进行用户界面具体命令的交互。中心控制模块和测试工具的TCP通信流程,将TCP通信流程分成三层处理:XML操作层,发送数据时,接收工具通信层的具体命令,将其封装为XML数据,然后传递给TCP侦听层发送;接收数据时,XML操作层接收TCP侦听层的原始XML数据,解析该原始XML数据,得到具体结果后,再传递给工具通信层处理;层与层之间通过回调和调用实现跨层操作。本发明的用于监控***的自动化测试的通信规范,用于集中控制多个测试工具并行工作,加快了测试速度、提高测试质量,实现更快、更好地开发软件产品的目标。
Description
技术领域
本发明涉及软件领域,具体涉及一种用于监控***的自动化测试的通信规范。
背景技术
随着对软件测试重视度的提高,国内软件测试技术发展突飞猛进,逐渐从单纯的手工测试向自动化测试与手工测试结合的方向发展。自动化测试主要是通过所开发的测试工具与编写测试脚本来实现,具有良好的可操作性、重复性和高效率等特点。它解决了在手动测试过程中无法覆盖所有代码路径;简单的功能性测试必须进行每轮测试;在进行***压力、性能测试时,需要模拟大量数据或大量并发用户等各种应用场合的问题。
在自动化测试过程中,应用恰当的测试工具,可以加快测试进度,提高测试质量,实现更快、更好地开发软件产品的目标。一般,测试工具分为通用测试工具和专用测试工具,通用测试工具主要有测试框架软件、录制回放软件等工具,专用测试工具主要是针对具体产品特别设计和开发的工具,如监控产品测试中用到的日志搜集工具、视频图像收集工具和串口云台控制工具等。以上所提到的测试工具都是单独辅助执行自动化测试,但是在监控产品自动化测试过程中需要同时启动多个测试工具,分别进行不同的操作,例如,运行自动化脚本,需要日志搜集工具每隔一段时间将日志搜集一次,在启动实况时,又需要视频图像搜集工具,进行实况抓拍,保存抓拍后的图像。集中控制多个测试工具并行工作在监控产品自动化测试环境中变得越来越重要。
发明内容
本发明的目的在于提供一种用于监控***的自动化测试的通信规范,将通信规范应用于自动化测试环境,实现了自动运行脚本和搜集日志两个主要功能。
一种用于监控***的自动化测试的通信规范,测试工具与中心控制模块进行通信,首先经过注册,然后与中心控制模块建立TCP通信,最后进行用户界面具体命令的交互。
1)中心控制模块注册过程设计:
中心控制模块在注册过程中一方面接收各个测试工具发送的注册报文,通过收到测试工具的注册报文对该测试工具进行控制;一方面接收到注册报文后,给测试工具发送注册响应报文,通知测试工具中心控制模块的存在,方便测试工具进行下一步操作;另一方面,为避免因测试工具异常退出后,中心控制模块仍旧继续发送通信命令,中心控制模块每隔15s检查一次测试工具注册登记表,及时更新注册登记表中测试工具状况。
一.数据结构设计:
中心控制模块接收到测试工具发送的注册报文后,分析注册报文,将注册报文中携带的信息项存储到注册登记表中,在之后的通信过程中中心控制模块就可以通过注册登记表根据测试工具ID号方便地读取和修改测试工具信息。注册登记表中记录着已注册过的测试工具的测试工具编号(ID)、测试工具类型名(TypeName)、测试工具所在PC机的IP地址(IpAddress)、UDP端口号(UdpPort)、最新注册时间(UpdateTime)、TCP客户端Socket(TCPClient)这六项信息。
二.XML注册响应报文设计:
中心控制模块在发送注册响应报文之前,先要生成XML注册响应报文,报文中携带中心控制模块的相关信息和发送时间。
三.中心控制模块注册过程设计:
中心控制模块的注册过程分为三个部分,分别是:接收注册报文、发送注册响应报文、循环检查注册登记表。
四.接收注册报文流程设计:
中心控制模块启动后,首先加入约定好的组播组中并绑定组播端口,然后在组播端口上接收注册报文,收到注册报文后,分析该注册报文,判断测试工具的ID号是否已经存在于注册登记表中,如果存在,只需修改“最新注册时间”;如果不存在,就添加该测试工具的相关信息项。接着发送注册响应报文。
五.发送注册响应报文流程设计:
中心控制模块接收注册报文,修改注册登记表之后,为了让测试工具知道自己的存在,必须向测试工具发送注册响应报文。该过程使用UDP单播发送注册响应报文。
中心控制模块首先开启UDP单播,然后生成XML注册响应报文,接着向接收到注册报文的测试工具发送注册响应报文,最后关闭UDP单播。
六.检查注册登记表流程设计:
注册登记表中的内容记录了正在与中心控制模块进行通信的测试工具的信息,当测试工具正常退出或异常停止后,中心控制模块就不再需要继续与测试工具保持通信关系,这时可以将退出的测试工具从注册登记表中删除。所以每隔15s检查注册登记表各测试工具ID对应的UpdateTime,如果当前时间与该时间之差大于15s,就认为测试工具已停止运行,将此测试工具对应的表项删除。
2)测试工具注册过程设计:
测试工具在注册过程中,主要负责三方面的任务:
1.发送注册报文,为确保中心控制模块在整个通信过程中处于运行状态,每隔5s发送一次注册报文;
2.接收注册响应报文,一方面测试工具通过注册响应报文了解中心控制模块的IP地址和TCP端口号,另一方面测试工具接收到注册响应报文就表示中心控制模块仍在运行,可以继续进行通信;
3.检测中心控制模块是否存在,测试工具自收到第一个注册响应报文,此后每隔15s判断一次注册响应报文数量是否增加。
一.数据结构设计:
测试工具接收到注册响应报文后,将报文中的中心控制模块信息记录到信息表中,便于在后续的通信中读取中心控制模块的相关信息。信息表中包括了中心控制模块编号(ServerID)、日志服务器编号(LogServerID)、中心控制模块TCP端口号(ServerTcpPort)这三项内容。
二.XML注册报文设计:
测试工具在发送注册报文前,先要生成XML注册报文,携带自己的ID编号、测试工具类型名、测试工具所在PC机的IP地址、UDP端口号和发送时间信息,然后再进行发送。
三.测试工具注册过程设计:
上面介绍了测试工具在注册过程中负责三方面的任务,分别是:发送注册报文、接收注册响应报文和检测中心控制模块是否存在。
四.发送注册报文流程设计:
测试工具启动后,首先加入约定好的组播组中,接着生成XML注册报文,然后向约定好的组播端口发送注册报文。这个过程每隔5s执行一次。
五.接收注册响应报文流程设计:
测试工具发送完注册报文后,它就开启UDP端口,在该端口上接收中心控制模块发送来的注册响应报文,接收到之后,分析注册响应报文,将报文中携带的中心控制模块的信息记录到信息表中。然后继续等待接收。
六.检测中心控制模块是否存在流程设计:
考虑到中心控制模块异常退出的情况,测试工具每隔15s检查一次注册响应报文的个数情况,如果在15s注册响应报文的个数没有增加,就认为中心控制模块已经异常退出,此时就停止和中心控制模块之间的具体通信。
3)通信规范TCP通信过程流程设计:
测试工具完成注册后,开始与中心控制模块进行TCP通信。
测试工具首先与中心控制模块建立TCP连接,然后发送Notify报文告诉中心控制模块自己的身份,然后等待中心控制模块的下一步指示。
中心控制模块自启动后,就在TCP端口进行侦听,接受来自各个测试工具的连接。当有连接进入,中心控制模块接受该连接,首先接收它的Notify报文,了解了对方的ID号之后,再对该类型的测试工具发送操作命令。
中心控制模块TCP通信过程设计 :
中心控制模块在具体通信过程中需要完成以下三项任务:
1.在TCP端口侦听测试工具的连接,侦听到连接后,对该连接进行处理:接收和发送原始XML数据信息。
2.对原始XML数据进行解析得到需要的信息,对裸命令进行XML格式的封装。
3.下发具体命令和上传执行结果。
可以将以上三项任务作为中心控制模块在具体通信过程中的三个层次:
底层,又称TCP侦听层,它完成第一项任务,负责接收TCP连接,并对接收到的连接进行读和写的原始操作;
中间层,又称XML操作层,它完成第二项任务,负责解析和生成XML原始数据;
上层,又称工具通信层,它完成第三项任务,负责下发具体命令和上传执行结果,它不会涉及任何与XML格式和TCP连接相关的操作。
中间层则是上层和底层的桥梁,发送数据时,它接收上层的具体命令,将其封装为XML数据,然后传递给底层发送,接收数据时,它接收底层的原始XML数据,解析该原始XML数据,得到具体结果后,再传递给上层处理。底层的任务就是对接受的TCP连接进行读和写的处理。分层后,各层只需处理好各自的
任务,层与层之间通过回调和调用实现跨层操作。
二.TCP侦听层具体设计:
为保证中心控制模块和测试工具之间的通信可靠性,在具体通信过程中采用TCP协议进行数据的传输。
TCP侦听层主要实现下面四个功能:
1.循环接收测试工具的TCP连接。
中心控制模块启动后,就在向外公布的TCP端口上开启TCP侦听,等待已注册的测试工具发来TCP连接。一旦接收到测试工具的连接,起线程处理该连接,中心控制模块又开始接着侦听下一个连接。
2.处理连接。
接收到测试工具连接后,首先在该连接上接收Notify报文,该报文中只携带了测试工具的ID号,是测试工具用来表明身份的报文。中心控制模块根据ID号查询注册登记表,获得该ID号对应的类型名TypeName,接着将此连接存储到注册登记表的此ID号对应的TCPClient项中,然后开始循环接收数据。
3.接收数据。
它根据ID号获取TCPClient连接,在该连接上接收测试工具发来的XML原始数据。
4.发送数据。
它与接收数据一样,先根据ID号获取TCPClient连接,然后向该连接发送XML原始数据。
三.XML操作层具体设计:
具体通信过程中不管是接收到的报文还是需要发送的报文,都采用XML封装。XML最大的优势在于对各种数据的管理,任何***都可以通过XML的解析器来读取XML数据。但是上层操作只负责对具体命令进行发送和对执行结果进行接收,对于原始XML数据,中心控制模块将其交由中间层处理。
XML操作层主要实现以下两个功能:
1.生成XML原始数据。
中心控制模块在上层发送了具体命令,中间层接收到该具体命令,将其封装成XML原始数据格式。
2.解析XML原始数据
中心控制模块在底层接收到测试工具发来的原始XML数据报文,回调给中间层进行解析,中间层解析获得到执行结果后,直接将执行结果回调给上层处理。
四.工具通信层设计:
中心控制模块的工具通信层连接着TCP通信过程和具体测试工具通信过程。它接收来自中心控制模块用户界面发来的具体命令,将其传给中间层封装,再交由下层发送;另外,它还接收由下层传到中间层解析后的测试工具执行结果,将该执行结果交给用户界面显示。
测试工具TCP通信过程设计 :
测试工具在具体通信过程中,首先与中心控制模块建立TCP连接,然后等待接收命令或者上报执行结果。
测试工具与中心控制模块类似,在具体通信过程中分为三个层次,分别是:底层,又称TCP连接层,负责建立TCP连接,然后发送Notify报文,之后专门负责接收和发送XML原始数据;中间层,又称XML处理层,与中心控制模块的中间层功能一样,负责解析和生成XML原始数据,只是具体实现有差别;上层,又称工具处理层,每个不同类型的测试工具拥有一个独立的工具处理层,处理和执行各自的命令。层与层之间仍旧通过回调和调用实现跨层操作。
一.TCP连接层具体设计:
测试工具的TCP连接层实现以下三个功能:
1.建立TCP连接。
测试工具在注册完毕后,立刻建立与中心控制模块的TCP连接。连接成功后,为了让中心控制模块了解它是谁,测试工具会主动发送一条Notify报文。
2.接收数据。
测试工具循环接收中心控制模块发送来的XML原始命令数据。随后将这些数据传入到中间层处理。
3.发送数据。
测试工具的中间层将已封装好的XML原始执行结果数据传递到底层,底层负责将它发送至中心控制模块。
二.XML操作层具体设计
测试工具的XML操作层完成的功能同中心控制模块的XML操作层,只是它比中心控制模块的XML操作层多了封装Notify报文的操作。
三.工具处理层操作
不同的测试工具拥有不同的工具处理层。本论文只讨论两个测试工具,分别是:命令行执行工具、日志搜集工具。
(一)命令行执行工具的工具处理层设计:
命令行执行工具是在程序运行过程中代替测试人员手工执行相关操作的工具。目前命令行执行工具实现了抓包功能、Ping功能和Python脚本运行功能。抓包功能使用tethereal.exe加上抓包时间、源地址、目的地址、协议类型和抓包数量等参数组成抓包命令。Ping功能使用Ping关键字加上IP地址就组成了简单的Ping命令。使用python.exe加上需要执行的脚本名即可实现命令行运行脚本的功能。命令行执行工具的工具处理层主要完成以下两个操作:
1.从中心控制模块接收命令行执行的具体命令,解析命令后,执行命令;
2.将执行后的结果发送给中心控制模块。
(二)日志搜集工具的工具处理层设计
日志搜集工具的工具处理层与日志搜集工具本身密切相关,它也负责两方面的任务:
1.从中心控制模块接收收集日志信息、收集***信息和检测日志信息的命令,然后将命令传给日志搜集工具处理;
2.接收日志搜集工具发来的处理结果,再将该结果发送给中心控制模块。
4)中心控制模块的用户界面设计:
中心控制模块根据具体测试工具下发对应命令,为此在中心控制模块端设计一个用户界面。由用户选择在线的测试工具,然后给该测试工具发送命令。
(1).命令行执行工具
中心控制模块的用户界面部分包含了命令行执行工具的页面,该测试工具上线后,用户可以选择抓包功能、Ping功能和Python脚本运行功能。中心控制模块与命令行执行工具之间进行通信的具体步骤如下:
一.用户在界面上选择上线的命令行执行工具;
二.用户选择抓包功能、Ping功能或Python脚本运行功能:
1.选择抓包功能:输入抓包时间、源地址、目的地址、协议类型和抓包数量参数,必填的是抓包时间参数。
2.选择Ping功能:输入Ping的IP地址。
3.选择Python脚本运行功能:输入Python脚本名。
三.用户点击发送,中心控制模块执行“发送数据”的三层处理,将原始XML数据发送到命令行执行工具。
四.命令行执行工具接收XML报文,经过测试工具“接收数据”的三层处理,得到命令数据,然后执行该命令。
五.命令执行完毕,命令行执行工具将执行结果进行处理后发送回中心控制模块。
六.中心控制模块将收到的执行结果显示到命令行执行工具用户界面。
(2)日志搜集工具 :
日志搜集工具是在脚本运行过程中收集服务器和终端设备的日志信息,收集服务器和终端设备的CPU信息、内存信息和磁盘信息,并可以在日志文件中找出某些关键字并杀掉指定进程的工具。日志搜集工具分为三部分:收集日志信息、收集***信息和检测日志信息。
中心控制模块的用户界面中也包含了日志搜集工具的页面,待日志搜集工具上线后,用户就可以输入想要收集和检测的设备信息。中心控制模块与日志搜集工具之间进行通信的具体步骤如下:
1.用户在界面上选择上线的日志搜集工具;
2.用户选择设备类型(服务器/终端)、输入设备IP地址、选择是否收集日志信息、收集***信息和检测日志信息。
3.用户点击发送,中心控制模块执行“发送数据”的三层处理,将原始XML数据发送到日志搜集工具;
4.测试工具接收到XML日志命令报文,经过测试工具“接收数据”的三层处理,得到命令数据,整理得到收集日志信息、收集***信息和检测日志信息的设备,之后交与日志搜集工具具体执行;
5.命令执行完毕,日志搜集工具将执行结果进行处理后发送回中心控制模块;
6.中心控制模块将收到的执行结果显示到日志搜集工具的用户界面。
与现有技术相比,本发明的优势在于:
一.本发明的通信规范设计了应用于监控***自动化测试的中心控制模块和测试工具的注册流程;
二.本发明的通信规范设计了应用于监控***自动化测试的中心控制模块和测试工具的TCP通信流程,将TCP通信流程分成三层处理;
三.本发明的通信规范设计了应用于监控***自动化测试的中心控制模块根据具体测试工具发送命令的用户界面。
本发明的通信规范用于集中控制多个测试工具并行工作,加快了测试速度、提高测试质量,实现更快、更好地开发软件产品的目标。
具体实施方式
实施例1
本发明的基于监控***的自动化测试工具的通信规范的编程实现分为下面两个步骤:
一.中心控制模块的通信规范实现。
二.测试工具的通信规范实现。
下表1列出了中心控制模块和测试工具在注册过程、TCP通信过程和具体测试工具通信过程中使用的类。
表1 通信规范各大类
(一)中心控制模块的通信规范实现:
中心控制模块的通信规范实现分为三个部分:注册实现、TCP通信实现、用户GUI界面实现。
一般是用户界面类、工具通讯类、XML操作类、TCP侦听类和注册类的依次传递,实现中心控制模块的通信规范。
1)中心控制模块的注册实现:
中心控制模块的注册过程包括:接收注册报文、发送注册响应报文和检查注册登记表三部分。
中心控制模块注册类IMOS_Server_TestFrame_Register中起线程执行接收注册报文函数和检查注册登记表函数。
1、中心控制模块变量 m_ToEndFlag和注册登记表registerDict:
m_ToEndFlag变量控制着中心控制模块是否继续执行接收注册报文和检查注册登记表。中心控制模块启动时将该值赋为false,中心控制模块退出时该值变为true。
将注册登记表registerDict定义为一个字典结构,字典的键为测试工具的ID号,字典的值为测试工具信息各项ClientItems结构体。
下面列出了ClientItems结构体定义与registerDict字典定义和赋值后的registerDict。
1.1、ClientItems结构体定义
struct ClientItems
{
public string IpAddress;
public string UdpPort;
public string UpdateTime;
public string TypeName;
public TcpClient TCPClient;
};
1.2、registerDict字典定义
Dictionary<string, ClientItems> registeredDict;
1.3、赋值后的registerDict
registerDict =
{“0001”:[“192.169.110.4”,“10001”,“2011-4-20:01:00 ”,
“CmdTool”,Client1]
“0002”:[ “192.169.110.3”, “10002”, “2011-4-20:03:00 ”,
“LogTool”,Client2]
}
2、中心控制模块注册类IMOS_Server_TestFrame_Register
中心控制模块注册类实现了中心控制模块在注册过程设计中的需要完成的三项任务。
注册启动时,开启两个线程,分别为:接收注册响应报文线程和检测注册登记表线程。
2.1、接受注册响应报文函数ReceiveRegisterPacketsThread。
在该线程中,首先调用加入组播组函数StartMulticast,然后开始循环接收注册报文。每接收到一个注册报文就启动分析和更新注册登记表线程AnalyzeAndUpdateRegisteredListThread。在分析和更新注册登记表线程中,首先根据XML格式分析出注册报文中的各项数据,接着更新注册登记表,最后调用发送注册响应报文函数SendRegisterAckPacket。至此中心控制模块就完成了一轮接收注册报文和发送注册响应报文的操作。
2.2、检测注册登记表函数CheckRegisterDictThread。
在此线程中,每隔15s,就循环遍历registerDict字典,对registerDict字典中的每一项,判断当前时间与该项的UpdateTime时间之差是否小于15s,如果小于则检查下一项,否则就将该项ID记录到unusedIDList中,遍历完registerDict后,再将出现在unusedIDList中测试工具ID从registerDict字典中移除。
2)中心控制模块的TCP通信实现:
将TCP通信过程设计为三层结构:底层,TCP侦听层主要负责发和接收原始XML数据;中间层,XML操作层主要负责解析和封装XML数据;上层,工具通信层,主要负责发送用户界面下发的命令和接收测试工具的执行结果。
TCP通信实现也分为三个类,分别是TCP侦听类、XML操作类和工具通类。其中TCP侦听类继承于注册类,XML操作类继承于TCP侦听类,而上层工具通信类则继承于XML操作类。
1、TCP侦听类IMOS_Server_TestFrame_TCPConnect
TCP侦听类负责接收各个测试工具的TCP连接、接收测试工具的Notify报文、发送XML命令包和接收XML执行结果包。
TCP通信启动时,调用开启TCP侦听连接函数StartTCPConnect,该函数中不断接收测试工具发来的TCP连接,一旦接收到一个TCP连接,就马上启动处理测试工具TCP连接函数线程ServiceClientMethodThread。此线程首先接收从该TCP连接传来的Notify报文,从报文中解析出建立该TCP连接的测试工具ID号CientID,然后订阅事件toolOnline通知用户界面类测试工具CientID上线,接着开始循环接收从该测试工具端发送的执行结果或上报信息报文。
2、XML操作类IMOS_Server_TestFrame_XMLOperation:
XML操作类负责解析从TCP侦听类传来的XML数据包和封装从工具通信类传来的用户命令。
XML类图中的解析XML函数AnalyzeXML在发送数据时被上层工具通信类调用,封装XML函数GenerateAndSendXML在接收数据时被下层TCP侦听类回调。
3、工具通信类IMOS_Server_TestFrame_ToolsCommunication:
工具通信类是TCP通信和用户界面的桥梁。工具通信类中获取GUI命令函数GetGUICommand从用户界面获得用户发出的第一手命令,然后向下层发送;获取测试工具结果GetToolResult从下层接收执行结果,再传递给用户界面显示。
4、TCP通信三大类的关系:
TCP通信三大类之间关系密切,在发送数据的过程中,由上至下调用各层函数,直至将XML数据发送至测试工具端;而在接收数据的过程中,则是从下向上回调各层函数,直至上层将执行结果传递给用户界面。
4.1、发送数据过程中,三大类之间的调用关系。
上层工具通信类接收到用户界面发来的命令,就调用中间层XML操作类进行命令封装,中间层封装完命令后,紧接着调用下层TCP侦听类中的发送XML命令数据包函数SendXMLMessage,将XML命令数据包发送至指定测试工具端。
4.2、接收数据过程中,三大类之间的回调关系:
下层TCP侦听类循环接收测试工具发送来的XML执行结果数据包,一旦接收到数据包,就触发事件messageReceived,于是回调执行中间层函数AnalyzeXML,解析完XML数据包后,再触发事件XMLAnalyzed,回调执行上层函数GetToolResult,上层回再次触发事件ResultToSend,待用户界面将结果显示到测试工具窗口。
4.3、中心控制模块的用户GUI界面实现 :
中心控制模块的用户界面实现了对用户命令的主动输入和对测试工具执行结果的显示。
用户界面类中可定义上层工具通信类的一个对象m_tools,对于用户命令的发送和测试工具执行结果的接收都由此对象负责操作。
用户界面类本身主要包括一个listView控件、一个tabControl控件。listView控件用来显示上、下线的测试工具,当下层接收到测试工具的TCP连接后,触发toolOnline事件,回调执行类图中增加测试工具项AddToolItem函数,将测试工具添加到listView中,用户便可选择此测试工具。当下层检测到测试工具的ID已不存在时,触发toolOfline事件,回调执行类图中使测试工具无效的UnvalidToolItem函数,将已下线的测试工具变灰,用户就不能再对此测试工具进行操作。
tabControl控件中的每一页就表示一种测试工具。目前tabControl控件中有三页,分别是StartPage、CmdTool和LogTool,其中CmdTool页中列出了执行命令行测试工具的命令选项和结果显示框,LogTool页中简化了日志搜集工具,以设备为搜集和检测对象,将收集日志信息、收集***信息和检测日志信息合为一行,在用户界面类内部处理日志命令。当工具通信层接收到了测试工具发来的执行结果,就触发ResultToSend事件,回调执行类图中的显示测试工具结果ShowToolResult函数,将结果显示到对应测试工具页的结果显示框中。
在用户界面类接收到用户输入的命令,将命令拼装后就调用工具通信类的GetGUICommand函数进行发送。
(二)、测试工具的通信规范实现:
测试工具的通信规范实现包括所有测试工具的通用注册实现、所有测试工具的TCP通信实现和具体测试工具实现三部分。
1)所有测试工具的通用注册实现:
测试工具在通用注册过程设计中负责三项任务:发送注册报文、接收注册响应报文和检测中心控制模块是否存在。
测试工具注册类IMOS_Client_TestFrame_Register实现了测试工具在通用注册过程设计中的需要完成的三项任务。
注册启动时,测试工具首先加入组播组JoinMulticastGroup,然后开启两个线程,分别为:发送注册报文线程和接收注册响应报文和检测中心控制模块是否存在线程。
1.1、发送注册报文函数SendRegisterPacketThread。
该线程只负责每隔5s发送注册报文到中心控制模块。
1.2、接收注册响应报文和检测中心控制模块是否存在函数ReceiveRegisterACKThread。
在此线程中,首先开启接收注册响应报文线程ReceiveFromThread ,该线程专门负责在UDP端口接收注册响应报文。ReceiveRegisterACKThread线程在开启ReceiveFromThread线程后,紧接着就每隔15s检查一次注册响应报文的数量,如果注册响应报文数量在增加,不做任何操作,否则将m_ActiveStatus变量置为false。m_ActiveStatus在测试工具接收到第一个注册响应报文后,被赋为true,表示中心控制模块处于活动状态。
2)所有测试工具的TCP通信实现:
将测试工具的TCP通信过程设计为三层结构:底层,TCP连接层主要负责发送和接收原始XML数据;中间层,XML操作层主要负责解析和封装XML数据;上层,工具处理层,该层中包含各种测试工具的处理过程。
测试工具的TCP通信实现对应设计部分也分为三大类,分别是TCP连接类、XML操作类和工具处理类。TCP连接类继承于注册类,XML操作类继承于TCP连接类,而工具处理类(命令行执行工具类,搜集日志类)则继承于XML操作类。
1、TCP连接类IMOS_Client_TestFrame_TCPConnect
测试工具的TCP连接类主要负责与中心控制模块建立TCP连接,连接建立成功后,接收XML命令包和发送XML执行结果包。
测试工具启动后,就启动了开始TCP连接的线程StartTCPConnectThread,该线程等待接收中心控制模块的第一个注册响应报文,一旦接收到第一个注册响应报文,该线程就开始与中心控制模块建立TCP连接,连接成功,触发SuccessConnected事件,回调执行中间层的发送Notify报文函数。接着就循环接收数据包,直至测试工具自身退出或中心控制模块退出。
2、XML操作类IMOS_Client_TestFrame_XMLOperation
测试工具的XML操作类同样是上层工具处理类和下层TCP连接类之间的桥梁。
测试工具的XML操作类功能前两项同中心控制模块的XML操作类功能类似。在接收数据的过程中,下层触发事件,回调中间层的解析XML数据包AnalyzeXMlInfo函数;在发送数据的过程中,上层调用生成并发送XML数据包GenerateAndSendXMLResult函数。另外测试工具的XML操作类还负责在TCP成功建立连接后执行发送NotifyXML数据包SendNotifyXML函数。
3、工具处理类
工具处理类实际上是每种测试工具的处理类的统称,目前暂时有命令行执行工具类和日志搜集处理类。
工具处理类与测试工具的用户界面类密切相关,具体测试工具的功能都体现在用户界面类中。
3.1、命令行执行工具类IMOS_Client_TestFrame_CmdTool
命令行执行工具类暂时只支持抓包命令、Ping命令和Python脚本执行命令三种。它从中心控制模块接收到命令后,首先解析命令字段,判断是何种命令,然后再执行。
例如中心控制模块端发送的命令为“WireShark|-a duration:2 –f src host 192.169.100.2 and ip proto/udp”, 命令行执行工具类首先解析命令字段为“WireShark”,然后执行"C:\\Program Files\\Ethereal\\tethereal.exe -a duration:2 –f src host 192.169.100.2 and ip proto/udp”命令。
执行完命令后,命令行执行工具类调用XML操作类的GenerateAndSendXMLResult(output)函数将结果发送到中心控制模块。
设置解析命令函数AnalyzeCmd专门负责解析命令类型,然后调用执行命令函数ExecOSCommand负责执行具体命令,将执行后的结果返回到AnalyzeCmd中。
3.2、日志搜集处理类IMOS_Client_TestFrame_LogTool
日志搜集处理类与日志搜集工具类不同,日志搜集工具类是一个完整的C#编写的日志搜集工具类,它负责收集日志信息、收集***信息和检测日志信息,它有自己的工具界面。而日志搜集处理类则是负责将中心控制模块的发送来的日志搜集命令转化为日志搜集工具类可用的命令。
日志搜集处理类IMOS_Client_TestFrame_LogTool类图设置:从中心控制模块接收日志命令函数ReceiveLogCommandFromServer负责转化中心控制块发来的命令,然后将转化过后的命令发送到日志搜集工具类。类图中发送日志运行结果函数SendLogResultToServer,负责将日志搜集工具的运行结果发送至中心控制模块。
3)日志搜集工具实现
日志搜集工具本身就是一个完整的测试工具,它包括内部处理和界面处理。日志搜集工具类实现是在原来日志搜集工具类的基础上结合日志搜集处理类,同时实现自身界面命令和中心控制模块命令的类。
日志搜集工具类新添加功能的类图设置:类图中m_logTool为日志搜集类的对象,它是日志搜集工具类与测试工具的TCP通信中间层的桥梁。
TransferItems函数把从日志搜集处理类中传来的命令添加到日志搜集工具的数据集dataSet中。然后执行收集日志信息、收集***信息和检测日志信息的脚本。
StopScripts函数停止执行上述三个脚本。
上述实施例只是为了说明本发明的技术构思及特点,其目的是在于让本领域内的普通技术人员能够了解本发明的内容并据以实施,并不能以此限制本发明的保护范围。凡是根据本发明内容的实质所作出的等效的变化或修饰,都应涵盖在本发明的保护范围内。
Claims (9)
1. 一种用于监控***的自动化测试的通信规范,其特征在于,
测试工具与中心控制模块进行通信,首先经过注册,然后与中心控制模块建立TCP通信,最后进行用户界面具体命令的交互,
1)中心控制模块和测试工具的注册流程:
中心控制模块的注册过程分为接收注册报文、发送注册响应报文、循环检查注册登记表这三个部分;
测试工具在注册过程中负责发送注册报文、接收注册响应报文和检测中心控制模块的存在性这三个任务;
2)中心控制模块和测试工具的TCP通信流程,将TCP通信流程分成三层处理:
TCP侦听层,作为底层,负责接收TCP连接,并对接收到的连接进行读和写的原始操作;
工具通信层,作为上层,负责下发具体命令和上传执行结果;
XML操作层,作为中间层,发送数据时,接收上层的具体命令,将其封装为XML数据,然后传递给底层发送,接收数据时,它接收底层的原始XML数据,解析该原始XML数据,得到具体结果后,再传递给上层处理;
层与层之间通过回调和调用实现跨层操作;
3)中心控制模块的用户界面:
中心控制模块根据具体测试工具下发对应命令,在中心控制模块端设计一个用户界面,由用户选择在线的测试工具,然后给该测试工具发送命令。
2. 根据权利要求1所述的用于监控***的自动化测试的通信规范,其特征在于,所述测试工具括包括业务产生类型的脚本运行工具,实况检测类型的视频图像收集工具、音频收集工具或串口云台控制命令工具,信息采集类型的日志搜集工具、Log服务器工具或Report工具。
3. 根据权利要求1所述的用于监控***的自动化测试的通信规范,其特征在于,所述测试工具每隔5s向中心控制模块发送一次注册报文,每隔15s检查注册响应报文的数量是否有增加;中心控制模块每隔15s检查一次注册登记表情况,及时更新注册登记表中测试工具状况。
4. 根据权利要求1所述的用于监控***的自动化测试的通信规范,其特征在于,所述中心控制模块接收到测试工具发送的注册报文后,分析注册报文,将注册报文中携带的测试工具编号、测试工具类型名、测试工具所在PC机的IP地址、UDP端口号、最新注册时间、TCP客户端Socket这六项信息项存储到注册登记表中。
5. 根据权利要求1所述的用于监控***的自动化测试的通信规范,其特征在于,所述中心控制模块在发送注册响应报文之前,先要生成XML注册响应报文,报文中携带中心控制模块的相关信息和发送时间。
6. 根据权利要求1所述的用于监控***的自动化测试的通信规范,其特征在于,所述测试工具接收到注册响应报文后,将报文中的中心控制模块编号、日志服务器编号、中心控制模块TCP端口号这三项中心控制模块信息记录到信息表中。
7. 根据权利要求1所述的用于监控***的自动化测试的通信规范,其特征在于,所述测试工具在发送注册报文前,先要生成XML注册报文,携带自己的ID编号、测试工具类型名、测试工具所在PC机的IP地址、UDP端口号和发送时间信息,然后再进行发送。
8. 根据权利要求1所述的用于监控***的自动化测试的通信规范,其特征在于,所述中心控制模块的用户界面中包含了命令行执行工具的页面,设有抓包功能、Ping功能和Python脚本运行功能。
9. 根据权利要求1所述的用于监控***的自动化测试的通信规范,其特征在于,所述中心控制模块的用户界面中还包含了日志搜集工具的页面,设有收集日志信息、收集***信息和检测日志信息这三部分脚本运行功能。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2011103098525A CN102355384A (zh) | 2011-10-13 | 2011-10-13 | 一种用于监控***的自动化测试的通信规范 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2011103098525A CN102355384A (zh) | 2011-10-13 | 2011-10-13 | 一种用于监控***的自动化测试的通信规范 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN102355384A true CN102355384A (zh) | 2012-02-15 |
Family
ID=45578881
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2011103098525A Pending CN102355384A (zh) | 2011-10-13 | 2011-10-13 | 一种用于监控***的自动化测试的通信规范 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102355384A (zh) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102932176A (zh) * | 2012-10-29 | 2013-02-13 | 深圳市华为技术软件有限公司 | 后台程序日志的跟踪方法、跟踪端、服务端和*** |
CN103984626A (zh) * | 2014-05-13 | 2014-08-13 | 华为技术有限公司 | 一种生成测试用例脚本的方法及装置 |
CN104270453A (zh) * | 2014-10-11 | 2015-01-07 | 苏州科达科技股份有限公司 | 一种多级服务器间数据通信方法及服务器 |
CN104777826A (zh) * | 2014-01-14 | 2015-07-15 | 株式会社东芝 | 用于工厂监控***的测试支持装置、测试支持方法和测试支持程序 |
CN106201883A (zh) * | 2016-07-15 | 2016-12-07 | 北京捷科智诚科技有限公司 | 一种测试分析平台 |
CN108491329A (zh) * | 2018-04-02 | 2018-09-04 | 郑州云海信息技术有限公司 | 一种ssr客户端的性能测试方法及测试工具 |
CN109634850A (zh) * | 2018-11-29 | 2019-04-16 | 中国船舶重工集团公司第七0五研究所 | 一种用于自动测试***中快速搭建测试软件的方法 |
CN111209007A (zh) * | 2020-01-17 | 2020-05-29 | 济南浪潮高新科技投资发展有限公司 | 一种基于移动环境监控可控设备软件实现方法 |
CN117290190A (zh) * | 2023-11-27 | 2023-12-26 | 博为科技有限公司 | 一种串口日志远程采集方法、装置及存储介质 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6581021B2 (en) * | 2000-06-17 | 2003-06-17 | Inventec Corporation | Method for downloading and managing test tool of test system |
CN1832433A (zh) * | 2005-03-08 | 2006-09-13 | 华为技术有限公司 | 分布式架构测试***和该测试***的测试方法 |
CN101727389A (zh) * | 2009-11-23 | 2010-06-09 | 中兴通讯股份有限公司 | 一种分布式综合业务自动化测试***及方法 |
-
2011
- 2011-10-13 CN CN2011103098525A patent/CN102355384A/zh active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6581021B2 (en) * | 2000-06-17 | 2003-06-17 | Inventec Corporation | Method for downloading and managing test tool of test system |
CN1832433A (zh) * | 2005-03-08 | 2006-09-13 | 华为技术有限公司 | 分布式架构测试***和该测试***的测试方法 |
CN101727389A (zh) * | 2009-11-23 | 2010-06-09 | 中兴通讯股份有限公司 | 一种分布式综合业务自动化测试***及方法 |
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102932176B (zh) * | 2012-10-29 | 2015-06-17 | 深圳市华为技术软件有限公司 | 后台程序日志的跟踪方法、跟踪端、服务端和*** |
CN102932176A (zh) * | 2012-10-29 | 2013-02-13 | 深圳市华为技术软件有限公司 | 后台程序日志的跟踪方法、跟踪端、服务端和*** |
CN104777826A (zh) * | 2014-01-14 | 2015-07-15 | 株式会社东芝 | 用于工厂监控***的测试支持装置、测试支持方法和测试支持程序 |
CN104777826B (zh) * | 2014-01-14 | 2018-10-26 | 株式会社东芝 | 用于工厂监控***的测试支持装置、测试支持方法和测试支持程序 |
CN103984626A (zh) * | 2014-05-13 | 2014-08-13 | 华为技术有限公司 | 一种生成测试用例脚本的方法及装置 |
CN103984626B (zh) * | 2014-05-13 | 2017-07-28 | 华为技术有限公司 | 一种生成测试用例脚本的方法及装置 |
CN104270453A (zh) * | 2014-10-11 | 2015-01-07 | 苏州科达科技股份有限公司 | 一种多级服务器间数据通信方法及服务器 |
CN104270453B (zh) * | 2014-10-11 | 2018-02-13 | 苏州科达科技股份有限公司 | 一种多级服务器间数据通信方法及服务器 |
CN106201883B (zh) * | 2016-07-15 | 2019-04-19 | 北京捷科智诚科技有限公司 | 一种测试分析平台 |
CN106201883A (zh) * | 2016-07-15 | 2016-12-07 | 北京捷科智诚科技有限公司 | 一种测试分析平台 |
CN108491329A (zh) * | 2018-04-02 | 2018-09-04 | 郑州云海信息技术有限公司 | 一种ssr客户端的性能测试方法及测试工具 |
CN109634850A (zh) * | 2018-11-29 | 2019-04-16 | 中国船舶重工集团公司第七0五研究所 | 一种用于自动测试***中快速搭建测试软件的方法 |
CN111209007A (zh) * | 2020-01-17 | 2020-05-29 | 济南浪潮高新科技投资发展有限公司 | 一种基于移动环境监控可控设备软件实现方法 |
CN111209007B (zh) * | 2020-01-17 | 2023-03-31 | 山东浪潮科学研究院有限公司 | 一种基于移动环境监控可控设备软件实现方法 |
CN117290190A (zh) * | 2023-11-27 | 2023-12-26 | 博为科技有限公司 | 一种串口日志远程采集方法、装置及存储介质 |
CN117290190B (zh) * | 2023-11-27 | 2024-02-13 | 博为科技有限公司 | 一种串口日志远程采集方法、装置及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102355384A (zh) | 一种用于监控***的自动化测试的通信规范 | |
US9641647B2 (en) | Communication protocol and system for network communications | |
US10963040B2 (en) | Generating storyboard for a knowledge base in virtual mobile management | |
US9202225B2 (en) | Aggregate monitoring of utilization data for vendor products in cloud networks | |
CN111835786A (zh) | 一种对多规约设备数据采集、设备控制的***及实现方法 | |
US7831959B1 (en) | Method and apparatus to manage configuration for multiple file server appliances | |
US20070213966A1 (en) | Traffic generator program | |
CN103338206B (zh) | 一种基于数据总线技术实现数据交换的方法及装置 | |
JP7453426B2 (ja) | ネットワーク管理システム、方法、装置及び電子機器 | |
US20150169392A1 (en) | System and method for providing an application programming interface intermediary for hypertext transfer protocol web services | |
CN107800565A (zh) | 巡检方法、装置、***、计算机设备和存储介质 | |
WO2021244644A1 (zh) | 动态整合应用程序的方法及其软件***与机器 | |
US8849947B1 (en) | IT discovery of virtualized environments by scanning VM files and images | |
CN108632111A (zh) | 一种基于日志的服务链路监控方法 | |
US20050286435A1 (en) | Remote management system | |
CN112738230B (zh) | 一种自动化网闸测试***及其工作方法 | |
CN107577820A (zh) | 数据处理的方法、设备及*** | |
CN107818268A (zh) | 大数据平台的访问控制方法及服务器 | |
CN108462598A (zh) | 一种日志生成方法、日志分析方法及装置 | |
US20180152313A1 (en) | Box for communication and management of devices | |
US11461218B1 (en) | Analyzing user API usage from recorded API macros for software product improvement | |
Evensen et al. | SenseWrap: A service oriented middleware with sensor virtualization and self-configuration | |
CN103581238A (zh) | 泛在网的统一业务平台及业务实现方法 | |
CN102281197A (zh) | 一种rfid路由器架构*** | |
CN114356704A (zh) | 一种面向云网端流式数据的软件定义方法和*** |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20120215 |