CN113572652B - 一种有线Mesh网络测试方法 - Google Patents

Abstract

本发明公开了一种有线Mesh网络测试方法，包括：设计有线Mesh网络虚拟设备框架；设计有线Mesh网络虚拟端口框架；设计有线Mesh网络的虚拟连接；设计有线Mesh网络的虚拟并发一跳；设计命令行交互接口。本发明将设备与端口的概念进行分离，打破了二者在传统物理观念上的绑定关系，从而可以用非常简单的代码实现非常复杂的组网场景。同时，本发明通过虚拟一跳的设计理念，避免了并发编程的复杂性，同步一跳模式可以模拟具备同步功能的有线Mesh组网，异步一跳模式也可以覆盖绝大多数的功能验证场景。整个测试框架非常简单，易于开发、维护和拓展，可以有效协助开发、测试人员开展相关工作，缩短项目周期，提高产品质量。

Description

一种有线Mesh网络测试方法

技术领域

本发明涉及网络通信技术领域，特别涉及一种有线Mesh网络测试方法。

背景技术

在工业互联网等嵌入式应用场景当中，有线Mesh网络会是未来的重要组网方式之一。有线Mesh网络的组网灵活性极强，这一方面大大拓宽了其应用领域，另一方面也给调试、测试等工作带来了极大的困难。传统的虚拟网络测试方法多采用并发编程，以一个线程或者进程来模拟一台网络设备，这导致资源开销大、测试框架开发和维护困难等问题。以上问题限制了有线Mesh网络在工业互联网等新兴应用场景下的产业化进程。

发明内容

本发明的目的在于提供一种有线Mesh网络测试方法，以克服现有技术中的不足。

为实现上述目的，本发明提供如下技术方案：

本申请公开了一种有线Mesh网络测试方法，具体包括如下步骤：

S1、设计有线Mesh网络虚拟设备框架并将虚拟设备框架实例化为虚拟设备；所述虚拟设备框架包括设备相关的信息和设备相关的接口；多个所述虚拟设备组成一个虚拟设备列表；

S2、设计有线Mesh网络虚拟端口框架并将虚拟端口框架实例化为虚拟端口；所述虚拟端口框架包括端口相关的信息和端口相关的接口；所述虚拟端口与所述虚拟设备之间存在多对多的关联或映射关系；

S3、设计有线Mesh网络的虚拟连接；

S4、设计有线Mesh网络的虚拟一跳；所述虚拟一跳包含同步模式和异步模式；

具体包括以下子步骤：

S41、设计配置接口：用于选择同步模式或者异步模式，同时设置虚拟一跳的延时时间；

S42、设计一个循环：在一个循环中，根据所述虚拟设备列表，将虚拟设备列表中部分或全部的虚拟设备的业务逻辑处理接口依次调用一遍；

S43、若所述配置接口配置为同步模式，则所述虚拟一跳采用同步一跳逻辑；

S44、若所述配置接口配置为异步模式，则所述虚拟一跳采用异步一跳逻辑；

S5、设计命令行交互接口；所述命令行交互接口具体包括命令行输入模块、命令行解析模块和命令行处理模块。

作为优选，所述设备相关的信息包括但不限于设备ID、设备端口数量、设备内存BUF；所述设备相关的接口包括但不限于设备初始化接口、设备状态获取接口、设备状态设置接口、设备连接接口、消息处理接口、业务逻辑处理接口；所述端口相关的信息包括但不限于端口ID、缓存BUF；所述端口相关的接口包括但不限于端口初始化接口、端口状态获取接口、端口状态设置接口、端口连接接口、端口读写网络消息接口。

作为优选，所述虚拟设备可以同时关联或映射多个虚拟端口；所述虚拟端口最多同时关联或映射不超过2个虚拟设备。

作为优选，所述步骤S3具体包括以下子步骤：

S31、获取虚拟连接的配置信息；

S32、根据虚拟连接的配置信息，将虚拟端口与对应的虚拟设备进行关联或映射，进而将不同的虚拟设备通过虚拟端口进行间接关联，从而实现虚拟连接；

作为优选，所述步骤S32中将不同的虚拟设备通过虚拟端口进行间接关联为以下方式中的一种：

