CN110380936B - 测试方法和装置 - Google Patents

Abstract

本公开提供了一种测试方法，应用于微服务架构，该微服务架构包括第一服务和第二服务，该方法包括：监听第一服务向第二服务发送的第一交易请求报文；确定第一交易请求报文是否能够用于对第二服务进行测试；如果确定第一交易请求报文能够用于对第二服务进行测试，则基于第一交易请求报文生成用于向第二服务请求服务的多个第一测试请求报文；向第二服务发送多个第一测试请求报文；以及监听第二服务针对多个第一测试请求报文的应答，以实现对第二服务的测试。本公开还提供了一种装置测试、一种电子设备以及一种计算机可读存储介质。

Description

测试方法和装置

技术领域

本公开涉及计算机技术领域，特别是涉及一种测试方法和装置。

背景技术

微服务架构作为一种开放式平台，可以将***业务按功能拆分为更加细粒度的服务。每个服务对外提供公共的API(Application Programming Interface，应用程序编程接口)，并独立承担对外服务的职责。一个涉及微服务的交易流程可以包括“发起方-＞服务A-＞服务B-＞服务C-＞服务D-＞服务E”等等多个环节并原路返回。假定当前项目修改点改进的是服务B和服务D，那么实际测试应聚焦在服务B和服务D上，并不需要对其它存量服务发起性能测试。

但目前传统的测试方法，要么是从发起方发起一定数量的并发请求，然后监控响应时间和***资源开销等，要么是只对单节点的服务B和服务D并发请求，然后监控响应时间和***资源开销等。

前者往往需要为全流程中所有服务准备数据并搭建这些服务所涉及的环境资源。比如上述例子就需要从服务A到服务E的环境资源和数据都齐备。这必然导致成本过高，测试效率较低。后者往往需要开发用于模拟服务B和服务D所调用服务的挡板程序，且无法完成长流程的性能验证。

发明内容

本公开的一个方面提供了一种测试方法，应用于微服务架构，所述微服务架构包括第一服务和第二服务，该方法包括：监听所述第一服务向所述第二服务发送的第一交易请求报文；确定所述第一交易请求报文是否能够用于对所述第二服务进行测试；如果确定所述第一交易请求报文能够用于对所述第二服务进行测试，则基于所述第一交易请求报文生成用于向所述第二服务请求服务的多个第一测试请求报文；向所述第二服务发送所述多个第一测试请求报文；以及监听所述第二服务针对所述多个第一测试请求报文的应答，以实现对所述第二服务的测试。

可选地，所述确定所述第一交易请求报文是否能够用于对所述第二服务进行测试，包括：确定所述第一交易请求报文中是否携带有预定指令，所述预定指令用于指示对所述第二服务进行测试。

可选地，所述微服务架构还包括第三服务；以及所述方法还包括在监听所述第二服务针对所述多个第一测试请求报文的应答的过程中：阻止所述第二服务向所述第三服务发送多个第二测试请求报文，其中，所述多个第二测试请求报文为所述第二服务响应于所述多个第一测试请求报文而生成的用于向所述第三服务请求服务的报文。

可选地，所述方法还包括：获取第二交易请求报文，所述第二交易请求报文为所述第二服务响应于所述第一交易请求报文而生成的用于向所述第三服务请求服务的报文；向所述第三服务转发所述第二交易请求报文；获取所述第三服务响应于所述第二交易请求报文而生成的交易应答报文；基于所述交易应答报文，生成多个测试应答报文，所述多个测试应答报文与所述多个第二测试请求报文一一对应；以及向所述第二服务发送所述多个测试应答报文。

可选地，在向所述第二服务发送所述多个测试应答报文之后，所述方法还包括：阻止所述第二服务向所述第一服务转发所述多个测试应答报文。

可选地，在获取第二交易请求报文之前，所述方法还包括：获取来自所述第一服务的所述第一交易请求报文；以及向所述第二服务转发所述第一交易请求报文。

可选地，在获取所述第三服务响应于所述第二交易请求报文而生成的交易应答报文之后，所述方法还包括：向所述第二服务转发所述交易应答报文。

