CN112162925A - 一种基于服务虚拟化的测试方法和系统 - Google Patents

Abstract

本公开提出了一种基于服务虚拟化的测试方法和系统，用于提高测试效率。本公开通过服务虚拟化工具录制/回放客户端经被测服务发送的请求以及被模拟服务的响应，然后通过虚拟化工具模拟实际服务，从而实现对被测服务的隔离测试，从而避免其他服务因为不稳定或不可用造成的测试误差，减少其他服务的部署依赖，提升测试效率。

Description

一种基于服务虚拟化的测试方法和系统

技术领域

本公开涉及测试技术领域，尤其涉及一种基于服务虚拟化的测试方法和系统。

背景技术

随着业务体量的发展，当下软件应用已经由前期的单体应用，逐渐发展为微服务架构。为了不让客户端直接面对各种各样的微服务，也为了更好地管理后端的微服务，又在软件架构中加入一层应用程序接口(Application Interface，API)网关，作为系统的唯一入口。如同客户在银行的取号和叫号服务，对到银行办理不同业务的人排号，然后通过叫号将这些客户分发到不同的窗口做业务处理。不仅如此，API网关还兼具有身份验证、监控、负载均衡等多种职责。当前实现API网关的技术有很多，主流的有Kong，Nginx，Haproxy，Netty等。

Kong，是一种开源的API网关，也可以理解为是一种针对API的管理工具。它是基于OpenResty(Nginx+Lua模块)编写的高可用的、易扩展的项目。Kong通过提供RESTful API来操作和配置API管理系统；也可以扩展为多个Kong服务器，并通过配置负载均衡将来自客户端的请求分发到各个微服务。

Kong有两个主要组件，Kong Server基于Nginx的服务器，用来接收API请求。Apache Cassandra用来存储操作数据。

当前，在云应用程序中多使用微服务。在这些微服务中，可以使用不同的技术，实现不同的相对独立的业务。虽然微服务带来了灵活的技术运用方式，以及快速发布和部署的优点，但也对整个系统的测试工作提出了新挑战。例如：当系统中的关键微服务处于开发中或不可用时，无法进行测试；因为某些特定的原因，一些微服务可能会停机；测试数据繁杂，不容易管理；由于各个微服务完成不同的业务，需要设计更加细粒度的用例和测试数据等。

发明内容

有鉴于此，本公开提供一种基于服务虚拟化的方法和系统，用于提高测试效率。

基于本公开一实施例，本公开提供了一种基于服务虚拟化的测试方法，所述方法包括：

在测试任务的第一阶段中，被测服务接收业务请求并将业务请求转发给服务虚拟化工具；服务虚拟化工具记录业务请求并将业务请求透传给被模拟服务；接收并记录被模拟服务发送的业务响应并将业务响应透传给被测服务；

在测试任务的第二阶段中，被测服务接收业务测试请求并将业务测试请求转发给服务虚拟化工具，服务虚拟化工具基于第一阶段中所记录的业务请求和业务响应模拟被模拟服务响应所述业务测试请求。

进一步地，所述方法还包括：在测试任务的第二阶段开始之前，还包括对所记录的业务请求和业务响应数据进行修改的步骤，所述修改至少包括对网络延迟、业务请求的正则匹配规则的修改；

在测试任务的第二阶段中，服务虚拟化工具基于被修改的第一阶段中所记录的业务请求和业务响应模拟被模拟服务响应所述业务测试请求。

进一步地，在测试任务的第二阶段中，对被测服务进行的测试可以是对被测服务进行的负载测试或压力测试，或对被测服务和链路的负载测试或压力测试。

进一步地，所述的被测服务为应用程序接口API网关，所述的被模拟服务为微服务。

进一步地，在测试任务的第一阶段中，所述服务虚拟化工具记录的是真实业务场景下的业务请求和业务响应。

基于本公开另一方面，本公开还提供了一种基于服务虚拟化的测试系统，该系统包括：

被测服务，在测试任务的第一阶段中，用于接收业务请求并将业务请求转发给服务虚拟化工具，以及接收业务响应并将业务响应转发给客户端；在测试任务的第二阶段中，用于接收业务测试请求并将业务测试请求转发给服务虚拟化工具，以及接收服务虚拟化工具针对业务测试请求的模拟响应；

