CN116319245B - 面向5g协议的分布式测试系统 - Google Patents

Abstract

本发明提供了一种面向5G协议的分布式测试系统，包括系统基础层、主控制模块、附属控制模块。主控制模块包括应用层和中间层；中间层作为RPC框架客户端，负责RPC调用的构建和封装。附属控制模块包括分布层和服务层；服务层存储被测系统接口的网络层信息并向上层提供信令调用接口。分布层作为RPC框架服务端，用于和RPC框架客户端建立连接，接受RPC请求，并根据RPC请求调用服务层相应的信令接口。通过中间层、应用层和分布层机制的配合。采用异步非阻塞模型，服务端则采用同步阻塞模型，使得框架在支持测试用例高并发的同时也能确保测试序列的按序执行。解决控制的多个点间时序问题。

Description

面向5G协议的分布式测试系统

技术领域

本发明涉及5G协议测试领域，具体涉及一种面向5G协议的分布式测试系统。

背景技术

随着移动互联网的高速发展，越来越多的商用场景和设备依赖移动通信网络，5G作为目前最瞩目的移动通信技术，有着良好的发展前景。协议测试作为验证5G系统是否能够正式商用的关键环节，无论是5G系统研发阶段子系统之间的协议互操作性测试、协议一致性测试，亦是交付阶段的协议性能测试，不仅关乎5G服务质量，同时影响着5G 的商用进度。5G系统为了满足三大场景下的性能指标，兼容独立组网（Standalone，SA）和非独立组网（Non-Standalone，NSA）方案，支持不同制式之间的互操作等需求，导致系统内通信协议复杂度极高，信令流程数目众多。其中在三大场景之一的海量机器类通信场景下（mMTC），更是需要对大规模、多类型的终端同时提供服务，从而5G协议性能测试将面临着并发度方面的挑战；同时由于5G系统内部架构朝着微服务化方向演进，以分布式异构系统的形式提供服务，5G协议交互测试将面临着多子系统间复杂的协议交互测试。

当前存在多种协议测试工具及平台，其中TTCN-3（Test and Test ControlNotation version 3）因其平台独立性和灵活性被3GPP指定为标准测试语言。但该集中式测试架构在针对5G分布式异构系统还存在以下三点问题：（1）组件模拟程度问题。由于该TTCN-3测试框架为集中式测试架构，部署在单个测试设备上，因此在对分布式异构系统中单个组件进行协议交互测试时，需要在测试用例中定义多个测试组件通信端口，模拟出多个测试组件与被测试组件以“多对一”的方式进行协议交互，观测被测组件所有接 口的协议交互，但组件模拟程度是需要考虑的问题，如果只对组件接口层面的模拟，则难以模拟完备在真实环境下组件由于内部错误产生的异常输出。如果对组件进行功能模拟，则由于组件异构性，必然需要对组件进行TTCN-3语言代码重复开发，大大增加了测试成本。（2）测试资源拓展问题。TTCN-3集中式测试框架由于所有模拟组件部署在单一测试设备上，不能进行计算存储资源的拓展，且不能在真实的网络拓扑环境下测试，由此也无法进行有效的协议的数据吞吐量、并发度测试即协议性能测试。（3）测试控制与接口实现耦合问题。TTCN-3测试框架由于编程语言和通信机制的抽象性，测试控制与测试接口实现耦合，使得测试人员即使在熟悉业务和参数的情况下，但由于编程能力薄弱导致测试用例开发难，维护不易等问题。

发明内容

发明目的：提出一种面向5G协议的分布式测试系统，以解决现有技术存在的上述问题。

本发明提出的面向5G协议的分布式测试系统包括系统基础层、主控制模块（Master Control，MC）、附属控制模块（Slave Control，SC）。服务层基于集中式TTCN-3架构，在架构功能上进行拆分优化，在测试代码逻辑上同样进行拆分优化以适配分布式测试框架。相较于传统的分布式测试系统，测试控制单元不再是TTCN-3测试脚本，而是协议流程中单条信令，有利于提升测试代码复用性，测试流程可控性。

