CN103684913B - 协议栈的测试方法、物理设备、终端和系统 - Google Patents

Abstract

本发明提供了协议栈的测试方法、物理设备、终端和系统，以解决现有协议栈测试中测试不准确的问题。所述的方法包括：物理设备接收终端发送的第一测试数据；所述物理设备对所述第一测试数据的数据头进行解析；所述物理设备按照解析的结果对所述第一测试数据进行协议栈测试，并反馈测试过程中产生的交互数据给终端，以使终端通过所述交互数据确定协议栈测试状态。在物理设备的实际硬件环境进行协议栈的测试，能够获取准确的测试结果，且通过物理设备与终端的交互可以控制协议栈的测试并确定测试状态，从而及时的了解测试过程，准确的对测试进行分析并调试。

Description

协议栈的测试方法、物理设备、终端和系统

技术领域

本发明涉及通信技术领域，特别是涉及一种协议栈的测试方法，一种物理设备、一种终端，以及一种协议栈的测试系统。

背景技术

协议栈（Protocol Stack）是指网络中各层协议的总和，其形象的反映了一个网络中文件传输的过程：由上层协议到底层协议，再由底层协议到上层协议。则协议栈的开发可以理解为用程序语言将协议栈中的各层协议表示为机器语言，从而使物理设备可以基于该协议栈实现数据的传输。

在协议栈的开发过程中，需要对协议栈进行测试以确定协议的运行状况，进而对协议栈进行调试。通常是在个人计算机（Personal Computer，PC）上模拟硬件环境，从而在PC端上实现对协议栈的测试，但是，PC端中模拟的硬件环境通常是理想化的，而实际上物理设备中常常会出现各式各样的问题，因此PC并不能模拟出真实的硬件环境，例如，PC系统不是实时、抢占式操作系统，而真实的物理设备具有实时，抢占式特点，所以在线程的切换及执行顺序上，PC端模拟不出真实的物理环境。导致对协议栈的测试结果不准确，无法对协议栈进行准确的调试。

为了解决上述问题，可以将协议栈放入真实的物理设备，利用实际使用中出现的各种场景，对设备进行测试。但是，上述过程是由物理设备独立且自行控制的，测试方法比较复杂且不灵活，无法及时的了解测试过程，以及测试过程中产生的数据，导致无法准确的对测试结果进行分析，从而无法对协议栈进行准确的调试。

发明内容

本发明提供了一种协议栈的测试方法，以解决现有协议栈测试中测试不准确的问题。

相应的，本发明实施例还提供了一种物理设备、一种终端，以及一种协议栈的测试系统。

为了解决上述问题，本发明实施例公开了一种协议栈的测试方法，包括：

物理设备接收终端发送的第一测试数据；

所述物理设备对所述第一测试数据的数据头进行解析；

所述物理设备按照解析的结果对所述第一测试数据进行协议栈测试，并反馈测试过程中产生的交互数据给终端，以使终端通过所述交互数据确定协议栈测试状态。

本发明实施例还公开了一种物理设备，包括：

设备接收模块，用于接收终端发送的第一测试数据；

设备解析模块，用于对所述第一测试数据的数据头进行解析；

设备测试模块，用于按照解析的结果对所述第一测试数据进行协议栈测试；

设备发送模块，用于反馈测试过程中产生的交互数据给终端，以使终端通过所述交互数据确定协议栈测试状态。

本发明实施例还公开了一种终端，包括：

终端发送模块，用于发送第一测试数据给物理设备；

终端接收模块，用于接收所述物理设备反馈的交互数据，其中所述交互数据是所述物理设备对所述第一测试数据执行协议栈测试过程中产生的；

终端分析模块，用于对接收的所述交互数据进行分析，确定协议栈测试状态。

本发明实施例还公开了一种协议栈的测试系统，其特征在于，包括：上述物理设备，以及上述终端。

与现有技术相比，本发明包括以下优点：

采用物理设备接收终端发送的第一测试数据并对第一测试数据进行解析，从而依据解析结果对第一测试数据进行协议栈测试，并反馈测试过程中产生的交互数据给终端以使终端可以确定协议栈测试的状态。在物理设备的实际硬件环境进行协议栈的测试，能够获取准确的测试结果，且通过物理设备与终端的交互可以控制协议栈的测试并确定测试状态，从而及时的了解测试过程，准确的对测试进行分析并调试。

附图说明

图1是本发明实施例一提供的物理设备侧的协议栈测试方法流程图；

图2是本发明实施例一提供的物理设备侧的协议栈测试方法可选流程图；