本公开的另一个方面提供了一种测试装置，应用于微服务架构，所述微服务架构包括第一服务和第二服务，所述装置包括：第一监听模块，用于监听所述第一服务向所述第二服务发送的第一交易请求报文；确定模块，用于确定所述第一交易请求报文是否能够用于对所述第二服务进行测试；生成模块，用于在确定所述第一交易请求报文能够用于对所述第二服务进行测试的情况下，基于所述第一交易请求报文生成用于向所述第二服务请求服务的多个测试请求报文；发送模块，用于向所述第二服务发送所述多个第一测试请求报文；以及第二监听模块，用于监听所述第二服务针对所述多个第一测试请求报文的应答，以实现对所述第二服务的测试。

本公开的另一方面提供了一种电子设备，包括：一个或多个处理器；存储器，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上所述的方法。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

本公开的另一方面提供了一种计算机程序，所述计算机程序包括计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

附图说明

为了更完整地理解本公开及其优势，现在将参考结合附图的以下描述，其中：

图1示意性示出了根据本公开实施例的适于测试方法和装置的***架构；

图2示意性示出了根据本公开实施例的测试方法的流程图；

图3示意性示出了根据本公开实施例的复制装置处理请求报文的流程图；

图4示意性示出了根据本公开实施例的挡板装置处理的流程图；

图5示意性示出了根据本公开实施例的复制装置处理应答报文的流程图；

图6示意性示出了根据本公开实施例的基于微服务架构的靶向性能测试的示意图；

图7示意性示出了根据本公开实施例的复制装置的框图；

图8示意性示出了根据本公开实施例的挡板装置的框图；

图9示意性示出了根据本公开实施例的测试装置的框图；以及

图10示意性示出了根据本公开实施例的电子设备的框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的***”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的***等)。在使用类似于“A、B或C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B或C中至少一个的***”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的***等)。

附图中示出了一些方框图和/或流程图。应理解，方框图和/或流程图中的一些方框或其组合可以由计算机程序指令来实现。这些计算机程序指令可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器，从而这些指令在由该处理器执行时可以创建用于实现这些方框图和/或流程图中所说明的功能/操作的装置。本公开的技术可以硬件和/或软件(包括固件、微代码等)的形式来实现。另外，本公开的技术可以采取存储有指令的计算机可读存储介质上的计算机程序产品的形式，该计算机程序产品可供指令执行***使用或者结合指令执行***使用。

本公开的实施例提供了一种测试方法以及能够应用该方法的测试装置。该方法应用于微服务架构，该微服务架构例如可以包括第一服务和第二服务，该方法例如可以包括监听第一服务向第二服务发送的第一交易请求报文，确定该第一交易请求报文是否能够用于对第二服务进行测试。如果确定第一交易请求报文能够用于对第二服务进行测试，则基于第一交易请求报文生成用于向第二服务请求服务的多个第一测试请求报文。并向第二服务发送多个第一测试请求报文，同时监听第二服务针对多个第一测试请求报文的应答，以实现对第二服务的测试。

图1示意性示出了根据本公开实施例的适于测试方法和装置的***架构。需要注意的是，图1所示仅为可以应用本公开实施例的***架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、***、环境或场景。

如图1所示，该***架构包括：服务消费者和服务提供者，以及服务注册中心、配置中心和监控中心。

应该理解，服务消费者表示消费服务的一方，服务提供者表示提供服务的一方。例如，对于上述示例“发起方-＞服务A-＞服务B-＞服务C-＞服务D-＞服务E”，服务A-＞服务B即服务A调用服务B，可见相对而言，服务A是服务消费者，服务B是服务提供者。而服务B-＞服务C即服务B调用服务C，可见相对而言，服务B是服务消费者，服务C是服务提供者，……。

此外，服务注册中心用于为每个服务注册相应的信息。配置中心用于为每个服务配置相应的信息。监控中心用于对各服务的全流程进行监控，以针对其中的某些服务节点进行性能测试。

通过本公开实施例提供的测试方法和装置，采用靶向高并发测试手段，即仅对已经明确需要进行性能测试的服务连续发送多条测试请求报文进行测试。具体地，在全链路上发起一笔正常交易请求，当交易请求到达已经明确需要进行性能测试的服务时，会自动对此服务发起高并发性能测试，经过此服务后会自动恢复为一笔正常交易请求，从而可以解决相关技术中存在的成本过高、测试效率较低以及无法完成长流程的性能验证的技术问题，进而可以降低性能测试对整体应用环境的依赖，提高性能测试的工作效率。

