CN106487603B - 一种响应测试方法及装置 - Google Patents

Abstract

本发明公开了一种响应测试方法及装置，该方法包括：测试平台接收被测系统发送的测试请求消息，其中，所述测试平台用于模拟与所述被测系统进行信息交互的业务系统，根据所述测试请求消息，在预先保存的历史响应消息中，确定与所述测试请求消息相匹配的历史响应消息，根据确定出的历史响应消息，对所述被测系统进行测试。本方法采用测试平台的方式模拟与该业务系统属于同一业务流程且进行信息交互的其他业务系统，这样的方式无需模拟全部业务流程，只需模拟与被测系统进行信息交互的业务系统，有效简化了测试过程，提升测试消息，此外，采用历史响应消息的方式，使得测试过程更贴合真实运行环境，得到准确的测试数据。

Description

一种响应测试方法及装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种响应测试方法及装置。

背景技术

随着信息技术的发展，网络服务商后台的服务系统可以为用户提供各类丰富的业务服务。业务服务的顺利实现，依赖于服务系统内部不同的业务系统的协同工作。

例如：在实际应用中，网站为用户提供一种登录业务，用户可以使用自身的用户信息登录至该网站中，从而用户可以获得该网站提供的丰富网络服务。在此场景中，该网站便可以看作一种服务系统，其中该网站中包含的登录系统和校验系统就是该网站中的两种业务系统，若用户使用自身的用户信息进行登录时，登录系统就会生成相应的登录业务，并将该登录业务的业务信息(包括：账户名、账户密码等)发送至校验系统中，以完成对登录业务的校验操作，校验系统会将校验结果反馈给登录系统，从而登录系统完成一整套登录业务的流程。显然，一次登录业务由登录系统和校验系统共同实现。

目前，网络服务商为了保证其业务服务在实际应用时能够正常运行，通常会对后台的各业务系统进行仿真测试，以检验不同业务系统的运算性能和负载能力。在仿真测试的过程中，会模拟真实场景下不同业务系统之间的交互。也就是说，目前的测试方式针对于任一种业务服务，会以真实场景为基准，部署一套完整的业务流程(包括参与该业务服务的所有业务系统)和测试数据(其中，业务流程是指一项完整的业务服务，在不同的业务系统之间的执行流程；测试数据是指在测试过程中，部署在参与测试的每一业务系统中的仿真数据)，以此测试不同业务系统在不同运行负荷下的状态。

然而对于目前的测试方式而言，针对每一种业务服务，都需要部署完整的业务流程，并调用多个业务系统以完成测试，测试过程较为繁琐，尤其在需要对多种业务服务进行测试的场景下，若采用这样的测试方式，将影响测试效率。

现有技术中，为了解决上述测试方式的缺陷，提出如下测试方式：

一种测试方式为：在测试过程中，只针对一个业务系统单独部署测试数据，同时去除该业务系统与相关的其他业务系统之间的业务链路(也就去除了业务流程)，从而对该业务系统进行“封闭”式的测试，这样就可以大大简化测试过程，提升测试的效率。

例如：在登录业务中，实际应用时需要登录系统和校验系统共同完成，假设按照现有技术中的上述测试方式，若针对登录系统进行测试，那么，只会在登录系统中部署用户数据作为测试数据，同时，略去该登录系统与验证系统之间交互的业务流程，从而形成了针对登录系统的“封闭”式的测试环境。由于原本向校验系统发送登录业务信息、并接收校验系统反馈的校验结果的业务流程被省略掉，那么，在测试过程中，登录系统就会根据用户数据只执行登录操作。

但显然，结合上例可以看出，在第一种测试方式下，由于略去了登录系统(也即被测系统)与校验系统之间的业务链路，登录系统直接根据用户数据执行登录操作，不再向校验系统发送校验请求，这样的测试结果与实际应用并不相符，导致测试结果的参考价值较低。

另一种方式为：根据人工经验，设置不同业务系统之间的响应时间，以此来测试被测系统在不同的响应时间下的运行状态。

例如：以上例进行说明，在测试过程中，登录系统将向校验系统发出校验请求，假设人工设定校验系统的响应时间为10s，那么，校验系统接收到了登录系统发送的校验请求后，将延迟10s后才向登录系统反馈校验结果，从而，将在校验系统延迟10s返回响应的情况下，测试登录系统的运行状态。

但是，在第二种测试方式下，由于是人工根据经验设置不同业务系统的响应时间，其设定的响应时间可能出现差错，例如：在实际应用时的正常情况下，登录系统将向校验系统发出校验请求，通常校验系统需要5ms后做出响应并反馈校验结果，当超过2s后登录系统仍未接收到校验系统的响应，则登录系统将取消本次校验。显然，人工设置的10s的响应时间，已超出登录系统的最长等待时间，而在测试过程中，被测系统将根据人工设置的响应时间进行等待，也就是说，在超出被测系统内部最长等待时间(2s)的延时过程中，被测系统中用来与校验系统进行通讯的组件，在后续的8s内无法运行，只能处于等待状态，这也将消耗被测系统中的处理资源，那么，这样的测试结果与实际运行的状态可能不符，导致测试结果准确性较低。