服务虚拟化工具，在测试任务的第一阶段中，用于记录业务请求并将业务请求透传给被模拟服务，以及接收并记录被模拟服务发送的业务响应并将业务响应透传给被测服务；在测试任务的第二阶段中，用于基于第一阶段所记录的业务请求和业务响应模拟被模拟服务响应所述业务测试请求。

本公开通过服务虚拟化工具录制/回放客户端经被测服务发送的请求以及被模拟服务的响应，然后通过虚拟化工具模拟实际服务，从而实现对被测服务的隔离测试，从而避免其他服务因为不稳定或不可用造成的测试误差，减少其他服务的部署依赖，提升测试效率。

附图说明

为了更加清楚地说明本公开实施例或者现有技术中的技术方案，下面将对本公开实施例或者现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据本公开实施例的这些附图获得其他的附图。

图1为本公开一实施例提供的一种基于服务虚拟化的测试方法的步骤流程图；

图2为本公开一具体实施例提供的基于服务虚拟化的测试方法中第一阶段的步骤流程图；

图3为该具体实施例提供的基于服务虚拟化的测试方法中第二阶段的步骤流程图。

具体实施方式

在本公开实施例使用的术语仅仅是出于描述特定实施例的目的，而非限制本公开实施例。本公开实施例中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其它含义。本公开中使用的术语“和/或”是指包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本公开实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，此外，所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

图1为本公开一实施例提供的一种基于服务虚拟化的测试方法的步骤流程图，该方法应用于对特定服务的测试任务中，测试任务被分为两个阶段，在第一阶段中，在被测服务和被模拟服务之间置入服务虚拟化工具，由服务虚拟化工具记录被测服务与被模拟服务之间的请求与响应数据。在第二阶段中，由服务虚拟化工具模拟被模拟服务为被测服务提供服务。该方法包括：

步骤101.在测试任务的第一阶段中，被测服务接收业务请求并将业务请求转发给服务虚拟化工具；服务虚拟化工具记录业务请求并将业务请求透传给被模拟服务；接收并记录被模拟服务发送的业务响应并将业务响应透传给被测服务；

该步骤中，客户端向被测服务发送业务请求，被测服务基于预设策略对业务请求进行处理后，通过服务虚拟化工具将业务请求发送给一个或多个被模拟服务。所述的基于预设策略的处理可以负载分担、身份认证、安全检测、业务监控等处理，本公开不做具体限定。

第一阶段的处理可以是在一个测试环境当中，也可以在真实业务环境当中。在测试环境中，可以采用多个模拟客户端发起业务请求，如果在真实业务环境中，可以采集到真实的业务处理过程中的数据，使得第二阶段的测试更加真实。

服务虚拟化工具可以捕获并完整地记录一段时间范围内的被测服务与被模拟服务之间的消息交互内容，从而作为第二阶段对被测服务进行模拟隔离测试的基础。

步骤102.在测试任务的第二阶段中，被测服务接收业务测试请求并将业务测试请求转发给服务虚拟化工具，服务虚拟化工具基于第一阶段中所记录的业务请求和业务响应模拟被模拟服务响应所述业务测试请求。

在本公开一实施例中，在测试任务的第一阶段中，所述服务虚拟化工具记录的是真实业务场景下的业务请求和业务响应。

在本公开一实施例中，在测试任务的第二阶段开始之前，还包括对所记录的业务请求和业务响应数据进行修改的步骤。所述修改至少包括但不限于对网络延迟、业务请求的正则匹配规则的修改；在测试任务的第二阶段中，服务虚拟化工具基于被修改的第一阶段中所记录的业务请求和业务响应模拟被模拟服务响应所述业务测试请求。

在本公开一实施例中，对被测服务进行的测试可以是对被测服务进行的负载测试或压力测试，或对被测服务和链路的负载测试或压力测试。

在本公开一实施例中，所述的被测服务为应用程序接口API网关，所述的被模拟服务为微服务。进一步地，所述服务虚拟化工具为Hoverfly。

