CN117093503B - 一种客户端测试管理方法与*** - Google Patents

Abstract

本发明提供一种客户端测试管理方法与***，属于客户端管理技术领域，具体包括：根据目标测试任务所对应的客户端的操作类型的差异划分为多个测试子任务，并通过所述测试子任务所对应的客户端的操作类型进行不同的测试子任务的历史使用数据的确定，通过测试子任务所对应的操作类型的不同的客户端的数据类型和数据量进行统一测试指令的解析复杂度的确定，并结合测试时长以及并发测试用户的数量进行统一测试指令的测试复杂度的确定；基于不同的测试子任务的统一测试指令的类型进行测试子任务的测试优先级的确定，并基于测试优先级和测试复杂度进行不同的测试子任务的统一测试指令的测试顺序的确定，实现了对不同的客户端的差异化的测试管理。

Description

一种客户端测试管理方法与***

技术领域

本发明属于客户端管理技术领域，尤其涉及一种客户端测试管理方法与***。

背景技术

为了满足用户的使用便利性，消费金融公司往往有多个针对不同终端以及操作***的客户端。但是在提高用户的使用便利性的同时，由于客户端的数量较多，一旦在版本更新或者某一场景更新时，测试人员需要对所有的客户端进行测试，极大的降低了测试的效率。

为了解决上述技术问题，现有技术方案给出了不同的客户端协同测试的技术手段，具体的在发明专利CN201610195842.6《多客户端协同测试方法和装置》中通过解析测试指令，获取对每一客户端进行操作的接口和参数，并向每一客户端对应的接口发送对应参数，以使每一客户端执行所述参数对应的操作，提升了测试的效率，但是与此同时，存在以下技术问题：

现有技术方案中忽视了根据客户端的使用数据的差异采用差异化的测试并发用户的数量的确定，具体的，由于不同的客户端的使用数据的差异导致不同的客户端在使用过程中的并发用户的数量存在一定程度的差异，因此若不能根据不同的客户端的使用数据进行差异化的测试并发用户的数量的确定，则无法实现对不同的客户端的使用情况的准确确定。

现有技术方案中忽视了根据测试用例的复杂度进行测试顺序的确定，具体的，由于不同的客户端支持的数据类型和测试耗时的差异，因此不同的测试用例的测试复杂度也存在一定程度的差异，因此若不能进行针对性的测试顺序的优化，则有可能导致测试效率会受到一定程度的影响。

针对上述技术问题，本发明提供了一种客户端测试管理方法与***。

发明内容

为实现本发明目的，本发明采用如下技术方案：

根据本发明的一个方面，提供了一种客户端测试管理方法。

一种客户端测试管理方法，其特征在于，具体包括：

S1根据目标测试任务所对应的客户端的操作类型的差异划分为多个测试子任务，并通过所述测试子任务所对应的客户端的操作类型进行不同的测试子任务的历史使用数据的确定，基于所述历史使用数据进行不同的客户端的测试子任务的历史并发用户数据的确定，并结合所述历史并发用户数据的变动情况进行不同的客户端的并发测试用户的数量的确定；

S2基于历史使用数据进行不同的客户端的测试子任务所对应的客户端的操作类型历史高峰使用时段的确定，并结合所述操作类型的不同时段的历史使用情况进行测试子任务的测试时长的确定；

S3通过所述测试子任务所对应的操作类型的不同的客户端的数据类型和数据量进行统一测试指令的解析复杂度的确定，并结合测试时长以及并发测试用户的数量进行所述统一测试指令的测试复杂度的确定；

S4基于不同的测试子任务的统一测试指令的类型进行测试子任务的测试优先级的确定，并基于所述测试优先级和测试复杂度进行不同的测试子任务的统一测试指令的测试顺序的确定。

本发明的有益效果在于：

通过结合测试子任务的历史并发用户数据以及历史并发用户数据的变动情况进行不同的客户端的并发测试用户的数量的确定，不仅考虑到不同的测试子任务所对应的操作类型和组成模块的使用差异性，同时通过对并发测试用户的数量的动态调整，也使得测试结果能够更加准确的反应程序问题。