S321、通过一个虚拟端口关联两个虚拟设备；

S322、通过两个虚拟端口，分别各自关联一个虚拟设备，再将两个虚拟端口之间再建立关联或映射关系；

作为优选，所述步骤S43具体包括如下子步骤：

S431、遍历所述虚拟设备列表，调用虚拟设备列表中虚拟设备的消息处理接口，将虚拟设备关联的虚拟端口中缓存的网络消息传入所述消息处理接口；

S432、将所述的消息处理接口在处理消息的过程中生成的待发送消息，按照目的设备和端口信息，写入对应的虚拟端口消息存储BUF当中；

S433、所述虚拟设备列表遍历完成后，按照配置的虚拟一跳的延时时间进行延时，延时完毕后一个循环结束，进入下一次虚拟一跳。

作为优选，所述步骤S44具体包括如下子步骤：

S441、针对虚拟设备列表中的虚拟设备设计调度机制，根据调度机制选择出部分虚拟设备；所述调度机制考虑优先级、时间片和随机性三个因素；

S442、遍历所述调度机制选择出的虚拟设备，调用虚拟设备的消息处理接口，将虚拟设备关联虚拟端口中缓存的网络消息传入所述消息处理接口；

S443、将所述的消息处理接口在处理消息的过程中生成的待发送消息，按照目的设备和端口信息，写入对应的虚拟端口消息存储BUF当中；

S444、所述调度机制选择出的虚拟设备遍历完成后，按照配置的虚拟一跳的延时时间进行延时，延时完毕后一个循环结束，进入下一次虚拟一跳。

本发明的有益效果：与现有技术相比，本发明提供一种有线Mesh网络测试方法，以解决现有测试方法成本高、操作复杂、测试框架开发和维护难度大等问题。本发明通过将设备与端口的概念进行分离，打破了二者在传统物理观念上的绑定关系，从而可以用非常简单的代码实现非常复杂的组网场景。同时，本发明通过虚拟一跳的设计理念，避免了并发编程的复杂性，同步一跳模式可以模拟具备同步功能的有线Mesh组网，异步一跳模式也可以覆盖绝大多数的功能验证场景。整个测试框架非常简单，易于开发、维护和拓展，可以有效协助有线Mesh网络的开发人员快速验证路由收敛性等基本功能，高效地反馈代码修改后的运行效果；也可以协助测试人员部署自动化测试，进行测试场景覆盖以及问题定位等工作。

本发明的特征及优点将通过实施例结合附图进行详细说明。

附图说明

图1是本发明实施例提供的一种有线Mesh网络测试方法的流程图。

图2是虚拟设备框架及其实现方式示意图。

图3是虚拟端口框架及其实现方式示意图。

图4是通过一个虚拟端口实现虚拟连接示意图。

图5是通过两个虚拟端口实现虚拟连接示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明了，下面通过附图及实施例，对本发明进行进一步详细说明。但是应该理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限制本发明的范围。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本发明的概念。

参考图1，本发明实施例提供一种有线Mesh网络测试方法，包括：

步骤S1，设计有线Mesh网络虚拟设备框架并将虚拟设备框架实例化为虚拟设备；

具体的，参考图2，虚拟设备框架包括但不限于设备ID、端口数量、内存BUF等设备相关的信息，也包括但不限于设备初始化、设备状态获取或设置、设备连接、接收或发送消息等设备相关的接口；虚拟设备框架的一个实例化，即为有线Mesh网络中的一个虚拟设备；所有实例化的虚拟设备组成一个虚拟设备列表。

虚拟设备框架可以通过C语言的结构体实现，也可以通过C++或其他面向对象编程语言的类实现，后者应用起来更加直观。以C++语言为例，一个虚拟设备的类即为虚拟设备框架，用该类实例化一个对象即为一个虚拟设备。参考图2，VirtualDevice类当中包含了设备ID、设备端口数量、设备内存BUF等私有元素，也包含了设备初始化、设备状态获取、设备状态设置、设备连接、消息处理、业务逻辑处理等接口，这些元素和接口可以根据实际应用需求进行扩展。实际应用时，可以在整体测试系统初始化的时候将虚拟设备类进行实例化，也可以通过后述的命令行系统添加设备时进行实例化，实例化后的虚拟设备组成一个虚拟设备列表，该列表可以通过C++的集合来管理，也可以通过链表等其他方式来管理。

