用于无线通信的测试方法、测试装置及存储介质与流程

本公开涉及测试技术领域，具体地，涉及用于无线通信的测试方法、测试装置及存储介质。

背景技术：

随着科学技术的日益发展，对各种设备和装置在设计时或实际投入使用前进行充分的功能或性能的测试变得越来越重要。示例性地，无线通信物理层为通讯设备之间的数据通信提供传输链路，并提供可靠的数据传输环境。随着现代通讯技术发展的日新月异以及dsp芯片的更新迭代，例如，embb（enhancedmobilebroadband，增强移动宽带）、mmtc（massivemachinetypeofcommunication，海量机器类通信）、urllc（ultrareliablelowlatencycommunication，高可靠和低延迟通信）等新的通信场景的引入，对无线通信系统的性能需求日益提升，基站物理层软件和硬件需要频繁更新和改进。在如此高频率更新的情况下，为保证设备间数据传输的可靠性，有必要对物理层的通信链路进行高覆盖性的测试。

示例性地，在现有的无线通信物理层测试方案中，测试者基于通信协议以及测试的目的和内容人工地设计测试参数，再通过算法仿真器生成固定的测试用例，随后使用上述测试用例实施测试。然而，现有的测试方法存在如下问题：

（1）无线通信物理层的应用场景多变，现有方式生成的测试用例无法遍历到各种场景，测试场景覆盖率低；

（2）目前的无线通信物理层测试主要是依靠人工来配置相应的测试参数，并通过算法仿真器生成固定的测试用例，并且，在日常维护中长期使用这些老旧的测试用例对物理层进行测试，不利于发现新问题；

（3）在无线通信物理层引入新的硬件技术、更新软件控制算法、或更换新的dsp芯片等操作之后，后续的相关测试需要根据相应的变化人工调整或引入新的测试参数，如调整或引入新的系统参数、各信道参数、用户级参数等。并且，根据重新配置的测试参数，也需要同步更新算法仿真器，来更新已有的测试用例，这增加了无线通信物理层日常维护工作的复杂性和工作量。

技术实现要素：

本公开的目的在于，针对现有技术中存在的问题，提供一种用于无线通信的测试方法、测试装置及存储介质，使测试能够覆盖目标测试对象多变的应用场景，并减轻测试用例的生成及日常维护的工作量。

根据本公开的一个方面，提出一种用于无线通信的测试方法，包括（s1）：根据测试参数和所述测试参数的预设遍历范围自动生成第一测试用例集合；（s2）：基于预设的约束条件对所述第一测试用例集合中的测试用例进行筛选以获得第二测试用例集合；（s3）：基于所述第二测试用例集合中的全部测试用例实施针对目标测试对象的测试。

在一些实施例中，所述测试方法还包括（s4）：统计测试结果以获得测试通过率，并记录测试结果为“失败”的测试用例。

在一些实施例中，所述测试方法还包括：（s5）：根据所述目标测试对象的硬件或软件功能特性的变化增加或删减所述测试参数；（s6）：根据增加或删减的所述测试参数，对应地修改所述约束条件；（s7）：根据所述目标测试对象的软件逻辑特性的变化更新所述约束条件。

根据本公开的另一个方面，提出一种用于无线通信的测试装置，包括用例生成模块，用于根据测试参数和所述测试参数的预设遍历范围自动生成第一测试用例集合；用例筛选模块，用于基于预设的约束条件对所述第一测试用例集合中的测试用例进行筛选以获得第二测试用例集合；测试执行模块，用于基于所述第二测试用例集合中的全部测试用例实施针对目标测试对象的测试。

在一些实施例中，所述测试装置还包括测试分析模块，用于统计测试结果以获得测试通过率，并记录测试结果为“失败”的测试用例。

根据本公开的再一个方面，提出一种用以存储处理器可执行指令的计算机可读存储介质，所述计算机可读存储介质中存储的处理器可执行指令在被执行时能够致使处理器实施如上所述的测试方法。