图2示意性示出了根据本公开实施例的测试方法的流程图。

如图2所示，该方法例如可以应用于微服务架构，该微服务架构例如可以包括第一服务和第二服务，该方法例如可以包括操作S210～S250。

在操作S210，监听第一服务向第二服务发送的第一交易请求报文。

应该理解，在本公开实施例中，第一服务对第二服务具有调用关系。即第一服务是服务消费者，第二服务是服务提供者。

并且，在本公开实施例中，第一交易请求报文例如可以是一个正常的交易请求报文。

接下来，在操作S220，确定第一交易请求报文是否能够用于对第二服务进行测试。

为了实现靶向测试，在本公开实施例中，可以在正常的交易请求报文中设置相应的指令，用于指示对某些服务进行性能测试。

然后，在操作S230，如果确定第一交易请求报文能够用于对第二服务进行测试，则基于第一交易请求报文生成用于向第二服务请求服务的多个第一测试请求报文。

具体地，可以基于第一交易请求报文生成多个第一测试请求报文并将这些报文全部发送给第二服务，从而实现对第二服务进行高并发压力测试。

再然后，在操作S240，向第二服务发送多个第一测试请求报文。

再然后，在操作S250，监听第二服务针对多个第一测试请求报文的应答，以实现对第二服务的测试。

比如，可以监听第二服务针对多个第一测试请求报文的应答，以测试第二服务所能承受的高并发压力以及做出响应的平均时间等。

进一步，作为一种可选的实施例，确定第一交易请求报文是否能够用于对第二服务进行测试例如可以包括确定第一交易请求报文中是否携带有预定指令。其中预定指令用于指示对第二服务进行测试。

图3示意性示出了根据本公开实施例的复制装置处理请求报文的示意图。如图3所示，在本公开实施例中，复制装置处理请求报文的流程如操作S310～S360。

在操作S310，启动复制装置，监听所有的交易请求报文。

应该理解，在本公开实施例中复制装置是通过复制程序实现的。在一些跨服务的性能测试项目中，往往由于客观因素的限制(如测试硬件资源有限、多服务之间的协调等)，无法搭建一个完整的测试环境来完成测试工作。本公开实施例，通过搭建出被测服务，然后采用软件程序来识别被测服务并以正常交易请求报文为基础连续复制多条请求报文作为测试请求报文发送给被测服务。该软件程序一般被称为复制程序。

接下来，在操作S320，对接收到的交易请求报文，分析是否含有性能测试标签的特殊指令，从而判断是否为测试请求报文。若是测试请求报文且开关为true，则继续操作S330。若不是测试请求报文，则直接跳转到操作S360。

需要说明的是，在本公开实施例中，测试请求报文可以对应于如表1的数据结构。

表1

应该理解，在本公开实施例中，上述特殊指令可以通过json格式的伪代码实现。

然后，在操作S330，当此报文信息到达指定的服务B和服务D时，根据正常交易请求报文中的交易信息，复制靶向请求报文，且结合预先已经埋点的用于参数化的数据资源，自动复制成一份测试请求报文。譬如预埋数据处理模块中预先定义100个***实际值如表2所示。

表2

cardno
	6222123456789000001
6222123456789000002
	…
6222123456789000100

应该理解，靶向请求报文即向已经明确需要进行性能测试的服务发送的测试请求报文。

需要说明的是，在本公开实施例中，每一次复制靶向请求报文时，均会将本次报文中的{cardno}替换为当前的真实***，即第一次替换为6222123456789000001，第二次替换为6222123456789000002，依此类推。

然后，在操作S340，基于操作S330生成的测试请求报文，转发靶向请求报文，调用请求下一服务。

再然后，在操作S350，根据性能测试标签的特殊指令，判断是否已经达到“并发数”和“持续时间”的目标要求。若已经达到，则结束靶向请求报文的复制操作，继续操作S360，否则跳转到操作S330，再次循环处理。

再然后，在操作S360，转发正常交易请求报文，按照正常流程继续调用下一服务。

