CN106470133A - 系统压力测试方法及装置 - Google Patents

Abstract

本申请实施例公开了系统压力测试方法及装置，其中，所述方法包括：测试平台总控服务器接收物流服务方客户端的压力测试请求，所述请求中携带有测试相关参数信息，所述测试相关参数信息包括：待测试的单位时间段内的订单数量、物流服务方所在位置以及测试场景；根据所述测试相关参数信息确定压力并发数；将所述测试相关参数信息以及所述压力并发数发送到预置的测试集群，由所述测试集群根据所述测试相关参数以及预置的脚本生成测试报文，以便按照所述压力并发数，将所述测试报文发送到所述物流服务方的业务系统；收集测试过程中产生的性能数据，并通过与性能指标进行比对，得到测试结果。通过本申请实施例，可以使得测试结果更加可靠。

Description

系统压力测试方法及装置

技术领域

本申请涉及压力测试技术领域，特别是涉及系统压力测试方法及装置。

背景技术

目前，有些电子商务交易平台提供了统一的物流管理服务，例如，淘宝的菜鸟物流宝平台等，这种模式一般会称为“4PL”，所谓的4PL也就是，交易平台可以通过采购等方式与物流服务提供商(例如，“日日顺”等)达成合作关系，这样，交易平台可以将其物流服务(包括仓储服务，配送服务等)包装成物流解决方案。然后商家可以订购交易平台提供的物流解决方案，这样，后续在有买家用户购买该商家的商品时，就可以通过这种物流解决方案中的各项物流资源提供具体的发货、配送等服务。在菜鸟体系下，一般将与菜鸟具有合作关系的物流服务提供商称为“CP”，为便于描述，下面以菜鸟及CP为例进行介绍。

在4PL模式下，CP一般可以在其内部部署ERP(企业资源管理)系统(为便于描述，可以简称为CP系统)，用于进行报文接收、处理等工作。买家用户在购买某商家的商品后，前端交易服务器可以将相关的交易订单发送到菜鸟服务器，此时，菜鸟服务器需要向关联的CP系统发送报文，包括发货指令等，CP根据接收到的发货指令进行具体的发货等后续的配送操作。可见，在实现的过程中，CP系统的稳定性是很重要的。

首先，对于商家或者卖家用户而言，CP系统的稳定性，关系着商家或者卖家对买家的承诺，比如时效产品，而且一个CP系统的稳定性也是卖家是否与CP合作的重要因素之一。

其次，对于平台内部应用而言，CP系统的稳定性及其重要，下发报文是通过PAC(Partner Access Center，网关平台)平台下发，如果下发CP失败，就会造成消息的堆积，影响集群的稳定性。也就是说，内部应用对CP的要求是信息不丢失，响应时间快。

为了能够更准确的控制发送到各个CP的订单量，尤其是在大型促销活动(例如双11等)期间，订单量非常大的情况下，避免出现信息丢失等情况，可以预先对CP进行压力测试，测试的目的就是确定出CP每秒能够处理的事物数、响应时间、失败率等信息。

在现有技术中有一些压力测试产品，但是，用这些现有的产品进行压力测试时，得到的测试结果往往并不准确。例如，传统的压力测试产品往往都是单点系统，也即只有一台用于生成报文的服务器，这会使得压力受到限制；另外，传统产品中，用于产生压力的服务器与被测试系统通常会部署在同一机房内，无法增加网络耗时，或者只能产生非常小的网络耗时，无法逼真的模拟真实的场景。再者，CP自行进行测试的结果，测试脚本可能会由CP自己的技术人员写脚本，生成测试报文时，一般也是使用伪造的数据重复生成多条报文，最后再由CP将测试结果报告给菜鸟平台，这会导致测试的可靠性以及测试结果可信性程度不高。

发明内容

本申请提供了系统压力测试方法及装置，能够更好地模拟真实的业务场景，使得测试结果更加可靠。