发明内容

本发明实施例提供一种响应测试方法及装置，用以解决现有的测试方法对业务系统的响应测试的准确性较低的问题。

本发明实施例提供的一种响应测试方法，包括：

测试平台接收被测系统发送的测试请求消息；其中，所述测试平台用于模拟与所述被测系统进行信息交互的业务系统；

根据所述测试请求消息，在预先保存的历史响应消息中，确定与所述测试请求消息相匹配的历史响应消息；

根据确定出的历史响应消息，对所述被测系统进行测试。

本发明实施例另提供的一种响应测试方法，包括：

被测系统向测试平台发送测试请求消息，使所述测试平台确定与所述测试请求消息相匹配的历史响应消息，并根据所述历史响应消息向所述被测系统返回测试响应消息；

接收由所述测试平台返回的测试响应消息，并对所述测试响应消息进行测试处理。

本发明实施例提供的一种响应测试装置，包括：

接收模块，用于接收被测系统发送的测试请求消息；

确定模块，用于根据所述测试请求消息，在预先保存的历史响应消息中，确定与所述测试请求消息相匹配的历史响应消息；

响应测试模块，根据确定出的历史响应消息，对所述被测系统进行测试。

本发明实施例还提供的一种响应测试装置，包括：

发送模块，用于向测试平台发送测试请求消息，使所述测试平台确定与所述测试请求消息相匹配的历史响应消息，并根据所述历史响应消息向所述被测系统返回测试响应消息；

接收模块，用于接收由所述测试平台返回的测试响应消息，并对所述测试响应消息进行测试处理。

本发明实施例提供一种响应测试方法及装置，通过本申请的方法，针对任一被测试的业务系统，采用测试平台的方式模拟与该业务系统属于同一业务流程且进行信息交互的其他业务系统，当测试平台接收到被测系统发送的测试请求消息后，将根据实际应用时的历史响应消息，确定与测试请求消息相匹配的响应结果，并将响应结果返回至被测系统，从而实现对被测系统的测试，这样的方式无需模拟全部业务流程，只需模拟与被测系统进行信息交互的业务系统，有效简化了测试过程，提升测试消息，此外，采用历史响应消息的方式，使得测试过程更贴合真实运行环境，得到准确的测试数据。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本发明的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为本发明实施例提供的测试平台侧的响应测试过程示意图；

图2为本发明实施例提供的被测系统侧的响应测试过程示意图；

图3为本发明实施例提供的测试平台侧的响应测试装置结构示意图；

图4为本发明实施例提供的被测系统侧的响应测试装置结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明具体实施例及相应的附图对本发明技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

若在测试过程中，只针对一个业务系统进行测试，同时只仿真与该业务系统进行了信息交互的其他业务系统，那么，不仅可以简化测试过程、提升测试效率，而且还保证了测试环境的真实性，提升测试结果的准确性。正是基于此，本申请提供了下述方法，如图1所示。

其中，图1为本发明实施例提供的响应测试过程，该过程具体包括以下步骤：

S101，测试平台接收被测系统发送的测试请求消息；其中，所述测试平台用于模拟与所述被测系统进行信息交互的业务系统。

正如前述，在实际应用中，一项业务服务是由多个业务系统基于该业务服务的业务流程协同完成的，对于同一业务流程中的不同业务系统而言，都需要与该业务流程中的至少一个其他业务系统进行信息交互，例如前述的登录系统，其会与校验系统进行信息交互。那么，若要对业务流程中的任一业务系统进行测试，则可以模拟与该业务系统进行信息交互的业务系统，而无需模拟完整的一套业务流程。这样的方式仿真测试方式既保证了与实际应用场景的一致性，也简化了测试过程。

基于此，在本申请实施例中，所述的被测系统就是进行测试的一个业务系统。所述的测试平台就是用于模拟与所述被测系统进行信息交互的业务系统。例如：可将上例中的登录系统作为被测系统，相应地，通过测试平台仿真模拟校验系统。在实际应用场景下，登录系统接收到了用户信息后，就会将用户信息发送给校验系统进行校验，并根据校验系统返回的校验结果，执行相应的登录操作，登录系统向校验系统发送的用户信息通常携带在校验请求中。在测试场景中，校验请求也就是本申请实施例中的测试请求消息(测试请求消息中包含相应的测试数据)。所以，所述的测试请求消息，可认为是被测系统向与其有信息交互的业务系统发送的业务请求消息，用于获得相应的业务响应。在本申请实施例中的一种可选方式下，测试请求消息中携带有被测系统所要调用的接口、请求的业务数据等信息，这里并不构成对本申请的限定。