通过历史高峰使用时段以及操作类型的不同时段的历史使用情况进行测试子任务的测试时长的确定，不仅考虑到不同的操作类型的历史使用情况的时间分布情况的差异，同时还考虑到不同的高峰使用情况的差异，从而实现了针对性的进行测试时长的调整，也为进一步保证测试结果的准确性和可靠性奠定了基础。

通过结合统一测试指令的解析复杂度、测试时长以及并发测试用户的数量进行所述统一测试指令的测试复杂度的确定，不仅考虑到统一测试指令转换为不同的客户端所需求的测试指令的转换复杂度，同时进一步与测试时长和用户的数量的结合，实现了对不同的测试子任务的测试复杂度的确定，也为进一步实现对不同的测试子任务的测试顺序的动态调整奠定了基础。

进一步的技术方案在于，所述客户端的操作类型根据目标测试任务的操作目标所对应的客户端的功能模块以及在所述功能模块中的功能子模块进行确定。

进一步的技术方案在于，所述历史使用数据包括历史并发用户数量以及不同时段的历史并发用户数量的变动数据、历史使用高峰时段的时长以及在单位时间内的历史使用高峰时段的分布数据。

进一步的技术方案在于，所述统一测试指令的测试复杂度的确定的方法为：

通过所述统一测试指令的解析复杂度进行单一的测试用户的测试复杂度的确定，并通过所述并发测试用户的数量、单一的测试用户的测试复杂度进行所述统一测试指令的用户的测试复杂度的确定，并结合所述测试时长进行所述统一测试指令的测试复杂度的确定。

第二方面，本发明提供了一种客户端测试管理***，采用上述的一种客户端测试管理方法，其特征在于，具体包括：

测试用户评估模块，测试时长评估模块，测试复杂度确定模块，测试顺序确定模块；

其中所述测试用户评估模块负责根据目标测试任务所对应的客户端的操作类型的差异划分为多个测试子任务，并通过所述测试子任务所对应的客户端的操作类型进行不同的测试子任务的历史使用数据的确定，基于所述历史使用数据进行不同的客户端的测试子任务的历史并发用户数据的确定，并结合所述历史并发用户数据的变动情况进行不同的客户端的并发测试用户的数量的确定；

所述测试时长评估模块负责基于历史使用数据进行不同的客户端的测试子任务所对应的客户端的操作类型历史高峰使用时段的确定，并结合所述操作类型的不同时段的历史使用情况进行测试子任务的测试时长的确定；

所述测试复杂度确定模块负责通过所述测试子任务所对应的操作类型的不同的客户端的数据类型和数据量进行统一测试指令的解析复杂度的确定，并结合测试时长以及并发测试用户的数量进行所述统一测试指令的测试复杂度的确定；

所述测试顺序确定模块负责基于不同的测试子任务的统一测试指令的类型进行测试子任务的测试优先级的确定，并基于所述测试优先级和测试复杂度进行不同的测试子任务的统一测试指令的测试顺序的确定。

其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点在说明书以及附图中所特别指出的结构来实现和获得。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

通过参照附图详细描述其示例实施方式，本发明的上述和其它特征及优点将变得更加明显；

图1是一种客户端测试管理方法的流程图；

图2是并发测试用户的数量的确定的方法的流程图；

图3是测试子任务的测试时长的确定的方法的流程图；

图4是统一测试指令的解析复杂度的确定的方法的流程图；

图5是一种客户端测试管理***的框架图。

具体实施方式

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。

申请人发现，为了提升授信申请的处理的实时性和效率，现有的授信处理机构往往设置有多个授信申请渠道，即存在多个客户端，同时这也为测试人员的测试效率和测试难度带来一定程度的挑战，现有技术方案中给出了通过统一的测试指令进行对不同的客户端的统一测试，但是忽视了不同的客户端的并发用户数量存在一定程度的差异，同时不同的客户端的使用数据也存在一定程度的差异，若不考虑上述因素进行动态调整，则无法实现对客户端的可靠测试。