本申请提供了如下方案：

一种系统压力测试方法，包括：

测试平台总控服务器接收物流服务方客户端的压力测试请求，所述请求中携带有测试相关参数信息，所述测试相关参数信息包括：待测试的单位时间段内的订单数量、物流服务方所在位置以及测试场景；

根据所述测试相关参数信息确定压力并发数；

将所述测试相关参数信息以及所述压力并发数发送到预置的测试集群，由所述测试集群根据所述测试相关参数以及预置的脚本生成测试报文，以便按照所述压力并发数，将所述测试报文发送到所述物流服务方的业务系统；

收集测试过程中产生的性能数据，并通过与性能指标进行比对，得到测试结果。

一种系统压力测试方法，包括：

测试集群接收总控服务器发送的测试相关参数信息以及压力并发数，其中，所述测试相关参数是所述总控服务器从接收到的压力测试请求中提取的，包括待测试的单位时间段内的订单数量、物流服务方服务器所在位置以及测试场景；所述总控服务器根据所述测试相关参数信息确定出所述压力并发数；

根据所述测试相关参数以及预置的脚本生成测试报文；

按照所述压力并发数，将所述测试报文发送到预置的网关平台，以便由所述网关平台将所述测试报文路由到所述物流服务方，所述物流服务方对所述测试报文进行解析处理，所述总控服务器收集测试过程中产生的性能数据，并通过与所述性能指标进行比对，得到测试结果。

一种系统压力测试方法，包括：

测试平台客户端接收物流服务方提交的压力测试请求，所述请求中携带有测试相关参数信息，所述测试相关参数信息包括：待测试的单位时间段内的订单数量、物流服务方标识以及测试场景；

将所述压力测试请求转发到总控服务器，以便所述总控服务器根据所述测试相关参数信息确定压力并发数，并将所述测试相关参数信息以及所述压力并发数发送到预置的测试集群，由所述测试集群根据所述测试相关参数以及预置的脚本生成测试报文，以便按照所述压力并发数，将所述测试报文发送到所述物流服务方的业务系统；

收集测试过程中产生的性能数据；

将收集到的性能数据提交到所述总控服务器，以便所述总控服务器通过与性能指标进行比对，得到测试结果。

一种系统压力测试装置，应用于测试平台总控服务器，包括：

请求接收单元，用于接收物流服务方客户端的压力测试请求，所述请求中携带有测试相关参数信息，所述测试相关参数信息包括：待测试的单位时间段内的订单数量、物流服务方所在位置以及测试场景；

压力并发数确定单元，用于根据所述测试相关参数信息确定压力并发数；

信息发送单元，用于将所述测试相关参数信息以及所述压力并发数发送到预置的测试集群，由所述测试集群根据所述测试相关参数以及预置的脚本生成测试报文，以便按照所述压力并发数，将所述测试报文发送到所述物流服务方的业务系统；

性能数据收集单元，用于收集测试过程中产生的性能数据，并通过与性能指标进行比对，得到测试结果。

一种系统压力测试装置，应用于测试集群，包括：

参数信息接收单元，用于接收总控服务器发送的测试相关参数信息以及压力并发数，其中，所述测试相关参数是所述总控服务器从接收到的压力测试请求中提取的，包括待测试的单位时间段内的订单数量、物流服务方服务器所在位置以及测试场景；所述总控服务器根据所述测试相关参数信息确定出所述压力并发数；

报文生成单元，用于根据所述测试相关参数以及预置的脚本生成测试报文；

报文发送单元，用于按照所述压力并发数，将所述测试报文发送到预置的网关平台，以便由所述网关平台将所述测试报文路由到所述物流服务方，所述物流服务方对所述测试报文进行解析处理，所述总控服务器收集测试过程中产生的性能数据，并通过与所述性能指标进行比对，得到测试结果。

一种系统压力测试装置，应用于测试平台客户端，包括：

