CN111026622B - 测试被测系统最大服务请求量的方法及装置 - Google Patents

Abstract

本申请实施例涉及一种测试被测系统最大服务请求量的方法及装置。该方法包括：获取被测系统的服务请求量决策模型，所述服务请求量决策模型指示服务请求的数量和步骤编号的对应关系，然后根据该服务请求量决策模型确定压力测试时的服务请求量。以此可以在压力测试过程中，减少压力测试次数，能够限制服务请求量的增长不会过快，避免由于服务请求量增长过快引起的被测系统崩溃，使得获取不到准确的最大服务请求量。

Description

测试被测系统最大服务请求量的方法及装置

技术领域

本申请实施例涉及电子技术领域，尤其涉及一种测试被测系统最大服务请求量的方法及装置。

背景技术

在业务系统上线前或者后续扩容时，都需要模拟真实用户的业务场景，对系统进行压力测试，通过模拟实际业务系统的软硬件环境及用户使用过程的系统负荷，对系统不断施加压力，确定一个系统的性能极限，来获得系统能提供的最大服务级别，以提高系统的可靠性、稳定性，减少系统的宕机的可能和因此带来的损失。

如今云化业务发展迅速，云服务提供商以在线公共服务的方式，提供安全、可靠的计算和数据处理能力，其中云服务器是他们的主要服务之一。企业或个人只需要在相应的云服务平台上按需申请所需的云服务器，就可以在其上部署自己的业务系统。

相应地，云服务提供商还提供配套的压力测试服务，让用户可以方便地对部署在云服务器上的业务系统进行压力测试。

压力测试中每次测试的服务请求量的设定通常依赖于测试人员经验设定，因为往往下一步测试设置为较小的增长数量，比如100每秒试呼次数(call attempt per second，caps)，因此需要进行多次的压力测试才能获知一个系统可以接受的最大服务请求量，且由于每次压力调整需要等待一个冷冻期，这就导致整个压力测试的周期过长。

发明内容

本申请实施例提供了一种测试被测系统最大服务请求量的方法及装置，以减少系统压力测试周期。

第一方面，提供了一种测试被测系统最大服务请求量的方法。该方法包括：获取被测系统的服务请求量决策模型，该服务请求量决策模型包含服务请求的数量与测试步骤编号的对应关系；根据服务请求量决策模型，确定步骤S1对应的请求数量C1；向被测系统发起C1个服务请求，并获取被测系统的负荷值L1；确定L1与预设负荷阈值Lt之差dlt1大于预设值d时，根据服务请求量决策模型确定步骤S2对应的第二请求数量C2，S2>S1；向被测系统发起C2个服务请求，并获取被测系统的负荷值L2；确定L2与预设负荷阈值Lt之差dlt2不大于预设值d时，将C2作为被测系统的最大服务请求量。本申请实施例通过根据确定的服务请求的数量和步骤编号的对应关系确定压力测试时的服务请求量，以此可以实现在压力测试过程中，减少压力测试次数，且服务请求量的增长可控，能够限制服务请求量的增长不会过快，避免由于服务请求量增长过快引起的被测系统崩溃，使得获取不到准确的系统最大服务请求量最大服务请求量。

在一种可能的设计中，前述获取被测系统的服务请求量决策模型包括：呈现多个服务请求量决策模型供用户选择；根据用户选择确定服务请求量决策模型；或者，获取被测系统的服务请求量决策模型包括还可以包括：获取被测系统的特性，所述被测系统的特性用于指示被测系统的服务请求量饱和度和负荷值之间的对应关系；根据所述被测系统的特性，在预定义的服务请求量决策模型中选择出被测系统的服务请求量决策模型。通过本申请实施例可以根据对被测系统的了解或者基于历史经验来配置被测系统的服务请求量决策模型，以此可以使得依据服务请求量决策模型确定的测试时的服务请求量更准确。

在另一种可能的设计中，前述根据所述服务请求量决策模型，确定步骤S1对应的请求数量C1包括：获取被测系统的特性，所述被测系统的特性用于指示被测系统的服务请求饱和度和负荷值之间的对应关系；根据已确定的一组或多组请求量和负荷值以及被测系统的特性估计被测系统最大服务请求量；根据估计的被测系统最大服务请求量、目标测试次数和所述服务请求量决策模型，确定步骤S1对应的请求数量C1，所述目标测试次数为预定义。通过本申请实施例可以实现依据被测系统的服务请求量饱和度和负荷值值之间的关系，服务请求量决策模型以及最大服务请求量最大服务请求量预先配置的目标测试次数来确定测试时的服务请求的数量，可以在指定测试次数时实现测试目标，确定测试结果。可以更好、更合理的控制服务请求量的增长速度，在被测系统侧承受范围内，快速的进行系统压力测试，提高了压力测试的效率。

在另一种可能的设计中，前述被测系统特性包括下述任意一项或多项：负荷随服务请求饱和度增长呈现线性增长、负荷随服务请求饱和度增长呈现上凸趋势增长、负荷随服务请求饱和度增长呈现下凹趋势增长。通过本申请实施例可以根据对被测系统的了解或者基于已经获得的测试数据来获取被测系统的特性服务请求量饱和度和负荷值最大服务请求量，以便更精确，稳定性更高的进行系统压力测试，提高了压力测试的效率。