针对上述技术问题，申请人采用以下技术方案：

首先通过不同的测试子任务所对应的操作类型获取其对应的客户端中的模块的使用数据，包括历史并发用户数量以及不同时刻的历史并发用户数量的变动情况，通过上述数据可以实现对不同的测试子任务的并发测试用户数量的动态调整，具体的可以通过历史并发用户数量的最大值进行并发测试用户数量的确定；

紧接着考虑到不同的测试子任务所对应的操作类型获取其对应的客户端中的模块的高峰使用时段的数量和分布情况，从而可以实现对不用的测试子任务的测试时长的确定，具体的可以通过高峰使用时段的最长持续时长或者平均持续时长进行确定；

由于统一操作指令转化为不同的客户端的指令的转化难度存在差异，同时不同的客户端在响应操作指令时的处理的数据类型和数据量也存在一定程度的差异，通过综合考虑上述多方面因素可以实现对不同的测试子任务的测试难度的确定；

根据测试难度可以动态的确定不同的测试子任务的测试优先级，一般来说测试难度较大或者较为复杂的测试子任务的测试优先级较高，并根据测试优先级进行不同的测试子任务的测试。

为便于理解，下面将通过方法类实施例和***类实施例进行方案的说明。

为解决上述问题，根据本发明的一个方面，如图1所示，提供了根据本发明的一个方面，提供了一种客户端测试管理方法，其特征在于，具体包括：

S1根据目标测试任务所对应的客户端的操作类型的差异划分为多个测试子任务，并通过所述测试子任务所对应的客户端的操作类型进行不同的测试子任务的历史使用数据的确定，基于所述历史使用数据进行不同的客户端的测试子任务的历史并发用户数据的确定，并结合所述历史并发用户数据的变动情况进行不同的客户端的并发测试用户的数量的确定；

需要说明的是，所述客户端的操作类型根据目标测试任务的操作目标所对应的客户端的功能模块以及在所述功能模块中的功能子模块进行确定。

进一步的，所述历史使用数据包括历史并发用户数量以及不同时段的历史并发用户数量的变动数据、历史使用高峰时段的时长以及在单位时间内的历史使用高峰时段的分布数据。

在其中的一个可能的实施例中，如图2所示，上述步骤S1中的所述并发测试用户的数量的确定的方法为：

S11通过所述客户端的测试子任务的历史并发用户数据进行所述测试子任务的历史并发用户的数量峰值的确定，并判断单位时间内在所述客户端的历史并发用户的数量峰值的出现次数是否大于预设次数，若是，则通过所述历史并发用户的数量峰值进行所述客户端的并发测试用户的数量的确定，若否，则进入下一步骤；

S12通过所述测试子任务的历史并发用户数据进行所述客户端的测试子任务的历史并发用户的数量的确定，并结合所述预设次数进行所述客户端的并发测试用户的推荐数量的确定；

S13将所述历史并发用户的数量大于所述并发测试用户的推荐数量的出现次数作为高峰出现次数，并判断所述高峰出现次数是否处于预设次数范围内，若是，则进入下一步骤，若否，则进入步骤S15；

S14将所述高峰出现次数所对应的历史并发用户作为筛选并发用户，并通过所述筛选并发用户的数量与所述并发测试用户的推荐数量的差值以及所述高峰出现次数是否可以将所述推荐数量作为所述客户端的并发测试用户的数量，若是，则将所述推荐数量作为所述客户端的并发测试用户的数量，若否，则进入下一步骤；

S15通过所述筛选并发用户的数量与所述并发测试用户的推荐数量的差值、在所述筛选并发用户的数量下的出现次数以及所述高峰出现次数进行所述推荐数量的修正数量的确定，并通过所述修正数量以及所述推荐数量进行所述客户端的并发测试用户的数量的确定。