通过本公开实施例，可以对靶向服务(即已经明确需要进行性能测试的服务)不断发起请求，直至达到所要求的并发数和持续时间为止，从而可以实现测试靶向服务的压力承受能力的目的。

在本公开实施例，采用在交易请求报文中添加性能测试标签的特殊指令的形式，由复制装置识别出交易请求报文下一个要调用的服务为需要性能测试的服务时，自动复制多份测试请求报文，并结合预先已经埋点的用于参数化的数据资源，以对该服务发起高并发请求来实现性能测试。

作为一种可选的实施例，微服务架构例如还可以包括第三服务。对应地，该方法例如还可以包括在监听第二服务针对多个第一测试请求报文的应答的过程中阻止第二服务向第三服务发送多个第二测试请求报文。其中，多个第二测试请求报文为第二服务响应于多个第一测试请求报文而生成的用于向第三服务请求服务的报文。

通过本公开实施例，对需要进行性能测试的服务，可以使用挡板装置对测试请求报文进行识别，并结合正常交易应答报文，自动得到测试返回报文(又称靶向应答报文或测试应答报文)，从而达到通过一个正常交易请求即可实现对需要进行性能测试的服务进行精准地靶向性能测试且不影响交易调用全链路上其余服务的目的。

应该理解，在本公开实施例中，挡板装置为通过挡板程序实现的装置。在一些跨服务的性能测试项目中，往往由于客观因素的限制(如测试硬件资源有限、多服务之间的协调等)，无法搭建一个完整的测试环境来完成测试工作。此时，一般会搭建出被测服务，然后采用软件程序来模拟其他相关服务的功能。该软件程序一般被称为挡板程序。

作为一种可选的实施例，该方法例如还可以包括获取第二交易请求报文，第二交易请求报文为第二服务响应于第一交易请求报文而生成的用于向第三服务请求服务的报文。向第三服务转发第二交易请求报文。获取第三服务响应于第二交易请求报文而生成的交易应答报文。基于交易应答报文，生成多个测试应答报文，多个测试应答报文与多个第二测试请求报文一一对应。向第二服务发送多个测试应答报文。

图4示意性示出了根据本公开实施例的挡板装置处理的流程图。如图4所示，该挡板装置处理请求报文的流程如操作S410～S480。

在操作S410，启动挡板装置，监听所有的交易请求报文。

接下来，在操作S420，对接收到的交易请求报文，分析判断是否为测试请求报文。若不是测试请求报文，则继续操作S430。若是测试请求报文，则跳转到操作S460。

然后，在操作S430，转发正常交易请求报文，按照正常流程继续调用下一服务。

再然后，在操作S440，监听正常交易应答报文，获取通过操作S430的正常交易请求报文调用下一服务后返回的正常交易应答报文的相关信息。

再然后，在操作S450，转发正常交易应答报文，按照正常流程返回给原请求服务。

再然后，在操作S460，对于每一笔测试请求报文，进行靶向应答报文的复制处理，具体为根据操作S440获取到的正常交易应答报文，结合预先已经埋点的用于参数化的数据资源，自动组装成正确的测试返回报文。譬如预埋数据处理模块中预先定义100个***实际值如表3所示。

表3

cardno
	6222123456789000001
6222123456789000002
	…
6222123456789000100

应该理解，每一次组装靶向应答报文时，均会将本次报文中的{cardno}替换为当前的真实***，即第一次替换为6222123456789000001，第二次替换为6222123456789000002，依此类推。

在操作S470，将操作S460基于生成的测试返回报文，转发靶向应答报文，返回给原请求服务。

在操作S480，判断靶向应答报文复制是否已经全部完成。若所有的测试请求报文均已经返回测试返回报文，则结束靶向应答报文的复制操作，完成整个处理流程。否则跳转到操作S460循环处理。

作为一种可选的实施例，在向第二服务发送多个测试应答报文之后，该方法例如还可以包括：阻止第二服务向第一服务转发多个测试应答报文。

图5示意性示出了根据本公开实施例的复制装置处理应答报文的流程图。如图5所示，该复制装置处理应答报文的相关流程如操作S510～S550。

在操作S510，启动复制装置后，自动监听返回的所有交易应答报文。