步骤S2，设计有线Mesh网络虚拟端口框架并将虚拟端口框架实例化为虚拟端口；

具体的，参考图3，虚拟端口框架包括但不限于端口ID、缓存BUF等端口相关的信息，也包括但不限于端口初始化、端口状态获取或设置、端口连接、读写网络消息等端口相关的接口；虚拟端口框架的一个实例化，即为有线Mesh网络中的一个虚拟端口；虚拟端口与虚拟设备之间存在多对多的关联或映射关系；所述虚拟设备可以同时关联或映射多个虚拟端口；所述虚拟端口最多同时关联或映射不超过2个虚拟设备。

此处的虚拟端口模拟的是实际设备上的网口，一般包含MAC驱动、PHY驱动和网口插座等部分组成，实际应用时则是通过MCU或者FPGA等读写MAC/PHY驱动的寄存器来实现，这些寄存器主要用到了控制寄存器、状态寄存器和缓存寄存器这三类。

以C++实现虚拟端口框架为例，一个虚拟端口的类即为虚拟端口框架，用该类实例化一个对象即为一个虚拟端口。参考图3，VirtualPort类当中包含了端口ID、端口BUF状态等私有成员，可以起到状态寄存器的作用。VirtualPort类还包含了数量和长度不等的BUF，这些BUF的具体参数可以按照实际应用场景的复杂程度来进行调整和扩展，此处模拟的是缓存寄存器的作用。比较特殊的是控制寄存器的虚拟化，由于实际设备的控制寄存器的读写对应的其实是设备自身的一个具体动作，这个映射关系由芯片或处理器内部逻辑实现，而此处则没必要进行这样一个映射，直接以VirtualPort类当中的成员函数接口即可代替。

虚拟设备可以同时关联或映射多个虚拟端口，对应的是一个有线Mesh网络设备往往具备多个物理网口。而虚拟端口最多同时关联或映射不超过2个虚拟设备，当虚拟端口只关联或映射1个虚拟设备时，此时的虚拟端口就可以理解成实际物理网口的虚拟化；当虚拟端口关联或映射2个虚拟设备时，此时的虚拟端口可以理解成实际网口对的虚拟化。实际场景当中的两个有线Mesh网络设备之间肯定是通过各自的一个网口——中间加一条网线——对接，用一个虚拟端口模拟网口对，可以更加节省资源，简化操作，但是不利于理解。具体的虚拟设备与虚拟网口之间的关联或映射方式要视具体情况并结合后述的虚拟链接方法而确定。

对虚拟端口框架进行实例化，获得虚拟端口。

虚拟端口框架实例化的过程会发生在两个阶段：初始化阶段和运行阶段。以C++实现本发明为例，初始化阶段虚拟端口框架实例化可以在主函数的while(1)循环之前，模拟的是真实的有线Mesh网络设备先通过网线连在一起，然后同时上电的场景。在运行阶段进行虚拟端口框架实例化需要后述的命令行模块配合，通过命令行模块在解析到虚拟连接的命令行时，命令行模块也可以触发虚拟端口框架的实例化，模拟的是真实的有线Mesh网络热插拔的场景。

每一个虚拟端口在实例化时，会分配一个端口ID，对该端口进行唯一性标识。针对端口ID的分配可以建立一个全局数组，记录当前已有ID；有新的端口生成则添加ID；有端口删除则释放对应ID。

所有实例化的虚拟端口的管理可以通过一个全局集合或者链表来进行。

步骤S3，设计有线Mesh网络的虚拟连接，具体包含以下子步骤：

步骤S31、获取虚拟连接的配置信息。

以C++实现本发明为例，获取配置信息最简单的实现方式，是在调用虚拟连接函数接口时通过函数参数直接传入，但这样不利于多场景扩展以及复杂命令行交互等需求。一种更好的实现是采用共享内存或者共享配置文件的方式，主函数的while(1)循环每次开始时扫描共享内存或者配置文件，如果扫描到配置信息的更新，则调用相关接口将虚拟连接的配置信息保存到虚拟端口的成员变量当中。