测试请求接收单元，用于接收物流服务方提交的压力测试请求，所述请求中携带有测试相关参数信息，所述测试相关参数信息包括：待测试的单位时间段内的订单数量、物流服务方标识以及测试场景；

测试请求转发单元，用于将所述压力测试请求转发到总控服务器，以便所述总控服务器根据所述测试相关参数信息确定压力并发数，并将所述测试相关参数信息以及所述压力并发数发送到预置的测试集群，由所述测试集群根据所述测试相关参数以及预置的脚本生成测试报文，以便按照所述压力并发数，将所述测试报文发送到所述物流服务方的业务系统；

性能数据收集单元，用于收集测试过程中产生的性能数据；

性能数据提交单元，用于将收集到的性能数据提交到所述总控服务器，以便所述总控服务器通过与性能指标进行比对，得到测试结果。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，可以为物流服务方提供统一的压力测试平台，物流服务方只需要提交自己需要测试的相关参数并发起请求，测试平台主控服务器就可以计算出压力并发数，并发送到测试集群，进行脚本的解析生成测试报文，其中，测试集群中的脚本可以是测试平台的技术人员根据不同的物流服务方、不同的场景预先编写的，可以更好得模拟实际业务场景的真实情况，测试集群可以采用分布式方式部署，可以避免压力受到限制，并且可以更真实地模拟出网络延迟等情况，综合以上这些特点，可以使得对物流服务方的压力测试结果更加真实可靠，为在大型促销等活动下保证系统的稳定性提供了更有力的参考依据。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的第一方法的流程图；

图2是本申请实施例提供的第二方法的流程图；

图3是本申请实施例提供的第三方法的流程图；

图4是本申请实施例提供的第一装置的示意图；

图5是本申请实施例提供的第二装置的示意图；

图6是本申请实施例提供的第三装置的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，交易平台可以提供压力测试平台(例如，可以称为“cnperf”)，该压力测试平台可以采用服务器-客户端，或者服务器-浏览器的模式实现。其中，服务器部署于交易平台侧，而客户端则部署于各个物流服务方侧，或者，物流服务方也可以通过浏览器页面登录到压力测试平台服务器。通过客户端的用户界面或者浏览器页面，可以物流服务方可以进行相关测试参数的设置，以及发起压力测试请求。

压力测试平台的服务器按照功能可以分为总控服务器以及测试集群，其中，总控服务器主要用于与物流服务方的客户端进行交互，接收测试任务等。而测试集群则由多台服务器组成，可以采用分布式结构进行部署。测试平台的测试技术人员可以预先编写测试脚本，其中，测试脚本一般为多个，针对不同物流服务方的不同场景(仓报文下发、配报文下发等)，都可以编写不同的测试脚本。测试脚本可以保存在测试集群的各台服务器上。这样，总控服务器在接收到测试任务后，由测试集群解析测试脚本生成测试报文，这样，由于分布式集群的存在，测试压力不会受到限制。

测试集群生成的测试报文就是用于进行测试的报文，可以下发给物流服务方的ERP系统，由于测试集群部署在交易平台侧，因此，报文传输过程中自然会产生网络延迟，更接近于实际的真实情况。

下面对具体的实现方式进行详细介绍。

实施例一

参见图1，该实施例1首先从测试平台总控服务器的角度，提供了一种系统压力测试方法，该方法可以包括以下步骤：

S101：测试平台总控服务器接收物流服务方客户端的压力测试请求，所述请求中携带有测试相关参数信息，所述测试相关参数信息包括：待测试的单位时间段内的订单数量、物流服务方标识以及测试场景；

在测试平台的客户端，物流服务方可以对需要测试的相关参数进行设置，包括待测试的单位时间段内的订单数量(例如每天2万单，也即，测试的目的是：在每天接收2万个事务的情况下，该物流服务方ERP系统的各项性能指标是否能够满足要求)、物流服务方所在位置(例如北京)以及测试场景(例如仓报文下发、配报文下发等等)。