需要说明的是，本申请中所述的测试平台，可以由具有模拟测试功能的服务器或者服务器集群构成，在实际应用场景中，不同的测试人员可以将不同业务系统的测试数据发布在测试平台中，这样一来，就可以对服务系统中的任意业务信息进行相应的测试，而且所述的测试平台是一种公开化的测试平台，也即，对于任一测试人员，均可以在该测试平台上发布自己所需的测试数据，也可以调用其他测试人员发布的测试数据。

S102，根据所述测试请求消息，在预先保存的历史响应消息中，确定与所述测试请求消息相匹配的历史响应消息。

在实际应用场景下，对于同一业务流程中的业务系统而言，当业务系统接收到了其他业务系统发送的业务请求消息后，会根据该业务请求消息进行相应的处理，并返回响应结果。而在测试过程中，被测系统所发出的测试请求消息，与实际应用中的业务请求消息通常是一致的，那么，测试平台就可以根据实际应用中业务系统反馈的信息来确定出将要反馈的信息。

例如：在实际应用中，校验系统接收到登录系统发送的携带有用户信息的校验请求，校验系统就会对接收到的用户信息进行校验，并向登录系统反馈校验结果。那么，在测试场景中，若以登录系统作为被测系统，测试平台模拟校验系统，当测试平台接收到被测系统发送的测试请求消息(此时的测试请求消息中含有用于进行测试的用户信息)后，就可以根据该测试请求消息，确定出要向被测系统反馈校验结果。

上例中只示出了测试过程中的一种情况，在进行测试时，测试平台可以针对不同被测系统发送的测试请求消息进行响应，而所有的被测系统，都是真实的业务系统，其发送的测试请求都可看作实际应用中的业务请求消息，那么，在测试过程中，当测试平台接收到了测试请求消息后，也就可以根据实际应用中的业务响应来确定测试请求消息对应的响应结果。

所以，在本申请实施例中，测试平台中预先保存了实际应用中的业务响应，也即，上述的历史响应消息。从而，当测试平台接收到了测试请求消息后，就可以确定出测试请求消息相匹配的历史响应消息。正如上例中，模拟校验系统的测试平台，在接收到登录系统发送的测试请求消息后，就可以确定出与该测试请求消息相匹配的校验结果。本申请实施例中的历史响应消息，通常是由不同的测试人员预先发布在测试平台中，这里并不构成对本申请的限定。

需要说明的是，历史响应消息只是进行响应的业务系统向发出业务请求的业务系统所反馈的业务结果，如：上例中校验系统向登录系统反馈“校验通过”或“校验未通过”两种校验结果。换言之，测试平台中无需对测试请求消息进行复杂的运算处理，而是直接根据测试请求消息，确定出与测试请求消息相匹配的历史响应消息。可见，这样的方式可以有效地减少测试过程的复杂程度。

S103，根据确定出的历史响应消息，对所述被测系统进行测试。

测试平台确定与测试请求消息相匹配的历史响应消息后，便会根据历史响应消息，向被测系统反馈相应的响应消息，在被测系统接收到了测试平台反馈的响应消息后，就将对响应消息进行处理，那么，也就可以测试被测系统在接收到响应消息后的运行状态。

需要说明的是，本申请中的测试方式，就是模拟与被测的业务系统进行信息交互的外部系统，并根据被测系统的请求做出相应的响应，进而测试被测的业务系统接收到响应后的运行状态。

通过上述方法，针对任一被测试的业务系统，采用测试平台的方式模拟与该业务系统属于同一业务流程且进行信息交互的其他业务系统，当测试平台接收到被测系统发送的测试请求消息后，将根据实际应用时的历史响应消息，确定与测试请求消息相匹配的响应结果，并将响应结果返回至被测系统，从而实现对被测系统的测试，这样的方式无需模拟全部业务流程，只需模拟与被测系统进行信息交互的业务系统，有效简化了测试过程，提升测试消息，此外，采用历史响应消息的方式，使得测试过程更贴合真实运行环境，得到准确的测试数据。

在实际应用中，对于测试平台而言，不同的测试人员可以针对要进行测试的被测系统，将相应的仿真代码发送至测试平台中，测试平台经过动态编译后，就会将仿真代码转换成运行在测试平台中的服务或进程。从而，在测试时，测试平台接收到被测系统的测试请求消息后，相应的服务或进程就会对测试请求消息进行处理，并向被测系统返回响应结果。其中，仿真代码中包含测试过程中需要返回至被测系统的响应消息。

而返回至被测系统的响应消息是由历史响应消息确定的，也就是说，只有在获知测试请求消息匹配的历史响应消息后，向被测系统返回的响应消息才更贴合真实场景。正如前述示例中，校验系统向登录系统返回两种校验结果“校验通过”、“校验未通过”，这两种校验结果就是历史响应消息，那么，在确定了历史响应消息后，在测试过程中，测试平台只需向被测的登录系统返回其中一种校验结果(也即响应消息)即可进行测试。