步骤S32、根据网络连接配置，将虚拟端口与对应的虚拟设备进行关联或映射，进而将不同的虚拟设备通过虚拟端口进行间接关联，从而实现虚拟连接。

具体的，步骤S32可以采用以下两种方式中的一种。

S321、通过所述的虚拟端口关联两个虚拟设备。

这种方式对应的S2步骤当中一个虚拟端口关联或映射2个虚拟设备的情况。具体的，参考图4，以C++实现本发明为例，virtual_dev_1和virtual_dev_2是VirtualDevice类实例化的虚拟设备对象，virtual_port_1是VirtualPort类实例化的虚拟端口对象。如步骤S1当中描述的，VirtualDevice类当中有一个记录端口ID的集合的成员变量m_portidset，在参考图4的虚拟连接状态下，virtual_dev_1和virtual_dev_2的m_ portidset当中都会增加virtual_port_1的端口ID。VirtualPort类当中也增加m_devid1和m_devid2两个成员变量，分别记录virtual_dev_1和设备virtual_dev_2的设备ID，并且m_devid1与m_msgbuf_1绑定、m_devid2与m_msgbuf_2绑定，由此 virtual_dev_1和设备virtual_dev_2这两个设备的虚拟连接就搭建完成。

当virtual_dev_1要向virtual_dev_2发送消息时，首先从自己的m_portidset中找到virtual_port_1的端口ID，通过该端口ID从虚拟端口全局列表当中获得virtual_port_1的地址，向virtual_port_1的m_msgbuf_1当中写入消息，并向m_msglen_1当中写入消息长度。简单场景下消息的收发可以是一对一的，也可以将m_msgbuf_1设计成一个队列，从而覆盖复杂的消息收发场景。virtual_dev_2会循环扫描自己m_ portidset当中记录的虚拟端口，查看自身以外其他设备ID绑定的消息BUF是否有未读的消息，如果有则取出来，并且将相应的标志位清零。由此virtual_dev_1发送、virtual_dev_2接收消息的过程已完成，virtual_dev_2向virtual_dev_1发送消息的过程亦可类推。

S322、通过两个虚拟端口，分别各自关联一个虚拟设备，再将两个虚拟端口之间再建立关联或映射关系。

这种方式对应的S2步骤当中虚拟端口只关联或映射1个虚拟设备的情况。具体的，参考图5，以C++实现本发明为例，virtual_dev_1和virtual_dev_2是VirtualDevice类实例化的虚拟设备对象，virtual_port_1和virtual_port_2是VirtualPort类实例化的虚拟端口对象。virtual_dev_1的m_portidset当中保存着virtual_port_1的端口ID，virtual_dev_2的m_portidset当中保存着virtual_port_2的端口ID。同时，virtual_port_1和virtual_port_2也通过成员变量m_linkportid保存对方的端口ID。由此 virtual_dev_1和设备virtual_dev_2这两个设备的虚拟连接就搭建完成。

当virtual_dev_1要向virtual_dev_2发送消息时，首先从自己的m_portidset中找到virtual_port_1的端口ID，通过该端口ID从虚拟端口全局列表当中获得virtual_port_1的地址，向virtual_port_1的m_msgbuf当中写入消息，并向m_msglen当中写入消息长度。此处的m_msgbuf和m_msglen也可以设计成队列的形式，从而满足复杂交互场景。virtual_dev_2会循环扫描自己m_ portidset当中记录的虚拟端口，再通过虚拟端口的m_linkportid查看对端端口的消息缓存当中是否有未读的消息，如果有则取出来，并清空相关的标志位。由此virtual_dev_1发送、virtual_dev_2接收消息的过程已完成，virtual_dev_2向virtual_dev_1发送消息的过程亦可类推。

步骤S4、设计有线Mesh网络的虚拟一跳；所述虚拟一跳包含同步模式和异步模式；具体包含以下子步骤：

S41、设计配置接口：用于选择同步模式或者异步模式，同时设置虚拟一跳的延时时间；

此处的配置接口有多种实现方法，最简单的一种是直接以两个全局变量存储模式和延时信息，该配置接口只需改动这两个信息即可完成配置。

配置接口的使用可以跟后述的命令行模块相结合，在解析到相关的配置命令行时，调用该接口。