图3是本发明实施例二提供的终端侧的协议栈测试方法流程图；

图4是本发明实施例二提供的终端侧的协议栈测试方法可选流程图；

图5是本发明实施例提供的协议栈的测试方法中物理设备和终端交互示意图；

图6是本发明实施例三提供的物理设备结构图；

图7是本发明实施例三提供的物理设备可选结构图；

图8是本发明实施例三提供的终端结构图；

图9是本发明实施例三提供的终端可选结构图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

本发明实施例提供一种协议栈的测试方法，采用物理设备接收终端发送的第一测试数据并对第一测试数据进行解析，从而依据解析结果对第一测试数据进行协议栈测试，并反馈测试过程中产生的交互数据给终端以使终端可以确定协议栈测试的状态。在物理设备的实际硬件环境进行协议栈的测试，能够获取准确的测试结果，且通过物理设备与终端的交互可以控制协议栈的测试并确定测试状态，从而及时的了解测试过程，准确的对测试进行分析并调试。

实施例一

本实施例通过物理设备和终端的交互进行协议栈的测试，其中物理设备侧的操作步骤如下：

参照图1，给出了本发明实施例一提供的物理设备侧的协议栈测试方法流程图。

步骤101，物理设备接收终端发送的第一测试数据。

在物理设备和终端的交互进行协议栈的测试时，终端可以通过发送第一测试数据对协议栈测试进行控制，确定进行协议栈的哪部分测试，因此物理设备可以接收到终端发送的第一测试数据。

其中，物理设备指的是硬盘和系统所挂接的各种设备，物理设备是实际存在的，本发明实施例中在物理设备中运行协议栈，如时分同步码分多址（Time Division-Synchronous Code Division Multiple Access，TD-SCDMA）协议栈的TD-SCDMA终端，又如分时长期演进（Time Division Long Term Evolution，TD-LTE）协议栈的TD-LTE终端等。本发明实施例中，终端可以采用个人计算机等设备。

步骤102，物理设备对第一测试数据的数据头进行解析。

第一测试数据的数据头中包括本次测试的测试内容等信息，从而物理设备可以对接收的第一测试数据的数据头进行解析，从数据头中解析出测试的内容，进而确定本次测试涉及协议栈的哪些模块等信息。

步骤103，物理设备按照解析的结果对第一测试数据进行协议栈测试，并反馈测试过程中产生的交互数据给终端，以使终端通过交互数据确定协议栈测试状态。

然后物理设备依据解析的结果，即本次测试的测试内容，调用协议栈的相应模块（或协议层）对第一测试数据进行协议栈测试，在协议栈测试的过程中，需要协议栈中各模块协作处理，因此在各模块通过接口进行调用时会产生相应的交互数据，可以将该交互数据传输给终端，以使终端可以了解协议栈测试的各个环节以及测试的状态等信息，便于后续对协议栈进行调试。

综上所述，采用物理设备接收终端发送的第一测试数据并对第一测试数据进行解析，从而依据解析结果对第一测试数据进行协议栈测试，并反馈测试过程中产生的交互数据给终端以使终端可以确定协议栈测试的状态。在物理设备的实际硬件环境进行协议栈的测试，能够获取准确的测试结果，且通过物理设备与终端的交互可以控制协议栈的测试并确定测试状态，从而及时的了解测试过程，准确的对测试进行分析并调试。

在上述实施例的基础上，进一步详细论述协议栈的测试中物理设备侧的处理流程。

本发明实施例中，在物理设备中运行协议栈的协议进程中，创建一个基于传输控制协议（Transmission Control Protocol，TCP）通信的线程。这个线程可以用来接收、解析终端如测试PC端传送的数据，然后将数据转发给协议栈的其他模块进行处理。模块间的数据交互是通过协议中特有的通信接口，在这些接口调用时会将交互数据利用TCP通信抄送给测试PC端，通过PC端对交互数据的接收解析来查看协议的运行情况。具体步骤如下：

参照图2，给出了本发明实施例一提供的物理设备侧的协议栈测试方法可选流程图。

步骤201，物理设备接收终端发送的连接请求，并按照连接请求与终端建立连接。

在物理设备中建立一个基于TCP通信的线程，该线程运行首先会初始化，建立TCP服务端，可以采用SOCK_STREAM协议（即TCP协议）创建的套接字（socket）有利于数据的交互的安全，数据传输不会丢失，绑定一个固定的端口号0x2525，绑定端口号有助于PC客户端通过端口实现与服务端的连接，然后等待终端如PC端的连接。例如，采用如下方法创建TCP通信的线程，并初始化建立TCP服务端：