在操作S520，对接收到的交易应答报文，分析判断是否为测试返回报文(即测试应答报文)。若是测试返回报文，则继续操作S530。若不是测试返回报文，而是正常交易应答报文，则跳转到操作S550。

在操作S530，进行靶向应答报文处理，对于每一笔测试返回报文进行终结关闭。

在操作S540，判断靶向应答报文处理是否已经全部完成。若所有的测试返回报文均已经终结关闭，则结束靶向应答报文处理的相关操作，继续操作S550；否则跳转到操作S530循环处理。

在操作S550，转发正常交易应答报文给原请求服务，完成整个处理流程。

需要说明的是，在本公开实施例的性能测试过程中，对于发起端是基本透明的，仅需要在报文中添加一条关于性能测试标签的特殊指令。具体地可以使用JMeter等发起工具，从Web前端或者合适的切入点发起一条测试请求报文。

应该理解，对于交易流程中的服务，只需要在用户服务的程序中，添加如下标柱，即可由框架自动完成相关服务的靶向性能测试，示例参考如下。

@Targeting

public RestTemplate restTemplate(){

}

具体地，靶向性能测试处理例如可以包括复制装置交易请求处理、挡板装置处理、复制装置交易应答处理等，这些均可以在Targeting所属的框架中实现。所有服务节点的详细信息(如性能测试结果)主要由微服务框架中的监控中心提供，包含其各节点的具体服务请求的开始时间、结束时间及相关CPU、内存和IO的统计数据等。

应该理解，在性能测试过程中，可以充分利用分布式***可动态伸缩的特性，达到节约***资源的目的。

具体地，测试前，可以将相关服务都制作好镜像，保存在镜像仓库中。开始测试时，前期可以使用基本的服务器资源，只要能完成交易流程即可。在靶向性能测试过程中，假如要评估服务B的性能容量，那么在报文中添加一条特殊指令，即可实时评估当前服务B的性能指标的目的。若发现服务B因当前的服务资源不足而导致无法满足生产实际需求，则按照实际性能数据进行差值计算，并通过微服务框架中的配置中心，实时创建和启动容器，对服务B进行动态扩容，直至性能容量指标达到预定的目标为止。当服务B的性能容量评估完成，可以开启下一个要评估的服务，如对服务D进行性能测试，那么此时可以通过动态停止删除服务B所在的容器，而仅对本次要靶向测试的服务D进行相应的动态扩容。

作为一种可选的实施例，在获取第二交易请求报文之前，该方法例如还可以包括：获取来自第一服务的第一交易请求报文，并向第二服务转发第一交易请求报文。

作为一种可选的实施例，在获取第三服务响应于第二交易请求报文而生成的交易应答报文之后，该方法例如还可以包括：向第二服务转发交易应答报文。

下面参考图6并结合具体实施例详细阐述本公开。

图6示意性示出了根据本公开实施例的基于微服务架构的靶向性能测试的示意图。如图6所示，一次交易的完整流程详述如下。

在发起方发起性能测试交易，调度服务A开始交易流程。由于服务A并不是已知的测试对象，此时并不需要发起高并发性能测试，而仅需发起一条正常交易请求报文，但需要在交易报文中注入关于性能测试标签的特殊指令(即预定指令)。此特殊指令可要求对特定服务(如服务B或者服务D等)进行精准的靶向性能测试。

应该理解，在本公开实施例中，性能测试指标例如可以包括但不限于吞吐量(QPS，即单位时间内***能处理的请求数量，如TPS即为每秒钟请求事务数量)、并发数(即***能同时处理的请求数量)、响应时间(TR，即执行一个请求从开始到最后收到应答的总体时间)、性能计数器(即服务器或操作***性能的数据指标)等。理想模型下，QPS(TPS)＝并发数/TR，因此可通过控制并发数的不同，获取到对应的具体性能指标。

在本公开实施例中，特殊指令的数据结构例如可以包括表4中所示的内容。

表4

是否性能测试表示本次请求是否需要做性能测试的开关判断(true/false)。当且仅当为真时，需要对特定服务发起高并发性能测试。