S42、设计一个循环，所述循环的单次循环过程即为虚拟一跳；

“一跳”指的是实际组网场景当中所有真实的有线Mesh网络设备并发执行一次业务逻辑的过程。“虚拟一跳”采用了并行转串行这样一种时序逻辑的理念，在一个循环当中，按照步骤S1所述的虚拟设备列表，把部分或全部虚拟设备的业务逻辑处理接口依次调用一遍。由此，可以摆脱对并发编程的依赖，一方面节省资源开销，另一方面降低了测试框架的设计和维护难度。

S43、若所述配置接口配置为同步模式，则所述虚拟一跳当中采用同步一跳逻辑，具体包含以下子步骤：

S431、遍历虚拟设备列表，调用虚拟设备的业务逻辑处理接口，扫描自身关联的虚拟端口，根据虚拟连接方式，将其他虚拟设备发给自身的消息读取出来，并传递给有线Mesh网络协议栈进行处理。

所述的有线Mesh网络协议栈即为本发明测试方法的被测对象。以C++实现本发明为例，可以设计一个有限Mesh网络协议栈的类WiredMesh，从而把协议栈所需要的所有资源进行封装。在VirtualDevice类当中，也要包含一个m_wiredmesh的私有成员，该成员就是WiredMesh类的对象。由此，模拟每一个真实的有线Mesh网络设备当中运行的协议栈。

一般协议栈的逻辑，都是从消息接收和传入开始，因而虚拟一跳当中调用的虚拟设备业务逻辑处理接口，其主要的动作也是读取接收到的消息，然后传入有线Mesh网络协议栈进行处理。

S432、将所述的消息处理接口在处理消息的过程中生成的待发送消息，按照目的设备和端口信息，写入对应的所述虚拟端口消息存储BUF当中。

以C++实现本发明为例，VirtualDevice类当中的逻辑处理接口会调用WiredMesh类当中的消息处理和消息发送接口，消息发送接口会生成从指定的物理网口号发送出去的消息。VirtualDevice类的m_ portidset当中记录的虚拟端口ID与实际物理网口号存在映射关系，最简单的一种映射就是通过m_ portidset当中的成员位置进行，例如集合中的第一个虚拟端口ID对应着实际物理网口1，第二个虚拟端口ID对应着实际物理网口2等等。这样，待发送的消息可以通过m_ portidset当中记录的虚拟端口ID，按照虚拟连接的具体方式，将消息拷贝到对应的buf当中，等待下一跳由消息接收方进行读取。

S433、所述虚拟设备遍历完成后，按照所述配置的单跳延时时间进行延时，延时完毕后单次循环结束，进入下一跳。

S44、若所述配置接口配置为异步模式，则所述虚拟一跳当中采用异步一跳逻辑。具体的，包含以下子步骤：

S441、针对实例化的虚拟设备列表中的虚拟设备设计调度机制，所述调度机制考虑优先级、时间片和随机性三个因素。

以C++实现本发明为例，在VirtualDevice类当中增加m_priority私有成员变量，该变量既标记着优先级又标记着时间片两个信息。m_priority为一个字符变量，最大值为255，但一般只设置为1-10之间，如果设置为0，则该设备会是一个仅支持同步一跳模式的设备，在异步一跳模式当中，将永远不会被调度。

在VirtualDevice类实例化时，需要设置m_priority值的大小，如果用户没有设置，则自动初始化为5。

设置两个随机数randnum和randstart，二者的取值范围是[1:已实例化的虚拟设备总数]。随机数randnum是用来决定当前异步一跳将会调度的设备总数，随机数randstart是用来决定从实例化的虚拟设备列表当中的第几个设备位置开始调度。例如，当前虚拟设备列表当中一共有10个设备，分别为dev0-dev9，当前异步一跳当中randnum=4、randstart=6，那么也就是从dev5开始往后选取4个优先级最高的设备。

每一次选取的时候，都是从m_priority值最大的开始选择；设备被选出来以后，则m_priority值减一；当m_priority值被减为零时，再恢复到初始的设置值，这样所有的设备最终都会被调度，m_priority既起到了优先级的作用，也起到了时间片的作用。