S102：根据所述测试相关参数信息确定压力并发数；

总控服务器在收到测试请求后，可以首先根据请求中携带的相关参数，确定出压力并发数，所谓压力并发数，也即每秒发送到物流服务方的报文数量。也就是说，假设确定出的压力并发数为800，则在后续生成测试报文后，每秒钟向物流服务方发送800个报文。

其中，具体确定压力并发数的方式可以有多种，例如，其中一种实现方式可以为：首先将测试相关参数代入预置的公式，计算出测试指标，其中，测试指标可以包括需达到的每秒处理的事务数量(TPS)、响应时间(RT)以及失败率。在计算出TPS后，可以将该TPS值确定为压力并发数。

需要说明的是，关于测试指标，可以是预先根据经验设置的，而在本申请实施例中，为了使得测试结果更接近物流服务方业务系统的实际情况，可以根据测试请求中携带的相关参数进行计算。在计算时，可以通过预先建立公式的方式，将单位时间段内的订单数量、物流服务方所在位置以及测试场景等作为输入参数，公式的输出参数即为前述各项测试指标。

其中，关于该公式，为了更接近于真实情况，可以预先对该物流服务方在线的实际订单数量以及测试场景下产生的实际TPS、RT以及失败率进行监控，然后，通过对监控所得的数据进行统计分析生成所述公式，统计分析的过程可以是根据正态分布进行计算，例如，可以计算出TPS＝sum/(10×3600)×3，其中，sum为订单数量；10×3600为有效时间，单位为秒，所谓有效时间也即实际操作的有效时长，由于一般工作人员的连续作业时间为10个小时，因此，这里将默有效时间默认设置为10小时；3为均值的系数，也是高峰系数，对于仓业务来说取值可以为3，配送业务来说取值可以为1，具体的取值可以根据实际业务来确定。

S103：将所述测试相关参数信息以及所述压力并发数发送到预置的测试集群，由所述测试集群根据所述测试相关参数以及预置的脚本生成测试报文，以便按照所述压力并发数，将所述测试报文发送到所述物流服务方的业务系统；

在确定出压力并发数后，主控服务器就可以将之前从测试请求中提取出的相关参数以及该压力并发数发送到测试集群，测试集群就可以根据测试相关参数以及预置的脚本生成测试报文，然后，就可以按照所述压力并发数，将测试报文发送到物流服务方的业务系统，物流服务方的业务系统通过解析并处理这些测试报文来进行测试。

其中，如前文所述，测试集群中保存的测试脚本有多个，对此，测试集群中还可以保存如表1所示的对应关系表：

表1

物流服务方标识	业务场景	脚本标识
			物流服务方甲	仓报文下发	脚本1
物流服务方甲	配报文下发	脚本2
			物流服务方乙	仓报文下发	脚本3
……	……	……

这样，在接收到主控服务器发送的测试相关参数后，可以从中提取出物流服务方标识、测试场景标识，进而可以确定出该物流服务方的该测试场景对应的测试脚本，然后基于该测试脚本生成测试报文。

关于通过解析测试脚本生成的测试报文，可以尽可能地模拟真实业务中生成的报文，每条测试报文中可以携带有不同的消息体，以便更全面地测试物流服务方业务系统的报文处理能力。例如，对于仓报文下发场景，生成第一条测试报文的消息体征包含一个商品对象，而第二条测试报文的消息体中可以是两个商品对象，等等，总之，通过消息体之间的差异，来更逼近实际的报文情况，使得测试的结果更加有效。

另外，在一些系统中，在实际在线执行业务时(也即实际的交易过程中，例如，买家用户下单了某商品对象，需要发送报文，指示物流服务方进行发货等等)，交易平台中的各应用产生的报文可能会通过一预置的网关平台路由到物流服务方，因此，在本申请实施例中，测试集群产生的测试报文，也可以先发送到该网关平台，再由网关平台路由到物流服务方业务系统，这样可以更逼真的模拟真实业务场景，使得测试结果更加可靠。