性能测试目标服务表示本次请求需要进行靶向性能测试的服务。譬如仅设置了服务B，则仅对服务B进行高并发的靶向性能测试。若同时设置了服务B和服务D，则仅对服务B和服务D进行高并发的靶向性能测试。对于交易流程中的其它服务，只需要维持单笔请求，并不需要发起高并发的靶向性能测试请求。

并发数表示设置本次性能测试对特定服务同时发起的事务请求数。譬如如果并发数设置为100，则需要对本次靶向性能测试所针对的服务(如服务B)，同时发起100个测试请求。

持续时间表示设置本次性能测试的持续时间。譬如如果持续时间设置为600s，即600秒，则持续600秒(10分钟)一直对本次靶向性能测试所针对的服务(如服务B)，不间断地发起100个测试请求。

参数名表示设置需要数据参数化的名称。譬如可以设置cardno，则在后续发起高并发性能测试时，可利用预埋数据处理模块，将每一笔交易请求中的cardno设置为具体的不同的银行卡***，而不是每一笔交易都使用同一张***，避免数据造成热点。

当此携带特殊指令的交易信息，在服务A进入调用服务B的流程时，可以通过复制装置自动检测到服务B是本次需要做高并发性能测试的精准对象。此时除了保留一条正常交易请求报文用于继续调用服务B外，还可以通过复制装置将正常交易请求报文中的交易信息与埋点的数据组合，自动复制成多份测试请求报文，逐一调用服务B，即对服务B执行高并发的调度操作。

当针对交易请求报文，服务B完成响应并进入调度服务C的流程时，可以通过挡板装置自动检测到服务C并不是本次需要高并发测试的对象，那么挡板装置仅针对原来的一条正常交易请求报文去调用服务C并获取返回结果即正常交易应答报文即可。挡板装置对于之前由复制装置自动复制的测试请求报文，并不实际调用服务C，而是根据当前的正常交易应答报文自动组装成正确的测试返回报文并逐一返回给服务B。

当所有的交易应答报文，由服务B返回给服务A的时候，复制装置仅将一条正常交易应答报文返回给服务A，而对于所有的由挡板装置自动应答的测试返回报文全部自动过滤掉，从而完成整个交易流程。

需要说明的是，在本公开实施例中，靶向性能测试***例如可以包括两个装置，分别是复制装置和挡板装置。

图7示意性示出了根据本公开实施例的复制装置的框图。复制装置主要负责如下操作。

(1)针对正常交易请求报文”，结合预埋点的数据，自动复制成多份测试请求报文，从而对明确的服务发起高并发性能测试。

(2)自动过滤测试返回报文，将高并发的响应报文进行降压处理，仅保留一条正常交易应答报文。

为了实现上述操作，具体地，在本公开实施例中，如图7所示，复制装置700例如可以包括请求报文监听模块701、应答报文监听模块702、正常转发处理模块703、预埋数据处理模块704、靶向请求处理模块705、靶向应答处理模块706。

其中，请求报文监听模块701用于监听所有的交易请求报文，并对接收到的交易请求报文，分析是否含有性能测试标签的特殊指令。

应答报文监听模块702用于监听所有的交易应答报文，对接收到的交易应答报文，判断是正常交易应答报文801还是测试返回报文。

正常转发处理模块703用于对接收到的交易请求报文，以正常交易请求报文按照正常流程继续调用下一服务。

预埋数据处理模块704用于预先定义好用于参数化的数据资源。以一个需要参数化***的服务为例，则可以在预埋数据处理模块704中预先定义100个***实际值，具体如表5所示。

靶向请求处理模块705用于将接收到的交易请求报文进行处理，根据正常交易请求报文中的交易信息，结合预埋点的用于参数化的数据资源，自动复制成多份测试请求报文，逐一调用下一服务，对下一服务执行高并发的调度执行。其每一份复制报文的示例参考如下。

startStresstesting(setStressMsg(data_msg，data_param))

其中data_msg表示正常交易请求报文中的交易信息，而data_param表示包含上述预埋数据处理模块704中预先定义的名为cardno的参数。

表5

cardno
	6222123456789000001
6222123456789000002
	…
6222123456789000100

靶向应答处理模块706用于将接收到的交易应答报文进行处理，仅将一条正常交易应答报文返回给原请求服务，而对于所有的测试返回报文全部自动过滤掉。其中每一份结束报文的示例参考如下。