假设当前有五个设备，分别为dev1-dev5，各个设备的优先级也分别设置为1-5。假设第一跳randnum=3、randstart=2，那么这一跳被调度出来的为dev5、dev4、dev3，此时各个设备的m_priority值为[1,2,2,3,4];第二跳randnum=1、randstart=3，那么这一跳被调度出来的为dev5，各个设备的m_priority值为[1,2,2,3,3];第三跳randnum=1、randstart=5，这一跳被调度出来的还是dev5而非dev4，尽管此时二者m_priority值相同，调度完后各设备的m_priority值为[1,2,2,3,2]；第四跳randnum=5、randstart=3，那么调度出来的为dev4、dev5、dev2、dev3、dev1，调度完后各个设备的m_priority值为[0,1,1,2,1]，此时dev1的m_priority值已经减到零，那么在下一跳调度的时候，会重新恢复为初始设定值1。

S442、遍历所述的调度机制选择出的虚拟设备，调用虚拟设备的消息处理接口，将关联的所述虚拟端口当中缓存的网络消息传入所述消息处理接口。

该步骤与S431的过程类似，所不同的是S431遍历整个虚拟设备列表，S442只遍历经S441步骤调度出来的虚拟设备。

S443、将所述的消息处理接口在处理消息的过程中生成的待发送消息，按照目的设备和端口信息，写入对应的所述虚拟端口消息存储BUF当中。

S444、所述虚拟设备遍历完成后，按照所述配置的单跳延时时间进行延时，延时完毕后单次循环结束，进入下一跳。

S5、设计命令行交互接口，具体包含以下子模块：

S51、命令行输入模块。

命令行输入模块的实现方式有多种，最简单的是通过键盘按键扫描或者中断来阻塞原业务逻辑，然后通过各种编程语言集成的键盘字符输入来实现。

S52、命令行解析模块。

设计命令行解析模块要首先设计命令行的格式，最简单的命令行格式可以参考linux shell，为命令+参数的形式，一个命令后面可以带多个参数，命令和参数之间、参数和参数之间以空格分隔开来。

命令行也可以设计成JSON格式，这样命令行的解析可以参考引用成熟的JSON库来实现，减少工作量。

S53、命令行处理模块。

命令行处理模块是在解析得到用户输入的命令和参数后，再执行对应的动作，并返回相应的结果。

以C++实现本发明为例，当命令行输入模块得到用户输入“add device deviceid-000 priority-10 portnum-4”的字符串（命令行的格式可以灵活多样），命令行解析模块可以将命令“add”及其所有参数解析存入一个链表或其他存储结构当中，命令行处理模块在得到这些信息后，会调用步骤S1当中虚拟设备类的实例化接口，实例化一个设备id为000、优先级为10、端口数量为4的虚拟设备，并添加到虚拟设备列表当中。

当命令行输入模块得到用户输入“link deviceid-000 port-3 deviceid-001port2”的字符串，命令行解析完成后，命令行处理模块会调用步骤S3，将设备ID为000的网口3与设备ID为001的网口2建立虚拟连接。

除了上述的命令以外，也可以设计发送指定消息、查看设备状态、查看设备协议栈路由表等等命令，从而满足测试的需求。

以上所述的有线Mesh网络测试方法的具体实施例，可以满足对Mesh网络进行虚拟化测试的功能。本发明通过将设备与端口的概念进行分离，打破了二者在传统物理观念上的绑定关系，从而可以用非常简单的代码实现非常复杂的组网场景。同时，本发明通过虚拟一跳的设计理念，避免了并发编程的复杂性，同步一跳模式可以模拟具备同步功能的有线Mesh组网，异步一跳模式也可以覆盖绝大多数的功能验证场景。整个测试框架非常简单，易于开发、维护和拓展，可以有效协助有线Mesh网络的开发人员快速验证路由收敛性等基本功能，高效地反馈代码修改后的运行效果；也可以协助测试人员部署自动化测试，进行测试场景覆盖以及问题定位等工作。

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

Claims (7)

1.一种有线Mesh网络测试方法，其特征在于，具体包括如下步骤：

S1、设计有线Mesh网络虚拟设备框架并将虚拟设备框架实例化为虚拟设备；所述虚拟设备框架包括设备相关的信息和设备相关的接口；多个所述虚拟设备组成一个虚拟设备列表；