本公开提供了一种用于无线通信的测试方法、测试装置及存储介质，能够覆盖目标测试对象多变的应用场景，并减轻测试用例的生成及日常维护的工作量。具体地，用例生成模块根据测试场景确定相关联的测试参数，并基于各个测试参数的遍历范围随机地生成各个测试参数的取值元素，将各个测试参数的取值元素进行随机组合以批量地生成测试用例。批量生成的测试用例能够覆盖测试目标多变的应用场景，有助于及时发现目标测试对象的存在的问题。进一步地，用例筛选模块根据预设的约束条件对批量生成的测试用例进行筛选，以剔除目标测试对象在原理上不支持的测试用例，有助于提高测试效率和测试结果的有效性。并且，约束条件根据每一次测试的测试结果进行更新，以在后续测试的筛选步骤中便将目标测试对象不支持的测试用例删除，避免相同测试场景的重复测试过程中因同样的原因造成测试“失败”。进一步地，在测试用例的日常维护过程中，若目标测试对象的软件或硬件功能特性发生变化，或者目标测试对象的软件逻辑特性发生变化，则通过用例生成模块和用例筛选模块对相关的测试参数和约束条件进行增加、删减或修改等操作，以重新批量地生成更新后的测试用例，不再需要逐一修改现有的测试用例，能够减轻测试用例的生成和日常维护的工作量。

附图说明

下面结合附图，通过对本公开的具体实施方式详细描述，将使本公开的技术方案及其它有益效果显而易见。

图1为本公开实施例一提供的测试方法的流程示意图。

图2至图4分别为本公开实施例一中s1、s2和s4的子步骤示意图。

图5为本公开实施例三提供的测试方法的流程示意图。

图6为本公开实施例四提供的测试装置的结构示意图。

具体实施方式

下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。本公开的说明书和权利要求书以及附图中的术语“第一”、“第二”、“第三”等（如果存在）是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应当理解，这样描述的对象在适当情况下可以互换。此外，术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排它的包含。在本公开的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。在本公开的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”“相连”“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接或可以相互通讯；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通或两个元件的相互作用关系。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本公开中的具体含义。

实施例一：

具体地，请参阅图1，为本公开实施例一提供的测试方法的流程示意图。本实施例将物理层软件作为目标测试对象，采用本公开提供的方法对物理层软件进行测试的步骤如下：

s1：根据测试参数和测试参数的预设遍历范围自动生成第一测试用例集合。

具体地，如图2所示，本步骤包括以下子步骤：

s110：确定测试场景；

物理层软件的测试场景可以是对物理层通信链路中任意信号或信道进行的测试，如信道状态信息参考信号（channelstateinformationreferencesignal，英文缩写：csi-rs）或物理广播信道测试；也可以是对物理层软件进行的系统级测试，如上下行调度过程测试。在本实施例中，具体的测试场景可以由测试人员预先设定，也可以是随机选定的，需要说明的是，如果物理层软件更新了功能特性或引入了新的技术，则需要对物理层软件的全部应用场景进行测试，以及时发现物理层软件的新问题，保证更新后的物理层软件的可靠性。

s120：基于测试场景确定与其相关联的一个或多个测试参数；

例如，与非零功率信道状态信息参考信号（non-zeropowerchannelstateinformationreferencesymbol，英文缩写：nzp-csi-rs）这一物理信号相关联的测试参数包括：该信号所处频段、端口（port）数量、该信号的行索引（rowindex）、信号密度、时域资源对应的两个符号（symbol）：l1和l0、频域起始资源块（resourceblock，英文缩写：rb）序列、所占资源块的个数、频域资源比特（bit）映射等。需要说明的是，测试参数的个数以及类别会随着测试场景的不同而变换。

再如，物理层上下行过程这一系统级的测试会涉及小区识别码（cellidentity）、上下行配比、天线数量等测试参数，还需要分配各信道所使用的时域资源以及与各信道相关的测试参数等。

s130：基于每个测试参数的预设遍历范围随机地生成与该测试参数相对应的一个取值元素，并将与各个测试参数一一对应的取值元素相组合以构成第一测试用例集合中的一个测试用例；

s140：重复s130以生成第一测试用例集合。

各个测试参数的遍历范围主要是根据通信协议进行设定的，例如3gpp（3rdgenerationpartnershipproject）协议。遍历范围可以理解为是一种取值区间，该区间内的变量可以是连续（变量个数无限）也可以是离散的（变量个数有限），在理想情况下，取值元素的选取应该遍历该取值区间，以满足随机测试的全面性。

例如，在nzp-csi-rs这一物理信号的测试中，根据通信协议，行索引（rowindex）这一测试参数对应的遍历范围是1至18，其取值元素可以是该区间内的任意数值。信号密度这一测试参数对应的遍历范围内的数值是离散的，其取值元素具体可能的取值为3、1、0.5。