在另一种可能的设计中，前前述获取被测系统的特性包括：根据用户配置确定被测系统的特性；或者，根据已确定的一组或多组请求量和负荷值，确定被测系统的特性，例如，根据已确定的一组或多组请求量和负荷值，在预定义的特性中，匹配被测系统的特性。通过本申请实施例可以根据在每次获取得到测试数据后，确定被测系统的特性，或者通过用户依据自己对被测系统的了解配置该被测系统，以此可以更合理的进行系统压力测试，更快速，且稳定性更高的确定被测系统最大服务请求量。

在另一种可能的设计中，前述确定L1与预设负荷阈值Lt之差dlt1大于预设值d时，根据所述服务请求量决策模型确定步骤S2对应的第二请求数量C2包括：确定L1与预设负荷阈值Lt之差dlt1大于预设值d时，根据dlt1确定测试步骤编号取值；根据服务请求量决策模型和测试步骤编号取值确定步骤S2对应的第二请求数量C2。通过本申请实施例可以根据已确定的数据对服务请求量的决策方式进行优化，根据优化后的方式确定测试时的请求数量，可以更精确，效率更高的确定被测系统的最大服务请求量。

在另一种可能的设计中，前述向被测系统发起C2个服务请求包括：在向被测系统发起C1个服务请求，并获取被测系统的负荷值L1后，经过一个冷冻期向被测系统发起C2个服务请求。

第二方面，提供了一种测试被测系统最大服务请求量的装置。该装置包括：获取单元，用于获取被测系统的服务请求量决策模型，所述服务请求量决策模型包含服务请求量与步骤编号的对应关系；确定单元，根据所述服务请求量决策模型，确定步骤S1对应的请求数量C1；发起单元，用于向所述被测系统发起C1个服务请求，并获取被测系统的负荷值L1；所述确定单元还用于，确定L1与预设负荷阈值Lt之差dlt1大于预设值d时，根据所述服务请求量决策模型确定步骤S2对应的请求数量C2，S2>S1；所述发起单元还用于，向所述被测系统发起C2个服务请求，并获取所述被测系统的负荷值L2；所述确定单元还用于，确定L2与预设负荷阈值Lt之差dlt2不大于预设值d时，将C2作为所述被测系统的最大服务请求量。

在一种可能的设计中，所述获取单元具体用于：呈现多个服务请求量决策模型供用户选择；根据用户选择确定服务请求量决策模型；或者，获取被测系统的特性，所述被测系统的特性用于指示被测系统的服务请求量饱和度和负荷值之间的对应关系；根据所述被测系统的特性，在预定义的服务请求量决策模型中选择出被测系统的服务请求量决策模型。

在另一种可能的设计中，所述确定单元具体用于：获取被测系统的特性，所述被测系统的特性用于指示被测系统的服务请求饱和度和负荷值之间的对应关系；根据已确定的一组或多组请求量和负荷值以及被测系统的特性估计被测系统最大服务请求量；根据估计的被测系统最大服务请求量、目标测试次数和所述服务请求量决策模型，确定步骤S1对应的请求数量C1，所述目标测试次数为预定义。

在另一种可能的设计中，前述被测系统特性包括下述任意一项或多项：负荷随服务请求饱和度增长呈现线性增长、负荷随服务请求饱和度增长呈现上凸趋势增长、负荷随服务请求饱和度增长呈现上凸趋势增长。

在另一种可能的设计中，前述确定单元具体用于：根据用户配置确定被测系统的特性；或者，根据已确定的一组或多组请求量和负荷值，确定被测系统的特性。

在另一种可能的设计中，前述确定单元具体用于：根据已确定的一组或多组请求量和负荷值，在预定义的特性中，匹配被测系统的特性。

在另一种可能的设计中，前述确定单元具体用于：确定L1与预设负荷阈值Lt之差dlt1大于预设值d时，根据dlt1确定测试步骤编号取值；根据服务请求量决策模型和测试步骤编号取值确定步骤S2对应的第二请求数量C2。

在另一种可能的设计中，前述发起单元具体用于：在向被测系统发起C1个服务请求，并获取被测系统的负荷值L1后，经过一个冷冻期向被测系统发起C2个服务请求。

第三方面，本发明实施例提供了一种计算设备。该设备包括收发器、处理器和存储器；收发器用于与被测系统通信，存储器用于存放程序；处理器用于执行存储器存储的程序，以控制运算设备执行上述第一方面以及其可能的设计中所述的方法。

第四方面，提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述第一方面以及其可能的设计中所述的方法。

第五方面，提供了一种包含指令的计算机程序产品，当计算机程序产品的指令在计算机上运行时，使得计算机执行上述第一方面以及其可能的设计中所述的方法。

附图说明

图1为本申请实施例提供的一种应用场景示意图；

图2为本申请实施例提供的一种测试被测系统最大服务请求量的方法流程示意图；

图3为本申请实施例提供的服务请求量决策模型示例；

图4为本申请实施例提供的服务请求量饱和度和负荷值之间的关系示例；

图5为本申请实施例提供的一种测试被测系统最大服务请求量的方法流程示意图；

图6为本申请实施例提供的一种测试被测系统最大服务请求量的装置结构示意图；

图7为本申请实施例提供的一种服务器结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例进行描述。

本申请的申请人通过分析发现：在目前系统性能压力测试过程中，服务请求量，也即性能压力的调整依赖于个人经验。例如当前压力测试中服务请求量设定为2000caps，各个节点还未到系统的性能极限，那么测试人员可以根据经验确定下次测试服务请求量增加100caps。每次增加压力后需要一个冷冻期再进行下次加压，待冷冻期过后才能再继续增加服务请求量进行测试，测试周期长。