从上述内容中可见，测试平台接收到测试请求消息后，将首先确定与测试请求消息相匹配的历史响应消息，也即，执行上述步骤S102。在本申请实施例中，上述步骤S102，根据所述测试请求消息，在预先保存的历史响应消息中，确定与所述测试请求消息相匹配的历史响应消息，具体为：确定所述测试请求消息对应的业务类型，根据确定出的所述业务类型，在所述测试平台预先保存的历史响应消息中，查找与所述业务类型相匹配的历史响应消息，将查找到的历史响应消息确定为与所述测试请求消息相匹配的历史响应消息。

不同的测试请求消息通常对应着不同的业务类型，例如：若被测系统是登录系统，测试平台模拟校验系统，那么，被测系统向测试平台发送的测试请求消息所对应的业务类型，就属于登录业务中的安全校验请求；又例如：若被测系统是交易系统，测试平台模拟支付系统，被测系统向测试平台发送的测试请求消息所对应的业务类型，就属于支付业务中的支付请求。在实际应用中，测试平台可以根据测试请求消息中携带的某些标识信息，来确定出测试请求消息对应的业务类型。

其中，测试请求消息中携带的标识信息，可以是业务类型标识、所要调用的接口标识、所要调用的服务标识等信息，通过这些信息，便可以确定出测试请求消息所属的业务类型。这里并不构成对本申请的限定。

在确定出测试请求消息所属的业务类型后，也就可以根据确定出的业务类型，查找出对应业务类型的历史相应消息。延续上例，当确定了测试请求消息对应的业务类型为登录业务中的安全校验请求，那么，就可以查找登录业务中的校验结果(此时的校验结果就是历史响应消息)；同样，当确定了测试请求消息对应的业务类型为支付业务中的支付请求，那么，就可以查找支付业务中的支付结果(此时的支付结果就是历史响应消息)。

经过上述过程，确定出了测试请求消息相匹配的历史响应消息，也就可以对测试系统进行测试。在本申请实施例中，提出了不同的响应测试方式，下面将对这些响应测试方式进行详细说明。

一、基于响应时间的响应测试

针对该方式，需要说明的是：考虑到实际应用场景下，业务流程中的某一业务系统向另一业务系统发送了业务请求后，接收业务请求的系统通常需要对业务请求进行处理，才能返回响应结果，也就是说，发出业务请求的业务系统需要等待一定时间后，才会接收到另一业务系统返回的响应结果，在这个过程中，发出业务请求的业务系统需要维持该业务的等待状态。而实际应用时，大量的用户会使用服务系统中的不同业务服务，那么，业务系统中将不断地有大量的业务生成，也即，在发出业务请求的业务系统中，也在不断地生成新的业务，如果该业务系统中的部分业务仍处于等待状态(还未接收到另一业务系统的响应)，这些处于等待状态的业务将占用该业务系统中的处理资源(如：进入等待状态的业务占用相应的处理线程，未接收到另一业务系统的响应，这些线程就无法释放)，这样依赖，新产生的业务也将不断地消耗业务系统中的处理资源，使得该业务系统的处理负荷增加。

可见，如果响应时间越长，对于发送业务请求的业务系统而言，其处理负荷就会逐渐增大，所以，就可以采用这样的方式对业务系统进行测试，以检测其处理性能。

因此，在本方式中，根据确定出的历史响应消息，对所述被测系统进行测试，具体为：根据确定出的历史响应消息，确定历史响应时间，根据确定出的所述历史响应时间，对所述被测系统进行测试。

其中，所述的历史响应时间，是在实际应用中统计得到的不同历史响应消息的实际的响应时间。考虑到在实际应用中，不同的历史响应时间，其对应的历史响应时间的差异可能较大。例如：对于登录业务中的校验系统而言，其返回的校验结果通常是固定的，假设为5ms或6ms。而在支付业务中，支付系统向银行系统请求支付，银行系统返回响应的时间可能并不固定，将受到银行系统的运行状态的影响，可能是1s，3s、6s、10s……等不固定的时间，也就是说，银行系统的响应时间是随机的。

这样一来，在该方式下，历史响应时间就分为固定和随机两种情况。

第一种情况，历史响应时间为固定的响应时间。可以认为，固定的历史响应时间是可以具体确定的，其数量并不会过多，正如上例中校验系统所返回的响应时间为5ms或6ms，可见，该响应时间就是固定为5ms或6ms。故在这种情况下，根据确定出的所述历史响应时间，对所述被测系统进行测试，具体为：当不同的历史响应时间的数量小于预设阈值时，从确定出的各历史响应时间中任选择一个历史响应时间，等待与所述历史响应时间相等的时长后，向被测系统返回测试响应消息，并测试所述被测系统接收到测试响应消息后的状态。