S104：收集测试过程中产生的性能数据，并通过与性能指标进行比对，得到测试结果。

物流服务方的业务系统在收到测试报文后，可以当作实际线上生成的报文来处理，在此过程中，测试平台主控服务器就可以收集测试过程中产生的性能数据，包括实际每秒处理的事务数量，实际的响应时间以及失败率等等，然后就可以与之前确定的性能指标进行比对，得出测试结果。其中，关于性能指标可以是预先根据经验等确定的，或者，还可以是根据步骤S102中所述的方式计算出来的。

需要说明的是，在具体实现时，可以预先确定压力测试的时间长度，例如可以设定为30分钟，也就是说，从测试开始时起，30分钟后就测试就可以停止，并收集相关的性能数据进行判断即可。关于得到的测试结果，一方面可以提供给测试平台的技术人员，技术人员可以据此帮助物流服务方分析可能存在的问题，并提供解决方案。或者，如果测试结果表明物流服务方在当前的测试单量以及压力并发数下，性能数据并不达标，则后续在具体的实际业务中，可以控制发送到该物流服务方的订单数量，以免出现订单丢失的情况，影响整个系统的稳定性。

如果物流服务方需要查看测试结果，还可以通过用户界面上的相关操作选项提交查看请求，相应的，测试平台主控服务器可以将测试结果通过发送电子邮件等方式发送给物流服务方。在完成一个业务场景的测试之后，还可以切换到其他业务场景进行测试。

可见，通过本申请实施例，可以为物流服务方提供统一的压力测试平台，物流服务方只需要提交自己需要测试的相关参数并发起请求，测试平台主控服务器就可以计算出压力并发数，并发送到测试集群，进行脚本的解析生成测试报文，其中，测试集群中的脚本可以是测试平台的技术人员根据不同的物流服务方、不同的场景预先编写的，可以更好得模拟实际业务场景的真实情况，测试集群可以采用分布式方式部署，可以避免压力受到限制，并且可以更真实地模拟出网络延迟等情况，综合以上这些特点，可以使得对物流服务方的压力测试结果更加真实可靠，为在大型促销等活动下保证系统的稳定性提供了更有力的参考依据。

实施例二

该实施例二是从测试集群的角度，提供了一种系统压力测试方法，参见图2，该方法可以包括以下步骤：

S201：测试集群接收总控服务器发送的测试相关参数信息以及压力并发数，其中，所述测试相关参数是所述总控服务器从接收到的压力测试请求中提取的，包括待测试的单位时间段内的订单数量、物流服务方服务器所在位置以及测试场景；所述总控服务器根据所述测试相关参数信息确定出所述压力并发数；

S202：根据所述测试相关参数以及预置的脚本生成测试报文；

S203：按照所述压力并发数，将所述测试报文发送到预置的网关平台，以便由所述网关平台将所述测试报文路由到所述物流服务方，所述物流服务方对所述测试报文进行解析处理，所述总控服务器收集测试过程中产生的性能数据，并通过与所述性能指标进行比对，得到测试结果。

其中，该实施例二与实施例一是相对应的，只是描述的角度有所不同，因此，相关的具体实现可以参见实施例一中的介绍，这里不再赘述。

实施例三

该实施例三是从测试平台客户端的角度，提供了一种系统压力测试方法，参见图3，该方法可以包括以下步骤：

S301：测试平台客户端接收物流服务方提交的压力测试请求，所述请求中携带有测试相关参数信息，所述测试相关参数信息包括：待测试的单位时间段内的订单数量、物流服务方标识以及测试场景；

S302：将所述压力测试请求转发到总控服务器，以便所述总控服务器根据所述测试相关参数信息确定压力并发数，并将所述测试相关参数信息以及所述压力并发数发送到预置的测试集群，由所述测试集群根据所述测试相关参数以及预置的脚本生成测试报文，以便按照所述压力并发数，将所述测试报文发送到所述物流服务方的业务系统；