主控制模块包括应用层和中间层；中间层作为RPC框架客户端，负责RPC调用的构建和封装，封装至关键字所映射的函数库或对象中供应用层调用。与传统的分布式测试脚本编写相比较，将关键字驱动测试技术与RPC调用相结合，可使得测试人员只需关注测试业务逻辑的情况下，基于关键字排列组合简洁高效的开发分布式测试用例，而不会限制于编程能力和网络通信知识。

附属控制模块包括分布层和服务层；服务层存储被测系统接口的网络层信息并向上层提供信令调用接口，同时该层实现信令构建、编解码、发送、匹配等功能。

分布层作为RPC框架服务端，用于和RPC框架客户端建立连接，接受RPC请求，并根据RPC请求调用服务层相应的信令接口。

在进一步的实施例中，在与被测试5G系统连接时，所述主控制模块的数量根据测试并发规模拓展为单个或多个，组建为主控制组件；

所述附属控制模块根据被测试5G系统实际接口拓展为多类，组建为附属控制组件；每类所述附属控制模块与被测试5G系统内部接口建立连接，进行信令消息的发送和接收；

其中，所述附属控制组件包括用户终端控制组件，对于所述用户终端控制组件，如果当前用户终端为真实的终端设备，则所述用户终端控制组件用路测软件替代用于控制并监控用户终端的信令流程；

如果当前用户终端为仿真资源，则所述用户终端控制组件和用户终端之间的控制接口自定义。

以RPC协议规范实现的Thrift框架可便捷的进行主控模块和分布模块拓展成集群，以支持大规模协议并发测试。横向节点拓展无需对现有环境进行改动，只需根据IDL接口描述文件，拓展相应的控制节点、分布节点。

附属控制模块根据被测试5G系统实际接口拓展为多类，组建为附属控制组件；每类附属控制模块与被测试5G系统内部接口建立连接，进行信令消息的发送和接受。

在进一步的实施例中，应用层包括测试用例管理模块和测试日志管理模块两部分。测试用例管理模块用于对测试用例进行管理，默认为所有测试用例生成标识号，标识号由组号加序号组合而成。测试日志管理模块用于测试日志的管理与读取，测试日志以文本格式存储。其中测试用例内容为关键字的排列组合，参数配置的读写。

在进一步的实施例中，中间层采用多线程异步非阻塞I/O模型，以支持多测试用例的并发执行。应用层采用单个测试用例中关键字按序执行。当多用例测试执行时，每一组测试用例对应单个进程，多组测试用例则创建多进程相对应，单个进程对该组中所有测试用例关键字的并行执行，当关键字调用结果返回时，应用层根据测试用例标号识别到测试用例，并执行该用例的下一关键字调用，由此达到多测试用例并发，单测试用例的关键字顺序执行效果。因此在设计RPC接口时需要添加测试用例标号入参，并随RPC调用结果返回至应用层。每一组测试用例数目可根据RPC调用网络时延，客户端、服务端处理性能相应设定，以充分利用测试资源。

传统的测试系统为单线程，多个测试用例串行执行。因此无法很好的利用测试资源，也无法支持大规模并发测试和分布式测试。本设计既支持大规模并发测试，高效的利用测试资源，又保证在分布部署的环境下单个测试用例中关键字所调用的信令按序执行。

在进一步的实施例中，所述服务层采用多线程阻塞I/O模型，考虑到本框架应用于大规模并发测试，服务端将基于多线程模型实现。服务端主进程阻塞式的监听客户端连接，每当客户端进行连接，都从线程池中分配一个线程用以具体业务请求处理，当并发达到线程最大值，可进行SC节点拓展。

在进一步的实施例中，RPC框架客户端为集中控制模块，RPC框架客户端基于关键字驱动技术开发测试用例，并将RPC调用封装至关键字映射的库函数中，以文本格式对关键字进行排列即完成对底层不同组件信令的构建和流程的监督逻辑的控制，将底层编码、通信细节封装，使得测试人员易使用。