这里的预设阈值是划分历史响应时间为固定或为随机的标准，通常可以根据对实际的响应时间进行统计后得到，这里确定预设阈值的过程并不构成对本申请的限定。固定的历史响应时间的数量至少为一个，如果多于一个，则在测试过程中，将选择其中的一个固定的历史响应时间作为测试时的响应时间。

例如：在对登录业务的测试过程中，由被测的登录系统发出的测试请求消息所对应的历史响应时间如前所述，即为5ms或6ms，此时，假设测试平台选择6ms作为测试时的响应时间，从而，测试平台在接收到了测试请求消息后，将等待6ms后，向被测的登录系统返回响应消息，以此测试登录系统的运行状态。

需要说明的是，在实际测试时，在被测的登录系统中将不断地生成大量的测试请求消息，且不断地发送至测试平台，测试平台会对其接收到的各测试请求消息，分别等待6ms后发出响应。这样便可以准确地测试出登录系统的性能。当然，上述方式只是本申请实施例中的一种示例，并不作为对本申请的限定。

第二种情况，历史响应时间为随机的响应时间。随机的历史响应时间难以具体确定，正如上例中银行系统所返回的响应时间并不固定，在一定的范围之内波动。故在这种情况下，根据确定出的所述历史响应时间，对所述被测系统进行测试，具体为：当不同的历史响应时间的数量不小于预设阈值时，根据确定出的各历史响应时间确定时间区间，随机确定落入所述时间区间内的等待时间，等待与随机确定的所述等待时间相等的时长后，向被测系统返回测试响应消息，并测试所述被测系统接收到测试响应消息后的状态。

当历史响应时间的数量超过预设阈值时，就表示历史响应时间的数量过多，属于随机的响应时间。此时，便可以确定出由随机的历史响应时间构成的时间区间，并以该时间区间中的时间作为响应时间。

例如：银行系统的响应时间从1s至13s不等，从而，可将时间区间确定为[1s，13s]，那么，在对银行卡支付业务的测试过程中，测试平台模拟银行系统，当测试平台接收到被测的支付系统发送的测试请求消息后，就可以将该时间区间中的时间作为等待时间，也即，随机在该时间区间中任选一个等待时间，假设选择的等待时间为8s，则测试平台接收到每一测试请求消息后，都会等待8s后再向被测的支付系统返回响应消息。

需要说明的是，作为本申请实施例中的一种可选方式，在测试过程中，将分别选择时间区间中的每一等待时间进行测试，这样可以获得更加充分的测试结果。此外，可根据实际测试的需要确定时间区间，如：在上例中，只以3s～10s的时间范围确定为时间区间。当然，这里并不构成对本申请的限定。

以上内容是仅基于历史响应时间的测试方式，在实际测试时，也可以基于真实的实际场景进行响应测试，也即，下述方式：

二、基于包含请求数量和响应时间的实际场景的响应测试

在该方式下，测试过程将模拟实际场景中的运行过程。而在实际场景的运行过程中，有两个因素将影响业务系统的运行状态，也即，请求数量和响应时间。请求数量或响应时间的增加，都会增加业务系统的运行负载，那么，在测试时，就可以将请求数量或响应时间作为测试的参数。

例如：以交易业务为例，交易业务由交易系统和支付系统共同完成。假设某历史时间段中，交易系统所处理的交易业务的数量为1W。现对交易系统进行测试，那么，就可以模拟上述时间段中交易系统处理的交易业务的数量和相应的每一笔交易业务的历史响应时间，以此来测试交易系统的运行状态。

那么，作为该方式下的一种情况，所述测试平台接收到的测试请求消息为多个测试请求消息；根据确定出的历史响应消息，对所述被测系统进行测试，具体为：针对接收到的每个测试请求消息，从根据该测试请求消息确定出的各历史响应消息中选择一个未选择过的历史响应消息，确定选择的该历史响应消息对应的历史响应时间，并等待与该历史响应时间相等的时长后，将选择的该历史响应消息返回给所述被测系统，并测试所述被测系统接收到该历史响应消息后的状态。

具体而言，正如前例所述，被测系统就是交易系统，测试平台模拟支付系统，对上述的实际场景进行测试时，将模拟1W笔交易业务，由被测的交易系统向测试平台发送测试请求消息，同时，测试平台按照实际场景中的历史响应时间，返回响应信息，换言之，以其中的两笔交易业务A和B为例，假设在实际场景中，支付系统针对交易业务A和B返回的历史响应消息分别为a’和b’，且各自的历史响应时间分别为0.6s和0.9s，那么在测试时，假设交易业务A和B的测试请求消息分别为a和b，被测的交易系统向测试平台发送测试请求消息a和b后，测试平台将等待0.6s后向被测的交易系统返回响应消息a’，等待0.9s后向被测的交易系统返回响应消息b’。