S303：收集测试过程中产生的性能数据；

S304：将收集到的性能数据提交到所述总控服务器，以便所述总控服务器通过与性能指标进行比对，得到测试结果。

与实施例一相对应，本申请实施例还提供了一种系统压力测试装置，应用于测试平台总控服务器，参见图4，该装置可以包括：

请求接收单元401，用于接收物流服务方客户端的压力测试请求，所述请求中携带有测试相关参数信息，所述测试相关参数信息包括：待测试的单位时间段内的订单数量、物流服务方所在位置以及测试场景；

压力并发数确定单元402，用于根据所述测试相关参数信息确定压力并发数；

信息发送单元403，用于将所述测试相关参数信息以及所述压力并发数发送到预置的测试集群，由所述测试集群根据所述测试相关参数以及预置的脚本生成测试报文，以便按照所述压力并发数，将所述测试报文发送到所述物流服务方的业务系统；

性能数据收集单元404，用于收集测试过程中产生的性能数据，并通过与性能指标进行比对，得到测试结果。

具体实现时，该装置还可以包括：

性能指标计算单元，用于将所述测试相关参数信息带入预置的公式，计算出所述性能指标，所述性能指标包括需达到的每秒处理的事务数量TPS、响应时间RT以及失败率。

其中所述预置的公式通过以下方式建立：

监控单元，用于预先对该物流服务方在线的实际订单数量以及测试场景下产生的实际TPS、RT以及失败率进行监控；

统计分析单元，用于通过对监控所得的数据进行统计分析生成所述公式。

此时，所述压力并发数确定单元具体可以用于：

根据所述计算得到的性能指标中包括的TPS信息，确定压力并发数。

其中，所述压力测试集群生成的测试报文为多条，其中，各条测试报文中携带有不同的消息体。

所述测试集群按照所述压力并发数，将所述测试报文发送到预置的网关平台，由所述网关平台将所述测试报文路由到所述物流服务方。

与实施例二相对应，本申请实施例还提供了一种系统压力测试装置，应用于测试集群，参见图5，该装置可以包括：

参数信息接收单元501，用于接收总控服务器发送的测试相关参数信息以及压力并发数，其中，所述测试相关参数是所述总控服务器从接收到的压力测试请求中提取的，包括待测试的单位时间段内的订单数量、物流服务方服务器所在位置以及测试场景；所述总控服务器根据所述测试相关参数信息确定出所述压力并发数；

报文生成单元502，用于根据所述测试相关参数以及预置的脚本生成测试报文；

报文发送单于503，用于按照所述压力并发数，将所述测试报文发送到预置的网关平台，以便由所述网关平台将所述测试报文路由到所述物流服务方，所述物流服务方对所述测试报文进行解析处理，所述总控服务器收集测试过程中产生的性能数据，并通过与所述性能指标进行比对，得到测试结果。

与实施例三相对应，本申请实施例还提供了一种系统压力测试装置，应用于测试平台客户端，参见图6，该装置可以包括：

测试请求接收单元601，用于接收物流服务方提交的压力测试请求，所述请求中携带有测试相关参数信息，所述测试相关参数信息包括：待测试的单位时间段内的订单数量、物流服务方标识以及测试场景；

测试请求转发单元602，用于将所述压力测试请求转发到总控服务器，以便所述总控服务器根据所述测试相关参数信息确定压力并发数，并将所述测试相关参数信息以及所述压力并发数发送到预置的测试集群，由所述测试集群根据所述测试相关参数以及预置的脚本生成测试报文，以便按照所述压力并发数，将所述测试报文发送到所述物流服务方的业务系统；

性能数据收集单元603，用于收集测试过程中产生的性能数据；

性能数据提交单元604，用于将收集到的性能数据提交到所述总控服务器，以便所述总控服务器通过与性能指标进行比对，得到测试结果。