S2、设计有线Mesh网络虚拟端口框架并将虚拟端口框架实例化为虚拟端口；所述虚拟端口框架包括端口相关的信息和端口相关的接口；所述虚拟端口与所述虚拟设备之间存在多对多的关联或映射关系；

S3、设计有线Mesh网络的虚拟连接；

S4、设计有线Mesh网络的虚拟一跳；所述虚拟一跳包含同步模式和异步模式；具体包括以下子步骤：

S41、设计配置接口：用于选择同步模式或者异步模式，同时设置虚拟一跳的延时时间；

S42、设计一个循环：在一个循环中，根据所述虚拟设备列表，将虚拟设备列表中部分或全部的虚拟设备的业务逻辑处理接口依次调用一遍；

S43、若所述配置接口配置为同步模式，则所述虚拟一跳采用同步一跳逻辑；

S44、若所述配置接口配置为异步模式，则所述虚拟一跳采用异步一跳逻辑；

S5、设计命令行交互接口；所述命令行交互接口具体包括命令行输入模块、命令行解析模块和命令行处理模块。

2.如权利要求1所述的一种有线Mesh网络测试方法，其特征在于：所述设备相关的信息包括但不限于设备ID、设备端口数量、设备内存BUF；所述设备相关的接口包括但不限于设备初始化接口、设备状态获取接口、设备状态设置接口、设备连接接口、消息处理接口、业务逻辑处理接口；所述端口相关的信息包括但不限于端口ID、缓存BUF；所述端口相关的接口包括但不限于端口初始化接口、端口状态获取接口、端口状态设置接口、端口连接接口、端口读写网络消息接口。

3.如权利要求1所述的一种有线Mesh网络测试方法，其特征在于：所述虚拟设备可以同时关联或映射多个虚拟端口；所述虚拟端口最多同时关联或映射不超过2个虚拟设备。

4.如权利要求1所述的一种有线Mesh网络测试方法，其特征在于，所述步骤S3具体包括以下子步骤：

S31、获取虚拟连接的配置信息；

S32、根据虚拟连接的配置信息，将虚拟端口与对应的虚拟设备进行关联或映射，进而将不同的虚拟设备通过虚拟端口进行间接关联，从而实现虚拟连接。

5.如权利要求4所述的一种有线Mesh网络测试方法，其特征在于，所述步骤S32中将不同的虚拟设备通过虚拟端口进行间接关联为以下方式中的一种：

S321、通过一个虚拟端口关联两个虚拟设备；

S322、通过两个虚拟端口，分别各自关联一个虚拟设备，再将两个虚拟端口之间再建立关联或映射关系。

6.如权利要求1所述的一种有线Mesh网络测试方法，其特征在于，所述步骤S43具体包括如下子步骤：

S431、遍历所述虚拟设备列表，调用虚拟设备列表中虚拟设备的消息处理接口，将虚拟设备关联的虚拟端口中缓存的网络消息传入所述消息处理接口；

S432、将所述的消息处理接口在处理消息的过程中生成的待发送消息，按照目的设备和端口信息，写入对应的虚拟端口消息存储BUF当中；

S433、所述虚拟设备列表遍历完成后，按照配置的虚拟一跳的延时时间进行延时，延时完毕后一个循环结束，进入下一次虚拟一跳。

7.如权利要求1所述的一种有线Mesh网络测试方法，其特征在于，所述步骤S44具体包括如下子步骤：

S441、针对虚拟设备列表中的虚拟设备设计调度机制，根据调度机制选择出部分虚拟设备；所述调度机制考虑优先级、时间片和随机性三个因素；

S442、遍历所述调度机制选择出的虚拟设备，调用虚拟设备的消息处理接口，将虚拟设备关联虚拟端口中缓存的网络消息传入所述消息处理接口；

S443、将所述的消息处理接口在处理消息的过程中生成的待发送消息，按照目的设备和端口信息，写入对应的虚拟端口消息存储BUF当中；

S444、所述调度机制选择出的虚拟设备遍历完成后，按照配置的虚拟一跳的延时时间进行延时，延时完毕后一个循环结束，进入下一次虚拟一跳。

Images