在进一步的实施例中，中间层包括RPC客户端模块和节点管理模块两部分。其中RPC客户端（RPC Client）模块是Thrift框架中客户端，采用多线程异步非阻塞I/O设计，以支持多测试用例的并发执行。该模块还需根据IDL文件生成客户端接口代码。节点管理模块（Node Management）中维护所有SC组件节点网络信息，由于所有组件均节点化，原组件管理模块（Component Management）则由节点管理模块替代，且模块在原有的功能基础上需要考虑在大规模并发测试下怎样维护SC节点负载均衡，避免节点过载影响测试。

在进一步的实施例中，客户端与服务端建立连接后所执行的均为信令相关事务， 不同线程在预定某时刻下的资源消耗趋于一致，因此采用基于客户端RPC连接数的负载均 衡算法：节点管理模块中记录第i个附属控制组件的节点最大可连接线程数记作，同时统 计第i个附属控制组件的节点上当前时刻存在的连接数记作；对连接数进行归一化记作，再与附属控制集群中L值比较，选取最小L值的附属控制组件进行任务调度，不 同附属控制组件的节点值根据节点计算资源设定。

在进一步的实施例中，分布式测试系统与5G系统连接时，构建得到协议栈控制面；协议栈控制面包括：

位于协议栈最底层的物理层，物理层作为数据传输的物理媒介；

位于协议栈中间的接入层，接入层包括介质访问控制层、无线链路控制层、分组数据汇聚协议层；

位于协议栈最上部的网络层，网络层的协议信令在5G系统内部各网元接口中传输。

本发明具有如下有益效果：

1、通过中间层、应用层和分布层机制的配合。采用异步非阻塞模型（应用层），服务端则采用同步阻塞模型（分布层），使得框架在支持测试用例高并发的同时也能确保测试序列的按序执行。解决控制的多个点间时序问题。

2、客户端基于关键字驱动技术开发测试用例，并提出将关键字映射至测试接口的RPC调用（应用层），由此测试人员只需在图形化界面对关键字进行排列组合，参数填充即可完成测试用例开发、维护，提升框架易用性。

3、在服务端设计测试控制消息和监督消息，服务端为分布模块且面向5G系统内组件接口分布部署，并根据接口协议在服务端设计测试控制消息和监督消息。从而可在真实环境下进行协议测试，并能够有效控制多组件测试流程和对输入输出进行观测。

附图说明

图1是分布式测试框架图。

图2是测试连接图。

图3是5G协议栈控制面示意图。

具体实施方式

下述实施例首先简要分析5G协议栈结构，再基于当前5G系统内部接口和协议实现情况，介绍测试框架的整体设计及模块功能，最后给出测试框架与被测5G系统逻辑连接图。

5G协议栈在基于OSI模型上划分成三层结构，在业务层面上分为控制面和用户面，其中控制面主要完成控制信令的相关过程，控制面三层协议栈如图3所示，层一位于协议栈最底层称为物理层，是数据传输的物理媒介，层二处于中间层，称为接入层，主要包含MAC、RLC和PDCP层。层三位于协议栈最上层，称为网络层，该层协议信令在5G系统内部各网元接口中传输，如RRC层消息承载在F1-C接口信令中，NAS层消息承载在NG-C接口信令中，是本框架测试的协议对象，本发明后续协议测试均指代针对5G层三协议测试。层三主要分为两层分别为无线资源控制层（Radio Resource Control，RRC）和非接入层（Non-AccessStratum，NAS），其中RRC子层基于对层一和层二的控制以完成对小区切换、RRC连接等功能控制。NAS子层主要负责包含通信安全，双向鉴权，管理用户移动性和会话等。由于用户面协议栈只存在于层一、层二，且在网元内部数据传输功能中实现，因此针对用户面协议测试不作为本发明协议测试研究对象。

申请人研究发现，要开展5G协议测试主要存在以下问题：