在另外的一个可能的实施例中，上述步骤S1中的所述并发测试用户的数量的确定的方法为：

通过所述测试子任务的历史并发用户数据进行所述客户端的测试子任务的历史并发用户的数量的确定，并结合所述预设次数进行所述客户端的并发测试用户的推荐数量的确定；

将所述历史并发用户的数量大于所述并发测试用户的推荐数量的出现次数作为高峰出现次数，并将所述历史并发用户的数量与所述并发测试用户的推荐数量的差值大于预设偏差量的出现次数作为数量峰值出现次数；

当所述高峰出现次数以及数量峰值出现次数均满足要求时：

将所述推荐数量作为所述客户端的并发测试用户的数量；

当所述高峰出现次数以及数量峰值出现次数任意一项不满足要求时：

将所述高峰出现次数所对应的历史并发用户作为筛选并发用户，通过所述筛选并发用户的数量与所述并发测试用户的推荐数量的差值、在所述筛选并发用户的数量下的出现次数以及所述高峰出现次数进行所述推荐数量的修正数量的确定，并通过所述修正数量以及所述推荐数量进行所述客户端的并发测试用户的数量的确定。

S2基于历史使用数据进行不同的客户端的测试子任务所对应的客户端的操作类型历史高峰使用时段的确定，并结合所述操作类型的不同时段的历史使用情况进行测试子任务的测试时长的确定；

在其中的一个可能的实施例中，如图3所示，所述测试子任务的测试时长的确定的方法为：

S21通过所述历史使用数据获取所述测试子任务所对应的客户端的操作类型的不同的预设时长内的使用人数和使用次数，并基于所述使用人数和使用次数进行历史高峰使用时段以及连续的历史高峰使用时段的最大持续时长的确定；

S22判断所述用户在单位时间内的历史高峰使用时段的数量是否大于预设数量，若是，则进入下一步骤，若否，则进入步骤S24；

S23获取所述用户在单位时间内的连续的历史高峰使用时段的最大持续时长，并结合所述用户在单位时间内的连续的历史高峰使用时段的持续时长的平均值以及持续时长大于预设时长历史高峰使用时段的数量进行所述测试子任务所对应的客户端的操作类型的使用频繁度的确定，并判断所述使用频繁度是否大于预设频繁度，若是，则通过所述用户在单位时间内的连续的历史高峰使用时段的最大持续时长进行所述测试子任务的测试时长的确定，若否，则进入下一步骤；

S24通过所述测试子任务所对应的客户端的操作类型的使用频繁度、在单位时间内使用人数、使用次数以及历史高峰使用时段的数量使用进行所述测试子任务的测试时长修正量的确定，并结合所述用户在单位时间内的连续的历史高峰使用时段的持续时长的平均值进行所述测试时长的确定。

进一步的，所述预设繁忙度根据所述操作类型的重要程度进行确定，具体的根据所述操作类型的适用客户数量、历史使用人数和历史使用次数进行确定，当所述操作类型的适用客户数量越多、历史使用人数越多、历史使用次数越多，则所述

S3通过所述测试子任务所对应的操作类型的不同的客户端的数据类型和数据量进行统一测试指令的解析复杂度的确定，并结合测试时长以及并发测试用户的数量进行所述统一测试指令的测试复杂度的确定；

在其中的一个可能的实施例中，如图4所示，所述统一测试指令的解析复杂度的确定的方法为：

S31获取所述测试子任务所对应的操作类型的客户端的数据类型和数据量，并判断所述数据类型和数据量是否均在预设区间内，若是，则进入下一步骤，若否，则进入步骤S33;

S32通过所述测试子任务的统一测试指令以及所述操作类型进行所述客户端的统一测试指令的指令转换复杂度的确定，并判断所述客户端的统一测试指令的指令转换复杂度是否小于预设复杂度，若是，则通过所述客户端的统一测试指令的指令转换复杂度进行所述统一测试指令的解析复杂度的确定，若否，则进入下一步骤；