上述情况将测试真实场景下，交易系统的运行状态，如果在测试过程中交易系统正常运行，那么，可以认为在后续的实际使用中，交易系统也能够正常运行。但是，使用上述的交易业务的数量进行测试时，由于业务数量是历史时间段中的交易业务的数量，可能在后续的实际应用中，将产生更大的交易业务数量，也就是说，交易系统在这样的交易业务数量下正常运行，并不能反映交易系统的最大承载负荷和性能极限，所以，可以在测试过程中增加交易业务的数量进行测试。交易业务的数量越多，交易系统向支付系统发送的业务请求也就越多，所以在测试过程中，可以调节测试请求消息的数量。

因此，在本方式的另一种情况下，根据确定出的历史响应消息，对所述被测系统进行测试，具体为：根据确定出的历史响应消息，确定基准等待时间，根据已经向所述被测系统返回的测试响应消息的数量，确定延迟系数，其中，已经向所述被测系统返回的测试响应消息的数量越多，所述延迟系数越大；将所述基准等待时间与所述延迟系数的乘积确定为实际等待时间，等待与所述实际等待时间相等的时长后，向被测系统返回测试响应消息，并测试所述被测系统接收到测试响应消息后的状态。

这种情况下，将不断地增加测试请求消息的数量，直到被测的业务系统出现问题为止。

需要说明的是，任意业务系统的处理能力都是有限的，当业务系统处理的业务数量越多时，其响应时间会越来越长。在本申请实施例中，在实际场景中，可以针对各业务系统所处理的业务数量和其响应时间进行统计，从而可以得到一种业务数量和响应时间之间的对应关系。该对应关系可以是诸如指数、正比等线性关系，这里并不做具体限定。而在上述的对应关系中，通常有基准时间，基准时间通常是跟随业务数量进行增长前的响应时间。根据该对应关系，可确定出相应的延迟系数，进而再根据延迟系数和基准时间，就可以确定出不同数量的测试响应消息对应的实际等待时间。

例如：延续上例，假设测试平台在向被测的交易系统反馈了1W条响应消息的情况下，被测的交易系统仍能够正常运行，假设在数据量为1W的情况下，测试平台的基准等待时间为2s(该基准等待时间可以是这1W条响应信息的平均响应时间)，那么，就可以增加测试响应消息的数量，假设增加5K条(测试请求消息的数量也增加5K条)，且每增加5K条测试响应消息，延迟系数就增加0.2，那么，此时的延迟系统变为1.2，也即，测试平台的实际等待时间为2s*1.2＝2.4s。所以，对于新增的5K条测试响应消息，测试平台对每一条测试响应消息等待2.4s后再向被测的交易系统返回。

通过这种方式可以测试出被测的业务系统的性能极限，而且，测试结果的准确性高，从而能够帮助测试人员了解每个业务系统的性能数据。

以上内容是测试平台侧的测试过程，而对于被测系统而言，本申请实施例中还提供一种响应测试方法，如图2所示，包括：

S201，被测系统向测试平台发送测试请求消息，使所述测试平台确定与所述测试请求消息相匹配的历史响应消息，并根据所述历史响应消息向所述被测系统返回测试响应消息。

本实施例中的测试平台就是上述内容中的测试平台，故在此不做过多赘述。

S202，接收由所述测试平台返回的测试响应消息，并对所述测试响应消息进行测试处理。

此外，对于被测系统而言，测试系统模拟了与该被测系统进行信息交互的业务系统，那么，原本将发送至相应业务系统的测试请求消息，现在将发送至测试平台中，故被测系统向测试平台发送测试请求消息，具体为：所述被测系统对预先设置的测试数据进行处理，生成测试请求消息，根据预先由所述测试平台发送的重定向地址，将所述测试请求消息发送至所述重定向地址，其中，所述重定向地址指向所述测试平台。

所述的测试数据，可以是测试人员预先部署在被测系统中的，也可以是部署在相应的服务器中，该服务器将不断地向被测系统发送业务请求，以模拟实际应用时的状态，当然，这里并不构成对本申请的限定。

以上为本发明实施例提供的响应测试方法，基于同样的思路，本发明实施例还提供一种响应测试装置。

如图3所示，响应测试装置包括：接收模块301、确定模块302、响应测试模块303，其中，

所述接收模块301，用于接收被测系统发送的测试请求消息。

所述确定模块302，用于根据所述测试请求消息，在预先保存的历史响应消息中，确定与所述测试请求消息相匹配的历史响应消息。

所述响应测试模块303，用于根据确定出的历史响应消息，对所述被测系统进行测试。

所述确定模块302，具体用于确定所述测试请求消息对应的业务类型，根据确定出的所述业务类型，在所述预先保存的历史响应消息中，查找与所述业务类型相匹配的历史响应消息，将查找到的历史响应消息确定为与所述测试请求消息相匹配的历史响应消息。

所述响应测试模块303，具体用于根据确定出的历史响应消息，确定历史响应时间，根据确定出的所述历史响应时间，对所述被测系统进行测试。