其中，冷冻期是指压力测试两次调整服务请求量需要的时间间隔。该时间间隔一般与被测系统加载缓存、建立数据库链接等初始化操作的时间、服务请求处理时长，如打电话时长相关，即需要等被测系统稳定后再开始增加压力。

服务请求量的单位可以为多种，例如，可以为下述任意一个：每秒试呼次数(callattemptper second，caps)、每秒事务数(transactions per second，TPS)、每秒查询率(query per second，QPS)。

本申请实施例通过根据被测系统历史测试的服务请求量和负荷的对应关系确定服务请求量和测试次数之间的关系，然后根据该关系确定压力测试时的服务请求量，通过服务请求量和测试次数之间的关系可以实现在压力测试过程中，减少压力测试次数，且限制服务请求量的增长不会过快，避免由于服务请求量增长过快引起的被测系统崩溃，使得获取不到准确的最大服务请求量。同时，当接近被测系统的性能极限时，服务请求量增长较慢，以便获取到更准确的最大服务请求量。

图1为本申请实施例提供的一种应用场景示意图。如图1所示，该场景中包括测试服务器100和被测系统200。其中，测试服务器100与被测系统200连接，测试服务器100用于向被测系统200发送服务请求，该服务请求包括试呼请求、事务请求或查询请求中的一项或多项。测试服务请100还用于接收被测系统返回的被测系统的资源使用情况，该资源使用情况包括但不限于中央处理器、内存、I/O、或网络等等。被测系统200可以包括一个或多个节点，每个节点都可以收集自身的资源使用情况并发送给测试服务器100。

图2为本申请实施例提供的一种压力测试流程示意图。该方法可以通过图1所示的场景实现，如图2所示，该方法包括：

S210，获取被测系统的服务请求量决策模型，所述服务请求量决策模型指示服务请求的数量和步骤编号的对应关系。

其中，被测系统的服务请求量决策模型可以包括多种确定方式。例如，可以根据用户配置确定服务请求量决策模型，举例来说，测试服务器可以呈现多个服务请求量决策模型供用户选择；根据用户选择确定服务请求量决策模型。或者，获取被测系统的特性，该被测系统的特性用于指示被测系统的服务请求量饱和度和负荷值之间的对应关系；根据被测系统的特性，在预定义的服务请求量决策模型中选择出被测系统的服务请求量决策模型。

在一个示例中，被测系统的服务请求量决策模型可以为如下公式：

在该式一中，a和b为参数，b为服务请求量的增长率，b的取值范围为(0，1)，a和b的值可以预定义，x为步骤编号，Y_x为步骤编号为x时请求的数量。其中，b的取值可以根据被测系统的特性确定，例如，对于b的取值，负荷随服务请求饱和度增长呈现上凸趋势增长的系统，大于负荷随服务请求饱和度增长呈现线性增长的系统，大于负荷随服务请求饱和度增长呈现下凹趋势增长的系统。

例如，可以给定一个数值指代被测系统的最大服务请求量，并根据经验确定a和b的值，具体地，x的取值范围为【0，6】，其中，x的最大值6为压测次数目标值，Y_x的取值范围为【0，6】，其中，Y_x的最大值6指代被测系统的最大服务请求量。经过综合多个系统的测试情况，可以指定(a＝3.04，b＝0.5)，此时，服务请求量决策模型可以如图3所示，该服务请求量决策模型初期压力增长相对不是很快，后期压力增长相对较慢。

再例如，可以假设当Y_x最大时等于被测系统最大服务请求量，其中，Y_x最大时，x趋于无限大，b^x趋于0，此时，被测系统最大服务请求量＝a/(1-b)，可以预设服务请求量的增长率b的值，并估计被测系统最大服务请求量，根据估计的被测系统最大服务请求量计算a的值。例如，结合式一，估计到被测系统最大服务请求量为10000caps，在给定式一中的b为0.5时，求得式一中a的值为5000。

其中，可以根据被测系统的历史数据或初始测试数据和被测系统的特性估计被测系统的被测系统最大服务请求量。该被测系统的特性用于指示被测系统的服务请求饱和度和负荷值之间的对应关系。该被测系统特性包括下述任意一项或多项：负荷随服务请求饱和度增长呈现线性增长、负荷随服务请求饱和度增长呈现上凸趋势增长、负荷随服务请求饱和度增长呈现下凹趋势增长。

例如，被测系统是中央处理器(central processing unit，CPU)密集型，即被测系统要进行大量的CPU计算，比如计算圆周率、对视频进行高清解码等等，大量消耗CPU的运算能力，这类系统随压力增长负荷会线性增加，如下图4中系统A所述。再例如，系统压力增长开始时需要建立数据库链接及缓存等，随着压力增长这部分开销减小，这类被测系统负荷随压力增长呈现上凸趋势，如图4中系统B所述。再例如，常见输入/输出(input/output，IO)密集型系统，随着压力增长CPU需要等待IO操作完成，这类被测系统负荷随压力增长呈现下凹趋势，如图4中系统C所述。

在具体计算时，给定任意一组服务请求量和负荷值，即可估计被测系统的最大服务请求量。例如，以被测系统为系统A为例，假设初始压力测试得到的测试结果为：服务请求量为1000caps，负荷值为10％。此时，根据被测系统的服务请求量饱和度和负荷值之间存在关系y＝x，可以确定负荷值为10％对应的被测系统的服务请求量饱和度为10％，所以可以估计被测系统的最大服务请求量为10000caps。

进一步地，在根据服务器请求量和负荷值的对应关系估计被测系统的最大服务请求量时，可以根据最新测量得到的服务器请求量和负荷值的对应关系进行估计。