S33通过所述测试子任务所对应的操作类型的客户端的数据类型和数据量进行所述客户端的数据测试复杂度的确定；

S34通过所述客户端的数据测试复杂度以及客户端的统一测试指令的指令转换复杂度进行所述统一测试指令的解析复杂度的确定。

在其中的一个可能的实施例中，所述统一测试指令的测试复杂度的确定的方法为：

通过所述统一测试指令的解析复杂度进行单一的测试用户的测试复杂度的确定，并通过所述并发测试用户的数量、单一的测试用户的测试复杂度进行所述统一测试指令的用户的测试复杂度的确定，并结合所述测试时长进行所述统一测试指令的测试复杂度的确定。

S4基于不同的测试子任务的统一测试指令的类型进行测试子任务的测试优先级的确定，并基于所述测试优先级和测试复杂度进行不同的测试子任务的统一测试指令的测试顺序的确定。

另一方面，如图5所示，本发明提供了一种客户端测试管理***，采用上述的一种客户端测试管理方法，其特征在于，具体包括：

测试用户评估模块，测试时长评估模块，测试复杂度确定模块，测试顺序确定模块；

其中所述测试用户评估模块负责根据目标测试任务所对应的客户端的操作类型的差异划分为多个测试子任务，并通过所述测试子任务所对应的客户端的操作类型进行不同的测试子任务的历史使用数据的确定，基于所述历史使用数据进行不同的客户端的测试子任务的历史并发用户数据的确定，并结合所述历史并发用户数据的变动情况进行不同的客户端的并发测试用户的数量的确定；

所述测试时长评估模块负责基于历史使用数据进行不同的客户端的测试子任务所对应的客户端的操作类型历史高峰使用时段的确定，并结合所述操作类型的不同时段的历史使用情况进行测试子任务的测试时长的确定；

所述测试复杂度确定模块负责通过所述测试子任务所对应的操作类型的不同的客户端的数据类型和数据量进行统一测试指令的解析复杂度的确定，并结合测试时长以及并发测试用户的数量进行所述统一测试指令的测试复杂度的确定；

所述测试顺序确定模块负责基于不同的测试子任务的统一测试指令的类型进行测试子任务的测试优先级的确定，并基于所述测试优先级和测试复杂度进行不同的测试子任务的统一测试指令的测试顺序的确定。

通过上述实施例，本发明主要具有以下有益效果：

通过结合测试子任务的历史并发用户数据以及历史并发用户数据的变动情况进行不同的客户端的并发测试用户的数量的确定，不仅考虑到不同的测试子任务所对应的操作类型和组成模块的使用差异性，同时通过对并发测试用户的数量的动态调整，也使得测试结果能够更加准确的反应程序问题。

通过历史高峰使用时段以及操作类型的不同时段的历史使用情况进行测试子任务的测试时长的确定，不仅考虑到不同的操作类型的历史使用情况的时间分布情况的差异，同时还考虑到不同的高峰使用情况的差异，从而实现了针对性的进行测试时长的调整，也为进一步保证测试结果的准确性和可靠性奠定了基础。

通过结合统一测试指令的解析复杂度、测试时长以及并发测试用户的数量进行所述统一测试指令的测试复杂度的确定，不仅考虑到统一测试指令转换为不同的客户端所需求的测试指令的转换复杂度，同时进一步与测试时长和用户的数量的结合，实现了对不同的测试子任务的测试复杂度的确定，也为进一步实现对不同的测试子任务的测试顺序的动态调整奠定了基础。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备、非易失性计算机存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

以上所述仅为本说明书的一个或多个实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书的一个或多个实施例可以有各种更改和变化。凡在本说明书的一个或多个实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书的权利要求范围之内。

Claims (9)

1.一种客户端测试管理方法，其特征在于，具体包括：

根据目标测试任务所对应的客户端的操作类型的差异划分为多个测试子任务，并通过所述测试子任务所对应的客户端的操作类型进行不同的测试子任务的历史使用数据的确定，基于历史使用数据进行不同的客户端的测试子任务的历史并发用户数据的确定，并结合历史并发用户数据的变动情况进行不同的客户端的并发测试用户的数量的确定；