在基于历史响应时间的基础上，所述响应测试模块303，具体用于当不同的历史响应时间的数量小于预设阈值时，从确定出的各历史响应时间中任选择一个历史响应时间，等待与所述历史响应时间相等的时长后，向被测系统返回测试响应消息，并测试所述被测系统接收到测试响应消息后的状态。

所述响应测试模块303，具体用于当不同的历史响应时间的数量不小于预设阈值时，根据确定出的各历史响应时间确定时间区间，随机确定落入所述时间区间内的等待时间，等待与随机确定的所述等待时间相等的时长后，向被测系统返回测试响应消息，并测试所述被测系统接收到测试响应消息后的状态。

而对于接收到的测试请求消息为多个测试请求消息的情况下，所述响应测试模块303，具体用于针对接收到的每个测试请求消息，从根据该测试请求消息确定出的各历史响应消息中选择一个未选择过的历史响应消息，确定选择的该历史响应消息对应的历史响应时间，并等待与该历史响应时间相等的时长后，将选择的该历史响应消息返回给所述被测系统，并测试所述被测系统接收到该历史响应消息后的状态。

所述响应测试模块303，具体用于根据确定出的历史响应消息，确定基准等待时间，根据已经向所述被测系统返回的测试响应消息的数量，确定延迟系数，其中，已经向所述被测系统返回的测试响应消息的数量越多，所述延迟系数越大；将所述基准等待时间与所述延迟系数的乘积确定为实际等待时间，等待与所述实际等待时间相等的时长后，向被测系统返回测试响应消息，并测试所述被测系统接收到测试响应消息后的状态。

通过上述如图3所示的装置，可以构建相应的测试平台，从而，不同的测试人员可以通过所述测试平台，对不同的业务系统进行测试。相应地，在本申请实施例中，还提供一种响应测试装置，如图4所示。所述装置包括：

发送模块401，用于向测试平台发送测试请求消息，使所述测试平台确定与所述测试请求消息相匹配的历史响应消息，并根据所述历史响应消息向所述被测系统返回测试响应消息。

接收模块402，用于接收由所述测试平台返回的测试响应消息，并对所述测试响应消息进行测试处理。

所述发送模块401，具体用于对预先设置的测试数据进行处理，生成测试请求消息，根据预先由所述测试平台发送的重定向地址，将所述测试请求消息发送至所述重定向地址，其中，所述重定向地址指向所述测试平台。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本发明的实施例可提供为方法、系统或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

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

Claims (10)

1.一种响应测试方法，其特征在于，包括：

测试平台接收被测系统发送的测试请求消息；其中，所述测试平台用于模拟与所述被测系统进行信息交互的业务系统；

根据所述测试请求消息，在预先保存的历史响应消息中，确定与所述测试请求消息相匹配的历史响应消息；

根据确定出的历史响应消息，对所述被测系统进行测试；

根据确定出的历史响应消息，对所述被测系统进行测试，具体包括：

根据确定出的历史响应消息，确定基准等待时间；

根据已经向所述被测系统返回的测试响应消息的数量，确定延迟系数，其中，已经向所述被测系统返回的测试响应消息的数量越多，所述延迟系数越大；

将所述基准等待时间与所述延迟系数的乘积确定为实际等待时间；

等待与所述实际等待时间相等的时长后，向被测系统返回测试响应消息，并测试所述被测系统接收到测试响应消息后的状态。

2.如权利要求1所述的方法，其特征在于，根据所述测试请求消息，在预先保存的历史响应消息中，确定与所述测试请求消息相匹配的历史响应消息，具体包括：

确定所述测试请求消息对应的业务类型；

根据确定出的所述业务类型，在所述测试平台预先保存的历史响应消息中，查找与所述业务类型相匹配的历史响应消息；

将查找到的历史响应消息确定为与所述测试请求消息相匹配的历史响应消息。

3.一种响应测试方法，其特征在于，包括：

测试平台接收被测系统发送的测试请求消息；其中，所述测试平台用于模拟与所述被测系统进行信息交互的业务系统；

根据所述测试请求消息，在预先保存的历史响应消息中，确定与所述测试请求消息相匹配的历史响应消息；

根据确定出的历史响应消息，对所述被测系统进行测试；

根据确定出的历史响应消息，对所述被测系统进行测试，具体包括：

根据确定出的历史响应消息，确定历史响应时间；

根据确定出的所述历史响应时间，对所述被测系统进行测试；

根据确定出的所述历史响应时间，对所述被测系统进行测试，具体包括：

当不同的历史响应时间的数量小于预设阈值时，从确定出的各历史响应时间中任选择一个历史响应时间；等待与所述历史响应时间相等的时长后，向被测系统返回测试响应消息，并测试所述被测系统接收到测试响应消息后的状态；

根据确定出的所述历史响应时间，对所述被测系统进行测试，具体包括：