将与各个测试参数一一对应的取值元素进行随机组合，以得到一个元素组合。每个元素组合中应包含与测试场景相关联的全部测试参数的取值元素。因此，各个元素组合（测试用例）之间的区别主要与每个测试参数的取值元素有关，而与元素组合中各个测试参数的排序无关。基于一个元素组合对应生成一个测试用例，重复这一步骤以得到第一测试用例集合。

s2：基于预设的约束条件对第一测试用例集合中的测试用例进行筛选以获得第二测试用例集合。

具体地，如图3所示，本步骤包括以下子步骤：

s210：确定第一测试用例集合中的每个测试用例所包含的取值元素的值是否满足预设的约束条件；

首先，获取测试参数之间的约束条件。具体地，根据物理层软件现有的功能特性，测试参数之间存在一定的约束关系，理论上，物理层软件只能处理满足所述约束条件的测试用例。例如，在针对nzp-csi-rs这一物理信号的测试过程中，行索引（rowindex）和信号密度形成约束，具体的约束条件为：在元素组合中，当行索引对应的取值元素为1时，信号密度的取值元素应当取3。

再如，针对物理广播信道信道（physicalbroadcastchannel，英文缩写：pbch）的测试过程中，会涉及n_ssb_crb和k_ssb这两种测试参数，前者表示当前bwp（bandwidthpart，带宽部分）与pointa（整个资源栅格的公共参考点）之间的rb（resourceblock，资源块）偏移量，后者表示ssb的子载波和当前bwp的子载波之间的偏移量，其中ssb是synchronizationsignalandpbchblock（同步信号和pbch块）的英文缩写。n_ssb_crb和k_ssb形成约束，具体的约束条件为：两者取值元素的和不能超出当前bwp的范围。

因此，需要判断第一测试用例集合中每个测试用例对应的元素组合是否满足预设的约束条件。

s220：删除不满足预设的约束条件的测试用例；

示例性地，经随机组合形成的大量的元素组合中，行索引和信号密度的取值元素之间必然会存在其他形式的组合。但只有元素组合满足两者之间的约束条件的测试用例，才是物理层软件能够处理的测试用例。

如果采用不满足约束条件的测试用例对物理层软件进行测试，则测试的过程中会出现卡顿（crash）等情况，使测试无法顺利进行，这种测试用例对应的测试结果为“失败”。因此，需要对随机、批量生成的测试用例进行筛选，并删除不满足约束条件的测试用例，以提高后续测试的效率。

本领域普通技术人员应当理解，约束条件的制定应以通信协议中的规范为依据，但不能只限于通信协议，同时也需要结合物理层软件实际处理数据的能力。

此处，以针对物理广播信道信道（physicalbroadcastchannel，英文缩写：pbch）的测试为例，其测试参数中的信道所处频段和ssb的子载波间隔形成约束，具体的约束条件为：如果信道所处频段为410mhz-7125mhz，对应的ssb的子载波间隔应该为120khz或者240khz。而实际情况是，ssb子载波间隔可以是15khz、30khz、120khz或者240khz。虽然将ssb的子载波间隔设置成15khz或者30khz不符合3gpp协议，但是由于物理层软件能够处理这种不符合协议的元素组合，因此，可以保留相应的测试用例。

应当理解的是，众多测试参数中的任意两个或多个之间都可能形成约束，因此，制定约束条件的另一个原则是：约束条件中子条件的个数应当适量。一方面，如果约束条件中的子条件数量过多，不仅会增加制定约束条件的工作量（代码数量），使测试变得复杂、测试效率降低；还可能会造成满足约束条件的测试用例数量偏少，使测试覆盖率降低，不利于及时发现问题；另一方面，如果约束条件中的子条件的数量过少，则筛选这一步骤便失去了意义，保留下来的一部分测试用例可能依然是物理层无法处理的，不利于提高测试效率或及时发现问题。

s230：基于预期采用的测试用例的数量，随机地从满足预设的约束条件的测试用例中选取该数量的测试用例以构成第二测试用例集合。

预期采用的测试用例的数量（设为n）可以由测试人员根据经验设定，也可以是随机生成的一个正整数。应当说明的是，n的数值越大，表示测试越充分，即本轮测试覆盖的场景越丰富。虽然，第一测试用例集合中的测试用例经过筛选后，一部分不满足约束条件的测试用例已经被删除，测试用例的数量减少。但是，如果在制定约束条件的过程中兼顾了个数适量的原则，那么第一测试用例集合中剩余的测试用例依然能够满足全面测试的需求，即n一般不会超出满足约束条件的测试用例的数量。