基于历史使用数据进行不同的客户端的测试子任务所对应的客户端的操作类型历史高峰使用时段的确定，并结合所述操作类型的不同时段的历史使用情况进行测试子任务的测试时长的确定；

通过所述测试子任务所对应的操作类型的不同的客户端的数据类型和数据量进行统一测试指令的解析复杂度的确定，并结合测试时长以及并发测试用户的数量进行所述统一测试指令的测试复杂度的确定；

所述统一测试指令的解析复杂度的确定的方法为：

S31获取所述测试子任务所对应的操作类型的客户端的数据类型和数据量，并判断所述数据类型和数据量是否均在预设区间内，若是，则进入下一步骤，若否，则进入步骤S33;

S32通过所述测试子任务的统一测试指令以及所述操作类型进行所述客户端的统一测试指令的指令转换复杂度的确定，并判断所述客户端的统一测试指令的指令转换复杂度是否小于预设复杂度，若是，则通过所述客户端的统一测试指令的指令转换复杂度进行所述统一测试指令的解析复杂度的确定，若否，则进入下一步骤；

S33通过所述测试子任务所对应的操作类型的客户端的数据类型和数据量进行所述客户端的数据测试复杂度的确定；

S34通过所述客户端的数据测试复杂度以及客户端的统一测试指令的指令转换复杂度进行所述统一测试指令的解析复杂度的确定；

基于不同的测试子任务的统一测试指令的类型进行测试子任务的测试优先级的确定，并基于所述测试优先级和测试复杂度进行不同的测试子任务的统一测试指令的测试顺序的确定。

2.如权利要求1所述的一种客户端测试管理方法，其特征在于，所述客户端的操作类型根据目标测试任务的操作目标所对应的客户端的功能模块以及在所述功能模块中的功能子模块进行确定。

3.如权利要求1所述的一种客户端测试管理方法，其特征在于，所述历史使用数据包括历史并发用户数量以及不同时段的历史并发用户数量的变动数据、历史使用高峰时段的时长以及在单位时间内的历史使用高峰时段的分布数据。

4.如权利要求1所述的一种客户端测试管理方法，其特征在于，所述并发测试用户的数量的确定的方法为：

S11通过所述客户端的测试子任务的历史并发用户数据进行所述测试子任务的历史并发用户的数量峰值的确定，并判断单位时间内在所述客户端的历史并发用户的数量峰值的出现次数是否大于预设次数，若是，则通过所述历史并发用户的数量峰值进行所述客户端的并发测试用户的数量的确定，若否，则进入下一步骤；

S12通过所述测试子任务的历史并发用户数据进行所述客户端的测试子任务的历史并发用户的数量的确定，并结合所述预设次数进行所述客户端的并发测试用户的推荐数量的确定；

S13将所述历史并发用户的数量大于所述并发测试用户的推荐数量的出现次数作为高峰出现次数，并判断所述高峰出现次数是否处于预设次数范围内，若是，则进入下一步骤，若否，则进入步骤S15；

S14将所述高峰出现次数所对应的历史并发用户作为筛选并发用户，并通过所述筛选并发用户的数量与所述并发测试用户的推荐数量的差值以及所述高峰出现次数是否可以将所述推荐数量作为所述客户端的并发测试用户的数量，若是，则将所述推荐数量作为所述客户端的并发测试用户的数量，若否，则进入下一步骤；

S15通过所述筛选并发用户的数量与所述并发测试用户的推荐数量的差值、在所述筛选并发用户的数量下的出现次数以及所述高峰出现次数进行所述推荐数量的修正数量的确定，并通过所述修正数量以及所述推荐数量进行所述客户端的并发测试用户的数量的确定。

5.如权利要求4所述的一种客户端测试管理方法，其特征在于，所述客户端的并发测试用户的推荐数量的确定的方法为：