通过本申请实施例，可以为物流服务方提供统一的压力测试平台，物流服务方只需要提交自己需要测试的相关参数并发起请求，测试平台主控服务器就可以计算出压力并发数，并发送到测试集群，进行脚本的解析生成测试报文，其中，测试集群中的脚本可以是测试平台的技术人员根据不同的物流服务方、不同的场景预先编写的，可以更好得模拟实际业务场景的真实情况，测试集群可以采用分布式方式部署，可以避免压力受到限制，并且可以更真实地模拟出网络延迟等情况，综合以上这些特点，可以使得对物流服务方的压力测试结果更加真实可靠，为在大型促销等活动下保证系统的稳定性提供了更有力的参考依据。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的系统压力测试方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (16)

1.一种系统压力测试方法，其特征在于，包括：

测试平台总控服务器接收物流服务方客户端的压力测试请求，所述请求中携带有测试相关参数信息，所述测试相关参数信息包括：待测试的单位时间段内的订单数量、物流服务方所在位置以及测试场景；

根据所述测试相关参数信息确定压力并发数；

将所述测试相关参数信息以及所述压力并发数发送到预置的测试集群，由所述测试集群根据所述测试相关参数以及预置的脚本生成测试报文，以便按照所述压力并发数，将所述测试报文发送到所述物流服务方的业务系统；

收集测试过程中产生的性能数据，并通过与性能指标进行比对，得到测试结果。

2.根据权利要求1所述的方法，其特征在于，还包括：

将所述测试相关参数信息带入预置的公式，计算出所述性能指标，所述性能指标包括需达到的每秒处理的事务数量TPS、响应时间RT以及失败率。

3.根据权利要求2所述的方法，其特征在于，其中所述预置的公式通过以下方式建立：

预先对该物流服务方在线的实际订单数量以及测试场景下产生的实际TPS、RT以及失败率进行监控；

通过对监控所得的数据进行统计分析生成所述公式。

4.根据权利要求2所述的方法，其特征在于，所述根据所述测试相关参数信息确定压力并发数，包括：

根据所述计算得到的性能指标中包括的TPS信息，确定压力并发数。

5.根据权利要求1所述的方法，其特征在于，所述压力测试集群生成的测试报文为多条，其中，各条测试报文中携带有不同的消息体。

6.根据权利要求1所述的方法，其特征在于，所述测试集群按照所述压力并发数，将所述测试报文发送到预置的网关平台，由所述网关平台将所述测试报文路由到所述物流服务方。

7.一种系统压力测试方法，其特征在于，包括：

测试集群接收总控服务器发送的测试相关参数信息以及压力并发数，其中，所述测试相关参数是所述总控服务器从接收到的压力测试请求中提取的，包括待测试的单位时间段内的订单数量、物流服务方服务器所在位置以及测试场景；所述总控服务器根据所述测试相关参数信息确定出所述压力并发数；

根据所述测试相关参数以及预置的脚本生成测试报文；

按照所述压力并发数，将所述测试报文发送到预置的网关平台，以便由所述网关平台将所述测试报文路由到所述物流服务方，所述物流服务方对所述测试报文进行解析处理，所述总控服务器收集测试过程中产生的性能数据，并通过与所述性能指标进行比对，得到测试结果。

8.一种系统压力测试方法，其特征在于，包括：

测试平台客户端接收物流服务方提交的压力测试请求，所述请求中携带有测试相关参数信息，所述测试相关参数信息包括：待测试的单位时间段内的订单数量、物流服务方标识以及测试场景；

将所述压力测试请求转发到总控服务器，以便所述总控服务器根据所述测试相关参数信息确定压力并发数，并将所述测试相关参数信息以及所述压力并发数发送到预置的测试集群，由所述测试集群根据所述测试相关参数以及预置的脚本生成测试报文，以便按照所述压力并发数，将所述测试报文发送到所述物流服务方的业务系统；