s3：基于第二测试用例集合中的全部测试用例实施针对目标测试对象的测试。

具体地，基于第二测试用例集合，经由预设的测试脚本触发物理层软件执行预定的动作以依序实施每个测试用例。在本实施例中，测试用例中的各个取值元素经由测试脚本按照约定的接口格式输入至物理层，以调度物理层进行预定的动作而完成测试。

s4：统计测试结果以获取测试通过率，并记录测试结果为“失败”的测试用例。

根据上文可知，设第二测试用例集合中测试用例的数量为n，则收集与这n个测试用例相对应的测试结果，并基于预期测试结果（即测试结果数据的判别基准）对n个测试结果进行统计和分析。在一些可能的测试场景中，预期测试结果可以设置为：物理层软件反馈的编解码数据能够被读取并解码。如果某个测试用例的测试结果是：物理层反馈的数据无法被解码，则说明该测试用例的测试结果为“失败”。将测试结果为“失败”的测试用例保存在一指定服务器中，并记录其数量，此处设为n。进一步地，基于测试结果为“失败”的测试用例的数量（n）和第二测试用例集合中测试用例的数量（n）计算本轮测试的通过率。通过率的计算方法可以参考下方公式：

测试通过率=(n-n)/n×100%

进一步地，请参阅图4，本步骤还包括以下子步骤：

s410：分析测试结果为“失败”的测试用例的失败原因；

s420：若失败原因是目标测试对象所关联的软件代码存在缺陷，则修改软件代码以消除该缺陷；

s430：若失败原因是目标测试对象在工作原理上不支持，则将该测试结果为“失败”的测试用例所对应的取值元素的组合加入约束条件，并在后续的测试用例筛选过程中使用更新后的约束条件。

进一步地，将测试结果为“失败”的测试用例保存在一指定服务器中，便于测试人员和开发人员对异常结果进行分析，以发现并解决问题。例如，针对测试结果为“失败”的测试用例，需要调查引起测试失败的原因是物理层软件代码存在缺陷还是物理层软件不支持该测试用例。若是因为物理层软件代码存在缺陷，则需要开发人员对代码进行修改，以消除缺陷；若是因为物理层软件不支持该测试用例，则需要将该测试用例中的元素组合加入约束条件中，并在后续的测试用例筛选过程中使用该更新后的约束条件。这样，在同一测试场景的重复测试中，能够提前将该元素组合所对应的测试用例删除，免去再次出现测试失败的情况。

实施例二：

作为对实施例一的改进方案，相同的步骤内容可以参考实施例一，本实施例中不再赘述。实施例二相对于实施例一的改进点主要体现为：针对相同测试场景的重复测试，总结过往每一次的测试经验，对现有约束条件进行更新。使用更新后的约束条件对第一测试用例集合中的测试用例进行筛选，能够提前将目标测试对象不支持的测试用例进行删除，免去再次出现测试“失败”的情况，有助于提高第二测试用例集合中测试用例的有效性和测试的效率。示例性地，请继续参阅图1，本实施例将物理层软件作为目标测试对象，采用本公开提供的方法对物理层软件进行测试的步骤如下：

s1：根据测试参数和测试参数的预设遍历范围自动生成第一测试用例集合。

s2：基于预设的约束条件对第一测试用例集合中的测试用例进行筛选以获得第二测试用例集合。

具体地，本步骤中使用的约束条件包括第一约束条件和第二约束条件。其中，第一约束条件包含：参考通信协议和物理层软件现有的功能特性，选择性地在两个或多个测试参数之间预设的取值元素的约束条件。如果被筛选的测试用例中相应测试参数的取值元素不满足该约束条件，则认为物理层软件无法处理该测试用例，因此需要删除该测试用例。第二约束条件是指：从过往测试结果中总结得到的物理层软件在工作原理上不支持的测试用例所对应的各个测试参数的取值元素的元素组合。如果被筛选的测试用例中包含与该元素组合相对应的测试用例，则需要删除该测试用例。

根据上一段落的描述可知，在同一测试场景的新一轮测试中，删除不满足约束条件中的第一约束条件的测试用例的同时，也需要删除与第二约束条件中的元素组合相匹配的测试用例。可以理解的是，第二约束条件是对第一约束条件的补充，结合两者对第一测试用例集合进行筛选，可以降低第二测试用例集合中不被物理层支持的测试用例所占的比例，以减少测试失败的次数，进而提高测试效率，并且，根据测试结果计算出的测试通过率也更准确。