问题1：集中式TTCN-3测试架构不能进行多组件间复杂的协议交互测试，需要考虑模拟程度，同时缺少对其他模块之间的交互的流程监督，无法检测出其他模块之间交互的异常。现有技术有选择使用分布模块在接口层面上模拟组件的方案，提出一种面向接口的含集中控制的分布式测试框架，该框架提出针对系统内每个组件接口设定分布的接口控制模块，独立于被测系统之外，仅与被测系统内组件接口建立连接，受集中控制模块控制向组件发送接口指令，从而控制整体的测试序列。该框架的优点在于系统内所有组件处于真实的运行环境下，测试框架不再需要考虑组件模拟程度问题，但需要对测试中组件的输入输出进行有效的观测和判定，该文限于针对通用型测试框架设计因此并没有详细讨论接口消息观测和匹配问题。该框架设计采用具有优先级的任务队列支持测试用例顺序执行、并发执行，但并没有考虑到集中控制模块与分布模块处于异步通信的情况下，分布模块在真实的网络环境、硬件下是否可以按照优先级顺序执行测试指令的问题，特别在协议测试中，信令测试流程往往需要严格遵循协议规范。

问题2：5G协议测试中存在测试控制与接口开发耦合，在设计测试用例时，由于测试控制与接口开发耦合，测试人员需要编写代码脚本，效率低门槛高，测试控制与接口开发解耦后，测试人员仅对关键字进行排列组合就可以完成测试用例的开发。

问题3：现有技术有选择使用分布模块在接口层面上模拟组件的方案，提出一种面向接口的含集中控制的分布式测试框架，该框架提出针对系统内每个组件接口设定分布的接口控制模块，独立于被测系统之外，仅与被测系统内组件接口建立连接，受集中控制模块控制向组件发送接口指令，从而控制整体的测试序列。该框架的优点在于系统内所有组件处于真实的运行环境下，测试框架不再需要考虑组件模拟程度问题，但需要对测试中组件的输入输出进行有效的观测和判定，该文限于针对通用型测试框架设计因此并没有详细讨论接口消息观测和匹配问题。因为测试逻辑控制与测试接口实现解耦，所以需要对服务端监督、控制接口信令进行设计设计，实现对测试流程的有效控制和多组件流程之间的监督。

为此，本发明设计面向5G协议的分布式测试框架。采取C/S架构，含主要包含主控制（Master Control，MC）模块、附属控制（Slave Control，SC）模块和系统基础层，如图1所示。本发明主要针对MC和SC模块进行设计。

MC模块包含应用层（Application Layer）和中间层（Intermediate Layer），MC模块中间层为RPC框架客户端，负责RPC调用的构建和封装，封装至关键字所映射的函数库或对象中供应用层调用。同时也负责向SC模块发送RPC调用，当SC模块为集群时，经负载均衡算法可将RPC调用发送至指定SC组件。

应用层主要向测试人员提供图形化界面，测试人员可以进行对关键字进行排列组合编写测试用例，同时支持测试用例的管理、测试用例的执行和测试日志的收集。

SC模块包含分布层（Distribute Layer）和服务层（Service Layer），SC模块中服务层存储被测系统接口的网络层信息并向上层提供信令调用接口，同时该层实现信令构建、编解码、发送、匹配等功能。分布层为RPC框架服务端，用于和客户端建立连接，接受RPC请求，且根据RPC请求调用服务层相应的信令接口。

分布式测试框架与5G系统逻辑连接如图2所示，测试框架中MC组件暂且为单个，实际上可根据测试并发规模进行MC模块拓展。SC组件当前根据5G系统内网元间主要接口分为五类，同样可根据实际被测5G系统实际接口进行拓展，每类SC组件与被测系统内部接口建立连接，能够进行信令消息的发送和接受。其中对于UE Control组件，如果UE为真实的终端设备，该组件可以用路测软件替代用于控制、监控UE信令流程；如果UE为仿真资源，则UEControl和UE之间的控制接口可自行定义，且UE仿真资源能够更便捷的模拟出大规模并发测试场景。

基于上述架构，为了解决现有的问题，本发明在中间层、应用层和分布层和服务层进行了如下设计。