另外，在测试过程中，若预先并未确定被测系统的服务请求量饱和度和负荷值之间的关系，或服务请求量决策模型中的具体参数的值，则可以进行一次或多次系统性能探测。

例如，可以通过少量服务请求来试探系统性能，该过程也可以理解为初始压力测试过程。此时，测试服务器可以向被测系统发送指定数量的服务请求，并接收被测系统返回的在该指定数量的服务请求下的被测系统负荷值。测试服务器可以根据被测系统的服务请求量饱和度和负荷值之间的关系，以及被测系统的初始压力测试时的服务请求量和初始压力测试时的负荷值，估计被测系统的最大服务请求量。

被测系统的特性可以包括多种获取方式，例如，可以根据用户配置确定被测系统的特性，或者，可以根据已确定的一组或多组请求量和负荷值，确定被测系统的特性。

例如，用户根据被测系统的类型(例如，CPU密集型或IO密集型等)配置被测系统的特性；进一步地，测试服务器可以根据用户配置确定被测系统的服务请求量饱和度和负荷值之间存在的对应关系模型，且确定该对应关系模型中参数的值。

结合图4所示，被测系统的服务请求量饱和度和负荷值之间存在关系可以预设为：y＝mx+nx²，其中，m+n等于1，y的取值范围为[0，1]，x的取值范围为[0，1]。可以预定义系统A对应的取值为“m＝1，n＝0”，也即系统A的服务请求量饱和度和负荷值之间存在线性关系；可以预定义系统B对应的取值为“m＝0.4，n＝0.6”，也即系统B的服务请求量饱和度和负荷值之间存在非线性关系；可以预定义系统C对应的取值为“m＝0.6，n＝0.4”，也即系统C的服务请求量饱和度和负荷值之间存在非线性关系。

例如，可以预定义多个特性，在测试被测系统最大服务请求量过程中，可以根据已确定的一组或多组请求量和负荷值，在预定义的特性中，匹配被测系统的特性。进一步的，测试服务器可以预先设置被测系统的服务请求量饱和度和负荷值之间存在的对应关系模型，该增长模型中的参数的值可以根据在测试过程中产生的数据确定。例如，可以预定义多种参数的组合，跟据根据已确定的一组或多组请求量和负荷值的走势，选择最符合要求的参数组合，基于此，本申请实施例可以包括：根据已确定的一组或多组请求量和负荷值，在预定义的特性中，匹配被测系统的特性。再例如，测试服务器可以根据测试过程中产生的数据确定被测系统的服务请求量饱和度和负荷值之间存在的对应关系模型。

例如，可以预设“m＝1，n＝0”、“m＝0.4，n＝0.6”和“m＝0.6，n＝0.4”三组参数。在测试过程中，收集到前3次压力测试数据如下表1所示，根据该三次压力测试数据中的任意两次或三次可以确定如下趋势：系统D负荷会随压力增长线性增加，那么系统D即是线性关系，选择的参数为“m＝1，n＝0”，对应的系统E为上凸，选择的参数为“m＝0.4，n＝0.6”，系统F为下凹，选择的参数为“m＝0.6，n＝0.4”，决策单元会系统特点来选取决策模型。

表1

服务请求量	系统D负荷	系统E负荷	系统F负荷
				0	0	0	0
100	10	28	5
				200	20	42	10
300	30	54	56

另外，还可以默认所有被测系统的服务请求量和负荷之间皆为线性关系。此时，可以根据被测系统历史测试的服务请求量和负荷值的对应关系估计被测系统的最大服务请求量，根据估计的被测系统的最大服务请求量确定服务请求量决策模型。例如，服务请求量决策模型也可以采用如前述式一所示的模型。另外，为例提供估计的被测系统的最大服务请求量的准确性，可以在每次新测量得到服务请求量和负荷之间的对应关系后，重新估计被测系统的最大服务请求量。

在另一个示例中，被测系统的服务请求量决策模型还以式一为例，还可以根据历史多次测试数据的结果计算a和b的值。例如，可以根据已经测量得到的两组以上的服务器请求量和负荷的对应关系求解算a和b的值，或者，还可以通过机器学习来确定a和b的值。

需要说明的是，前述被测系统的服务请求量饱和度和负荷值之间的存在关系，或服务请求量决策模型中的公式仅为示例，还可以为其他能体现关系的公式，该其他能体现关系的公式可以由更多或更少的参数定义，具体根据实际需要确定，例如，被测系统的服务请求量饱和度和负荷值之间的存在关系还可以为：y＝mx+nx²+px³。

S220，根据所述服务请求量决策模型，确定步骤Sn对应的请求数量Cn。其中，n为正整数。

根据所述服务请求量决策模型，确定步骤S1对应的请求数量C1。可以包括多种实现方式。

在一个示例中可以获取被测系统的特性，所述被测系统的特性用于指示被测系统的服务请求饱和度和负荷值之间的对应关系；根据已确定的一组或多组请求量和负荷值以及被测系统的特性估计被测系统最大服务请求量；根据估计的被测系统最大服务请求量、目标测试次数和服务请求量决策模型，确定步骤Sn对应的请求数量Cn。其中，目标测试次数、被测系统的特性以及估计被测系统最大服务请求量具体可以参见前述S210中的描述。

例如，还可以预先将式一中y轴代表对应的服务请求量，取值范围为设置为[0，6]，即6代表最大服务请求量。以及给定式一中参数的值，其中，“a＝3.04，b＝0.5”

式一可以变形为，其中a＝3.04，b＝0.5：