s3：基于第二测试用例集合中的全部测试用例实施针对目标测试对象的测试。

s4：统计测试结果以获得测试通过率，并记录测试结果为“失败”的测试用例。

应当理解的是，随着重复测试次数的增加，第二约束条件中保存的元素组合会逐渐增多，那么在第二测试用例集合中，无效的第一测试用例会逐渐减少。在此基础上使用测试用例对物理层软件进行测试，使测试能够覆盖的有效场景更加丰富，测试过程更加顺利，根据测试结果统计得到的测试通过率也更加准确。

实施例三：

作为对实施例一和实施例二的改进方案，相同的步骤内容可以参考实施例一和实施例二，本实施例中不再赘述。实施例三中提供的测试方法主要是针对目标测试对象发生变化的情形，例如，若目标测试对象的软件或硬件功能特性发生了变化，或者目标测试对象的软件逻辑特性发生了变化，此时，需要针对这些变化对目标测试对象进行全面的测试，以及时发现问题，保证目标测试对象的可靠性。本实施例将物理层软件作为目标测试对象，当物理层软件的功能特性或逻辑特性发生变化后，在正式的测试之前，需要根据物理层软件的变化，有针对性地增加、删减或修改测试参数、测试参数的遍历范围以及相关的约束条件。

请参阅图5，目标测试对象（物理层软件）的测试方法还包括以下步骤：

s5：根据目标测试对象的硬件或软件功能特性的变化增加或删减测试参数。

例如，物理层软件新增了预编码的功能特性，相应地，需要增加的测试参数包括：预编码矩阵索引（precodingmatrixindicator，英文缩写：pmi）、码本（codebook）、n1字节、n2字节等，并根据通信协议限定各个测试参数的遍历范围。

再如，物理层软件更新了代码，更新后的物理层软件可以根据输入的数据计算传输块（transportblock，英文缩写：tb）的大小（size），不再需要从接口获取tbsize。因此，可以删除tbsize这一测试参数及其对应的遍历范围。

s6：根据增加或删减的测试参数，对应地修改约束条件。

例如，对应地增加预编码矩阵索引、码本、n1字节、n2字节等新增测试参数的约束条件。

再如，删除与tbsize相关的约束条件。

s7：根据目标测试对象的软件逻辑特性的变化更新约束条件。

例如，物理层软件扩展了天线数量，从2天线扩展成4天线，那么，需要对应修改与天线数量相关的约束条件，使得后续在对第一测试用例集合中的测试用例进行筛选时，与4天线相关的测试用例能够保留下来，用于测试。

在对引入了新的技术或新的功能特性的物理层软件进行全面测试之前，采用本实施例提供的方法对相关的测试参数和约束条件进行更新，来重新批量生成更新后的测试用例，一方面有助于及时发现物理层软件的新问题，另一方面，相较于传统的逐一修改已有测试用例的方法，采用本实施例提供的方法有助于减轻测试用例的生成和日常维护的工作量。

实施例四：

为实现上述目的，本实施例提出了一种用于无线通信的测试装置，请参阅图6，为本公开实施例四提供的测试装置的结构示意图。该测试装置600能够实现本公开实施例一至实施例三提供的测试方法，具体地，测试装置600包括：用例生成模块610、用例筛选模块620、测试执行模块630和测试分析模块640。

用例生成模块610用于根据测试参数及其预设遍历范围自动生成第一测试用例集合。具体地，与目标测试对象相关联的各个测试参数及其对应的遍历范围可以存储在一个指定的服务器中，用例生成模块610确定测试场景后，从所述指定的服务器中调取相应的一个或多个测试参数及其遍历范围。基于每个测试参数的预设遍历范围随机地生成与该测试参数相对应的一个取值元素，并将与各个测试参数一一对应的取值元素相组合以构成所述第一测试用例集合中的一个测试用例。重复上述取值元素生成过程以产生多个测试用例，由此生成所述第一测试用例集合。