收集测试过程中产生的性能数据；

将收集到的性能数据提交到所述总控服务器，以便所述总控服务器通过与性能指标进行比对，得到测试结果。

9.一种系统压力测试装置，其特征在于，应用于测试平台总控服务器，包括：

请求接收单元，用于接收物流服务方客户端的压力测试请求，所述请求中携带有测试相关参数信息，所述测试相关参数信息包括：待测试的单位时间段内的订单数量、物流服务方所在位置以及测试场景；

压力并发数确定单元，用于根据所述测试相关参数信息确定压力并发数；

信息发送单元，用于将所述测试相关参数信息以及所述压力并发数发送到预置的测试集群，由所述测试集群根据所述测试相关参数以及预置的脚本生成测试报文，以便按照所述压力并发数，将所述测试报文发送到所述物流服务方的业务系统；

性能数据收集单元，用于收集测试过程中产生的性能数据，并通过与性能指标进行比对，得到测试结果。

10.根据权利要求9所述的装置，其特征在于，还包括：

性能指标计算单元，用于将所述测试相关参数信息带入预置的公式，计算出所述性能指标，所述性能指标包括需达到的每秒处理的事务数量TPS、响应时间RT以及失败率。

11.根据权利要求10所述的装置，其特征在于，其中所述预置的公式通过以下方式建立：

监控单元，用于预先对该物流服务方在线的实际订单数量以及测试场景下产生的实际TPS、RT以及失败率进行监控；

统计分析单元，用于通过对监控所得的数据进行统计分析生成所述公式。

12.根据权利要求10所述的装置，其特征在于，所述压力并发数确定单元具体用于：

根据所述计算得到的性能指标中包括的TPS信息，确定压力并发数。

13.根据权利要求9所述的装置，其特征在于，所述压力测试集群生成的测试报文为多条，其中，各条测试报文中携带有不同的消息体。

14.根据权利要求9所述的装置，其特征在于，所述测试集群按照所述压力并发数，将所述测试报文发送到预置的网关平台，由所述网关平台将所述测试报文路由到所述物流服务方。

15.一种系统压力测试装置，其特征在于，应用于测试集群，包括：

参数信息接收单元，用于接收总控服务器发送的测试相关参数信息以及压力并发数，其中，所述测试相关参数是所述总控服务器从接收到的压力测试请求中提取的，包括待测试的单位时间段内的订单数量、物流服务方服务器所在位置以及测试场景；所述总控服务器根据所述测试相关参数信息确定出所述压力并发数；

报文生成单元，用于根据所述测试相关参数以及预置的脚本生成测试报文；

报文发送单元，用于按照所述压力并发数，将所述测试报文发送到预置的网关平台，以便由所述网关平台将所述测试报文路由到所述物流服务方，所述物流服务方对所述测试报文进行解析处理，所述总控服务器收集测试过程中产生的性能数据，并通过与所述性能指标进行比对，得到测试结果。

16.一种系统压力测试装置，其特征在于，应用于测试平台客户端，包括：

测试请求接收单元，用于接收物流服务方提交的压力测试请求，所述请求中携带有测试相关参数信息，所述测试相关参数信息包括：待测试的单位时间段内的订单数量、物流服务方标识以及测试场景；

测试请求转发单元，用于将所述压力测试请求转发到总控服务器，以便所述总控服务器根据所述测试相关参数信息确定压力并发数，并将所述测试相关参数信息以及所述压力并发数发送到预置的测试集群，由所述测试集群根据所述测试相关参数以及预置的脚本生成测试报文，以便按照所述压力并发数，将所述测试报文发送到所述物流服务方的业务系统；

性能数据收集单元，用于收集测试过程中产生的性能数据；

性能数据提交单元，用于将收集到的性能数据提交到所述总控服务器，以便所述总控服务器通过与性能指标进行比对，得到测试结果。