假设当前要进行的是第二次测试，测试服务器需要决策第二次测试的服务请求量。

在被测系统的服务请求量饱和度和负荷值之间存在关系为线性关系时，初始压力测试得到的压力测试数据为“服务请求量为1000caps，负荷为10％”，根据被测系统的特性以及初始测试时的数据，可以估计得到最大服务请求量为10000caps，即模型中Y_x＝6代表10000caps，那么，1000caps对应Y_x＝0.6。

当Y_x为0.6时，计算出x的值为0.1499。即，初始测试在式一中相当于第0.1499次测试。

那么，第二次测试的步骤编号可以增加1，即X＝1.1499，根据式一计算Y为3.34，换算为实际的服务请求量为5567caps。之后的每次测试步骤编号都可以增加1，以此类推。

在另一个示例中可以，可以直接将步骤编号输入服务请求量决策模型中，可以输出为请求的数量。

例如，结合式一，在被测系统的服务请求量饱和度和负荷值之间存在关系为线性关系时，初始压力测试得到的压力测试数据为“服务请求量为1000caps，负荷为10％”，在给定式一中的b为0.5时，求得式一中a的值为5000。那么，第二次测试时，可以另x等于2，求得第二次测试对应的服务请求量即为7500caps，依次类推。或者，由于初始压力测试对应的式一中的次数约为0.15，那么，第二次测试时，可以另x等于“1+0.15”，求得第二次测试对应的服务请求量即为5500caps，依次类推。

另外，测试被测系统最大服务请求量允许一定的误差，该误差可以体现为与系统负荷阈值之间的误差。例如，本申请实施例中误差为2％，负荷阈值可以为100％，当被测系统负荷达到阈值时，得到的测试结果就是有效的被测系统的最大服务请求量。

例如，结合式一所示，在被测系统的服务请求量饱和度和负荷值之间存在线性对应关系时，确定被测系统负荷达到阈值即为，测试过程中的服务请求量与估计的性能极限的比值达到阈值。x趋于无限大，估计的被测系统的最大服务请求量＝a/(1-b)，此时，测试过程中的服务请求量与估计的性能极限的比值即为“1-b^x”，由此可知，求解被测系统负荷达到阈值，即为求解b^x大于误差。在b＝0.5时，让b^x大于2％，此时，x大于6。假设目标测试次数为6，由于初始测试对应的测试次数值一般大于1，若步骤编号增加的取值为1，那么第六步的测试次数值大于6，b^x大于2％，所以还需要进行第七次测试。所以，在确定目标测试次数以及初始测试对应的测试次数值时，可以确定步骤编号使得第6次测试时对应的测试次数的值等于或大于6。例如，若初始测试对应的值为0.15，那么，步骤编号每次增加的值可以选择大于等于(6-0.15)/5的值，例如，步骤编号可以取值1.17，或1.5等等。另外，还可以根据被测系统的性能，设定步骤编号增长上限，例如，步骤编号增长的最大取值不能超过2。其中，步骤编号的增长上限可以根据实际需要确定。

S230，向被测系统发起C1个服务请求，并获取被测系统的负荷值L1。

测试服务器根据确定的第一请求数量C1，向被测系统发送服务请求。被测系统采集在本次压力测试时的负荷值，并将采集到的负荷值发送至测试服务器。

测试服务器在接收到被测系统发送的负荷值时，判断该确定L1与预设负荷阈值Lt1之差dlt1大于预设值d时。其中，预设值d可以为测试被测系统最大服务请求量允许存在的误差，例如，该误差可以为2％，预设负荷阈值Lt可以为100％。

若测试服务器确定L1与预设负荷阈值Lt之差dlt1不大于预设值d时，则测试服务器确定C1为所述被测系统的最大服务请求量。

若测试服务器确定Ln与预设负荷阈值Lt之差dltn大于预设值d时，则继续执行如下步骤S240。

S240，确定Ln与预设负荷阈值Lt之差dltn大于预设值d时，根据服务请求量决策模型确定步骤Sn+1对应的请求数量C n+1，Sn+1>Sn。

该S240中，服务请求量决策模型可以参见前述S220中的相关描述，不再赘述。

另外，在根据服务请求量决策模型确定步骤Sn+1对应的请求数量Cn+1时，还可以根据步骤Sn确定的负荷值与负荷阈值的差和服务请求量决策模型，确定该步骤Sn的下一步骤Sn+1对应的服务请求量。例如，可以根据负荷值与负荷阈值的差对服务请求量决策模型进行优化。在一个示例中，可以根据步骤Sn确定的负荷值与负荷阈值的差计算下一步骤Sn+1对应的服务请求量时的测试步骤编号取值，根据服务请求量决策模型和测试步骤编号取值确定步骤Sn+1对应的第二请求数量Cn+1。结合前述S220中的相关描述，以步骤Sn的编号为1.15，步骤编号增长了1为例，若该步骤Sn获取到的负荷值为55％时，符合预期(其中，预期可以根据服务请求量决策模型确定)，则可以不对服务请求量决策模型进行调整，确定下一步骤Sn+1的编号为2.15，若该步骤Sn编号为1.15，获取到的负荷值为65％时，大于预期，则可以对服务请求量决策模型进行调整，确定下一步骤Sn+1的编号为2，也就是步骤Sn的编号与下一步骤Sn+1的编号之差小于1，从而放缓服务请求量的增长速度。在另一个示例中，还也可以根据上一步骤确定的负荷值与负荷阈值的差以及服务请求量决策模型中其他参数的值，例如可以调整前述式一中b的值。