本公开提出的一种基于服务虚拟化的测试方法通过服务虚拟化工具，例如Hoverfly，录制/回放客户端经被测服务，例如API网关，发送请求给实际服务过程中的请求和响应，将实际服务“断开”，从而实现对被测服务的隔离测试，从而避免其他服务因为不稳定或不可用造成的测试误差。通过本公开的方案可以减少其他服务的部署依赖，提升测试效率；通过对所记录的测试数据进行修改，例如增加网络延迟，可进行限速等边缘测试场景，克服了在局域网中进行测试不能模拟网络和限速场景的缺陷；可对被测服务本身进行并发或压力测试等。通过本公开的方案，不会存在通过单元测试进行Mock的复杂度和开发工作量，通过捕获/回放实际的服务也能够使模拟的微服务反复使用，提高测试效率。

图2为本公开一具体实施例提供的基于服务虚拟化的测试方法中第一阶段的步骤流程图，图3为该具体实施例提供的基于服务虚拟化的测试方法中第二阶段的步骤流程图。在该实施例中，被测服务为API网关Kong，服务虚拟化工具采用Hoverfly，被模拟服务采用微服务。

Hoverfly是一种轻量的API服务模拟工具(也称为服务虚拟化工具)。它能够创建可重复使用的虚拟服务，在CI环境中替代缓慢和不稳定的服务；模拟网络的延迟，限速等场景；支持多种编程语言的扩展，如Go，Java，Python等；支持导入/导出模拟数据，易于数据管理等特点。

在第一阶段的过程开始之前，需要首先启动Hoverfly，并将Hoverfly设置为捕获模式，测试过程的具体实现步骤如下：

步骤201.通过客户端请求工具(如JMeter)向服务端发送请求；

步骤202.请求经过网关Kong处理并转发给Hoverfly；

步骤203.Hoverfly捕获并记录下请求，然后把请求发送给真实的微服务；

步骤204.后端真实的微服务在处理完请求之后会把响应发送给Hoverfly；

步骤205.Hoverfly会捕获并记录下响应，然后将响应传给Kong。

步骤206.Kong将响应返回给客户端Client。

至此，一次请求和响应的过程被Hoverfly捕捉记录下来。

在该实施例中，在进行第二阶段的步骤之前，还包括如下步骤：

步骤207.导出Hoverfly捕获的请求和响应数据；

步骤208.对导出的数据进行修改。如，增加网络的延迟，添加请求的正则匹配等；

步骤209.导入已修改的响应数据到Hoverfly，启动Hoverfly。

通过上述修改步骤，可以实现对网络的延迟、限速等边缘场景的模拟，增加系统在不同网络情况下的测试场景。

图3为该具体实施例提供的基于服务虚拟化的测试方法中第二阶段的步骤流程图，具体步骤如下：

步骤301.客户端再次向Kong发起请求；

步骤302.Kong对请求进行必要的处理后，将请求转发给Hoverfly；

步骤303.Hoverfly根据之前录制时捕获记录的存根数据找到与请求对应的响应数据，然后将响应返回给Kong；

步骤304.Kong将响应返回给客户端。

通过该实施例可知，请求不再发送给实际服务进行处理，通过这样的方式，可以将后端服务隔离开来，在开发过程中减少对后端服务的依赖，避免由于服务本身不稳定造成的测试波动。在客户端增加并发或压力，也能够对网关Kong进行性能测试，不会因后端服务的性能瓶颈造成测试误判。

应当认识到，本公开的实施例可以由计算机硬件、硬件和软件的组合、或者通过存储在非暂时性计算机可读存储器中的计算机指令来实现或实施。所述方法可以使用标准编程技术，包括配置有计算机程序的非暂时性计算机可读存储介质在计算机程序中实现，其中如此配置的存储介质使得计算机以特定和预定义的方式操作。每个程序可以以高级过程或面向对象的编程语言来实现以与计算机系统通信。然而，若需要，该程序可以以汇编或机器语言实现。在任何情况下，该语言可以是编译或解释的语言。此外，为此目的该程序能够在编程的专用集成电路上运行。

此外，可按任何合适的顺序来执行本公开描述的过程的操作，除非本公开另外指示或以其他方式明显地与上下文矛盾。本公开描述的过程(或变型和/或其组合)可在配置有可执行指令的一个或多个计算机系统的控制下执行，并且可作为共同地在一个或多个处理器上执行的代码(例如，可执行指令、一个或多个计算机程序或一个或多个应用)、由硬件或其组合来实现。所述计算机程序包括可由一个或多个处理器执行的多个指令。