void test_target_socket_init(void)

{

sfp_test_target_tcp=socket(AF_INET,SOCK_STREAM,0);//创建SOCK_STREAM

src_add_test_target.sin_family=AF_INET;

src_add_test_target.sin_addr.s_addr=htonl(INADDR_ANY);

src_add_test_target.sin_port=htons(port_test_target);

bzero(&(src_add_test_target.sin_zero),8);

bind(sfp_test_target_tcp,(struct sockaddr*)(&src_add_test_target),sizeof(struct sockaddr);//绑定的端口，port_test_target=0x2525

listen(sfp_test_target_tcp,20);

}

在初始化成功后，物理设备可以接收PC端发送的连接请求，物理设备根据该链接请求与PC端建立连接。

步骤202，物理设备循环接收终端发送的第一测试数据。

步骤203，物理设备从第一测试数据中获取数据头。

步骤204，物理设备对数据头中携带的参数进行解析，确定待执行的功能函数。

步骤205，物理设备按照功能函数调用协议栈的各模块对第一测试数据进行协议栈测试。

连接成功后物理设备循环接收PC端发送的第一测试数据，本发明实施例中数据的接收采用阻塞方式，即当PC端没有第一测试数据等消息发送到物理设备时，recv函数将阻塞等待数据；当PC端断开连接后，recv函数将不再阻塞等待，接收的消息长度length一直为0，这时需要重新跳转到loop处等待PC端的再次连接。

物理设备在接收PC发送的第一测试数据时，首先会接收三个字节的数据头，通过对数据头进行解析可以判断协议栈测试的测试内容，即本次测试待执行的功能函数，如：

readbuf[0]=5，readbuf[1]=5，readbuf[2]=1，将执行CopySendReadfun()函数；

readbuf[0]=5，readbuf[1]=5，readbuf[2]=2，将执行ACHReadfun()函数；

readbuf[0]=5，readbuf[1]=5，readbuf[2]=4，将执行Rexefun()函数；

readbuf[0]=5，readbuf[1]=5，readbuf[2]=8，将执行Registerfun()函数；

不同的功能函数具备不同的功能，在协议栈测试时采用不同的功能函数会调用不同的模块，下面举例介绍其中几种功能函数的功能：

CopySendReadfun()功能函数：CopySendReadfun函数接收PC端使用Copysend函数发送的消息，CopySendReadfun接收完消息后将消息送到协议栈中模块的消息队列中，协议栈的模块取自己的消息队列内容进行处理；PC端调用Copysend函数发送的消息到物理设备端，发送的消息头（三个字节）内容即是5、5、1。

ACHReadfun()功能函数介绍：ACHReadfun函数接收PC端使用的ACHSend函数发送的消息，ACHReadfun接收完消息后将消息进行处理后，该处理功能可以改变协议栈中某些状态变量；PC端调用ACHSend函数发送的消息到物理设备端，发送的消息头（三个字节）内容即是5、5、2。

Rexefun()功能函数介绍：Rexefun()函数接收PC端使用的Rexe函数发送的消息，Rexefun接收完消息后将消息进行处理，该处理功能是执行接收到消息内容中指定的函数，因为PC端使用Rexe发送的消息内容即是协议栈中的一个函数名称字符串，可以理解为PC端远程调用协议执行函数的功能；PC端调用Rexe函数发送的消息到物理设备端，发送的消息头（三个字节）内容即是5、5、4。

Registerfun()功能函数介绍：Registerfun()函数接收PC端使用的Register函数发送的消息，Registerfun接收完消息后将消息进行处理，该处理功能是屏蔽协议栈中某个模块的启动功能，因为协议栈中会有多个模块在运行，比如无线资源控制协议（RadioResource Control，RRC），介质访问控制（Media Access Controlmac，MAC）等模块，PC端使用Register发送的消息内容即是协议栈中某个模块的标识（Identity，ID）值，Registerfun根据模块ID关闭相应模块的功能；PC端调用Register函数发送的消息到物理设备端，发送的消息头（三个字节）内容即是5、5、8。

从而采用如下的阻塞方式进行第一测试数据的接收，并在接收第一测试数据后进行第一测试数据的解析等操作。

loop:（loop处，pc端断开后，tcp通信线程将跳转到该处等待PC端连接）

上述实施例仅提供了几种功能函数的协议栈测试方法，此处仅用于举例论述，不应理解为是对本实施例的限制。

本发明实施例中，会首先接收第一测试数据的数据头，在解析出数据头对应的功能函数后，可以仅进入该功能函数的测试处理，此后继续接收第一测试数据，并按照功能函数调用协议栈的各模块对第一测试数据进行协议栈测试。

步骤206，协议栈测试时，物理设备将协议栈中各模块的接口调用过程中产生的交互数据反馈给终端。

本发明一个可选实施例中，将协议栈中各模块的接口调用过程中产生的交互数据反馈给终端，包括：依据交互数据标识对协议栈中各模块的接口调用过程中产生的交互数据进行选择，并将选择的交互数据反馈给终端。

物理设备采用协议栈中各个模块协同进行协议栈测试时，模块间的数据交互是通过协议中特有的通信接口，从而可以将接口它调用过程中产生的交互数据选择性的抄送到PC端消息队列中，供PC端检查。

由于协议栈中有多个模块在同时运行，各个模块之间会进行消息通信，可以在调用的模块消息通信接口中使用物理设备端的Copysend函数将交互数据抄送到PC端，PC端接收后将交互数据存放在一个消息队列中。模块间所有的通信消息都会有一个特定的ID值来标识，所以在物理设备端的Copysend函数中可以根据交互数据的消息ID值来选择哪些ID的交互数据可以发送到PC端，哪些不需要发送到PC端。

其中，可以采用如下方式在物理设备端采用Copysend函数选择性的发送交互数据：

If(MessageID[msgID]==1)//选择性发送消息到PC端，如果该消息ID值对应的数组值为1，

{//则不发送

return0;

}

//定义数据头

databuf[0]=5;

databuf[1]=5;

databuf[2]=1;

//定义数据内容的参数

databuf[3]=src&0x000000FF;

databuf[4]=(src>>8)&0x000000FF;

databuf[5]=msgID&0x000000FF;

databuf[6]=(msgID>>8)&0x000000FF;

databuf[7]=dst&0x000000FF;

databuf[8]=(dst>>8)&0x000000FF;

databuf[9]=wCount&0x000000FF;

databuf[10]=(wCount>>8)&0x000000FF;

//先发送数据头及数据内容参数，长度为11个字节

bResult=send(sfp_test_target,databuf,11,0);

if(bResult!=11)//如果数据发送失败返回发送的实际长度

{

return bResult;

}

if(wCount!=0)//发送数据内容除参数外的数据内容

{

bResult=send(sfp_test_target,writebuf,wCount,0);

return bResult;//返回发送除参数外的数据内容长度

}

从而采用上述方法可以将交互数据选择性的反馈给终端。

综上所述，本实施例中终端和物理设备的芯片类型不同，因此该测试方法是一种跨芯片交互方法，可以将协议放在真实的物理设备中运行，通过PC端和物理设备中协议栈进行通信。从而即可以将协议栈放在真实的物理环境中，又可以在PC端控制测试协议内容，方便灵活，提高开发协议的效率。

其次，通过对数据头的解析确定本次的测试内容，即待执行的功能函数，依据该功能函数进行协议栈测试时需要协议栈的各模块协同完成，然后将协议栈中各模块的接口调用过程中产生的交互数据反馈给终端，使终端可以确定协议栈的测试状态，以便于后续对协议栈进行调试。

实施例二

上述实施例中提供了协议栈的测试中物理设备侧的处理步骤，下面继续论述终端侧的操作步骤：

参照图3，给出了本发明实施例二提供的终端侧的协议栈测试方法流程图。

步骤301，终端发送第一测试数据给物理设备。

在物理设备和终端的交互进行协议栈的测试时，终端可以通过发送第一测试数据对协议栈测试进行控制，确定进行协议栈的哪部分测试。

步骤302，终端接收物理设备反馈的交互数据。

其中，交互数据是物理设备对第一测试数据执行协议栈测试过程中产生的。物理设备对第一测试数据进行协议栈测试时，需要协议栈中各模块协作处理，且各模块在接口调用时会产生相应的交互数据，终端会接收到物理设备传输的交互数据。

步骤303，终端对接收的交互数据进行分析，确定协议栈测试状态。

终端在接收到交互数据后，可以对该交互数据进行分析，分析依据各功能函数进行测试时，协议栈中各模块接口调用时产生的交互数据是否准确等，从而了解在该接口调用时协议栈运行是否准确，确定协议栈测试状态，后续若需要对协议栈进行调试，则可以依据该分析结构快速的定位协议栈中出现问题的部分，快速的对协议栈进行调整。

综上所述，终端发送第一测试数据给物理设备，并接收接物理设备在协议栈测试过程中产生并反馈的交互数据，从而可以通过对交互数据进行分析，确定各接口调用时协议栈运行是否准确，进而确定协议栈测试状态，从而可以准确的掌握协议栈的测试过程，并在后续调试时快速定位协议栈中出现问题的部分，快速的对协议栈进行调整。

在上述实施例的基础上，进一步详细论述协议栈的测试中终端侧的处理流程。

与物理设备侧的处理操作类似，终端如PC端也可以建立TCP客户端与物理设备的TCP服务端进行交互。

参照图4，给出了本发明实施例二提供的终端侧的协议栈测试方法可选流程图。

步骤401，终端发送连接请求给物理设备。

PC端建立TCP客户端后，可以发送连接请求给物理设备的TCP服务端，在接收到物理设备的TCP服务端反馈后可以确定连接建立成功。其中一种PC端建立与物理设备的跨芯片交互的立方法如下：

建立PC客户端与物理设备的服务端连接；

struct sockaddr_in serv;

serv.sin_family=AF_INET;

serv.sin_port=htons(port);//物理设备的服务端端口

serv.sin_addr.s_addr=inet_addr(cp);//物理设备服务端的网络互连协议（Internet Protocol，IP）地址

//创建套接字

client=socket(AF_INET,SOCK_STREAM,0);

//连接物理设备的服务器

connect(client,(struct sockaddr*)&serv,sizeof(serv))

从而可以建立PC端与物理设备的连接后续可以进行PC端与物理设备的跨芯片交互。

步骤402，终端执行协议栈测试的测试用例获取第二测试数据，并按照物理设备的格式要求对第二测试数据进行转换生成第一测试数据。

PC端的TCP客户端与物理设备的TCP服务端连接建立成功后，PC端可以执行测试用例函数，用例函数中会选择使用哪些函数将对应的测试数据发送到物理设备端。

由于PC端和物理设备的芯片类型不同，因此需要建立跨芯片的交互。其中，数据内容在不同中央处理器（CentralProcessingUnit，CPU）存放的位置会不同，导致读取的数据容易不能够正确解析，因此在交互过程中要考虑传送的数据在两者之间是否存在字节序的不同，即大小端问题，如果存在，则需要在交互传输过程中对数据进行转换，即通过对数据大小端的转换，物理设备与PC端才可以识别对方发送的实际数据内容。其中，数据的数据大小端转换是由PC端执行的。

本发明实施例中，由于物理设备与PC端的CPU结构不同，数据存放的顺序不同，即计算机技术中大小端模式的概念，所谓的大端模式，是指数据的高位，保存在内存的低地址中，而数据的低位，保存在内存的高地址中；所谓小端模式，是指数据的高位保存在内存的高地址中，而数据的低位保存在内存的低地址中。

例如，同样的数据内容，存放在PC端内存中的顺序采用小端模式，存放在物理设备内存中的顺序采用大端模式，PC和物理设备识别数据的结果才能相同。因此为了数据内容被PC和物理设备识别相同，需要在发送前或接收后对数据进行转换。在发送测试数据时，调用testl2_message_hton功能函数，COPYSEND函数将转换后的数据发送给物理设备；而在接收到物理设备反馈的交互数据时，同样要将交互数据进行还原，因此还要调用testl2_message_hton函数。

实际处理中，testl2_message_hton函数可以通过参数确定数据转换的模式，如参数中第三个参数为1代表转换为大端模式，第三个参数为0代表转换为小端模式。

步骤403，终端发送第一测试数据给物理设备。

在终端完成测试数据的大小端转换后，可以将第一测试数据发送给物理设备。其中，PC端向物理设备发送交互数据时可以使用Copysend函数；

int CopySend(U16src,U16msgID,U16dst,void*writebuf,U16wCount)

{

testl2_message_hton(msgID,writebuf,1);

COPYSEND(src,msgID,dst,writebuf,wCount,0);

testl2_message_hton(msgID,writebuf,0);

return0;

}

步骤404，终端接收物理设备反馈的交互数据。

步骤405，终端按照终端的格式要求对交互数据进行转换。

步骤406，终端将转换后的交互数据存储的数据队列中。

PC端和物理设备端都使用Copysend函数将数据发送到对端，发送的消息格式相同。PC端发送的消息到物理设备端，物理设备端相应的模块将从消息队列中取出消息并执行处理。而物理设备端调用Copysend只是选择性的将物理设备端模块间交互的消息抄送到PC端检测。因此PC端循环接收物理设备在协议栈测试中接口调用产生的交互数据后，此后还要对数据进行大小端转换，然后将转换后的交互数据存入消息队列，后续可供PC端查询。

步骤407，终端从数据队列中获取转换后的交互数据。

步骤408，终端对转换后的交互数据进行分析，确定协议栈中各模块的接口调用过程中协议栈测试状态。

终端从数据队列中获取转换后的交互数据后，可以对交互数据进行分析，分析依据各功能函数进行测试时，协议栈中各模块接口调用时产生的交互数据是否准确等，从而了解在该接口调用时协议栈运行是否准确，确定协议栈测试状态，后续若需要对协议栈进行调试，则可以依据该分析结构快速的定位协议栈中出现问题的部分，快速的对协议栈进行调整。

其中，一种PC端接收物理设备的交互数据并分析的方法如下：

while(1)//循环接收物理侧协议栈发送的消息

从而通过上述方法，可以在接收交互数据后对数据进行分析，快速确定协议栈测试状态。

综上所述，本实施例中终端和物理设备的芯片类型不同，因此该测试方法是一种跨芯片交互方法，可以将协议放在真实的物理设备中运行，通过PC端和物理设备中协议栈进行通信。从而即可以将协议栈放在真实的物理环境中，又可以在PC端控制测试协议内容，方便灵活，提高开发协议的效率。

其次，终端和物理设备的芯片类型不同可能导致数据存储位置不同，因此终端在发送测试数据前以及接收交互数据后，可以对数据进行转换，从而便于物理设备与终端两端分别识别对方发送的实际数据内容。

在上述实施例的基础上，进一步从整体的角度论述物理设备和终端交互过程。

参照图5，给出了本发明实施例提供的协议栈的测试方法中物理设备和终端交互示意图。

5.01、物理设备建立TCP服务端，终端建立TCP客户端。

5.02、终端的TCP客户端发送连接请求给物理设备的TCP服务端。

5.03、物理设备依据连接请求建立与终端的连接。

5.04、终端调用测试用户获取第二测试数据。

5.05、终端对第二测试数据进行大小端转换生成第一测试数据。

5.06、终端将第一测试数据发送给物理设备。

5.07、物理设备解析接收的第一测试数据的数据头，获取本次测试中待执行的功能函数。

5.08、物理设备按照功能函数调用协议栈的各模块对第一测试数据进行协议栈测试。

5.09、物理设备获取协议栈测试时，协议栈中各模块的接口调用过程中产生的交互数据

5.10、物理设备将交互数据发送给终端。

5.11、终端对交互数据按照大小端模式进行转换。

5.12、终端将转换后的交互数据存储的数据队列中。

5.13、终端从数据队列中获取转换后的交互数据并分析，确定协议栈中各模块的接口调用过程中协议栈测试状态。

综上所述，本实施例提供了终端和物理设备的跨芯片交互方法，可以将协议放在真实的物理设备中运行，通过PC端和物理设备中协议栈进行通信。从而即可以将协议栈放在真实的物理环境中，又可以在PC端控制测试协议内容，方便灵活，提高开发协议的效率。

实施例三

参照图6，给出了本发明实施例三提供的物理设备结构图。

在上述实施例的基础上，本实施例还提供了一种物理设备，包括：设备接收模块601、设备解析模块602、设备测试模块603和设备发送模块604。

其中，设备接收模块601连接设备解析模块602，设备接收模块601用于接收终端发送的第一测试数据；设备解析模块602用于对第一测试数据的数据头进行解析；设备测试模块603分别连接设备解析模块602和设备发送模块604，设备测试模块603用于按照解析的结果对第一测试数据进行协议栈测试；设备发送模块604用于反馈测试过程中产生的交互数据给终端，以使终端通过交互数据确定协议栈测试状态。

综上，采用物理设备接收终端发送的第一测试数据并对第一测试数据进行解析，从而依据解析结果对第一测试数据进行协议栈测试，并反馈测试过程中产生的交互数据给终端以使终端可以通过协议栈测试状态。在物理设备的实际硬件环境进行协议栈的测试，能够获取准确的测试结果，且通过物理设备与终端的交互可以控制协议栈的测试并确定测试状态，从而及时的了解测试过程，准确的对测试进行分析并调试

参照图7，给出了本发明实施例三提供的物理设备可选结构图。

本发明一个可选实施例中，设备解析模块602包括：数据头获取子模块6021和解析子模块6022，其中，数据头获取子模块6021连接解析子模块6022，数据头获取子模块6021用于从第一测试数据中获取数据头；解析子模块6022用于对数据头中携带的参数进行解析，确定待执行的功能函数。

本发明一个可选实施例中，设备测试模块603用于按照功能函数调用协议栈的各模块对第一测试数据进行协议栈测试；设备发送模块604用于在协议栈测试时，将协议栈中各模块的接口调用过程中产生的交互数据反馈给终端。

本发明一个可选实施例中，设备发送模块604用于依据交互数据标识对协议栈中各模块的接口调用过程中产生的交互数据进行选择，并将选择的交互数据反馈给终端。

本发明一个可选实施例中，设备接收模块601包括：连接建立子模块6011和数据接收子模块6012，其中连接建立子模块6011连接数据接收子模块6012，连接建立子模块6011用于接收终端发送的连接请求，并按照连接请求与终端建立连接；数据接收子模块6012用于循环接收终端发送的第一测试数据，其中，第一测试数据是终端执行协议栈测试的测试用例获取的第二测试数据，并按照物理设备的格式要求对第二测试数据进行转换后获得的。

综上所述，通过对数据头的解析确定本次的测试内容，即待执行的功能函数，依据该功能函数进行协议栈测试时需要协议栈的各模块协同完成，然后将协议栈中各模块的接口调用过程中产生的交互数据反馈给终端，是终端可以确定协议栈的测试状态，以便于后续对协议栈进行调试。

参照图8，给出了本发明实施例三提供的终端结构图。

相应的，本发明实施例还提供了一种终端，包括：终端发送模块801、终端接收模块802和终端接收模块803。

其中，终端发送模块801用于发送第一测试数据给物理设备；终端接收模块802分别连接终端发送模块801和终端接收模块803，终端接收模块802用于接收物理设备反馈的交互数据，其中交互数据是物理设备对第一测试数据执行协议栈测试过程中产生的；终端分析模块803用于对接收的第一测试数据进行分析，确定协议栈测试状态。

综上，终端发送第一测试数据给物理设备，并接收接物理设备在协议栈测试过程中产生并反馈的交互数据，从而可以通过对交互数据进行分析，确定各接口调用时协议栈运行是否准确，进而确定协议栈测试状态，从而可以准确的掌握协议栈的测试过程，并在后续调试时快速定位协议栈中出现问题的部分，快速的对协议栈进行调整。

参照图9，给出了本发明实施例三提供的终端可选结构图。

本发明一个可选实施例中，终端发送模块801还用于发送连接请求给物理设备，以使物理设备按照连接请求建立连接；该终端还包括：用例执行模块804和转换模块805，用例执行模块804连接转换模块805，用例执行模块804用于终端执行协议栈测试的测试用例获取第二测试数据；转换模块805还连接终端发送模块801，转换模块805用于按照物理设备的格式要求对第二测试数据进行转换生成第一测试数据。

本发明一个可选实施例中，转换模块805还连接终端接收模块802，转换模块805用于按照终端的格式要求对交互数据进行转换；并将转换后的交互数据存储的数据队列中。

本发明一个可选实施例中，终端分析模块803用于终端从数据队列中获取转换后的交互数据；对转换后的交互数据进行分析，确定协议栈中各模块的接口调用过程中协议栈测试状态。

综上所述，终端和物理设备的芯片类型不同可能导致数据存储位置不同，因此终端在发送测试数据前以及接收交互数据后，可以对数据进行转换，从而便于物理设备与终端两C端识别对方发送的实际数据内容。

实施例四

在上述实施例的基础上，本实施例还提供了一种协议栈的测试系统，包括如上述实施例三提供的物理设备和终端。其中，关于物理设备和终端的论述与上述实施例基本一致，此处不再赘述。

综上所述，本实施例中终端和物理设备的芯片类型不同，因此该测试方法是一种跨芯片交互方法，可以将协议放在真实的物理设备中运行，通过PC端和物理设备中协议栈进行通信。从而即可以将协议栈放在真实的物理环境中，又可以在PC端控制测试协议内容，方便灵活，提高开发协议的效率。

对于系统实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本发明可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本发明，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上对本发明所提供的一种协议栈的测试方法，一种物理设备、一种终端，以及一种协议栈的测试系统，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (13)

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

物理设备接收与所述物理设备交互的终端发送的第一测试数据；

所述物理设备对所述第一测试数据的数据头进行解析；所述第一测试数据的数据头中包括本次测试的测试内容；

所述物理设备按照解析的结果对所述第一测试数据进行协议栈测试，并反馈测试过程中产生的交互数据给终端，以使终端通过所述交互数据确定协议栈测试状态。

2.根据权利要求1所述的方法，其特征在于，所述物理设备对所述第一测试数据的数据头进行解析，包括：

所述物理设备从所述第一测试数据中获取数据头；

对所述数据头中携带的参数进行解析，确定待执行的功能函数。

3.根据权利要求2所述的方法，其特征在于，所述物理设备按照解析的结果对所述第一测试数据进行协议栈测试，并反馈测试过程中产生的交互数据给终端，包括：

所述物理设备按照所述功能函数调用所述协议栈的各模块对所述第一测试数据进行协议栈测试；

协议栈测试时，将所述协议栈中各模块的接口调用过程中产生的交互数据反馈给所述终端。

4.根据权利要求1所述的方法，其特征在于，所述物理设备接收终端发送的第一测试数据，包括：

所述物理设备接收所述终端发送的连接请求，并按照所述连接请求与所述终端建立连接；

所述物理设备循环接收所述终端发送的第一测试数据，其中，所述第一测试数据是所述终端执行所述协议栈测试的测试用例获取的第二测试数据，并按照所述物理设备的格式要求对所述第二测试数据进行转换后获得的。

5.根据权利要求1所述的方法，其特征在于，所述终端通过所述交互数据确定协议栈测试状态包括：

所述终端按照所述终端的格式要求对所述交互数据进行转换，并将转换后的交互数据存储的数据队列中；

所述终端从所述数据队列中获取所述转换后的交互数据；

所述终端对所述转换后的交互数据进行分析，确定所述协议栈中各模块的接口调用过程中所述协议栈测试状态。

6.一种物理设备，其特征在于，包括：

设备接收模块，用于接收与所述物理设备交互的终端发送的第一测试数据；

设备解析模块，用于对所述第一测试数据的数据头进行解析；所述第一测试数据的数据头中包括本次测试的测试内容；

设备测试模块，用于按照解析的结果对所述第一测试数据进行协议栈测试；

设备发送模块，用于反馈测试过程中产生的交互数据给终端，以使终端通过所述交互数据确定协议栈测试状态。

7.根据权利要求6所述的物理设备，其特征在于，所述设备解析模块，包括：

数据头获取子模块，用于从所述第一测试数据中获取数据头；

解析子模块，用于对所述数据头中携带的参数进行解析，确定待执行的功能函数。

8.根据权利要求7所述的物理设备，其特征在于：

所述设备测试模块，用于按照所述功能函数调用所述协议栈的各模块对所述第一测试数据进行协议栈测试；

所述设备发送模块，用于在协议栈测试时，将所述协议栈中各模块的接口调用过程中产生的交互数据反馈给所述终端。

9.根据权利要求6所述的物理设备，其特征在于，所述设备接收模块，包括：

连接建立子模块，用于接收所述终端发送的连接请求，并按照所述连接请求与所述终端建立连接；

数据接收子模块，用于循环接收所述终端发送的第一测试数据，其中，所述第一测试数据是所述终端执行所述协议栈测试的测试用例获取的第二测试数据，并按照所述物理设备的格式要求对所述第二测试数据进行转换后获得的。

10.一种终端，其特征在于，包括：

终端发送模块，用于发送第一测试数据给与所述终端交互的物理设备；

终端接收模块，用于接收所述物理设备反馈的交互数据，其中所述交互数据是所述物理设备按照解析的结果对所述第一测试数据执行协议栈测试过程中产生的；所述解析的结果是由物理设备对所述第一测试数据的数据头进行解析得到的，所述第一测试数据的数据头中包括本次测试的测试内容，所述解析的结果是由所述物理设备对所述第一测试数据的数据头解析后得到的；

终端分析模块，用于对接收的所述交互数据进行分析，确定协议栈测试状态。

11.根据权利要求10所述的终端，其特征在于：

所述终端发送模块，还用于发送连接请求给所述物理设备，以使所述物理设备按照所述连接请求建立连接；

所述的终端还包括：

用例执行模块，用于执行所述协议栈测试的测试用例获取第二测试数据；

转换模块，用于按照所述物理设备的格式要求对所述第二测试数据进行转换生成所述第一测试数据。

12.根据权利要求11所述的终端，其特征在于：

所述转换模块，用于按照所述终端的格式要求对所述交互数据进行转换；并将转换后的交互数据存储的数据队列中；

所述终端分析模块，用于所述终端从所述数据队列中获取所述转换后的交互数据；对所述转换后的交互数据进行分析，确定所述协议栈中各模块的接口调用过程中所述协议栈测试状态。

13.一种协议栈的测试系统，其特征在于，包括：如权利要求6至9任一所述的物理设备，以及如权利要求10至12任一所述的终端。