问题1的解决方法是：通过中间层、应用层和分布层机制的配合。计客户端采用异步非阻塞模型（应用层），服务端则采用同步阻塞模型（分布层），使得框架在支持测试用例高并发的同时也能确保测试序列的按序执行。解决控制的多个点间时序问题。

设计客户端采用异步非阻塞模型（中间层）。中间层采用多线程异步非阻塞I/O模型设计，以支持多测试用例的并发执行。（应用层）因此在应用层考虑单个测试用例中关键字按序执行，防止测试序列执行混乱导致测试失败。因此提出对测试用例进行分组排序标号的设计，当多用例测试执行时，每一组测试用例对应单个进程，多组测试用例则创建多进程相对应，单个进程对该组中所有测试用例关键字的并行执行，当关键字调用结果返回时，应用层需要根据测试用例标号识别到测试用例，并执行该用例的下一关键字调用，由此达到多测试用例并发，单测试用例的关键字顺序执行效果。因此在设计RPC接口时需要添加测试用例标号入参，并随RPC调用结果返回至应用层。每一组测试用例数目可根据RPC调用网络时延，客户端、服务端处理性能相应设定，以充分利用测试资源。

服务端则采用多线程阻塞IO模型（分布层）。考虑到本框架应用于大规模并发测试，服务端将基于多线程模型实现。服务端主进程阻塞式的监听客户端连接，每当客户端进行连接，都从线程池中分配一个线程用以具体业务请求处理，当并发达到线程最大值，可进行SC节点拓展。

问题2的解决方法是通过应用层与服务层的优化设计实现的。在应用层的设计：客户端为集中控制模块，客户端基于关键字驱动技术开发测试用例，并提出将关键字映射至测试接口的RPC调用（应用层），由此测试人员只需在图形化界面对关键字进行排列组合，参数填充即可完成测试用例开发、维护，提升框架易用性。

将关键字映射至测试接口的RPC调用：关键字技术与RPC调用相结合，将RPC调用封装至关键字映射的库函数中，以文本格式对关键字进行排列即完成对底层不同组件信令的构建和流程的监督逻辑的控制，将底层编码、通信细节封装，使得测试人员易使用。

对TTCN-3集中式架构优化（服务层）：服务层将拆解出原框架中测试管理（TestManagement）模块、测试日志（Test Logging）模块，将这两个模块功能转移至应用层实现。原框架中组件管理模块（Component Handling）主要负责实现不同测试组件的创建、启动、销毁以及组件的消息分发功能，该模块将拆解至中间层实现。

编解码模块（CODEC）主要负责对测试数据进行二进制比特流转换，将保留在服务层。该模块编解码源文件可根据3GPP接口协议中ASN.1文档，利用asn1c工具进行解析生成。不同类型SC组件所包含的编解码并不相同，如NGAP Control SC组件由上至下包含NAS协议编解码、NGAP协议编解码、SCTP协议编解码。被测系统适配器（SUT Adapter，SA）作用是将TE模块中需要发送的消息添加传输层信息，实现与被测系统之间的交互。平台适配器（Platform Adapter，PA）主要提供外部服务函数实现和计时器管理模块。SA、PA两个模块也同样保留在服务层。

原集中式测试框架核心模块TTCN-3可执行模块（TTCN-3Executable，TE），包含TTCN-3语言编写的测试代码即代码模块（Generated Code, GC），和对TTCN-3测试代码进行语义翻译、代码编译的系统运行时模块（Run Time System, RTS）。通常GC模块中TTCN-3语言编写的测试代码经RTS模块编译后生成可单独执行的程序，如果保留这样的设计测试脚本将在服务层预先构建，会导致应用层只能基于测试脚本为单元进行测试操作，对测试的控制性大大降低，同时对测试脚本的修改也较为不便。由此考虑对该模块进行优化，将TTCN-3测试代码只经过RTS模块翻译，翻译成C++语言的接口供RPC调用，同时将测试代码的编译转移至应用层中实现。然而这样功能上的变化，需要对TTCN-3测试代码逻辑的相适配。