if(isStresstMsg(data_msg))

endStresstesting(data_msg)

图8示意性示出了根据本公开实施例的挡板装置的框图。如图8所示，挡板装置800主要负责对高并发的测试请求报文进行挡板处理，根据实际的正常交易应答报文组装成正确的测试返回报文，然后直接自动返回。

为了实现上述操作，具体地，在本公开实施例中，如图8所示，挡板装置800例如可以包括请求报文监听模块801、应答报文监听模块802、正常转发处理模块803、预埋数据处理模块804和靶向应答处理模块805。

请求报文监听模块801用于监听所有的交易请求报文，并对接收到的交易请求报文分析是正常交易请求报文还是测试请求报文。

应答报文监听模块802用于监听所有的交易应答报文，并获取正常交易应答报文的所有信息。

正常转发处理模块803用于将接收到的正常交易请求报文的信息进行转发，返回给原请求服务。

预埋数据处理模块804用于预先定义好用于参数化的数据资源。

靶向应答处理模块805用于对于所有的测试请求报文，根据应答报文监听模块802获取到的正常交易应答报文，结合预先已经埋点的用于参数化的数据资源，自动组装成正确的测试返回报文，并逐一返回给原请求服务。

图9示意性示出了根据本公开实施例的测试装置的框图。

如图9所示，该测试装置900例如可以应用于微服务架构，所述微服务架构包括第一服务和第二服务，该测试装置900包括第一监听模块901、确定模块902、生成模块903、发送模块904和第二监听模块905。该处理装置可以执行上面参考方法实施例部分描述的方法，在此不再赘述。

具体地，第一监听模块901例如可以用于监听第一服务向第二服务发送的第一交易请求报文。

确定模块902例如可以用于确定第一交易请求报文是否能够用于对第二服务进行测试。

生成模块903例如可以用于在确定第一交易请求报文能够用于对第二服务进行测试的情况下，基于第一交易请求报文生成用于向第二服务请求服务的多个测试请求报文。

发送模块904例如可以用于向第二服务发送多个第一测试请求报文。

第二监听模块905例如可以用于监听第二服务针对多个第一测试请求报文的应答，以实现对第二服务的测试。

需要说明的是，装置部分的实施例方式与方法部分的实施例方式对应类似，并且所达到的技术效果也对应类似，在此不再赘述。

根据本公开的实施例的模块中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上***、基板上的***、封装上的***、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

例如，第一监听模块901、确定模块902、生成模块903、发送模块904和第二监听模块905中的任意多个可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，第一监听模块901、确定模块902、生成模块903、发送模块904和第二监听模块905中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上***、基板上的***、封装上的***、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，第一监听模块901、确定模块902、生成模块903、发送模块904和第二监听模块905中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

图10示意性示出了根据本公开实施例的电子设备的框图。图10示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图10所示，电子设备1000包括处理器1010、计算机可读存储介质1020。该电子设备1000可以执行根据本公开实施例的方法。

具体地，处理器1010例如可以包括通用微处理器、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器1010还可以包括用于缓存用途的板载存储器。处理器1010可以是用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

计算机可读存储介质1020，例如可以是非易失性的计算机可读存储介质，具体示例包括但不限于：磁存储装置，如磁带或硬盘(HDD)；光存储装置，如光盘(CD-ROM)；存储器，如随机存取存储器(RAM)或闪存；等等。

计算机可读存储介质1020可以包括计算机程序1021，该计算机程序1021可以包括代码/计算机可执行指令，其在由处理器1010执行时使得处理器1010执行根据本公开实施例的方法或其任何变形。

计算机程序1021可被配置为具有例如包括计算机程序模块的计算机程序代码。例如，在示例实施例中，计算机程序1021中的代码可以包括一个或多个程序模块，例如包括1021A、模块1021B、……。应当注意，模块的划分方式和个数并不是固定的，本领域技术人员可以根据实际情况使用合适的程序模块或程序模块组合，当这些程序模块组合被处理器1010执行时，使得处理器1010可以执行根据本公开实施例的方法或其任何变形。