用例筛选模块620用于基于预设的约束条件对第一测试用例集合中的测试用例进行筛选以获得第二测试用例集合。具体地，与目标测试对象相关联的各个测试参数的约束条件也可以存储在一个指定的服务器中，用例筛选模块620从所述指定的服务器中调取相应测试参数的约束条件，并判断所述第一测试用例集合中的每个测试用例所包含的取值元素的值是否满足测试参数之间预设的约束条件。如果测试用例所包含的取值元素的值不满足测试参数之间预设的约束条件，则删除该测试用例。并且，所述预设的约束条件中还包含目标测试对象在工作原理上不支持的测试用例所对应的各个测试参数的取值元素组合。因此，用例筛选模块620在对第一测试用例集合进行筛选的过程中，还会根据这些已知目标测试对象不支持的测试用例，对第一测试用例集合中的测试用例进行相似度匹配操作，以从第一测试用例集合中删除与这些已知不支持的测试用例相同的测试用例，避免“失败”的测试结果重复出现，有助于提高测试效率。

进一步地，用例筛选模块620还用于基于预期采用的测试用例的数量，随机地从满足上述预设的约束条件的测试用例中选取该数量的测试用例以构成第二测试用例集合。

测试执行模块630用于基于上述第二测试用例集合中的全部测试用例实施针对目标测试对象的测试。具体地，测试执行模块630基于所述第二测试用例集合，经由预设的测试脚本触发所述目标测试对象执行预定的动作以依序实施每个测试用例。

测试分析模块640用于统计测试结果以获取测试通过率，并记录测试结果为“失败”的测试用例。具体地，测试分析模块640将测试结果为“失败”的测试用例保存在指定的服务器中，并分析失败原因。若失败原因是目标测试对象所关联的软件代码存在缺陷，则提示开发者修改软件代码以消除该缺陷；若失败原因是目标测试对象在工作原理上不支持，则将该测试结果为“失败”的测试用例所对应的各个测试参数的取值元素组合加入约束条件，并在后续的测试用例筛选过程中使用更新后的约束条件，以在对同一测试场景的另一轮测试中，能够提前将该目标测试对象不支持的测试用例删除，免去再次出现测试“失败”的情况。

测试分析模块640还用于根据测试结果为“失败”的测试用例的数量和所述第二测试用例集合中测试用例的总数量计算并发布测试通过率。

进一步地，当目标测试对象的硬件或软件功能特性发生变化时，测试人员可以通过用例生成模块610相应地增加或删减测试参数，并通过用例筛选模块620还用于根据增加或删减的测试参数，对应地修改约束条件。

进一步地，当目标测试对象的软件逻辑特性发生变化时，测试人员也可以通过用例筛选模块620来更新约束条件。

因此，在目标测试对象发生变化后，通过用例生成模块610和用例筛选模块620对相关的测试参数和约束条件进行增加、删减或修改等操作，以重新批量地生成更新后的测试用例，不再需要逐一修改现有的测试用例，减轻了测试用例的生成和日常维护的工作量。

实施例五：

为实现上述目的，本实施例提出一种用以存储处理器可执行指令的计算机可读存储介质，所述计算机可读存储介质中存储的处理器可执行指令在被执行时能够致使处理器实施如上所述的用于无线通信的测试方法。

本公开实施例提供了一种用于无线通信的测试方法、测试装置及存储介质，能够覆盖目标测试对象多变的应用场景，并减轻测试用例的生成及日常维护的工作量。具体地，由于能够根据测试场景确定相关联的测试参数，并基于各个测试参数的遍历范围随机地生成各个测试参数的取值元素，将各个测试参数的取值元素进行随机组合以批量地生成测试用例，从而能够覆盖测试目标多变的应用场景，有助于及时发现目标测试对象的存在的问题。进一步地，由于能够根据预设的约束条件对批量生成的测试用例进行筛选，以剔除目标测试对象在原理上不支持的测试用例，从而显著地提高了测试效率和测试结果的有效性。并且，约束条件根据每一次测试的测试结果进行更新，以在后续测试的筛选步骤中便将目标测试对象不支持的测试用例删除，避免相同测试场景的重复测试过程中因同样的原因造成测试“失败”。进一步地，在测试用例的日常维护过程中，若目标测试对象的软件或硬件功能特性发生变化，或者目标测试对象的软件逻辑特性发生变化，则对相关的测试参数和约束条件进行增加、删减或修改等操作，以重新批量地生成更新后的测试用例，不再需要逐一修改现有的测试用例，减轻了测试用例的生成和日常维护的工作量。

在上述实施例中，应用具体的实施例对本公开的原理及实施方式进行了阐述，各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。以上实施例的说明只是用于帮助理解本公开的技术方案及其核心思想；本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本公开各实施例的技术方案的范围。