应用层主要包含三个模块，主线程维护下述两个模块，（1）测试用例管理模块（Test Case Management）中对测试用例进行管理。默认为所有测试用例生成标识号，标识号由组号加序号组合而成。测试用例内容为关键字的排列组合，参数配置的读写。（2）测试日志管理模块（Test Logging Management）模块主要用于测试日志的管理与读取，测试日志同样以文本格式存储。

上述讨论中间层采用异步非阻塞模式实现，因此在应用层需要考虑单个测试用例中关键字按序执行，防止测试序列执行混乱导致测试失败。因此提出对测试用例进行分组排序标号的设计，当多用例测试执行时，每一组测试用例对应单个进程，多组测试用例则创建多进程相对应，单个进程对该组中所有测试用例关键字的并行执行，当关键字调用结果返回时，应用层需要根据测试用例标号识别到测试用例，并执行该用例的下一关键字调用，由此达到多测试用例并发，单测试用例的关键字顺序执行效果。因此在设计RPC接口时需要添加测试用例标号入参，并随RPC调用结果返回至应用层。每一组测试用例数目可根据RPC调用网络时延，客户端、服务端处理性能相应设定，以充分利用测试资源。

在服务层介绍将编译功能转移至应用层实现，同时考虑到Thrift框架支持跨语言开发客户端和服务端，由此应用层可采用解释性语言如Python实现。采用Python高级语言开发应用层，不仅可以使得界面得以高效快速开发，同时可以使得编译过程得以简化，测试人员只需要专注于测试用例的实现。

问题3的解决方法是在服务端设计测试控制消息和监督消息。服务端为分布模块且面向5G系统内组件接口分布部署，并根据接口协议在服务端设计测试控制消息和监督消息。从而可在真实环境下进行协议测试，并能够有效的控制多组件测试流程和对输入输出进行观测。增加了待测组件以外其他组件的交互。（在服务层实现）。

TTCN-3代码以模块为单位（类比于C++语言中class），模块中包含定义部分和控制部分，定义部分声明了该模块所使用的变量，模板，通信端口，行为函数等。其中模板是TTCN-3的一种数据结构，模板包含一系列预设的元素，可以用作消息报文的构造和匹配，且模板支持继承和参数化，功能灵活强大，本框架信令构建和匹配的接口代码也将基于模板实现。控制部分则是测试逻辑的编写部分，服务层TTCN-3代码模块将不包含控制部分，实际上是将测试逻辑控制部分转移到MC模块的应用层中，在应用层图形化界面中测试人员可以对关键字进行排列组合完成测试逻辑的编写。因此服务层TTCN-3测试代码将只包含对信令构建发送和信令应答匹配的定义部分，再经由RTS模块翻译成C++语言接口，将所有信令存在的接口进行管理则原本的TE模块实际上就转变成服务层TTCN-3Lib模块。这样的设计使得测试人员在应用层将以信令为单元完成测试用例的开发，有效提升了应用层对测试流程的控制性，测试用例的管理，维护也更加方便。

为了形成标准的信令接口库供上层调用，则信令接口的设计也应当有明确的规范，才能统一供上层调用。3GPP组织对5G系统接口均有明确的标准规范，协议中信令由字段组成，每个字段可复用于不同的信令中，由此考虑以字段为最小结构体构建单位，利用结构体可嵌套特性进行完整信令结构体构建，能够降低测试代码开发的重复性。TTCN-3信令接口库构建分为以下步骤：

（1）以字段构建相应的字段结构体类型（Record Type），根据3GPP中信令标准对字段结构体进行嵌套组合成完整的信令结构体，信令结构体不仅可以作为信令模板（Template Type）的构建基础，同时也可以作为信令模板入参数据结构。

