开云优惠体育网页版入口

专利名称：一种测试方法、测试装置、测试设备、存储介质和系统

专利类型：实用新型专利

专利申请号：CN202211541131.1

专利申请（专利权）人：OPPO广东移动通信有限公司
权利人地址：广东省东莞市长安镇乌沙海滨路18号

专利发明（设计）人：刘政,吴伟,曹涛,年秋实,张佩珊

专利摘要：本申请实施例公开了一种测试方法、测试装置、测试设备、存储介质和系统，该方法包括：获取待测用例场景；基于待测用例场景，确定信令模型编号和协议参数；调用仪表设备中信令模型编号对应的目标信令模型，并将协议参数传递到目标信令模型中，以控制仪表设备生成目标测试脚本；基于目标测试脚本对待测用例场景进行测试，得到待测用例场景对应的测试结果。如此，不仅能够提高脚本开发效率，而且还能够实现信令参数级别的仿真，提高仿真精度；同时由于无需人工挑选测试脚本，还可以提升测试执行效率。

主权利要求：
1.一种测试方法，所述方法应用于全球运营商网络模拟测试，其特征在于，所述方法包括：获取待测用例场景；
基于所述待测用例场景，确定信令模型编号和协议参数；
调用仪表设备中所述信令模型编号对应的目标信令模型，并将所述协议参数传递到所述目标信令模型中，以控制所述仪表设备生成目标测试脚本；
基于所述目标测试脚本对所述待测用例场景进行测试，得到所述待测用例场景对应的测试结果；
其中，所述获取待测用例场景，包括：
根据预设规划表和/或预置输入信息，生成用例场景全集；
从所述用例场景全集中，获取所述待测用例场景；
其中，所述方法还包括：
遍历所述用例场景全集中的所有用例场景，将每一个用例场景依次作为所述待测用例场景，循环执行所述测试方法，直至得到所有用例场景对应的测试结果；
根据所有用例场景对应的测试结果，生成目标测试开云优惠体育网页版入口；
其中，若所述待测用例场景与第一用例场景满足复用条件，则复用所述第一用例场景对应的信令模型，和/或，复用所述第一用例场景的部分协议参数；
其中，所述第一用例场景为所述用例场景全集中的任意一个用例场景。
2.根据权利要求1所述的方法，其特征在于，在所述基于所述目标测试脚本对所述待测用例场景进行测试之前，所述方法还包括：向切卡器发送第一控制命令；其中，所述第一控制命令用于控制所述切卡器切换到第一测试卡。
3.根据权利要求1所述的方法，其特征在于，所述基于所述待测用例场景，确定信令模型编号和协议参数，包括：基于所述待测用例场景，从预设数据库中获取所述信令模型编号和所述协议参数。
4.根据权利要求3所述的方法，其特征在于，所述方法还包括：从所述预设数据库中获取第一参数信息；
根据所述第一参数信息，配置所述仪表设备的环境。
5.根据权利要求3或4所述的方法，其特征在于，在所述获取待测用例场景之前，所述方法还包括：获取预设规划表和信令参数表；
将所述预设规划表和所述信令参数表存储至所述预设数据库中。
6.根据权利要求5所述的方法，其特征在于，所述方法还包括：若通信技术演进或者规划变更，则更新所述预设规划表；
或者，
若配置参数变更或者出现异常参数，则更新所述信令参数表。
7.根据权利要求1所述的方法，其特征在于，所述方法还包括：若所述待测用例场景为视频场景，则复用语音场景对应的信令模型；
或者，
若所述待测用例场景为5G独立组网制式下的数据场景，则复用5G非独立组网制式下所述数据场景对应的信令模型；
或者，
若所述待测用例场景为5G独立组网制式下的非数据场景，则复用4G网络制式下所述非数据场景对应的信令模型；
或者，
若所述待测用例场景为至少两个用例场景的组合场景，则将所述至少两个用例场景对应的信令模型进行并联。
8.根据权利要求1所述的方法，其特征在于，在所述待测用例场景为语音场景的情况下，所述方法还包括：确定支持语音业务时所对应的语音协议参数；
若所述语音业务的服务类型为IMS注册服务，则调用所述IMS注册服务对应的第一目标信令模型，并将所述语音协议参数传递到所述第一目标信令模型中，以控制所述仪表设备生成IMS注册测试脚本；
若所述语音业务的服务类型为IMS主叫服务，则调用所述IMS主叫服务对应的第二目标信令模型，并将所述语音协议参数传递到所述第二目标信令模型中，以控制所述仪表设备生成IMS主叫测试脚本；
若所述语音业务的服务类型为IMS被叫服务，则调用所述IMS被叫服务对应的第三目标信令模型，并将所述语音协议参数传递到所述第三目标信令模型中，以控制所述仪表设备生成IMS被叫测试脚本；
相应地，所述基于所述目标测试脚本对所述待测用例场景进行测试，得到所述待测用例场景对应的测试结果，包括：根据所述IMS注册测试脚本对被测设备的IMS注册服务进行用例测试，生成第一测试结果；
根据所述IMS主叫测试脚本对被测设备的IMS主叫服务进行用例测试，生成第二测试结果；
根据所述IMS被叫测试脚本对被测设备的IMS被叫服务进行用例测试，生成第三测试结果；
基于所述第一测试结果、所述第二测试结果和所述第三测试结果，得到所述语音场景对应的测试结果。
9.根据权利要求1所述的方法，其特征在于，在所述待测用例场景为紧急呼叫场景的情况下，所述方法还包括：设置i的初始值等于0；
判断紧急信令模型编号是否等于i；
若所述紧急信令模型编号不等于i，则将i+1赋值为i，继续执行所述判断紧急信令模型编号是否为i的操作；
若所述紧急信令模型编号等于i，则确定第i组协议参数，并将所述第i组协议参数传递到第i个紧急信令模型，以控制所述仪表设备生成紧急呼叫测试脚本；其中，不同组的协议参数之间具有交织关系，且i为大于或等于0且小于N的整数，N表示所述紧急信令模型的总数量；
相应地，所述基于所述目标测试脚本对所述待测用例场景进行测试，得到所述待测用例场景对应的测试结果，包括：根据所述紧急呼叫测试脚本对被测设备的紧急呼叫服务进行用例测试，得到所述紧急呼叫场景对应的测试结果。
10.根据权利要求1所述的方法，其特征在于，在所述待测用例场景为VoWIFI场景的情况下，所述方法还包括：从预设数据库中获取小区参数和第一服务器参数；
若需要配置文件，则修改所述仪表设备的配置文件，并根据所述配置文件与鉴权方式之间的映射关系进行鉴权方式更新；
若不需要配置文件，则从所述预设数据库中获取第一鉴权方式；
通过判断被测设备是否VoWIFI注册成功以及是否支持语音业务，生成所述VoWIFI场景对应的测试开云优惠体育网页版入口。
11.根据权利要求10所述的方法，其特征在于，在判断被测设备是否VoWIFI注册成功以及是否支持语音业务之前，所述方法还包括：若需要更换到目标MAC地址，则设置所述目标MAC地址；
若需要在飞行模式下进行VoWIFI注册，则开启所述飞行模式。
12.根据权利要求1所述的方法，其特征在于，在所述待测用例场景为补充业务场景的情况下，所述方法还包括：从预设数据库中获取小区参数、第二服务器参数和第二鉴权方式；
若需要安全证书进行加密，则加载所述安全证书并配置加密端口；
加载业务配置文件，通过判断所述业务配置文件中的业务设置是否成功，生成所述补充业务场景对应的测试开云优惠体育网页版入口。
13.一种测试装置，所述装置应用于全球运营商网络模拟测试，其特征在于，所述测试装置包括主控模块、测试执行模块和结果管理模块，其中：所述主控模块，配置为获取待测用例场景；
所述主控模块，还配置为根据预设规划表和/或预置输入信息，生成用例场景全集；以及从所述用例场景全集中获取所述待测用例场景；
所述测试执行模块，配置为基于所述待测用例场景，确定信令模型编号和协议参数；以及调用仪表设备中所述信令模型编号对应的目标信令模型，并将所述协议参数传递到所述目标信令模型中，以控制所述仪表设备生成目标测试脚本；以及基于所述目标测试脚本对所述待测用例场景进行测试，得到所述待测用例场景对应的测试结果；
所述结果管理模块，配置为遍历所述用例场景全集中的所有用例场景，在所有用例场景全部测试完成后，生成目标测试开云优惠体育网页版入口；其中，若所述待测用例场景与第一用例场景满足复用条件，则复用所述第一用例场景对应的信令模型，和/或，复用所述第一用例场景的部分协议参数；其中，所述第一用例场景为所述用例场景全集中的任意一个用例场景。
14.根据权利要求13所述的测试装置，其特征在于，所述测试装置还包括信息获取模块和数据处理模块，其中：所述信息获取模块，配置为获取预设规划表和信令参数表；
所述数据处理模块，配置为将所述预设规划表和所述信令参数表存储至预设数据库中。
15.根据权利要求14所述的测试装置，其特征在于，所述测试执行模块，还配置为基于所述待测用例场景，从所述预设数据库中获取所述信令模型编号和所述协议参数。
16.根据权利要求14所述的测试装置，其特征在于，所述测试执行模块，还配置为从所述预设数据库中获取第一参数信息；以及根据所述第一参数信息，配置所述仪表设备的环境。
17.根据权利要求14所述的测试装置，其特征在于，所述数据处理模块，还配置为若通信技术演进或者规划变更，则更新所述预设规划表；或者，若配置参数变更或者出现异常参数，则更新所述信令参数表。
18.根据权利要求13所述的测试装置，其特征在于，所述测试执行模块，还配置为向切卡器发送第一控制命令；其中，所述第一控制命令用于控制所述切卡器切换到第一测试卡。
19.根据权利要求18所述的测试装置，其特征在于，所述测试装置还包括通信接口模块，其中：所述通信接口模块，配置为与硬件系统建立通信连接，其中所述硬件系统至少包括所述仪表设备和所述切卡器。
20.一种测试设备，其特征在于，所述测试设备包括存储器和处理器；其中，所述存储器，用于存储能够在所述处理器上运行的计算机程序；
所述处理器，用于在运行所述计算机程序时，执行如权利要求1至12中任一项所述的方法。
21.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序被至少一个处理器执行时实现如权利要求1至12中任一项所述的方法。
22.一种测试系统，其特征在于，所述测试系统至少包括如权利要求20所述的测试设备和硬件系统；其中，所述硬件系统至少包括仪表设备和切卡器。 说明书 : 一种测试方法、测试装置、测试设备、存储介质和系统技术领域[0001] 本申请涉及测试技术领域，尤其涉及一种测试方法、测试装置、测试设备、存储介质和系统。背景技术[0002] 随着互联网的快速发展和终端的普及，移动终端(例如手机、掌上电脑、笔记本等)已经成为人们必备的通讯工具。各种方便人们生活的功能都能够在移动终端上实现，例如手机电视、网上购物、位置共享、移动支付等，都需要移动终端接入到互联网才能实现。[0003] 为了提升问题内场拦截率，移动终端在测试阶段需要进行全球运营商网络模拟测试。目前可以采用以下两种方式：一种是利用真实基站、核心网模拟运营商网络环境，以供移动终端测试；另一种是利用通信仪表逐条开发测试脚本模拟运营商网络环境，以供移动终端覆盖各个场景测试。然而，已有的测试方案均存在一些缺陷，例如，由于全球运营商数量庞大和测试场景过多而导致仪表脚本开发效率低，各个运营商的信令和参数都有差异，脚本开发难以兼顾诸多细节而导致模拟仿真精度低等等。发明内容[0004] 本申请提出一种测试方法、测试装置、测试设备、存储介质和系统，不仅能够提高脚本开发效率，而且还能够实现信令参数级别的仿真，提高仿真精度；同时由于无需人工挑选测试脚本，还可以提升测试执行效率。[0005] 本申请的技术方案是这样实现的：[0006] 第一方面，本申请实施例提供了一种测试方法，该方法包括：[0007] 获取待测用例场景；[0008] 基于待测用例场景，确定信令模型编号和协议参数；[0009] 调用仪表设备中信令模型编号对应的目标信令模型，并将协议参数传递到目标信令模型中，以控制仪表设备生成目标测试脚本；[0010] 基于目标测试脚本对待测用例场景进行测试，得到待测用例场景对应的测试结果。[0011] 第二方面，本申请实施例提供了一种测试装置，该测试装置包括主控模块和测试执行模块，其中：[0012] 主控模块，配置为获取待测用例场景；[0013] 测试执行模块，配置为基于待测用例场景，确定信令模型编号和协议参数；以及调用仪表设备中信令模型编号对应的目标信令模型，并将协议参数传递到目标信令模型中，以控制仪表设备生成目标测试脚本；以及基于目标测试脚本对待测用例场景进行测试，得到待测用例场景对应的测试结果。[0014] 第三方面，本申请实施例提供了一种测试设备，该测试设备包括存储器和处理器；其中，[0015] 存储器，用于存储能够在处理器上运行的计算机程序；[0016] 处理器，用于在运行计算机程序时，执行如第一方面所述的方法。[0017] 第四方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被至少一个处理器执行时实现如第一方面所述的方法。[0018] 第四方面，本申请实施例提供了一种测试系统，测试系统至少包括如第三方面所述的测试设备和硬件系统；其中，硬件系统至少包括仪表设备和切卡器。[0019] 本申请实施例所提供的一种测试方法、测试装置、测试设备、存储介质和系统，获取待测用例场景；基于待测用例场景，确定信令模型编号和协议参数；调用仪表设备中信令模型编号对应的目标信令模型，并将协议参数传递到目标信令模型中，以控制仪表设备生成目标测试脚本；基于目标测试脚本对待测用例场景进行测试，得到待测用例场景对应的测试结果。这样，基于信令模型化和参数变量化的设计，能够实现仪表脚本的自动生成，提高脚本的开发效率；而且对于不同用例场景分别对应有一套信令参数，从而还能够实现信令参数级别的仿真，提高仿真精度；另外，对于测试脚本的生成，该过程无需人工挑选测试脚本，同时信令模型和协议参数的复用率高，从而不仅能够降低迭代维护成本，还能够提升测试执行效率。附图说明[0020] 图1为本申请实施例提供的一种测试方法的流程示意图；[0021] 图2为本申请实施例提供的一种智能开发系统的整体业务流程示意图；[0022] 图3为本申请实施例提供的一种用户操作界面的组成结构示意图；[0023] 图4为本申请实施例提供的一种智能开发系统的逻辑实现示意图；[0024] 图5为本申请实施例提供的一种VoLTE场景的逻辑实现示意图；[0025] 图6为本申请实施例提供的一种E911call场景的逻辑实现示意图；[0026] 图7为本申请实施例提供的一种VoWIFI场景的逻辑实现示意图；[0027] 图8为本申请实施例提供的一种Ut补充业务场景的逻辑实现示意图；[0028] 图9为本申请实施例提供的一种测试系统的架构示意图；[0029] 图10为本申请实施例提供的一种硬件系统的网络拓扑示意图；[0030] 图11为本申请实施例提供的一种常规测试脚本的结构示意图；[0031] 图12为本申请实施例提供的一种信令模型脚本的结构示意图；[0032] 图13为本申请实施例提供的一种测试装置的组成结构示意图；[0033] 图14为本申请实施例提供的一种测试设备的组成结构示意图；[0034] 图15为本申请实施例提供的一种测试系统的组成结构示意图。具体实施方式[0035] 为了能够更加详尽地了解本申请实施例的特点与技术内容，下面结合附图对本申请实施例的实现进行详细阐述，所附附图仅供参考说明之用，并非用来限定本申请实施例。[0036] 除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。[0037] 在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。还需要指出，本申请实施例所涉及的术语“第一\第二\第三”仅是用于区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。[0038] 可以理解，在本申请实施例中，全球运营商网络内场模拟测试目前主要是以下两种方式，部分厂家一般同时部署两种：[0039] (1)利用真实基站、核心网模拟运营商网络环境，构建相同的网络信令流程和通信协议参数以供手机终端测试。这种方式依赖对基站和核心网的高控制权限和丰富的开放接口，除了个别厂家同时拥有终端产品线和网络产品线，具有得天独厚的优势；但是其他厂家只能进行有限的模拟和自动化操作，不利于实现全球运营商网络内场模拟测试。[0040] (2)利用通信仪表(如罗德斯瓦茨CMW500，是德开云优惠体育网页版入口E7515B，安立MT8000A等)逐条开发测试脚本，模拟运营商的网络信令流程和通信协议参数，以供手机终端在内场覆盖各个场景测试。[0041] 然而，在相关技术中，已有的测试方案存在一些缺陷，例如：[0042] (1)仪表脚本开发效率低。全球运营商数量大，某些厂家基本覆盖300+运营商，测试场景多，第四代移动通信技术(4thGenerationMobileCommunicationTechnology，简称4G)及第五代移动通信技术(5thGenerationMobileCommunicationTechnology，简称5G)的语音主叫、被叫，视频主叫、被叫，切换，紧急通话，补充业务，数据功能，既有长期演进语音承载(VoiceoverLong?TermEvolution，VoLTE)场景也有基于移动热点语音(VoiceoverWirelessFidelity，VoWIFI)场景，大小场景加起来超过50+；再算上漫游业务，漫入、漫出、海外漫游等。多个因子正交后测试场景达到数万的量级，逐条开发脚本效率远远不够。[0043] (2)模拟仿真精度低。各个运营商信令和参数都有差异，脚本开发工程师难以兼顾诸多细节，加上如此量级的脚本开发需求，往往只能做到一套通用模型点检各个运营商场景，远远达不到网络信令参数级别的仿真。[0044] (3)迭代维护成本高。全球运营商4G/5G的规划和部署是持续变化的，4GVoLTE语音通话商用已超过好几年，但仍有运营商未规划打开VoLTE，而有的运营商已逐渐打开5G新空口承载语音(VoiceoverNewRadio，VoNR)。持续的规划变动会导致测试脚本一直变更，需要专业的仪表开发工程师持续投入，同时还长时间占用昂贵的通信测试仪表。[0045] (4)测试执行效率偏低。针对不同系列产品，运营商规划是不同的，即每款产品需要测试的用例集也是不一样的，每次测试都需要执行人员从仪表脚本集合里挑选出适用的脚本，额外花费不少时间。[0046] 基于此，本申请实施例提供了一种测试方法，该测试方法可以适用于手机终端类产品在测试阶段进行全球运营商网络模拟测试，能够达到提升问题内场拦截率，降低外场测试成本的目的。[0047] 下面将结合附图对本申请各实施例进行详细说明。[0048] 在本申请的一实施例中，参见图1，其示出了本申请实施例提供的一种测试方法的流程示意图。如图1所示，该方法可以包括：[0049] S101：获取待测用例场景。[0050] 需要说明的是，在本申请实施例中，该测试方法应用于测试装置，或者集成有该测试装置的测试设备。其中，测试设备可以是诸如智能手机、平板电脑、笔记本电脑、掌上电脑、个人数字助理(PersonalDigitalAssistant，PDA)、台式电脑、个人计算机(PersonalComputer，PC)等，这里不作任何限定。[0051] 还需要说明的是，在本申请实施例中，该测试方法适用于全球运营商网络模拟测试。其中，不同运营商网络差异主要有两项，信令流程和第三代合作伙伴计划(3rdGenerationPartnershipProject，3GPP)协议参数。在这里，信令流程可以是指手机终端做通信业务时与运营商网络交互的消息，协议参数是由3GPP和请求评论文档(RequestForComment，RFC)协议规定的各个交互信令中的固定信息元素(InformationElement，IE)。[0052] 应理解，相关技术中往往采用一套模型，即信令流程和协议参数一致，只需修改运营商的公共陆地移动网络(PublicLandMobileNetwork，PLMN)来开发仪表脚本进行模拟，这样仿真精度很低。但如果每个运营商都配置对应的信令流程和协议参数，逐条开发脚本，这样无论是时间成本还是人力、仪表资源成本都极高，可行性不高，大多数厂家都不会这样做的。然而，本申请实施例的测试方法可以有效解决这一难题。[0053] 虽然同一业务场景下，信令流程有多种，以最复杂的VoLTE语音主叫通话场景为例，是否支持预留(Precondition)媒体协商，是否支持183消息(183progress)，有无提前放音，有无二次协商都会导致信令流程的差异，但信令流程的种类个数与运营商总数相比却极大的减少。从实际应用中获取的200+运营商日志(Log)来看，VoLTE语音主叫通话只有13种信令流程，表1为一种VoLTE语音主叫的信令流程示例，表2为一种VoLTE语音主叫的信令流程示例。而Ut补充业务场景只有一种信令流程。[0054] 表1[0055][0056] 表2[0057][0058] 还应理解，协议参数虽然不同的运营商配置不一样，但这些参数本身是由通信协议规定的，比如小区参数包含：小区身份标识(IdentityDocument，ID)、频段、频点等信息，VoLTE参数包含：会话初始协议(SessioninitializationProtocol，SIP)协议中的contact、feature?caps、support，require等字段和会话描述协议(SessionDescriptionProtocol，SDP)协议中的RR、RS、audio/videocodec等字段，Ut补充业务包含：naf/bsfserveraddress、port、鉴权算法等信息。在这里，不同的运营商只是对这些参数赋值不同而已，参数本身个数是固定的。[0059] 这样，在信令流程种类不多，参数个数固定的前提下，在仪表设备上按流程种类开发脚本，把协议参数都封装成函数变量来传递不同运营商的配置，将流程类型和参数与运营商做好映射，就可以控制仪表设备自动生成特定信令流和参数IE的测试脚本。通过信令流程模型化和协议参数变量化就能实现高精度仿真，以预开发不到50个脚本模型的成本达到几万量级的测试覆盖面，同时动态灵活的配置方式可以极大降低后续4G/5G技术演进、运营商规划变更、配置参数变更等带来的迭代维护成本。[0060] 可以理解地，在执行测试之前，首先需要获取输入信息。其中，输入信息可以包括预设规划表和信令参数表。这些信息可以是由石墨表格作为信息输入口(也可使用Excel等信息储存介质)，而且这些信息最终存入预设数据库中供测试装置进行管理和调用。因此，在获取待测用例场景之前，该方法还可以包括：[0061] 获取预设规划表和信令参数表；[0062] 将预设规划表和信令参数表存储至预设数据库中。[0063] 在本申请实施例中，预设规划表可以为全球运营商规划表(或称为“全球运营商规划信息”)，具体是由手机终端公司规划部门根据产品规划、定位、目标上市区域等结合各运营商白皮书制定的一份上市规划，不同产品系列略有差异。这里，该规划表决定了手机终端针对全球运营商需要测试的场景全集：需要测试的运营商总数以及每家运营商需要测试的场景总数。[0064] 在本申请实施例中，信令参数表可以为运营商信令参数表(或称为“全网信令参数表”)，具体用于存储各个测试场景对应的信令流程类型和通信3GPP协议参数等信息，与各运营商一一对应。其中，这两个信息可以通过运营商白皮书和各运营商网络下手机终端日志来提炼获取得到，技术门槛很低，通信领域测试工程师都可以做；或者，也可以用脚本实现自动提炼，无需依赖专业仪表开发人员和仪表资源。[0065] 进一步地，根据预设规划表或者用户自定义输入信息，可以生成需要进行测试的用例场景全集，然后将该用例场景全集中的每一个用例场景依次作为待测用例场景进行测试。因此，在一些实施例中，获取待测用例场景，可以包括：根据预设规划表和/或预置输入信息，生成用例场景全集；从用例场景全集中，获取待测用例场景。[0066] 在本申请实施例中，预置输入信息可以是用户(或者测试执行人员)自定义输入信息，例如用户对场景/平台的设置。对于用例场景全集的确定，可以是通过全球运营商规划来自动生成的，或者也可以是通过用户自定义输入来自动生成的，这里也不作任何限定。[0067] 还可以理解地，全球运营商4G/5G的规划和部署是持续变化的，考虑到后续的迭代维护成本，在一些实施例中，该方法还可以包括：若通信技术演进或者规划变更，则更新预设规划表；或者，若配置参数变更或者出现异常参数，则更新信令参数表。[0068] 在一种具体的实施例中，如果通信技术演进或者运营商规划变更，那么可以更新全球运营商规划表；或者，如果运营商数量增加或者配置参数变更或者出现异常参数，那么可以更新运营商信令参数表。[0069] 也就是说，对于全球运营商规划表和运营商信令参数表，以石墨表格作为信息输入口，导入数据库进行管理和调用的模式可以极大降低后续迭代维护成本。具体地，运营商4G/5G通信技术演进和规划变更，可以通过修改全球运营商规划表进行更新(一般来说这类变更是由规划部门提供，测试业务部门只需调用即可)；而运营商数量增加或配置参数变更或出现异常参数导致的不常见案例(CornerCase)需要模拟测试，这时候只需更新运营商信令参数表即可。[0070] 这样，在确定出用例场景全集之后，可以从中选取待测用例场景，然后针对该待测用例场景执行测试。[0071] S102：基于待测用例场景，确定信令模型编号和协议参数。[0072] 需要说明的是，在本申请实施例中，用例场景与信令模型编号和协议参数之间具有映射关系。换言之，针对每一种用例场景，都设置有对应的信令模型编号和协议参数。在一些实施例中，以待测用例场景为例，对于信令模型编号和协议参数，该方法还可以包括：基于待测用例场景，从预设数据库中获取信令模型编号和所述协议参数。[0073] 还需要说明的是，在本申请实施例中，对于每一种用例场景，可以有多家运营商需要进行待测用例场景的测试。在这里，运营商与信令模型编号和协议参数之间也具有映射关系。换言之，在待测用例场景下，针对每一个运营商，都设置有对应的信令模型编号和协议参数。在一些实施例中，对于目标运营商对应的信令模型编号和协议参数，该方法还可以包括：基于待测用例场景，从预设数据库中获取目标运营商对应的信令模型编号和协议参数。[0074] 也就是说，在预设数据库中存储预设规划表和信令参数表，可以供后续模型选择和参数传递调用，以便针对待测用例场景从预设数据库中获取对应的信令模型编号和协议参数。[0075] S103：调用仪表设备中信令模型编号对应的目标信令模型，并将协议参数传递到目标信令模型中，以控制仪表设备生成目标测试脚本。[0076] 需要说明的是，在本申请实施例中，可以针对信令流程进行模型化设计，针对协议参数都封装成函数变量来传递不同的配置，然后将信令模型和协议参数与用例场景建立映射关系，从而就能够方便控制仪表设备自动生成特定的信令模型和协议参数对应的测试脚本。[0077] 还需要说明的是，在本申请实施例中，在执行测试之前，除了调用信令模型和传递参数之外，还需要配置硬件仪表环境。因此，在一些实施例中，该方法还可以包括：从预设数据库中获取第一参数信息；根据第一参数信息，配置仪表设备的环境。[0078] 在本申请实施例中，第一参数信息可以为小区参数信息。这样，根据小区参数信息配置硬件系统(即仪表设备)的环境，调用仪表设备中对应的信令模型，将协议参数传递配置到信令模型中，从而能够控制仪表设备自动生成一条仪表测试脚本。[0079] S104：基于目标测试脚本对待测用例场景进行测试，得到待测用例场景对应的测试结果。[0080] 需要说明的是，在本申请实施例中，根据待测用例场景来调用预设数据库中的小区参数、信令模型编号和协议参数信息，然后配置硬件仪表环境、调用信令模型、传递协议参数，进而控制仪表设备动态生成目标测试脚本，以便执行测试。在此之前，该方法还可以包括：向切卡器发送第一控制命令；其中，第一控制命令用于控制切卡器切换到第一测试卡。[0081] 还需要说明的是，在本申请实施例中，可以针对信令流程进行模型化设计，针对协议参数都封装成函数变量来传递不同运营商的配置，然后将信令模型和协议参数与运营商建立映射关系，从而就能够方便控制仪表设备自动生成特定的信令模型和协议参数对应的测试脚本，进而执行脚本测试。[0082] 这样，在执行脚本测试之前，还需要确定所对应的目标运营商，这里的第一测试卡即为目标运营商对应的测试卡。如果当前的切卡器处于非目标运营商对应的测试卡(如第二测试卡)，那么第一控制命令用于控制切卡器由第二测试卡切换到第一测试卡。换言之，首先控制切卡器切换到目标运营商对应的测试卡，然后再基于目标测试脚本对待测用例场景进行测试，以得到测试结果。[0083] 还需要说明的是，在本申请实施例中，测试卡可以为用户识别卡(SubscriberIdentityModule，SIM)，故切卡器又可称为“SIMSwitch”。其中，控制硬件系统(即切卡器)切换到目标运营商对应的SIM卡，然后执行目标测试脚本，以实现对待测用例场景的测试。[0084] 进一步地，对于硬件系统(如仪表设备、切卡器等)而言，在一些实施例中，该方法还可以包括：与硬件系统建立通信连接。其中，通过虚拟仪器软件架构(VirtualInstrumentsSoftwareArchitecture，VISA)接口可以建立测试设备与仪表设备之间的通用接口总线(General?PurposeInterfaceBus，GPIB)/传输控制协议(TransmissionControlProtocol，TCP)通信。在此基础上二次封装仪表设备的应用程序编程接口(ApplicationProgrammingInterface，API)，能够为测试执行提供远程控制、调用信令模型和传递协议参数信息。[0085] 进一步地，对于用例场景全集中的所有用例场景，在一些实施例中，以某一运营商为例，该方法还可以包括：遍历用例场景全集中的所有用例场景，将每一个用例场景依次作为待测用例场景，循环执行如图1所示的流程，直至得到所有用例场景对应的测试结果；根据所有用例场景对应的测试结果，生成目标测试开云优惠体育网页版入口。[0086] 进一步地，对于用例场景全集中的所有用例场景，在一些实施例中，以所有运营商为例，该方法还可以包括：遍历用例场景全集中的所有用例场景，将每一个用例场景依次作为待测用例场景，将每一个运营商依次作为目标运营商，循环执行以下步骤：[0087] 获取待测用例场景；基于待测用例场景，确定目标运营商对应的信令模型编号和协议参数；调用仪表设备中信令模型编号对应的目标信令模型，并将协议参数传递到目标信令模型中，以控制仪表设备生成目标测试脚本；基于目标测试脚本对待测用例场景进行测试，得到目标运营商在待测用例场景下对应的测试结果；[0088] 直至得到所有运营商在所有用例场景下对应的测试结果后，根据所有运营商在所有用例场景下的测试结果，生成目标测试开云优惠体育网页版入口。[0089] 也就是说，在本申请实施例中，对于每一个用例场景和每一个运营商，可以重复执行图1所示的流程，在所有运营商所有用例场景全部测试完成后，可以得到目标测试开云优惠体育网页版入口。[0090] 还需要说明的是，在本申请实施例中，除了在运营商规划、参数变更时迭代维护成本很低，在测试用例场景拓展方面成本同样极低，主要原因是本申请实施例的技术方案中信令模型和协议参数可复用率非常高，场景拓展开发工作量很小。具体地，在一些实施例中，该方法还可以包括：若待测用例场景与第一用例场景满足复用条件，则复用第一用例场景对应的信令模型，和/或，复用第一用例场景的部分协议参数。[0091] 其中，第一用例场景为用例场景全集中的任意一个用例场景。[0092] 在这里，表3示出了本申请实施例的技术方案在当前实践阶段针对200+运营商4G长期演进(Long?TermEvolution，LTE)、5G非独立组网(Non?StandAlone，NSA)/5G独立组网(StandAlone，SA)几大测试场景的信令模型建立和复用情况示例。[0093] 表3[0094][0095] 根据表3，由于ViLTE场景与VoLTE场景满足复用条件，那么ViLTE场景对应的信令模型可以直接复用VoLTE模型，对于协议参数而言，需要在SDP协议参数中增加视频编解码(videocodec)信息传递。另外，由于5GSAData场景与5GNSAData场景满足复用条件，那么对于5GSAData场景而言，可以复用5GNSA模型，然后用5GNSA参数配置仪表环境即可。[0096] 进一步地，在一些实施例中，该方法还可以包括：[0097] 若待测用例场景为视频场景，则复用语音场景对应的信令模型；或者，[0098] 若待测用例场景为5G独立组网制式下的数据场景，则复用5G非独立组网制式下数据场景对应的信令模型；或者，[0099] 若待测用例场景为5G独立组网制式下的非数据场景，则复用4G网络制式下非数据场景对应的信令模型；或者，[0100] 若待测用例场景为至少两个用例场景的组合场景，则将至少两个用例场景对应的信令模型进行并联。[0101] 也就是说，在本申请实施例中，目前预开发的信令模型一共有28个，覆盖的测试场景拆解成测试用例的话已经超过50，按已有常规方式则需开发上万脚本(用例数*运营商数)；但是以下几种拓展方案也都能体现高复用率和极小的开发量。示例性地，具体如下：[0102] (1)视频场景(ViLTE)拓展：直接复用语音场景(VoLTE)模型，在sdp协议参数中增加videocodec信息传递，ViWIFI场景也是同理；[0103] (2)5GSA相关场景拓展：这更能体现本技术方案的高复用率。运营商4G和5G网络使用的是IP多媒体系统(IPMultimediaSubsystem，IMS)、VoWIFI、Utserver等都是同一套，因此5G的语音场景(VoNR、EPSFB)，Ut补充业务，VoWIFI等都可以直接复用对应4G场景的信令模型和协议参数，只需在配置小区环境时，用5GNR参数替换4GLTE参数即可。而按照已有常规方式仅仅是VoNR中注册、主叫、被叫三条最基础的用例，想要覆盖200个运营商就是600仪表脚本的开发量，在本技术方案中只需额外增加VoNR用例集生成逻辑以及修改小区参数传递即可；[0104] (3)漫游场景拓展：这种最为简单，这时候直接读取漫游目的地的信令和参数即可；[0105] (4)组合场景拓展：比如VoWIFIUt或VoWIFIE911，则需将两种信令模型进行并联，相应的增加控制逻辑即可。[0106] 本实施例提供了一种测试方法，以其中一种用例场景为例，获取待测用例场景；基于待测用例场景，确定信令模型编号和协议参数；调用仪表设备中信令模型编号对应的目标信令模型，并将协议参数传递到目标信令模型中，以控制仪表设备生成目标测试脚本；基于目标测试脚本对待测用例场景进行测试，得到待测用例场景对应的测试结果。这样，基于信令模型化和参数变量化的设计，能够实现仪表脚本的自动生成，提高脚本的开发效率；而且对于不同用例场景分别对应有一套信令参数，从而还能够实现信令参数级别的仿真，提高仿真精度；另外，对于测试脚本的生成，该过程无需人工挑选测试脚本，同时信令模型和协议参数的复用率高，从而不仅能够降低迭代维护成本，还能够提升测试执行效率。[0107] 在本申请的另一实施例中，基于前述实施例所述的测试方法，这里提出了一种智能开发系统，智能开发系统作为一套软件系统承载在测试装置中。其中，信息获取、用例场景全集锁定、信令模型调用、协议参数传递、控制仪表设备自动生成脚本和测试执行等逻辑处理和代码实现都在智能开发系统中。对于智能开发系统，总共可以包括六个模块：图形用户界面(GraphicalUserInterface，GUI)模块、数据处理模块、主控(MainControl)模块、测试执行模块、结果管理模块和通信接口模块，如图2所示。[0108] 具体参见图2，智能开发系统中各模块的设计与交互如下：[0109] (1)GUI模块：提供用户操作界面(UserInterface，UI)，负责对接信息输入管理部分，获取全球运营商规划表和各运营商信令参数信息并存储到预设数据库。GUI模块还提供个性化设置接口，供测试人员按需选择测试场景，用于定向场景测试和辅助调试。其中，UI使用对象是专业测试执行人员，目前UI界面只实现了功能，并未做美化，如图3所示。[0110] 参见图3，通过UI界面可以选择手机平台、选择测试模式、输入运营商、输入项目规划表、选择通信方式、漫游运营商、输入公共参数运营商、选择测试业务等。另外，在UI界面中还显示有测试进度条，以及“开始”、“停止”、“退出”等按钮，便于测试执行人员选择是否开始/停止/退出测试。[0111] (2)数据处理模块：从GUI模块获取并储存全球运营商规划表和运营商信令参数表，供测试执行模块调用。[0112] (3)MainControl模块：智能开发系统的中控模块，对测试开云优惠体育网页版入口，测试log，硬件仪表、切卡器和手机终端进行对象创建和管理；根据运营商规划表信息或测试执行人员输入信息生成测试用例场景全集；运行异常保护机制，在测试时进行过程管理和异常处理，控制测试重试，信息重传，软/硬件系统重启等。[0113] (4)测试执行模块：脚本智能开发生成和测试执行的发起者。根据MainControl模块中的测试用例场景全集调用预设数据库中的小区参数、信令模型编号和协议参数信息，配置硬件仪表环境、调用信令模型、传递参数、控制仪表设备动态生成用例脚本，执行测试；控制切卡器改写SIM卡参数配合测试。[0114] (5)结果管理模块：负责测试开云优惠体育网页版入口生成和log打印保存。[0115] (6)通信接口模块：通过VISA建立测试设备与硬件仪表GPIB/TCP通信链路，在此链路上二次封装硬件仪表API接口，供测试执行模块远程控制、调用仪表和传递协议参数信息。[0116] 基于图2所示的智能开发系统，图4为本申请实施例提供的一种智能开发系统的逻辑实现示意图。如图4所示，在GUI模块中，首先进行业务选择(Thebusinessselection)，包括自动/手动(Auto/Manu)、公共运营商(CommonMarket)、漫游/本地(RoamingorLocal)和全球/项目测试(Gobalorprojecttest)。在仪表通信模块中，设置VISA接口(SetupVISAbase)、根据VISA接口的封装函数以及用于识别仪表的函数(Packagingfunctionaccordtovisabase,andthefunctionTodistinguishtheinstrument)，然后返回仿真对象(Returnsimulationobject)，包括获取Phone对象/VISA对象/logger对象/csv对象等；在加载通用仿真参数(Loadthecommonsimulationparameter)之后可以进入主控模块。在主控模块中，首先获取待测场景(Getthetestmarket)，从数据处理模块中获取用例场景全集，在该待测场景属于用例场景全集时，记录该场景和PLMN，并且获取场景信息；然后控制切卡器进行SIM卡切换、设置业务参数和加载测试脚本、执行用例和记录测试结果等；在该过程中，测试执行模块是脚本智能开发生成和测试执行的发起者，包括SIM卡切换、配置仪表环境、生成脚本、开始仿真和执行测试脚本等；直至最后一个运营商完成脚本测试；最后可以由结果管理模块生成测试开云优惠体育网页版入口和日志开云优惠体育网页版入口。[0117] 简单来说，智能开发系统的整个业务流程可分为以下几个步骤：[0118] a、信息获。和ü鼼UI模块获取全球运营商规划和各运营商信令参数信息，将信息更新到预设数据库，以供后续模型选择和参数传递调用；[0119] b、测试全集锁定：通过全球运营商规划或者用户自定义输入自动得出需要进行测试的用例场景全集；[0120] c、模型参数确定：针对待测用例场景从预设数据库中获取对应运营商的信令模型编号和相关协议参数；[0121] d、智能开发脚本：通过通信接口模块根据小区参数信息配置硬件系统(仪表设备)环境，调用仪表设备中对应的信令脚本模型，将协议参数传递配置到模型中，自动生成一条仪表测试脚本；[0122] e、触发测试执行：控制硬件系统(切卡器)切换对应运营商的测试卡，执行仪表测试脚本；[0123] f、循环执行步骤c～e直到所有运营商所有场景测试完成，生成测试开云优惠体育网页版入口。[0124] 进一步地，在本申请实施例中，本技术方案的信令模型和协议参数可复用率非常高，场景拓展开发工作量很小。虽然针对不同业务场景的总体设计理念和逻辑是一致的，但在具体实践中这些业务场景都有其特有的设计，下面以几大业务场景为例对其进行详细介绍。[0125] 在一种可能的实现方式中，待测用例场景为语音(VoLTE)场景。这时候，该方法还可以包括：[0126] 确定支持语音业务时所对应的语音协议参数；[0127] 若语音业务的服务类型为IMS注册服务，则调用IMS注册服务对应的第一目标信令模型，并将语音协议参数传递到第一目标信令模型中，以控制仪表设备生成IMS注册测试脚本；[0128] 若语音业务的服务类型为IMS主叫服务，则调用IMS主叫服务对应的第二目标信令模型，并将语音协议参数传递到第二目标信令模型中，以控制仪表设备生成IMS主叫测试脚本；[0129] 若语音业务的服务类型为IMS被叫服务，则调用IMS被叫服务对应的第三目标信令模型，并将语音协议参数传递到第三目标信令模型中，以控制仪表设备生成IMS被叫测试脚本；[0130] 相应地，基于目标测试脚本对待测用例场景进行测试，得到待测用例场景对应的测试结果，可以包括：[0131] 根据IMS注册测试脚本对被测设备的IMS注册服务进行用例测试，生成第一测试结果；[0132] 根据IMS主叫测试脚本对被测设备的IMS主叫服务进行用例测试，生成第二测试结果；[0133] 根据IMS被叫测试脚本对被测设备的IMS被叫服务进行用例测试，生成第三测试结果；[0134] 基于第一测试结果、第二测试结果和第三测试结果，得到语音场景对应的测试结果。[0135] 需要说明的是，VoLTE是信令模型和协议参数最复杂的测试场景，同时也是信令模型化和参数变量化最典型的应用，对于该测试场景而言，信令模型多(13种)，参数多(小区参数、SIP协议参数、SDP协议参数)。在测试执行模块从主控模块中获取待测试的VoLTE用例集(需要测试VoLTE的运营商)之后，从预设数据库中获取对应运营商的信令模型编号和几十个协议参数，然后通过通信接口模块调用仪表设备对应的信令模型和传递参数变量。其中，表4示出了本申请实施例提供的一种VoLTE信令模型的示例。[0136] 表4[0137][0138] 参见图5，其示出了本申请实施例提供的一种VoLTE场景的逻辑实现示意图。如图5所示，被测设备以用户设备(UserEquipment，UE)为例，该流程可以包括：[0139] S501：运营商信令仿真数据。[0140] S502：是否支持VoLTE。[0141] S503：若不支持VoLTE，则确定结果列CallResult为NS。[0142] S504：若支持VoLTE，则是否已确认VoLTE参数。[0143] S505：若未确认VoLTE参数，则确定结果列CallResult为NR。[0144] 需要说明的是，在已确认VoLTE参数的情况下，这里包括以下三种服务类型：[0145] S506：若为IMS注册服务，则根据运营商数据选择对应的信令模型(type0～Type2)。[0146] S507：若为IMS主叫服务，则根据运营商数据选择对应的信令模型(type0～Type13)。[0147] S508：若为IMS被叫服务，则根据运营商数据选择对应的信令模型(type0～Type2)。[0148] S509：参数变量传递。[0149] 其中，对于IMS注册服务，用例变量如：VoLTE_reg_200OK_contact、VoLTE_reg_200OK_FeatureCaps；对于IMS主叫服务，用例变量如：VoLTE_voiceMO_183_from、VoLTE_voiceMO_183_contact；但是不作具体限定。[0150] S510：生成IMS注册测试用例并开始测试。[0151] 其中，具体包括：判断UE是否成功注册网络，若未成功注册网络，则确定结果列Reg为ATTACHFAIL；若成功注册网络，则UE注册IMS，并继续判断IMS是否注册完成；若IMS未注册完成，则确定结果列Reg为FAIL；若IMS注册完成，则确定结果列Reg为PASS。[0152] S511：生成IMS主叫测试用例并开始测试。[0153] 其中，具体包括：判断UE是否成功注册网络，若未成功注册网络，则确定结果列VoLTE_MO/VoLTE_MT为ATTACHFAILl；若成功注册网络，则UE注册IMS，并继续判断IMS是否注册完成；若IMS未注册完成，则确定结果列VoLTE_MO为NT；若IMS注册完成，则进行语音主叫通话，判断是否通话成功，若未通话成功，则确定结果列VoLTE_MO为FAIL；若通话成功，则确定结果列VoLTE_MO为PASS。[0154] S512：生成IMS被叫测试用例并开始测试。[0155] 其中，具体包括：判断UE是否成功注册网络，若未成功注册网络，则确定结果列VoLTE_MO/VoLTE_MT为ATTACHFAILl；若成功注册网络，则UE注册IMS，并继续判断IMS是否注册完成；若IMS未注册完成，则确定结果列VoLTE_MT为NT；若IMS注册完成，则进行语音被叫通话，判断是否通话成功，若未通话成功，则确定结果列VoLTE_MT为FAIL；若通话成功，则确定结果列VoLTE_MT为PASS。[0156] S513：汇总结果列CallResult。[0157] S514：保存测试结果。[0158] S515：判断遍历运营商已完成。[0159] 其中，若没有遍历完运营商，则返回继续执行S501；若遍历完运营商，则结束流程。[0160] 在另一种可能的实现方式中，待测用例场景为紧急呼叫(E911call)场景。这时候，该方法还可以包括：[0161] 设置i的初始值等于0；[0162] 判断紧急信令模型编号是否等于i；[0163] 若紧急信令模型编号不等于i，则将i+1赋值为i，继续执行判断紧急信令模型编号是否为i的操作；[0164] 若紧急信令模型编号等于i，则确定第i组协议参数，并将第i组协议参数传递到第i个紧急信令模型，以控制仪表设备生成紧急呼叫测试脚本；其中，不同组的协议参数之间具有交织关系，且i为大于或等于0且小于N的整数，N表示紧急信令模型的总数量；[0165] 相应地，基于目标测试脚本对待测用例场景进行测试，得到待测用例场景对应的测试结果，可以包括：[0166] 根据紧急呼叫测试脚本对被测设备的紧急呼叫服务进行用例测试，得到紧急呼叫场景对应的测试结果。[0167] 需要说明的是，在本申请实施例中，N的取值一般为12，即实际中有12个紧急信令模型。每一个紧急信令模型对应有一组协议参数；但是这12组协议参数之间存在交织关系，并非是相互独立的。[0168] 还需要说明的是，在E911call场景下，信令模型多(12种)，参数少，这里的参数主要涉及网络附加存储(NetworkAttachedStorage，NAS)协议、原小区及回落小区参数和少量SIP协议。E911call场景并不像VoLTE那样信令模型选型和参数传递相对独立，这两块是交织耦合，互相影响的；因此需要在测试执行模块中额外增加一些选型和传参逻辑。其中，表5示出了本申请实施例提供的一种E911call信令模型的示例。[0169] 表5[0170][0171][0172] 参见图6，其示出了本申请实施例提供的一种E911call场景的逻辑实现示意图。如图6所示，被测设备仍以UE为例，该流程可以包括：[0173] S601：加载预设数据库。[0174] S602：按序读取数据库中内容。[0175] S603：判断紧急信令模型是否为0。[0176] S604：若紧急信令模型为0，则传递参数PLMN、网络支持VOLTE、紧急号码、网络不支持E911、网络带的紧急号码列表。[0177] S605：若紧急信令模型不为0，则判断紧急信令模型是否为1。[0178] S606：若紧急信令模型为1，则传递参数PLMN、网络支持VOLTE、紧急号码、网络支持E911、网络带的紧急号码列表，网络响应的380拒绝码。[0179] S607：若紧急信令模型不为1，则判断紧急信令模型是否为2。[0180] S608：若紧急信令模型为2，则传递参数PLMN、网络支持VOLTE、紧急号码、网络不支持E911、网络带的紧急号码列表，380拒绝码。[0181] S609：若紧急信令模型不为2，则判断紧急信令模型是否为3。[0182] S610：若紧急信令模型为3，则传递参数PLMN、网络支持VOLTE、紧急号码、网络支持E911、网络带的紧急号码列表。[0183] S611：若紧急信令模型不为3，则判断紧急信令模型是否为4。[0184] S612：若紧急信令模型为4，则传递参数PLMN、网络支持VOLTE、紧急号码、网络不支持E911、网络带的紧急号码列表、网络响应的380拒绝码。[0185] S613：若紧急信令模型不为4，则判断紧急信令模型是否为5。[0186] S614：若紧急信令模型为5，则传递参数PLMN、网络不支持VOLTE、紧急号码、网络不支持E911、网络带的紧急号码列表。[0187] 需要说明的是，若紧急信令模型不为5，则继续判断紧急信令模型是否为6，依次类推，直至执行步骤S615：判断紧急信令模型是否为11。其中，若紧急信令模型不为11，则返回执行步骤S602，进入一个运营商紧急号码的执行操作。[0188] S616：若紧急信令模型为11，则传递参数PLMN、网络支持VOLTE、紧急号码、网络支持E911。[0189] S617：生成测试用例脚本。[0190] S618：执行用例脚本。[0191] S619：UE注册网络，拨打紧急号码。[0192] S620：判断UE上报信令与信令模型一致。[0193] S621：若判断结果不一致，则记录测试结果为失败。[0194] S622：若判断结果一致，则记录测试结果为通过。[0195] S623：是否已遍历完所有运营商紧急号码。[0196] 其中，若没有遍历完所有运营商紧急号码，则返回继续执行S602；若遍历完所有运营商紧急号码，则结束流程。[0197] 在又一种可能的实现方式中，待测用例场景为基于WIFI热点的语音(VoWIFI)场景。这时候，该方法还可以包括：[0198] 从预设数据库中获取小区参数和第一服务器参数；[0199] 若需要配置文件，则修改仪表设备的配置文件，并根据配置文件与鉴权方式之间的映射关系进行鉴权方式更新；[0200] 若不需要配置文件，则从预设数据库中获取第一鉴权方式；[0201] 通过判断被测设备是否VoWIFI注册成功以及是否支持语音业务，生成VoWIFI场景对应的测试开云优惠体育网页版入口。[0202] 需要说明的是，第一服务器参数可以为演进型分组数据网关(EvolevdPacketDataGateway，EPDA)服务器参数。另外，配置文件可以为初始化文件(InitializationFile，.ini)。在这里，如果需要配置ini文件，那么修改仪表设备的ini文件，并更新鉴权方式；如果不需要配置ini文件，那么可以用预设数据库中直接选择IKE_SA鉴权方式(即第一鉴权方式)。[0203] 进一步地，在一些实施例中，在判断被测设备是否VoWIFI注册成功以及是否支持语音业务之前，该方法还可以包括：[0204] 若需要更换到目标媒体访问控制(MediaAccessControlAddress，MAC)地址，则设置目标MAC地址；[0205] 若需要在飞行模式下进行VoWIFI注册，则开启飞行模式。[0206] 还需要说明的是，在VoWIFI场景下，VoWIFI场景只需要一种模型，除了小区参数和少量SIP参数，还需传递EPDA服务器参数，该场景复杂之处在于鉴权算法有多种且需要额外预置不同的配置ini文件，因此测试执行模块中增加了鉴权算法和配置文件之间的映射关系，并额外建立套接字(Socket)通信给硬件仪表发送预置ini文件。[0207] 参见图7，其示出了本申请实施例提供的一种VoWIFI场景的逻辑实现示意图。如图7所示，被测设备仍以UE为例，该流程可以包括：[0208] S701：载入仪表配置模板，选择小区制式。[0209] S702：传递小区/IMS服务器参数。[0210] S703：传递EPDG服务器参数。[0211] S704：是否需要配置ini文件。[0212] S705：若需要配置ini文件，则修改仪表外部ini文件，以及更改鉴权方式。[0213] S706：若不需要配置ini文件，则选择IKE_SA鉴权方式。[0214] 需要说明的是，步骤S702、S703和S706均是从预设数据库中读取得到的。[0215] S707：是否需要更换MAC地址。[0216] S708：若需要更换MAC地址，则设置对应的MAC地址。[0217] S709：是否需要飞行模式下注册voWIFI。[0218] S710：若需要飞行模式下注册voWIFI，则开启飞行模式。[0219] S711：判断注册VoWIFI成功。[0220] S712：判断是否支持VoLTE。[0221] S713：生成csv记录测试结果。[0222] 还需要说明的是，如果注册VoWIFI不成功，那么可以直接生成csv记录测试结果；如果注册VoWIFI成功，那么可以根据VoWIFIMO/MTCall生成csv记录测试结果，也可以根据VoWIFIMO/MTSMS生成csv记录测试结果。[0223] 还需要说明的是，如果不支持VoLTE，那么可以直接生成csv记录测试结果；如果支持VoLTE，那么可以根据VoLTE注册(VoLTERegistration)生成csv记录测试结果，也可以根据在语音呼叫结果(VoWIFI&VoLTEHODuringvoicecall)生成csv记录测试结果。[0224] S714：判断是否测试完成。[0225] 其中，对于VoWIFI运营商测试集，若测试没有完成，则返回继续执行S701；若测试完成，则结束流程。[0226] 在又一种可能的实现方式中，待测用例场景为补充业务(Ut)场景。这时候，该方法还可以包括：[0227] 从预设数据库中获取小区参数、第二服务器参数和第二鉴权方式；[0228] 若需要安全证书进行加密，则加载安全证书并配置加密端口；[0229] 加载业务配置文件，通过判断业务配置文件中的业务设置是否成功，生成补充业务场景对应的测试开云优惠体育网页版入口。[0230] 需要说明的是，第二服务器参数可以为XML配置访问协议(XMLConfigurationAccessProtocol，XCAP)/绑定支持功能(BindingSupportFunction，BSF)服务器参数，第二鉴权方式可以为BSF服务器的通用引导架构(GnericBootstrappingArchitecture，GBA)鉴权方式。其中，根据终端通用集成电路卡(UniversalIntegratedCircuitCard，UICC)能力的不同，GBA可以分为GBA_ME和GBA_U。前者密钥的协商和生成都在移动设备(MobileEquipment，ME)中完成，而后者密钥的协商和生成都在UICC中完成，因此安全性更高。[0231] 还需要说明的是，在Ut补充业务场景下，Ut也是一种模型，除了少量SIP参数外，还需传递XCAP/BSF服务器参数；测试执行模块针对GBA?ME和GBA?U两种鉴权模式额外增加接口控制硬件仪表；对于支持安全传输层协议(TransportLayerSecurity，TLS)加密的运营商，还增加了TLS证书载入操作并配置加密端口。[0232] 参见图8，其示出了本申请实施例提供的一种Ut补充业务场景的逻辑实现示意图。如图8所示，被测设备仍以UE为例，该流程可以包括：[0233] S801：载入仪表配置模板，选择小区制式。[0234] S802：传递小区IMS服务器参数。[0235] S803：传递XCAP/BSF服务器参数。[0236] S804：选择BSF服务器GBA鉴权方式。[0237] 需要说明的是，步骤S802、S803和S804均是从预设数据库中读取得到的。[0238] S805：判断是否需要TLS证书加密。[0239] S806：若需要TLS证书加密，则载入TLS证书，配置https加密端口。[0240] S807：载入业务配置文件xml。[0241] S808：生成csv记录测试结果。[0242] 还需要说明的是，在载入业务配置文件xml之后，如果无条件呼叫转移(CallForwardingUnconditional，CFU)业务设置成功，那么生成csv记录测试结果；如果CFU业务设置不成功，那么也会生成csv记录测试结果；如果遇忙些呼叫转移(CallForwardingBusy，CFB)业务设置成功，那么生成csv记录测试结果；如果CFB业务设置不成功，那么也会生成csv记录测试结果；如果CFU业务设置不成功，那么也会生成csv记录测试结果；如果不可及呼叫转移(CallForwardwhenNoReachable，CFNR/CFNRc)业务设置成功，那么生成csv记录测试结果；如果CFNR/CFNRc业务设置不成功，那么也会生成csv记录测试结果；如果呼叫等待(CallWaiting，CW)业务设置成功，那么生成csv记录测试结果；如果CW业务设置不成功，那么也会生成csv记录测试结果。[0243] S809：判断是否测试完成。[0244] 其中，对于Ut运营商测试集，若测试没有完成，则返回继续执行S801；若测试完成，则结束流程。[0245] 本实施例提供了一种智能开发系统，通过上述实施例对前述实施例的具体实现进行了详细阐述，从中可以看出，通过前述实施例的技术方案，基于信令模型化和参数变量化的设计，能够实现仪表脚本的自动生成，提高脚本的开发效率；而且对于不同用例场景下各运营商分别对应有一套信令参数，从而还能够实现信令参数级别的仿真，提高仿真精度；另外，对于测试脚本的生成，该过程无需人工挑选测试脚本，同时信令模型和协议参数的复用率高，从而不仅能够降低迭代维护成本，还能够提升测试执行效率。[0246] 在本申请的又一实施例中，基于前述实施例所述的智能开发系统，具体可以称为全球信令仿真????智能开发系统，目的是实现仪表脚本批量智能生成，无需逐条开发，同时实现信令参数级别的模拟，极大提升仿真精度，且后续迭代维护成本极低。[0247] 在本申请实施例中，图9示出了本申请实施例提供的一种测试系统的架构示意图。如图9所示，从整体架构上可以分为三部分：信息输入管理、智能开发系统和硬件系统。其中，信息输入管理包括有全球运营商规划表和现网信令参数表；智能开发系统包括GUI模块、数据处理模块、结果管理模块、主控模块和测试执行模块；硬件系统以Anritsu8000+8475B测试系统为例，可以包括测试模式、场景库和切卡器。[0248] 其中，对于信息输入管理，该部分由石墨表格作为信息输入口(也可使用excel等信息储存介质)，信息最终存入智能开发系统中的数据库供其管理和调用。该部分主要存储两类信息：全球运营商规划表和现网信令参数表(即运营商信令参数表)。其中，全球运营商规划信息是由手机终端公司规划部门根据产品规划、定位、目标上市区域等结合各运营商白皮书制定的一份上市规划，不同产品系列略有差异。该信息决定了手机终端针对全球运营商需要测试的场景全集：需要测试的运营商总数以及每家运营商需要测试的场景总数。[0249] 可以理解地，已有的常规做法就是测试执行人员根据规划信息，从仪表脚本集中挑选适用的脚本进行测试。而在本技术方案中无需挑选脚本，智能开发系统会根据规划信息输入触发生成所需的测试脚本。[0250] 另外，运营商信令参数表储存着各个测试场景信令流程类型和3GPP协议参数信息，与各运营商一一对应。这两个信息通过运营商白皮书和各运营商网络下手机终端log提炼获。际趺偶骱艿，通信领域测试工程师都可以做，也可以用脚本实现自动提炼，无需依赖专业仪表开发人员和仪表资源。[0251] 以石墨表格作为信息输入口，导入数据库进行管理和调用的模式可以极大降低后续迭代维护成本。运营商4G/5G技术演进和规划变更，可以通过修改全球运营商规划表进行更新(一般来说这类变更是由规划部门提供，测试业务部门只需调用即可)；运营商数量增加或配置参数变更或出现异常参数导致的cornercase需要模拟，则只需更新信令参数表，本技术方案的另外两大部分–智能开发系统和硬件系统是无需修改的。[0252] 对于智能开发系统，该智能开发系统是独立设计开发的一套软件系统，是整套方案的核心部分，输入信息的管理处理、测试全集锁定、信令模型调用、协议参数变量传递、控制仪表自动生成脚本和测试执行等逻辑处理和代码实现都在这个部分。在这里，智能开发系统对接信息输入管理和硬件系统两个部分，总共有六个模块：GUI模块、数据处理模块、MainControl模块、测试执行模块、结果管理模块和通信接口模块。[0253] 对于硬件系统，硬件系统主要包含一套安立MT8000仪表设备和SIMswitch切卡器，加上辅助设备如PC机，多端口转发器(HUB)，供电装置等，具体参见图10。如图10所示，智能开发系统和信息输入管理位于测试设备中，硬件系统有仪表设备和切卡器。除此之外，这里还包括有服务设备(ServerPC)、以太网交换机(ethernetswitchingHub)、信令测试仪(MD8475B)、系统监控软件(SystemSafetyMonitor，SSM)和功率计(PowerMeter)等；其中，设备与设备之间可以通过以太网电缆(Ethernetcable)、通用串行总线(UniversalSerialBus，USB)、射频(RadioFrequency，RF)线、同步线缆(Sync)等进行通信连接。[0254] 具体地，安立MT8000仪表(8475B仪表也可复用作为4G场景测试资源)作为信令模型载体和测试执行实体，由智能开发系统中的测试执行模块进行配置、调用和控制。信令模型脚本与现有常规测试脚本是有明显差异的，以VoLTE通话SIP协议中INVITE信令为例，图11呈现的是常规测试脚本，信令中的协议参数都是RFC协议中的标准内容；图12呈现的是信令模型脚本，协议参数都是自定义的函数变量，具体内容由智能开发系统进行赋值。[0255] 还可以理解地，信令模型只是一套信令框架，在智能开发系统中传递参数之前是无法单独执行测试的。另外，Simswitch是一个可以修改各种SIM参数的小型设备，模拟运营商测试SIM卡，由智能开发系统中的测试执行模块进行参数改写等控制，配合自动生成的测试脚本执行测试。[0256] 简单来说，在本申请实施例中，基于信令模型化和参数变量化的设计，实现仪表脚本智能开发生成，达到信令参数级仿真；这里提供了一种集用例选型、脚本开发、测试执行一体化的全自动全球运营商测试系统，一方面，脚本开发效率高：所有仪表测试脚本智能动态生成，全自动化开发，取代传统人工逐条脚本开发的模式。另一方面，模拟仿真精度高：实现各运营商各场景信令参数级别仿真，取代同一模型只做点检这种传统方式。又一方面，迭代维护成本低：运营商规划变更、新增，参数变更等只需修改输入表，工作量。际趺偶鞯，不依赖专业脚本开发工程师和仪表资源；而且信令模型和协议参数复用率高，业务场景拓展开发量。4G?5G协议演进绝大部分场景可直接复用，无需额外开发仪表脚本。再一方面，测试执行效率提升：根据运营商规划表或人工选择自动生成测试用例全集，无需人工挑选测试脚本。[0257] 在本申请的再一实施例中，基于前述实施例相同的发明构思，参见图13，其示出了本申请实施例提供的一种测试装置130的组成结构示意图。如图13所示，测试装置130可以包括：主控模块1301和测试执行模块1302，其中：[0258] 主控模块1301，配置为获取待测用例场景；[0259] 测试执行模块1302，配置为基于待测用例场景，确定信令模型编号和协议参数；以及调用仪表设备中信令模型编号对应的目标信令模型，并将协议参数传递到目标信令模型中，以控制仪表设备生成目标测试脚本；以及基于目标测试脚本对待测用例场景进行测试，得到待测用例场景对应的测试结果。[0260] 在一些实施例中，主控模块1301，配置为根据预设规划表和/或预置输入信息，生成用例场景全集；以及从用例场景全集中获取待测用例场景。[0261] 在一些实施例中，参见图13，测试装置130还包括信息获取模块1303和数据处理模块1304，其中：[0262] 信息获取模块1303，配置为获取预设规划表和信令参数表；[0263] 数据处理模块1304，配置为将预设规划表和信令参数表存储至预设数据库中。[0264] 在一些实施例中，测试执行模块1302，还配置为基于待测用例场景，从预设数据库中获取信令模型编号和协议参数。[0265] 在一些实施例中，测试执行模块1302，还配置为从预设数据库中获取第一参数信息；以及根据第一参数信息，配置仪表设备的环境。[0266] 在一些实施例中，数据处理模块1304，还配置为若通信技术演进或者规划变更，则更新预设规划表；或者，若配置参数变更或者出现异常参数，则更新信令参数表。[0267] 在一些实施例中，测试执行模块1302，还配置为向切卡器发送第一控制命令；其中，第一控制命令用于控制切卡器切换到第一测试卡。[0268] 在一些实施例中，参见图13，测试装置130还包括通信接口模块1305，配置为与硬件系统建立通信连接，其中硬件系统至少包括仪表设备和切卡器。[0269] 在一些实施例中，参见图13，测试装置130还包括结果管理模块1306，配置为遍历用例场景全集中的所有用例场景，在所有用例场景全部测试完成后，生成目标测试开云优惠体育网页版入口。[0270] 可以理解，在本实施例中，“单元”可以是部分电路、部分处理器、部分程序或软件等等，当然也可以是模块，还可以是非模块化的。而且在本实施例中的各组成部分可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。[0271] 所述集成的单元如果以软件功能模块的形式实现并非作为独立的产品进行销售或使用时，可以存储在一个计算机可读取存储介质中，基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或processor(处理器)执行本实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ReadOnlyMemory，ROM)、随机存取存储器(RandomAccessMemory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。[0272] 因此，本实施例提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，计算机程序被至少一个处理器执行时实现前述实施例中任一项所述的方法的步骤。[0273] 基于上述测试装置130的组成以及计算机可读存储介质，参见图14，其示出了本申请实施例提供的测试设备140的具体硬件结构示意图。如图14所示，测试设备140可以包括：通信接口1401、存储器1402和处理器1403；各个组件通过总线系统1404耦合在一起。可理解，总线系统1404用于实现这些组件之间的连接通信。总线系统1404除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图14中将各种总线都标为总线系统1404。其中：[0274] 通信接口1401，用于在与其他外部网元之间进行收发信息过程中，信号的接收和发送；[0275] 存储器1402，用于存储能够在处理器1403上运行的计算机程序；[0276] 处理器1403，用于在运行所述计算机程序时，执行：[0277] 获取待测用例场景；[0278] 基于待测用例场景，确定信令模型编号和协议参数；[0279] 调用仪表设备中信令模型编号对应的目标信令模型，并将协议参数传递到目标信令模型中，以控制仪表设备生成目标测试脚本；[0280] 基于目标测试脚本对待测用例场景进行测试，得到待测用例场景对应的测试结果。[0281] 可以理解，本申请实施例中的存储器1402可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read?OnlyMemory，ROM)、可编程只读存储器(ProgrammableROM，PROM)、可擦除可编程只读存储器(ErasablePROM，EPROM)、电可擦除可编程只读存储器(ElectricallyEPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(RandomAccessMemory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(StaticRAM，SRAM)、动态随机存取存储器(DynamicRAM，DRAM)、同步动态随机存取存储器(SynchronousDRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(DoubleDataRateSDRAM，DDRSDRAM)、增强型同步动态随机存取存储器(EnhancedSDRAM，ESDRAM)、同步链动态随机存取存储器(SynchronouslinkDRAM，SLDRAM)和直接内存总线随机存取存储器(DirectRambusRAM，DRRAM)。本文描述的系统和方法的存储器1402旨在包括但不限于这些和任意其它适合类型的存储器。[0282] 而处理器1403可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器1403中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1403可以是通用处理器、数字信号处理器(DigitalSignalProcessor，DSP)、专用集成电路(ApplicationSpecificIntegratedCircuit，ASIC)、现场可编程门阵列(FieldProgrammableGateArray，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器1402，处理器1403读取存储器1402中的信息，结合其硬件完成上述方法的步骤。[0283] 可以理解的是，本文描述的这些实施例可以用硬件、软件、固件、中间件、微码或其组5合来实现。对于硬件实现，处理单元可以实现在一个或多个专用集成电路(ApplicationSpecificIntegratedCircuits，ASIC)、数字信号处理器(DigitalSignalProcessing，DSP)、数字信号处理设备(DSPDevice，DSPD)、可编程逻辑设备(ProgrammableLogicDevice，PLD)、现场可编程门阵列(Field?ProgrammableGateArray，FPGA)、通用处理器、控制器、微控制器、微处理器、用于执行本申请所述功能的其它电子单元或其组合中。[0284] 0对于软件实现，可通过执行本文所述功能的模块(例如过程、函数等)来实现本文所述的技术。软件代码可存储在存储器中并通过处理器执行。存储器可以在处理器中或在处理器外部实现。[0285] 可选地，作为另一个实施例，处理器1403还配置为在运行所述计算机程序时，执行前述实施例中任一项所述的方法的步骤。[0286] 5在本申请的再一实施例中，本申请实施例还提供了另一种测试设备140，该测试设备140[0287] 包括前述实施例中所述的测试装置130。[0288] 在本申请的再一实施例中，本申请实施例还提供了一种测试系统，图15示出了本申请实施例提供的一种测试系统的组成结构示意图。如图15所示，测试系统150至少可以包括[0289] 测试设备140和硬件系统；其中，该硬件系统至少可以包括仪表设备1501和切卡器1502。0在本申请实施例中，测试设备140分别与仪表设备1501和切卡器1502连接，用于基于[0290] 待测用例场景，确定信令模型编号和协议参数；调用仪表设备1501中信令模型编号对应的目标信令模型，并将协议参数传递到目标信令模型中，以控制仪表设备1501生成目标测试脚本；然后控制切卡器1502切换到目标运营商对应的测试卡，基于目标测试脚本对待测用例场景进行测试，得到待测用例场景对应的测试结果。[0291] 5这样，基于信令模型化和参数变量化的设计，能够实现仪表脚本的自动生成，提高脚本的开发效率；而且对于不同用例场景下各运营商分别对应有一套信令参数，从而还能够实现信令参数级别的仿真，提高仿真精度；另外，对于测试脚本的生成，该过程无需人工挑选测试脚本，同时信令模型和协议参数的复用率高，从而不仅能够降低迭代维护成本，还能够提升测试执行效率。[0292] 0需要说明的是，在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排[0293] 他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。[0294] 5上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。[0295] 本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。[0296] 本申请所提供的几个产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。[0297] 0本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任[0298] 意组合，得到新的方法实施例或设备实施例。[0299] 以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应[0300] 涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

专利地区：广东

专利申请日期：2022-12-02

专利公开日期：2024-11-29

专利公告号：CN116055344B