S250，向被测系统发起Cn+1个服务请求，获取被测系统的负荷值Ln+1。

其中，在步骤Sn向被测系统发起Cn个服务请求，并获取被测系统的负荷值Ln后，经过一个冷冻期在经过Sn+1向被测系统发起Cn+1个服务请求。

测试服务器在接收到被测系统发送的负荷值Ln+1时，判断该确定Ln+1与预设负荷阈值Lt之差dltn+1是否大于预设值d时。

若测试服务器确定Ln+1与预设负荷阈值Lt之差dltn+1不大于预设值d时，则测试服务器执行步骤S260。

若测试服务器确定Ln+1与预设负荷阈值Lt之差dltn+1大于预设值d时，则继续根据dltn+1以及服务请求量决策模型确定第三请求数量Cn+2，直到确定最近一次获取的负荷值与预设负荷阈值之差大于预设值d。也即，另S240-S250中的n+1等于n+2，直到确定dltn+1最近一次获取的负荷值与预设负荷阈值之差大于预设值d时，则确定最近一次获取的负荷值对应的请求数量为被测系统的最大服务请求量，也即，重复执行S240-S250，直至确定负荷值与负荷阈值的差不大于预设值d时，得到被测系统的最大服务请求量。

S260，确定L2与预设负荷阈值Lt之差dlt2不大于预设值d时，将C2作为被测系统的最大服务请求量。

本申请实施例通过确定的服务请求的数量和步骤编号的对应关系确定压力测试时的服务请求量，在压力测试过程中，减少压力测试次数，且限制服务请求量的增长不会过快，避免由于服务请求量增长过快引起的被测系统崩溃，使得获取不到准确的最大服务请求量。进一步地，根据性能测试过程中收集到的被测系统的历史负荷情况，评估达到系统性能极限时被测系统能够处理的服务请求量，并根据评估的性能极限确定的下一步测试的服务请求量。另外还可以设定目标值，以便在通过指定次数的测试即可得到测试结果。通过本方案设定测试的服务请求量的方法，可以按测试人员设定的目标测试次数，加压达到系统性能极限，有效降低压测耗时，提高系统业务上线速度。

图5为本申请实施例提供的另一种压力测试流程示意图。该方法可以通过图1所示的场景实现，如图5所示，实现该方法的测试服务器包括配置单元、收集单元、决策单元以及服务请求发起单元等等，另外，在被测系统上包括采集单元。服务请求发起单元：每次测试时，按配置单元或决策单元指定的服务请求量向被测系统节点发送服务请求。其中初始测试由配置单元指定，后续测试由决策单元指定。被测系统节点可以是被测系统中的部分节点，也可以是被测系统中的全部节点。

其中，收集单元，用来收集测试过程中被测系统的各个节点上的资源占用情况。

配置单元：测试人员在初始测试前通过配置单元配置初始测试的服务请求量、目标测试次数。可选地，测试人员还可以在初始测试前通过测试单元配置系统最大服务请求量评估模型、服务请求量决策模型。

决策单元：在初始测试之后的每次测试前，根据压力测试过程中收集到的被测系统的历史测试数据，评估达到系统的最大服务请求量，并根据评估结果和目标测试次数确定的本次测试的服务请求量，其中本次压力测试为即将执行的压力测试。

采集单元：部署在被测系统上，在测试过程中向收集单元报告所在被测系统节点的资源占用情况。

具体地，该方法可以包括如下步骤：

S501，配置单元向服务请求发起单元指定初始测试的请求数量为C1，如C1为1000Caps。

其中，测试人员在配置单元配置初始化信息，初始化信息包括初始测试的服务请求的数量或目标测试次数等。初始化信息还包括系统最大服务请求量的特性、服务请求量决策模型。

S502，配置单元指示决策单元进行初始化。

其中，配置单元可以将上述初始化信息发送给决策单元，或者配置单元将配置的系统最大服务请求量特性、服务请求量决策模型发送给决策单元，决策单元初始化，加载相应的模型。或者，决策单元根据目标测试次数选择默认的最大服务请求量特性和服务请求量决策模型。

S503，服务请求发起单元按指定的初始测试服务请求量向被测系统节点发起C1个服务请求，开始初始测试。

S504，收集单元收集被测系统节点的资源使用情况，包括但不限于CPU资源情况，、内存占用情况等，用于评估被测试系统的负荷值。例如收集到被测系统的CPU占用为10％，则评估被测系统的负荷值为10％。

S505，收集单元将被测系统节点的历史负荷情况发送给决策单元。决策单元可以根据收集到的历史负荷情况，来匹配被测系统的最大服务请求量特性。

S506，决策单元根据历史负荷情况，评估被测系统的最大服务请求量特性，并根据服务请求量决策模型和目标测试次数确定第二次压力测试的请求数量C2。