（2）接口信令有发起信令和应答信令两种。信令流程也分为两类，一类流程包含发起信令和应答信令可称作双流程，另一类流程仅有发起信令可称作单流程，因此在对所有信令模板构建完成后，再进行发起信令模板与应答信令模板区分，封装成发起信令函数和应答信令函数，再将信令函数封装成包含发起信令函数和应答信令函数的双流程函数和仅包含发起信令函数的单流程函数。（3）双流程函数和单流程函数可用作子系统测试，而对整系统进行业务测试时，除业务发起的第一条信令使用双流程函数外，其余均信令仅使用应答函数用于监督业务信令流程。上述函数的返回类型均为字符类型并向上层传递，最终应用层会根据关键字返回值是否为包含错误原因判断是否继续或结束测试用例，如果关键字执行无异常返回值不包含错误原因指示，有异常则返回值则包含错误原因，这样的设计有利于将测试异常快速定位至单个信令层面，提高测试效率。

在基于上述函数库建立完成的情况下，对库中的函数进行C++语言翻译，最终生成C++信令函数接口。由于本框架需要支持大规模并发测试，就必然需要考虑到对接口的多线程操作问题，为了防止多线程同时对某个接口进行调用而产生错误，需要对信令函数接口进行加锁操作，最终生成的接口才能被上层调用。

分布层、中间层将基于Thrift框架实现，使用Thrift中的IDL文件，可便捷的进行客户端节点拓展。设计分布层采用多线程同步阻塞服务模型，以支持服务端与多个客户端建立连接进行并发测试，在中间层提出基于RPC连接数的负载均衡算法，防止节点出现过载，影响测试流程。

RPC（Remote Procedure Call）是一种通讯标准，用于不同主机之间的进程通信[8]。根据此标准定义出来的RPC框架，可以使得服务调用者像调用本地方法一般调用远程主机方法。开源的Thrift框架则是根据RPC标准定义的框架，Thrift框架是客户端/服务端架构，使用中间语言（interface definition language，IDL）定义RPC接口和数据类型，并可以将中间语言文件编译成不同语言接口代码，且框架本身包含RPC协议层和传输层实现。其中客户端支持同步阻塞I/O、异步非阻塞I/O；服务端支持单线程模型、多线程阻塞模型，多线程非阻塞模型。相较于其他RPC框架Thrift支持跨语言平台开发，适用于数据交换量大、伸缩要求高、并发频率高的分布式系统，因此本框架分布层、中间层将基于Thrift框架实现。

分布层中RPC服务模块（RPC Service）是Thrift框架中服务端，考虑到本框架应用于大规模并发测试，服务端将基于多线程同步阻塞模型实现。服务端主线程用于监听客户端连接，每当客户端进行连接，都从线程池中分配一个线程用以具体业务请求处理，当并发达到线程最大值，可进行SC节点拓展。该模块主要工作是将服务层接口使用IDL文件描述，再将IDL文件进行编译生成RPC接口，供Thrift框架使用。

中间层（intermediate Layer）包含两个功能模块，其中RPC客户端（RPC Client）模块是Thrift框架中客户端，采用多线程异步非阻塞I/O设计，以支持多测试用例的并发执行。该模块还需根据IDL文件生成客户端接口代码。节点管理模块（Node Management）中维护所有SC组件节点网络信息，由于所有组件均节点化，原组件管理模块（ComponentManagement）则由节点管理模块替代，且模块在原有的功能基础上需要考虑在大规模并发测试下怎样维护SC节点负载均衡，避免节点过载影响测试。

考虑到客户端与服务端建立连接后所执行的均为信令相关事务，不同线程在某个 时刻下的资源消耗几乎相近，由此可考虑设计基于客户端RPC连接数的负载均衡算法：节点 管理模块中记录第i个附属控制组件的节点最大可连接线程数记作，同时统计第i个附属 控制组件的节点上当前时刻存在的连接数记作；对连接数进行归一化记作，再 与附属控制集群中L值比较，选取最小L值的附属控制组件进行任务调度，不同附属控制组 件的节点值根据节点计算资源设定。

如上所述，尽管参照特定的优选实施例已经表示和表述了本发明，但其不得解释为对本发明自身的限制。在不脱离所附权利要求定义的本发明的精神和范围前提下，可对其在形式上和细节上做出各种变化。

Claims (7)