进一步，所述方法可以在可操作地连接至合适的任何类型的计算平台中实现，包括但不限于个人电脑、迷你计算机、主框架、工作站、网络或分布式计算环境、单独的或集成的计算机平台、或者与带电粒子工具或其它成像装置通信等等。本公开的各方面可以以存储在非暂时性存储介质或设备上的机器可读代码来实现，无论是可移动的还是集成至计算平台，如硬盘、光学读取和/或写入存储介质、RAM、ROM等，使得其可由可编程计算机读取，当存储介质或设备由计算机读取时可用于配置和操作计算机以执行在此所描述的过程。此外，机器可读代码，或其部分可以通过有线或无线网络传输。当此类媒体包括结合微处理器或其他数据处理器实现上文所述步骤的指令或程序时，本公开所述的发明包括这些和其他不同类型的非暂时性计算机可读存储介质。当根据本公开所述的方法和技术编程时，本公开还包括计算机本身。

Claims (10)

1.一种基于服务虚拟化的测试方法，其特征在于，所述方法包括：

在测试任务的第一阶段中，被测服务接收业务请求并将业务请求转发给服务虚拟化工具；服务虚拟化工具记录业务请求并将业务请求透传给被模拟服务；接收并记录被模拟服务发送的业务响应并将业务响应透传给被测服务；

在测试任务的第二阶段中，被测服务接收业务测试请求并将业务测试请求转发给服务虚拟化工具，服务虚拟化工具基于第一阶段中所记录的业务请求和业务响应模拟被模拟服务响应所述业务测试请求。

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

在测试任务的第二阶段开始之前，还包括对所记录的业务请求和业务响应数据进行修改的步骤，所述修改至少包括对网络延迟、业务请求的正则匹配规则的修改；

在测试任务的第二阶段中，服务虚拟化工具基于被修改的第一阶段中所记录的业务请求和业务响应模拟被模拟服务响应所述业务测试请求。

3.根据权利要求1所述的方法，其特征在于，

在测试任务的第二阶段中，对被测服务进行的测试为对被测服务进行的负载测试或压力测试，或对被测服务和链路的负载测试或压力测试。

4.根据权利要求1所述的方法，其特征在于，

所述的被测服务为应用程序接口API网关，所述的被模拟服务为微服务。

5.根据权利要求1所述的方法，其特征在于，

在测试任务的第一阶段中，所述服务虚拟化工具记录的是真实业务场景下的业务请求和业务响应。

6.一种基于服务虚拟化的测试系统，其特征在于，该系统包括：

被测服务，在测试任务的第一阶段中，用于接收业务请求并将业务请求转发给服务虚拟化工具，以及接收业务响应并将业务响应转发给客户端；在测试任务的第二阶段中，用于接收业务测试请求并将业务测试请求转发给服务虚拟化工具，以及接收服务虚拟化工具针对业务测试请求的模拟响应；

服务虚拟化工具，在测试任务的第一阶段中，用于记录业务请求并将业务请求透传给被模拟服务，以及接收并记录被模拟服务发送的业务响应并将业务响应透传给被测服务；在测试任务的第二阶段中，用于基于第一阶段所记录的业务请求和业务响应模拟被模拟服务响应所述业务测试请求。

7.根据权利要求6所述的系统，其特征在于，

所述服务虚拟化工具还用于在测试任务的第二阶段开始之前，通过接口实现对所记录的业务请求和业务响应数据进行修改，所述修改至少包括对网络延迟、业务请求的正则匹配规则的修改；

在测试任务的第二阶段中，所述服务虚拟化工具基于被修改的第一阶段中所记录的业务请求和业务响应模拟被模拟服务响应所述业务测试请求。

8.根据权利要求6所述的系统，其特征在于，

在测试任务的第二阶段中，对被测服务进行的测试为对被测服务进行的负载测试或压力测试，或对被测服务和链路的负载测试或压力测试。

9.根据权利要求6所述的系统，其特征在于，

所述的被测服务为应用程序接口API网关，所述的被模拟服务为微服务。

10.根据权利要求6所述的系统，其特征在于，

在测试任务的第一阶段中，所述服务虚拟化工具记录的是真实业务场景下的业务请求和业务响应。

Images