例如，在前一次测试之后，等待一个冷冻期的时间后(冷冻期是一个固定值，可以由测试服务提供方根据经验设定并固化到测试服务中，也可以作为初始化信息配置。一般与被测系统加载缓存、建立数据库链接等初始化操作的时间、服务请求处理时长，如打电话时长相关。决策单元根据收集单元收集的历史测试数据评估系统最大服务请求量。

例如，当前要进行的是第二次测试，决策单元根据收集到的初始测试被测系统的CPU占用为10％，以及初始测试的服务请求量为1000caps，被测系统的负荷随服务请求饱和度增长呈现线性增长，因此预估压测到被测系统的CPU达到100％占用时的最大服务请求量最大服务请求量，能够处理的最大服务请求量为：1000caps*(100％/10％)＝10000caps。

决策单元采用服务请求量决策模型，根据评估得到的最大服务请求量和目标测试次数确定的第二次测试的服务请求量。

压力测试允许一定的误差，例如，误差为2％，即只要能够加压让被测系统节点的CPU占用达到98％以上时，测试结果就是有效的。

测试被测系统最大服务请求量过程中，压力增长不能太快，如果太快的话容易引起被测系统因为请求浪涌导致的系统崩溃，从而获取不到准确的最大服务请求量。同时后期加压要比较慢，当系统接近性能极限时，加压过大也很容易导致系统崩溃，从而获取不到准确的最大服务请求量。

因此，在满足目标测试次数的前提下，往往综合上述两方面因此来选择服务请求量决策模型，如前所述该模型可以由测试人员在初始测试之前通过配置单元配置，也可以是测试服务提供方根据经验固化下来的默认模型。

S507，决策单元向服务请求发起单元指定第二次测试的请求数量C2。

S508，服务请求发起单元向被测系统节点发起服务C2和请求，开始第二次测试。

重复S504-S508步，进行第三次测试甚至第四次测试，直至已执行的测试次数达到目标测试次数，或者获得的被测系统负荷与预设负荷阈值之差不大于预设值d时。其中，预设值d可以为误差，预设负荷阈值可以为1。

图6为本申请实施例提供的一种测试被测系统最大服务请求量的装置结构示意图。该装置可以用于执行图2或图4所示实施例中服务器所执行的方法。如图6所示，该装置包括：

获取单元601，用于获取被测系统的服务请求量决策模型，所述服务请求量决策模型指示服务请求量和步骤编号的对应关系；

确定单元603，用于根据所述服务请求量决策模型，确定步骤S1对应的请求数量C1；

发起单元602，用于向被测系统发起C1个服务请求，并获取被测系统的负荷值L1；

确定单元603还用于，确定L1与预设负荷阈值Lt1之差dlt1大于预设值d时，根据服务请求量决策模型确定步骤S2对应的请求数量C2，S2>S1；

所述发起单元602还用于，向被测系统发起C2个服务请求，获取被测系统的负荷值L2；

所述确定单元603还用于，确定L2与预设负荷阈值Lt2之差dlt2不大于预设值d时，将C2作为被测系统的最大服务请求量。

可选地，所述获取单元601具体用于：

呈现多个服务请求量决策模型供用户选择；

根据用户选择确定服务请求量决策模型。

可选地，所述获取单元601具体用于：

获取被测系统的特性，所述被测系统的特性用于指示被测系统的服务请求量饱和度和负荷值之间的对应关系；

根据所述被测系统的特性，在预定义的服务请求量决策模型中选择出被测系统的服务请求量决策模型。

可选地，所述确定单元603具体用于：

获取被测系统的特性，所述被测系统的特性用于指示被测系统的服务请求饱和度和负荷值之间的对应关系；

根据已确定的一组或多组请求量和负荷值以及被测系统的特性估计被测系统最大服务请求量；

根据估计的被测系统最大服务请求量、目标测试次数和所述服务请求量决策模型，确定步骤S1对应的请求数量C1，所述目标测试次数为预定义。

可选地，所述被测系统特性包括下述任意一项或多项：

负荷随服务请求饱和度增长呈现线性增长、负荷随服务请求饱和度增长呈现上凸趋势增长、负荷随服务请求饱和度增长呈现上凸趋势增长。

可选地，所述确定单元603具体用于：

根据用户配置确定被测系统的特性；

可选地，所述确定单元603具体用于：

根据已确定的一组或多组请求量和负荷值，确定被测系统的特性。

例如，根据已确定的一组或多组请求量和负荷值，在预定义的特性中，匹配被测系统的特性。

可选地，确定单元603具体用于：

确定L1与预设负荷阈值Lt之差dlt1大于预设值d时，根据dlt1确定测试步骤编号取值；

根据服务请求量决策模型和测试步骤编号取值确定步骤S2对应的第二请求数量C2。

可选地，所述发起单元602具体用于：

在向被测系统发起C1个服务请求，并获取被测系统的负荷值L1后，经过一个冷冻期向被测系统发起C2个服务请求。

图7为本申请实施例提供的一种服务器结构示意图。该服务器700具体包括：包括收发器701，处理器702，存储器703。收发器701、处理器702和存储器703可以通过总线连接。该服务器可以用于实现图2或图5所示实施例中服务器的功能。

其中，收发器701用于支持服务器与上述实施例中的终端或其他服务器之间收发信息。在服务器与终端之间通信过程中，数据和信令消息由处理器702进行处理，并由收发器701发送给终端。来自终端的数据和信令的经由收发器701接收，由处理器702进行处理得到终端发送的数据和信令。处理器702可以控制发送设备700执行图2所示实施例中涉及发送端的处理过程和/或用于本申请所描述的技术的其他过程。例如，处理器702用于执行图2和图4所示的实施例中的S210、S230、S240、S501、S502或S504-S507等步骤中的一步或多步，收发器701用于执行图2或图5所示的实施例中的S220、S503或S508等步骤中的一步或多部，其中，收发器701可以在处理器702的配合下执行上述步骤。存储器703用于存储终端的程序代码和数据。

在上述各个本发明实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读介质向另一个计算机可读介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如，固态硬盘)等。

以上所述，仅为本申请较佳的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。

Claims (14)

1.一种测试被测系统最大服务请求量的方法，其特征在于，所述方法包括：