1.面向5G协议的分布式测试系统，至少包括系统基础层、主控制模块、附属控制模块；其特征在于：

所述主控制模块包括应用层和中间层；

所述中间层作为RPC框架客户端，负责RPC调用的构建和封装，封装至关键字所映射的函数库或对象中供应用层调用；

所述附属控制模块包括分布层和服务层；所述服务层存储被测系统接口的网络层信息并向上层提供信令调用接口；

所述分布层作为RPC框架服务端，用于和所述RPC框架客户端建立连接，接受RPC请求，并根据RPC请求调用服务层相应的信令接口；

其中，所述应用层包括：

测试用例管理模块，用于对测试用例进行管理，默认为所有测试用例生成标识号，标识号由组号加序号组合而成；

测试日志管理模块，用于测试日志的管理与读取，测试日志以文本格式存储；

其中测试用例内容为关键字的排列组合，参数配置的读写；

所述中间层采用多线程异步非阻塞I/O模型，以支持多测试用例的并发执行；

所述应用层采用单个测试用例中关键字按序执行；

当多用例测试执行时，每一组测试用例对应单个进程，多组测试用例则创建多进程相对应，单个进程对组中所有测试用例关键字的并行执行，当关键字调用结果返回时，应用层根据测试用例标号识别到测试用例，并执行该用例的下一关键字调用。

2.根据权利要求1所述的分布式测试系统，其特征在于，在与被测试5G系统连接时，所述主控制模块的数量根据测试并发规模拓展为单个或多个，组建为主控制组件；

所述附属控制模块根据被测试5G系统实际接口拓展为多类，组建为附属控制组件；每类所述附属控制模块与被测试5G系统内部接口建立连接，进行信令消息的发送和接收；

其中，所述附属控制组件包括用户终端控制组件，对于所述用户终端控制组件，如果当前用户终端为真实的终端设备，则所述用户终端控制组件用路测软件替代用于控制并监控用户终端的信令流程；

如果当前用户终端为仿真资源，则所述用户终端控制组件和用户终端之间的控制接口自定义。

3.根据权利要求1所述的分布式测试系统，其特征在于，所述服务层采用多线程阻塞I/O模型，服务端主进程阻塞式的监听客户端连接，每当客户端进行连接，都从线程池中分配一个线程用以具体业务请求处理，当并发达到线程最大值进行附属控制节点拓展。

4.根据权利要求1所述的分布式测试系统，其特征在于，所述RPC框架客户端为集中控制模块，所述RPC框架客户端基于关键字驱动技术开发测试用例，并将RPC调用封装至关键字映射的库函数中，以文本格式对关键字进行排列即完成对底层不同组件信令的构建和流程的监督逻辑的控制。

5.根据权利要求1所述的分布式测试系统，其特征在于，所述中间层包括：

RPC客户端模块，根据IDL文件生成客户端接口代码；

节点管理模块，用于维护所有附属控制组件的节点网络信息。

6.根据权利要求1所述的分布式测试系统，其特征在于，所述客户端与服务端建立连接后所执行的均为信令相关事务，不同线程在预定某时刻下的资源消耗趋于一致，因此采用基于客户端RPC连接数的负载均衡算法：

节点管理模块中记录第i个附属控制组件的节点最大可连接线程数记作，同时统计第i个附属控制组件的节点上当前时刻存在的连接数记作/>；

对连接数进行归一化记作，再与附属控制集群中L值比较，选取最小L值的附属控制组件进行任务调度，不同附属控制组件的节点/>值根据节点计算资源设定。

7.根据权利要求1所述的分布式测试系统，其特征在于，所述分布式测试系统与被测试5G系统建立连接时，构建得到协议栈控制面；

所述协议栈控制面包括：

位于协议栈最底层的物理层；所述物理层作为数据传输的物理媒介；

位于协议栈中间的接入层；所述接入层包括介质访问控制层、无线链路控制层、分组数据汇聚协议层；

位于协议栈最上部的网络层；所述网络层的协议信令在5G系统内部各网元接口中传输。