获取所述客户端的测试子任务的历史并发用户的数量以及不同的历史并发用户的数量在单位时间内的出现次数的确定；

按照所述测试子任务的历史并发用户的数量从大到小进行排序，直到测试子任务的历史并发用户的数量在单位时间内的出现次数的次数和大于所述预设次数时，则将此时对应的测试子任务的历史并发用户的数量的最小值作为所述客户端的并发测试用户的推荐数量。

6.如权利要求1所述的一种客户端测试管理方法，其特征在于，所述测试子任务的测试时长的确定的方法为：

S21通过所述历史使用数据获取所述测试子任务所对应的客户端的操作类型的不同的预设时长内的使用人数和使用次数，并基于所述使用人数和使用次数进行历史高峰使用时段以及连续的历史高峰使用时段的最大持续时长的确定；

S22判断所述用户在单位时间内的历史高峰使用时段的数量是否大于预设数量，若是，则进入下一步骤，若否，则进入步骤S24；

S23获取所述用户在单位时间内的连续的历史高峰使用时段的最大持续时长，并结合所述用户在单位时间内的连续的历史高峰使用时段的持续时长的平均值以及持续时长大于预设时长历史高峰使用时段的数量进行所述测试子任务所对应的客户端的操作类型的使用频繁度的确定，并判断所述使用频繁度是否大于预设频繁度，若是，则通过所述用户在单位时间内的连续的历史高峰使用时段的最大持续时长进行所述测试子任务的测试时长的确定，若否，则进入下一步骤；

S24通过所述测试子任务所对应的客户端的操作类型的使用频繁度、在单位时间内使用人数、使用次数以及历史高峰使用时段的数量使用进行所述测试子任务的测试时长修正量的确定，并结合所述用户在单位时间内的连续的历史高峰使用时段的持续时长的平均值进行所述测试时长的确定。

7.如权利要求6所述的一种客户端测试管理方法，其特征在于，所述预设频繁度根据所述操作类型的重要程度进行确定，具体的根据所述操作类型的适用客户数量、历史使用人数和历史使用次数进行确定，当所述操作类型的适用客户数量越多、历史使用人数越多、历史使用次数越多，则所述预设频繁度越小。

8.如权利要求1所述的一种客户端测试管理方法，其特征在于，所述统一测试指令的测试复杂度的确定的方法为：

通过所述统一测试指令的解析复杂度进行单一的测试用户的测试复杂度的确定，并通过所述并发测试用户的数量、单一的测试用户的测试复杂度进行所述统一测试指令的用户的测试复杂度的确定，并结合所述测试时长进行所述统一测试指令的测试复杂度的确定。

9.一种客户端测试管理***，采用权利要求1-8任一项所述的一种客户端测试管理方法，其特征在于，具体包括：

测试用户评估模块，测试时长评估模块，测试复杂度确定模块，测试顺序确定模块；

其中所述测试用户评估模块负责根据目标测试任务所对应的客户端的操作类型的差异划分为多个测试子任务，并通过所述测试子任务所对应的客户端的操作类型进行不同的测试子任务的历史使用数据的确定，基于所述历史使用数据进行不同的客户端的测试子任务的历史并发用户数据的确定，并结合所述历史并发用户数据的变动情况进行不同的客户端的并发测试用户的数量的确定；

所述测试时长评估模块负责基于历史使用数据进行不同的客户端的测试子任务所对应的客户端的操作类型历史高峰使用时段的确定，并结合所述操作类型的不同时段的历史使用情况进行测试子任务的测试时长的确定；

所述测试复杂度确定模块负责通过所述测试子任务所对应的操作类型的不同的客户端的数据类型和数据量进行统一测试指令的解析复杂度的确定，并结合测试时长以及并发测试用户的数量进行所述统一测试指令的测试复杂度的确定；

所述测试顺序确定模块负责基于不同的测试子任务的统一测试指令的类型进行测试子任务的测试优先级的确定，并基于所述测试优先级和测试复杂度进行不同的测试子任务的统一测试指令的测试顺序的确定。