当不同的历史响应时间的数量不小于预设阈值时，根据确定出的各历史响应时间确定时间区间；随机确定落入所述时间区间内的等待时间；等待与随机确定的所述等待时间相等的时长后，向被测系统返回测试响应消息，并测试所述被测系统接收到测试响应消息后的状态。

4.一种响应测试方法，其特征在于，包括：

被测系统向测试平台发送测试请求消息，使所述测试平台确定与所述测试请求消息相匹配的历史响应消息，并根据所述历史响应消息向所述被测系统返回测试响应消息；

接收由所述测试平台返回的测试响应消息，并对所述测试响应消息进行测试处理；

根据所述历史响应消息向所述被测系统返回测试响应消息包括：根据确定出的历史响应消息，确定基准等待时间；根据已经向所述被测系统返回的测试响应消息的数量，确定延迟系数，其中，已经向所述被测系统返回的测试响应消息的数量越多，所述延迟系数越大；将所述基准等待时间与所述延迟系数的乘积确定为实际等待时间；等待与所述实际等待时间相等的时长后，向被测系统返回测试响应消息。

5.如权利要求4所述的方法，其特征在于，被测系统向测试平台发送测试请求消息，具体包括：

所述被测系统对预先设置的测试数据进行处理，生成测试请求消息；

根据预先由所述测试平台发送的重定向地址，将所述测试请求消息发送至所述重定向地址，其中，所述重定向地址指向所述测试平台。

6.一种响应测试装置，其特征在于，设置在测试平台中，包括：

接收模块，用于接收被测系统发送的测试请求消息；

确定模块，用于根据所述测试请求消息，在预先保存的历史响应消息中，确定与所述测试请求消息相匹配的历史响应消息；

响应测试模块，根据确定出的历史响应消息，对所述被测系统进行测试；

所述响应测试模块，具体用于根据确定出的历史响应消息，确定基准等待时间，根据已经向所述被测系统返回的测试响应消息的数量，确定延迟系数，其中，已经向所述被测系统返回的测试响应消息的数量越多，所述延迟系数越大；将所述基准等待时间与所述延迟系数的乘积确定为实际等待时间，等待与所述实际等待时间相等的时长后，向被测系统返回测试响应消息，并测试所述被测系统接收到测试响应消息后的状态。

7.如权利要求6所述的装置，其特征在于，所述确定模块，具体用于确定所述测试请求消息对应的业务类型，根据确定出的所述业务类型，在所述预先保存的历史响应消息中，查找与所述业务类型相匹配的历史响应消息，将查找到的历史响应消息确定为与所述测试请求消息相匹配的历史响应消息。

8.一种响应测试装置，其特征在于，设置在测试平台中，包括：

接收模块，用于接收被测系统发送的测试请求消息；

确定模块，用于根据所述测试请求消息，在预先保存的历史响应消息中，确定与所述测试请求消息相匹配的历史响应消息；

响应测试模块，根据确定出的历史响应消息，对所述被测系统进行测试；

所述响应测试模块，具体用于根据确定出的历史响应消息，确定历史响应时间，根据确定出的所述历史响应时间，对所述被测系统进行测试；

所述响应测试模块，具体用于当不同的历史响应时间的数量小于预设阈值时，从确定出的各历史响应时间中任选择一个历史响应时间，等待与所述历史响应时间相等的时长后，向被测系统返回测试响应消息，并测试所述被测系统接收到测试响应消息后的状态；

所述响应测试模块，具体用于当不同的历史响应时间的数量不小于预设阈值时，根据确定出的各历史响应时间确定时间区间，随机确定落入所述时间区间内的等待时间，等待与随机确定的所述等待时间相等的时长后，向被测系统返回测试响应消息，并测试所述被测系统接收到测试响应消息后的状态。

9.一种响应测试装置，其特征在于，设置在被测系统中，包括：

发送模块，用于向测试平台发送测试请求消息，使所述测试平台确定与所述测试请求消息相匹配的历史响应消息，并根据所述历史响应消息向所述被测系统返回测试响应消息；

接收模块，用于接收由所述测试平台返回的测试响应消息，并对所述测试响应消息进行测试处理；

根据所述历史响应消息向所述被测系统返回测试响应消息包括：根据确定出的历史响应消息，确定基准等待时间；根据已经向所述被测系统返回的测试响应消息的数量，确定延迟系数，其中，已经向所述被测系统返回的测试响应消息的数量越多，所述延迟系数越大；将所述基准等待时间与所述延迟系数的乘积确定为实际等待时间；等待与所述实际等待时间相等的时长后，向被测系统返回测试响应消息。

10.如权利要求9所述的装置，其特征在于，所述发送模块，具体用于对预先设置的测试数据进行处理，生成测试请求消息，根据预先由所述测试平台发送的重定向地址，将所述测试请求消息发送至所述重定向地址，其中，所述重定向地址指向所述测试平台。