根据本公开的实施例，第一监听模块901、确定模块902、生成模块903、发送模块904和第二监听模块905中的至少一个可以实现为参考图8描述的计算机程序模块，其在被处理器810执行时，可以实现上面描述的相应操作。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/***中所包含的；也可以是单独存在，而未装配入该设备/装置/***中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

附图中的流程图和框图，图示了按照本公开各种实施例的***、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的***来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，尽管已经参照本公开的特定示例性实施例示出并描述了本公开，但是本领域技术人员应该理解，在不背离所附权利要求及其等同物限定的本公开的精神和范围的情况下，可以对本公开进行形式和细节上的多种改变。因此，本公开的范围不应该限于上述实施例，而是应该不仅由所附权利要求来进行确定，还由所附权利要求的等同物来进行限定。

Claims (10)

1.一种测试方法，应用于微服务架构，所述微服务架构包括第一服务和第二服务，所述方法包括：

监听所述第一服务向所述第二服务发送的第一交易请求报文；

确定所述第一交易请求报文是否能够用于对所述第二服务进行测试；

如果确定所述第一交易请求报文能够用于对所述第二服务进行测试，则基于所述第一交易请求报文生成用于向所述第二服务请求服务的多个第一测试请求报文；

向所述第二服务发送所述多个第一测试请求报文；以及

监听所述第二服务针对所述多个第一测试请求报文的应答，以实现对所述第二服务的测试。

2.根据权利要求1所述的方法，其中，所述确定所述第一交易请求报文是否能够用于对所述第二服务进行测试，包括：

确定所述第一交易请求报文中是否携带有预定指令，所述预定指令用于指示对所述第二服务进行测试。

3.根据权利要求1所述的方法，其中，

所述微服务架构还包括第三服务；以及

所述方法还包括在监听所述第二服务针对所述多个第一测试请求报文的应答的过程中：

阻止所述第二服务向所述第三服务发送多个第二测试请求报文，

其中，所述多个第二测试请求报文为所述第二服务响应于所述多个第一测试请求报文而生成的用于向所述第三服务请求服务的报文。

4.根据权利要求3所述的方法，其中，所述方法还包括：

获取第二交易请求报文，所述第二交易请求报文为所述第二服务响应于所述第一交易请求报文而生成的用于向所述第三服务请求服务的报文；

向所述第三服务转发所述第二交易请求报文；

获取所述第三服务响应于所述第二交易请求报文而生成的交易应答报文；

基于所述交易应答报文，生成多个测试应答报文，所述多个测试应答报文与所述多个第二测试请求报文一一对应；以及

向所述第二服务发送所述多个测试应答报文。

5.根据权利要求4所述的方法，其中，在向所述第二服务发送所述多个测试应答报文之后，所述方法还包括：

阻止所述第二服务向所述第一服务转发所述多个测试应答报文。

6.根据权利要求4所述的方法，其中，在获取第二交易请求报文之前，所述方法还包括：

获取来自所述第一服务的所述第一交易请求报文；以及

向所述第二服务转发所述第一交易请求报文。

7.根据权利要求4所述的方法，其中，在获取所述第三服务响应于所述第二交易请求报文而生成的交易应答报文之后，所述方法还包括：

向所述第二服务转发所述交易应答报文。

8.一种测试装置，应用于微服务架构，所述微服务架构包括第一服务和第二服务，所述装置包括：

第一监听模块，用于监听所述第一服务向所述第二服务发送的第一交易请求报文；

确定模块，用于确定所述第一交易请求报文是否能够用于对所述第二服务进行测试；

生成模块，用于在确定所述第一交易请求报文能够用于对所述第二服务进行测试的情况下，基于所述第一交易请求报文生成用于向所述第二服务请求服务的多个第一测试请求报文；

发送模块，用于向所述第二服务发送所述多个第一测试请求报文；以及

第二监听模块，用于监听所述第二服务针对所述多个第一测试请求报文的应答，以实现对所述第二服务的测试。

9.一种电子设备，包括：

一个或多个处理器；

存储器，用于存储一个或多个程序，

其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现权利要求1至7中任一项所述的方法。

10.一种计算机可读存储介质，存储有计算机可执行指令，所述指令在被执行时用于实现权利要求1至7中任一项所述的方法。

Images