获取被测系统的服务请求量决策模型，所述服务请求量决策模型包含服务请求的数量与测试步骤编号的对应函数关系；所述测试步骤编号的取值不大于压测次数的目标值；

根据所述服务请求量决策模型，确定所述测试步骤编号为S1的第一测试步骤对应的请求数量C1；

向所述被测系统发起C1个服务请求，并获取被测系统的负荷值L1；

确定L1与预设负荷阈值Lt之差dlt1大于预设值d时，根据所述服务请求量决策模型确定所述测试步骤编号为S2的第二测试步骤对应的第二请求数量C2，S2>S1；

向所述被测系统发起C2个服务请求，并获取所述被测系统的负荷值L2；

确定L2与预设负荷阈值Lt之差dlt2不大于预设值d时，将C2作为所述被测系统的最大服务请求量；其中，S1、S2为正实数；C1、C2为正整数。

2.根据权利要求1所述的方法，其特征在于，所述获取被测系统的服务请求量决策模型包括：

呈现多个服务请求量决策模型供用户选择；

根据用户选择确定服务请求量决策模型；

或者，

获取被测系统的特性，所述被测系统的特性用于指示被测系统的服务请求量饱和度和负荷值之间的对应关系；

根据所述被测系统的特性，在预定义的服务请求量决策模型中选择出被测系统的服务请求量决策模型。

3.根据权利要求2所述的方法，其特征在于，所述获取被测系统的特性包括：

根据用户配置确定被测系统的特性；

或者，

根据已确定的一组或多组请求量和负荷值，确定被测系统的特性。

4.根据权利要求3所述的方法，其特征在于，所述根据已确定的一组或多组请求量和负荷值，确定被测系统的特性包括：

根据已确定的一组或多组请求量和负荷值，在预定义的特性中，匹配被测系统的特性。

5.根据权利要求1-4任意一项所述的方法，其特征在于，所述确定L1与预设负荷阈值Lt之差dlt1大于预设值d时，根据所述服务请求量决策模型确定测试步骤编号为S2的第二测试步骤对应的第二请求数量C2包括：

确定L1与预设负荷阈值Lt之差dlt1大于预设值d时，根据dlt1确定测试步骤编号取值；

根据服务请求量决策模型和测试步骤编号取值确定测试步骤编号为S2的第二测试步骤对应的第二请求数量C2。

6.根据权利要求1-4任意一项所述的方法，其特征在于，所述向所述被测系统发起C2个服务请求包括：

在向所述被测系统发起C1个服务请求，并获取被测系统的负荷值L1后，经过一个冷冻期向被测系统发起C2个服务请求。

7.一种测试被测系统最大服务请求量的装置，其特征在于，所述装置包括：

获取单元，用于获取被测系统的服务请求量决策模型，所述服务请求量决策模型包含服务请求的数量与测试步骤编号的对应函数关系；所述测试步骤编号的取值不大于压测次数的目标值；

确定单元，用于根据所述服务请求量决策模型，确定所述测试步骤编号为S1的第一测试步骤对应的请求数量C1；

发起单元，用于向所述被测系统发起C1个服务请求，并获取被测系统的负荷值L1；

所述确定单元还用于，确定L1与预设负荷阈值Lt之差dlt1大于预设值d时，根据所述服务请求量决策模型确定所述测试步骤编号为S2的第二测试步骤对应的第二请求数量C2，S2>S1；

所述发起单元还用于，向所述被测系统发起C2个服务请求，并获取所述被测系统的负荷值L2；

所述确定单元还用于，确定L2与预设负荷阈值Lt之差dlt2不大于预设值d时，将C2作为所述被测系统的最大服务请求量；其中，S1、S2为正实数；C1、C2为正整数。

8.根据权利要求7所述的装置，其特征在于，所述获取单元具体用于：

呈现多个服务请求量决策模型供用户选择；

根据用户选择确定服务请求量决策模型；

或者，

获取被测系统的特性，所述被测系统的特性用于指示被测系统的服务请求量饱和度和负荷值之间的对应关系；

根据所述被测系统的特性，在预定义的服务请求量决策模型中选择出被测系统的服务请求量决策模型。

9.根据权利要求7或8所述的装置，其特征在于，所述确定单元具体用于：

根据用户配置确定被测系统的特性；

或者，

根据已确定的一组或多组请求量和负荷值，确定被测系统的特性。

10.根据权利要求9所述的装置，其特征在于，所述确定单元具体用于：

根据已确定的一组或多组请求量和负荷值，在预定义的特性中，匹配被测系统的特性。

11.根据权利要求7-8任意一项所述的装置，其特征在于，所述确定单元具体用于：

确定L1与预设负荷阈值Lt之差dlt1大于预设值d时，根据dlt1确定测试步骤编号取值；

根据服务请求量决策模型和测试步骤编号取值确定测试步骤编号为S2的第二测试步骤对应的第二请求数量C2。

12.根据权利要求7-8任意一项所述的装置，其特征在于，所述发起单元具体用于：

在向被测系统发起C1个服务请求，并获取被测系统的负荷值L1后，经过一个冷冻期向被测系统发起C2个服务请求。

13.一种计算机设备，其特征在于，包括收发器、处理器和存储器；所述收发器用于与被测系统通信，所述存储器用于存放程序；所述处理器用于执行所述存储器存储的所述程序，以控制所述计算机设备执行权利要求1-6任意一项所述的方法。

14.一种计算机可读存储介质，包括计算机可读指令，当计算机读取并执行所述计算机可读指令时，使得计算机执行如权利要求1-6任意一项所述的方法。

Images