CN112929230A - 测试处理方法、装置、电子设备及计算机可读存储介质 - Google Patents

Abstract

本申请实施例涉及软件测试技术领域，公开了一种测试处理方法、装置、电子设备及计算机可读存储介质，包括：通过云平台的测试控制平面的控制中心服务，获取目标测试套件服务的服务实例列表，实例列表中存储有每个服务实例的地址信息，每一测试套件服务及其对应的挎斗式代理Sidecar Proxy位于同一Pod中，每一Pod位于云平台的测试数据平面中、且各个Pod之间相互独立，各个Pod是基于服务网格Service Mesh的微服务中的测试网格；接着，基于服务实例列表中的每个服务实例的地址信息，对目标测试套件服务进行测试处理，测试处理包括以下至少一项：流量拦截、负载均衡、流量治理、服务监测及访问控制。

Description

测试处理方法、装置、电子设备及计算机可读存储介质

技术领域

本申请实施例涉及软件测试技术领域，具体而言，本申请涉及一种测试处理方法、装置、电子设备及计算机可读存储介质。

背景技术

随着IT技术的快速发展以及用户业务日趋复杂的背景下，在云平台上支持多种架构已是必不可少的功能，更多的用户选择使用微服务治理来解决自己的问题。其中，微服务是一种架构模式，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的进程中，服务间采用轻量级的通信机制互相沟通(通常是基于Http协议的RESTful API)。每个服务都围绕着具体业务进行构建，并且能够独立的部署到生产环境、类生产环境等。

在现有的微服务测试技术中，测试框架或工具多采用本地单体服务架构，本地单体服务架构中的测试框架或工具大多针对某一特定语言开发的。本申请发明人在具体实例过程中发现：单体架构导致不同开发语言形成的异构测试工具融合困难，由于已有测试框架或工具往往针对某一特定语言开发的系统，对于异构系统测试支持不够灵活，且测试工具间缺乏统一对接标准，导致测试开发资源浪费，同时测试框架紧耦合，致使扩展新业务成本较高。

发明内容

本申请实施例的目的旨在至少能解决上述的技术缺陷之一，特提出以下技术方案：

一方面，提供了一种测试处理方法，应用于测试套件服务的测试请求方，包括：

通过云平台的测试控制平面的控制中心服务，获取目标测试套件服务的服务实例列表，实例列表中存储有每个服务实例的地址信息，每一测试套件服务及其对应的挎斗式代理Sidecar Proxy位于同一Pod中，每一Pod位于云平台的测试数据平面中、且各个Pod之间相互独立，各个Pod是基于服务网格Service Mesh的微服务中的测试网格；

基于服务实例列表中的每个服务实例的地址信息，对目标测试套件服务进行测试处理，测试处理包括以下至少一项：流量拦截、负载均衡、流量治理、服务监测及访问控制。

在一种可能的实现方式中，通过云平台的测试控制平面的控制中心服务，获取目标测试套件服务的服务实例列表，包括：

通过测试套件服务的测试请求方的Sidecar Proxy，调用控制中心服务的服务发现接口，获取目标测试套件服务的服务实例列表。

在一种可能的实现方式中，当测试处理包括流量拦截时，基于服务实例列表中的每个服务实例的地址信息，对目标测试套件服务进行测试处理，包括：

基于测试请求方的Pod在初始化时修改配置的iptables规则，根据服务实例列表中的每个服务实例的地址信息，拦截目标测试套件服务的Inbound流量和Outbound流量。

在一种可能的实现方式中，当测试处理包括流量治理时，基于服务实例列表中的每个服务实例的地址信息，对目标测试套件服务进行测试处理，包括：

测试请求方通过其对应的Sidecar Proxy，从控制中心服务获取预配置的流量治理规则；

根据流量治理规则及服务实例列表中的每个服务实例的地址信息，对Inbound流量和Outbound流量执行相应的治理处理。

在一种可能的实现方式中，当测试处理包括负载均衡时，基于服务实例列表中的每个服务实例的地址信息，目标测试套件服务进行测试处理，包括：

测试请求方根据预配置的负载均衡策略，从目标测试套件服务中选择目标服务实例，并根据服务实例列表中的每个服务实例的地址信息，连接目标服务实例的地址信息，以对目标测试套件服务进行负载均衡配置。

在一种可能的实现方式中，当测试处理包括服务监测时，基于服务实例列表中的每个服务实例的地址信息，对目标测试套件服务进行测试处理，包括：

当测试请求方与目标测试套件服务进行通信时，根据服务实例列表中的每个服务实例的地址信息，通信双方的Sidecar Proxy分别将监测到的监测数据发送至各自对应的监控测试套件服务的服务器，以用于对通信双方进行服务监测。

在一种可能的实现方式中，当测试处理包括访问控制时，基于服务实例列表中的每个服务实例的地址信息，对目标测试套件服务进行测试处理，包括：

当测试请求方接收到目标测试套件服务的访问请求时，测试请求方通过其对应的Sidecar Proxy，从控制中心服务获取预配置的访问策略；

根据访问策略和服务实例列表中的每个服务实例的地址信息，控制测试请求方与目标测试套件服务之间的访问；

其中，测试请求方与目标测试套件服务之间的访问，包括：

测试请求方同意目标测试套件服务的访问，或者，测试请求方拒绝目标测试套件服务的访问。

一方面，提供了一种测试处理装置，应用于测试套件服务的测试请求方，包括：

第一处理模块，用于通过云平台的测试控制平面的控制中心服务，获取目标测试套件服务的服务实例列表，实例列表中存储有每个服务实例的地址信息，每一测试套件服务及其对应的挎斗式代理Sidecar Proxy位于同一Pod中，每一Pod位于云平台的测试数据平面中、且各个Pod之间相互独立，各个Pod是基于服务网格Service Mesh的微服务中的测试网格；

第二处理模块，用于基于服务实例列表中的每个服务实例的地址信息，对目标测试套件服务进行测试处理，测试处理包括以下至少一项：流量拦截、负载均衡、流量治理、服务监测及访问控制。

在一种可能的实现方式中，通过云平台的测试控制平面的控制中心服务，获取目标测试套件服务的服务实例列表，包括：

通过测试套件服务的测试请求方的Sidecar Proxy，调用控制中心服务的服务发现接口，获取目标测试套件服务的服务实例列表。

在一种可能的实现方式中，当测试处理包括流量拦截时，第二处理模块具体用于：

基于测试请求方的Pod在初始化时修改配置的iptables规则，根据服务实例列表中的每个服务实例的地址信息，拦截目标测试套件服务的Inbound流量和Outbound流量。

在一种可能的实现方式中，当测试处理包括流量治理时，第二处理模块具体用于：

测试请求方通过其对应的Sidecar Proxy，从控制中心服务获取预配置的流量治理规则；

根据流量治理规则及服务实例列表中的每个服务实例的地址信息，对Inbound流量和Outbound流量执行相应的治理处理。

在一种可能的实现方式中，当测试处理包括负载均衡时，第二处理模块具体用于：

测试请求方根据预配置的负载均衡策略，从目标测试套件服务中选择目标服务实例，并根据服务实例列表中的每个服务实例的地址信息，连接目标服务实例的地址信息，以对目标测试套件服务进行负载均衡配置。

在一种可能的实现方式中，当测试处理包括服务监测时，第二处理模块具体用于：

当测试请求方与目标测试套件服务进行通信时，根据服务实例列表中的每个服务实例的地址信息，通信双方的Sidecar Proxy分别将监测到的监测数据发送至各自对应的监控测试套件服务的服务器，以用于对通信双方进行服务监测。

在一种可能的实现方式中，当测试处理包括访问控制时，第二处理模块具体用于：

当测试请求方接收到目标测试套件服务的访问请求时，测试请求方通过其对应的Sidecar Proxy，从控制中心服务获取预配置的访问策略；

根据访问策略和服务实例列表中的每个服务实例的地址信息，控制测试请求方与目标测试套件服务之间的访问；

其中，测试请求方与目标测试套件服务之间的访问，包括：

测试请求方同意目标测试套件服务的访问，或者，测试请求方拒绝目标测试套件服务的访问。

一方面，提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行所述程序时实现上述的测试处理方法。

一方面，提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现上述的测试处理方法。

本申请实施例提供的测试处理方法，基于服务网格Service Mesh的微服务中的测试网格，可以解耦工具业务和公共能力，解决了不同语言实现的异构测试工具间融合和管控困难的问题，充分发挥测试人员技能偏好，使其采用擅长开发语言编写测试代码；通过对测试工具进行微服务化得到测试套件服务，解决了测试工具各模块间因紧密耦合导致的测试工具或框架自身性能下降、扩展复用困难的问题，同时解决了测试工具间缺乏对接标准，测试工具或框架演进实施成本高、复杂度高的问题。

本申请实施例附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请实施例上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本申请实施例的测试处理方法的流程示意图；

图2为本申请实施例的网格化云平台的示意图；

图3为本申请实施例的测试套件服务和Sidecar Proxy形成的测试网格的示意图；

图4为本申请实施例的测试处理装置的基本结构示意图；

图5为本申请实施例的电子设备的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本申请的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

下面以具体地实施例对本申请实施例的技术方案以及本申请实施例的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

本申请一个实施例提供了一种测试处理方法，该方法由计算机设备执行，该计算机设备可以是终端或者服务器。终端可以是台式设备或者移动终端。服务器可以是独立的物理服务器、物理服务器集群或者虚拟服务器。如图1所示，该方法应用于测试套件服务的测试请求方，包括：

步骤S110，通过云平台的测试控制平面的控制中心服务，获取目标测试套件服务的服务实例列表，所述实例列表中存储有每个服务实例的地址信息，每一测试套件服务及其对应的挎斗式代理Sidecar Proxy位于同一Pod中，每一Pod位于所述云平台的测试数据平面中、且各个Pod之间相互独立，所述各个Pod是基于服务网格Service Mesh的微服务中的测试网格；步骤S120，基于所述服务实例列表中的每个服务实例的地址信息，对所述目标测试套件服务进行测试处理，所述测试处理包括以下至少一项：流量拦截、负载均衡、流量治理、服务监测及访问控制。

为了实现更好的微服务管理，尤其是现在容器云平台越来越成为主流的趋势，服务网格的概念越来越成熟的走进开发者的视线。为了实现更好的微服务管理，尤其是现在容器云平台越来越成为主流的趋势，服务网格的概念越来越成熟的走进开发者的视线。服务网格的职责，在于处理服务间通讯，这正是服务治理的核心所在。服务网格的实现通常是提供一个代理实例，我们称之为"sidecar"。sidecar包含在每一个service之中。针对每一个服务实例，服务网格都会在同一主机上一对一并行部署一个边车进程，接管该服务实例所有对外的网络通讯，任何可以从服务本体中抽象出来的安全方面的部分。通过这种方式，开发者可以在服务中专注于开发、支持以及维护，运维人员可以维护服务网格并运行app(应用程序)。

Pod是Kubernetes集群中的一个应用实例，总是部署在同一个节点上。Pod中包含了一个或多个容器，还包括了存储、网络等各个容器共享的资源。Pod支持多种容器环境，Docker则是最流行的容器环境。

Sidecar是挎斗模式，是将应用程序的组件部署到单独的进程或容器中，以提供隔离和封装。使用此模式还可以使用异构组件和技术来构建应用程序。

本申请实施例的网格化云平台的示意图如图1所示，所有组件均运行于基于k8s的云平台，包含测试控制平面和测试数据平面，其中，测试数据平面包含各种微服务测试套件服务，例如自研测试工具、开源测试工具、监控服务、链路追踪服务、挡板服务、存储服务、日志服务、可视化服务等。Sidecar Proxy集成TCP/HTTP/RPC/JDBC服务通信代理、负载均衡、流量治理等，用于测试套件集群的流量劫持，并接受测试控制平面的组件的控制。每个微服务测试套件(即测试套件服务)和Sidecar Proxy部署在同一pod，多组pod构成测试网格，如图3所示。换言之，每一测试套件服务及其对应的挎斗式代理Sidecar Proxy位于同一Pod中，每一Pod位于云平台的测试数据平面中、且各个Pod之间相互独立，各个Pod是基于服务网格Service Mesh的微服务中的测试网格。其中，测试套件服务是通过对相应的测试工具进行微服务化处理得到的。

图2中的测试控制平面为本申请实施例的总控，包含策略配置模块(负责策略配置)，可视化模块(负责展示监控数据)，管理中枢模块(负责部署测试策略、测试策略的修改及下发、部署Sidecar、服务容器注入和服务发现等)。

本申请实施例是基于Service Mesh微服务架构形成测试网格的，其与容器技术相结合，将测试工具(即测试套件服务)容器化，并在每种测试工具所在pod内部署Sidecar，同时将测试公共能力集成于Sidecar中。其中，测试脚本开发无需局限于特定编程语言，为异构测试工具提供更好的融合模式；各测试套件服务可以快速地增减测试工具实例以适应测试活动，测试工具集的负载均衡、流量治理、服务监测数据采集等能力由微服务Sidecar托管输出。

本申请实施例对测试套件服务进行微服务化，各个测试套件服务的职责分明，例如，压测服务只负责压力构造，监控服务只负责资源监控，报告服务只负责测试分析接收报告生成。每个测试工具从开发到交付整条链路上独立进行，大大加快测试工具的迭代和交付效率，有效缩短测试实施周期。

本申请实施例提供了各个测试套件服务之间的标准化接口，即将服务间API统一和标准化，摒弃层层类库依赖，各测试套件服务间可灵活搭配、快速形成新的测试框架或工具，提升上下游服务复用能力和灵活性，降低工具开发复杂度。

本申请实施例提供的测试处理方法，基于服务网格Service Mesh的微服务中的测试网格，可以解耦工具业务和公共能力，解决了不同语言实现的异构测试工具间融合和管控困难的问题，充分发挥测试人员技能偏好，通过控制面板配置测试服务部署信息及测试执行策略，在k8s上创建测试套件并自动注入Sidecar Proxy。

使其采用擅长开发语言编写测试代码；通过对测试工具进行微服务化得到测试套件服务，解决了测试工具各模块间因紧密耦合导致的测试工具或框架自身性能下降、扩展复用困难的问题，同时解决了测试工具间缺乏对接标准，测试工具或框架演进实施成本高、复杂度高的问题。

下面对本申请实施例进行具体介绍：

本申请实施例的执行流程可以为部署和运行两个过程，其中，部署过程可以为：

在k8s中创建Pod时，Kube-apiserver调用控制面的控制中心组件进行策略修改，自动修改测试套件的yaml(是一个可读性高，用来表达数据序列化的格式)描述信息并注入Sidecar Proxy。在真正创建Pod时，在创建业务容器的Pod中同时创建Sidecar Proxy容器。其中，Kube-apiserver相当于是k8集群的一个入口，提供了k8s的rest api，实现了认证、授权和准入控制等安全功能,同时也负责了集群状态的存储操作。

运行过程可以为：

(1)测试工具发送测试请求，调用控制中心进行服务发现；

测试套件服务发起方的Sidecar Proxy调用测试控制平面的控制中心的服务发现接口，获取目标测试套件服务的实例列表。如图2所示，测试引擎服务侧的Sidecar Proxy，通过测试控制平面的控制中心的服务发现接口，得到监控服务各个服务实例的地址。相当于，通过云平台的测试控制平面的控制中心服务，获取目标测试套件服务的服务实例列表，包括：通过测试套件服务的测试请求方的Sidecar Proxy，调用控制中心服务的服务发现接口，获取目标测试套件服务的服务实例列表。

(2)基于Sidecar Proxy进行流量拦截；

在Pod初始化时修改iptables规则，基于配置的iptables规则拦截测试套件容器的Inbound流量和Outbound流量到Sidecar Proxy上。这里的inbound/outbound都是对交换机而言，即，inbound是从外向交换机方向的流量outbound是交换机发往外部的流量，以连接服务器的1/0/6端口来说，inbound是服务器到交换机的流量，outbound则是交换机到服务器的流量。相当于，当测试处理包括流量拦截时，基于服务实例列表中的每个服务实例的地址信息，对目标测试套件服务进行测试处理，包括：基于测试请求方的Pod在初始化时修改配置的iptables规则，根据服务实例列表中的每个服务实例的地址信息，拦截目标测试套件服务的Inbound流量和Outbound流量。

需要说明的是，在这个过程中各个测试套件服务感知不到Sidecar Proxy的存在，还以原本的方式进行互相访问(即进行通信)。如图2所示，流出测试引擎服务的流量会被监控服务侧的Sidecar Proxy拦截，而当流量到达测试引擎容器时，Inbound流量被测试引擎服务侧的Sidecar Proxy拦截。

(3)基于Sidecar Proxy进行流量治理；

Sidecar Proxy从控制中心中获取配置的流量规则，在拦截到Inbound流量和Outbound流量时执行治理逻辑。如图2所示，测试引擎服务侧的Sidecar Proxy从控制中心中获取流量治理规则，并根据该流量治理规则将不同特征的流量分发到外部被测服务服务的v1或v2版本。相当于，当测试处理包括流量治理时，基于所述服务实例列表中的每个服务实例的地址信息，对目标测试套件服务进行测试处理，包括：测试请求方通过其对应的Sidecar Proxy，从控制中心服务获取预配置的流量治理规则；根据流量治理规则及服务实例列表中的每个服务实例的地址信息，对Inbound流量和Outbound流量执行相应的治理处理。

(4)基于Sidecar Proxy进行负载均衡；

测试套件服务发起方的Sidecar Proxy根据配置的负载均衡策略选择服务实例，并连接对应的实例地址。如图2所示，数据面的各个Sidecar Proxy从策略配置中心中获取挡板服务的负载均衡配置，并执行负载均衡动作。相当于，当测试处理包括负载均衡时，基于服务实例列表中的每个服务实例的地址信息，目标测试套件服务进行测试处理，包括：测试请求方根据预配置的负载均衡策略，从目标测试套件服务中选择目标服务实例，并根据服务实例列表中的每个服务实例的地址信息，连接目标服务实例的地址信息，以对目标测试套件服务进行负载均衡配置。

(5)基于Sidecar Proxy进行服务监测

在服务间通信时，通信双方的Sidecar Proxy都会将监测数据转发给对应的监控测试套件后端。如图2所示，测试引擎服务对外部被测系统的访问监控指标、日志和调用链都可以通过这种方式收集到对应的监控测试套件后端。相当于，当测试处理包括服务监测时，基于服务实例列表中的每个服务实例的地址信息，对目标测试套件服务进行测试处理，包括：当测试请求方与目标测试套件服务进行通信时，根据服务实例列表中的每个服务实例的地址信息，通信双方的Sidecar Proxy分别将监测到的监测数据发送至各自对应的监控测试套件服务的服务器，以用于对所述通信双方进行服务监测。

(6)基于Sidecar Proxy进行策略执行；

在进行服务访问时，Sidecar Proxy从控制中心获取策略配置来控制服务间的访问，判断对访问是放行还是拒绝。在Figure1中，Sidecar Proxy可以对接一个限流服务对从测试引擎服务到外部被测服务的访问进行速率控制等操作。相当于，当测试处理包括访问控制时，基于服务实例列表中的每个服务实例的地址信息，对目标测试套件服务进行测试处理，包括：当测试请求方接收到目标测试套件服务的访问请求时，测试请求方通过其对应的Sidecar Proxy，从控制中心服务获取预配置的访问策略；根据访问策略和服务实例列表中的每个服务实例的地址信息，控制测试请求方与目标测试套件服务之间的访问。其中，测试请求方与目标测试套件服务之间的访问，包括：测试请求方同意目标测试套件服务的访问，或者，测试请求方拒绝目标测试套件服务的访问。

(7)控制面板的可视化展示

Sidecar Proxy采集的调用链及监控数据汇聚至监控服务后端，通过集成控制面板的可视化展示监控数据。

本申请实施例的测试套件服务和Sidecar Proxy形成的测试网格如图3所示。

本申请实施例已经在基于Scala语法的自研压测服务工具中得到使用。在实际应用中，以微服务形式构建基于Java语言的自研压测服务(负责同步线程模型压测)，基于Go语言的监控服务(负责资源监控)，基于NODEJS的挡板服务(负责服务虚拟化)，基于JS的测试报告展示平台(负责测试报告展示)。其中，各服务之间通过标准API协议交互，基于Sidecar Proxy集成监控数据采集、流量控制能力。因测试需求变更，现需要集成一款自研异步压测工具，该工具使用Scala语言实现，使用本申请实施例，测试人员只需开发该工具，通过标准的API接口协议，复用本发明装置的Go监控服务、NODEJS挡板服务、JS测试报告展示平台，无需关注负载均衡，流量治理，服务监测数据采集等能力，快速完成了一套完整测试工具的开发。

本申请实施例已在IT服务网关性能测试项目中应用。主要包括：

在进行IT服务网关性能测试过程中，通过该发明控制面板策略中心配置服务列表(这些服务包括Java自研压测服务，Scala自研压测服务,GO监控服务，NODEJS挡板服务，JS测试报告展示平台)。

测试应用一：限流场景，因需求场景前端是同步线程模型方式，故使用同步线程模型的JAVA自研压测服务实施测试；配置自研压测服务限流策略(1500TPS)，部署测试套件至本发明装置，启动挡板服务，挡板侧Sidecar Proxy通过控制面板策略中心获取IT服务网关白名单，接受被测IT服务网关的服务请求；开启自研压测服务对网关服务实施压测，Sidecar Proxy拦截自研压测服务流量，根据控制面板策略中心的限流配置(1500TPS)，Sidecar Proxy可稳定向被测IT服务网关发送流量(1500TPS)，实现精准网关限流测试；测试期间，监控服务接受自研压测服务侧Sidecar Proxy的监测数据(压测数据及资源监控数据)和被测IT服务网关监控数据(应用及资源监控数据)，存储至监控服务后台；通过控制面板可视化查看测试报告数据

测试应用二：最优TPS场景，因需求场景是评测系统最优TPS，可忽略网关前端服务的连接方式。在该场景中，Scala自研压测工具在网格化测试工具中胜出，为最匹配工具，其具有优良的TPS探测能力，故选用Scala自研压测服务实施测试。测试期间，可通过复用GO监控服务，NODEJS挡板服务，JS测试报告展示平台实时查看测试情况。

本申请实施例在新测试工具开发过程中，测试开发人员可专注于特定功能本身，使用自己擅长的语言进行开发，只需遵守约定的API规则，充分发挥多语言异构系统的威力，百家争鸣，节省测试开发人力，提升效率。在性能测试过程中，可根据场景选择合适的测试工具，真正达到做自己擅长的事的目的，提供丰富的测试模型，提升测试效率。

图4为本申请又一实施例提供的一种测试处理装置的结构示意图，如图4所示，该装置400应用于测试套件服务的测试请求方，可以包括第一处理模块401与第二处理模块402，其中：

第一处理模块401，用于通过云平台的测试控制平面的控制中心服务，获取目标测试套件服务的服务实例列表，实例列表中存储有每个服务实例的地址信息，每一测试套件服务及其对应的挎斗式代理Sidecar Proxy位于同一Pod中，每一Pod位于云平台的测试数据平面中、且各个Pod之间相互独立，各个Pod是基于服务网格Service Mesh的微服务中的测试网格；

第二处理模块402，用于基于服务实例列表中的每个服务实例的地址信息，对目标测试套件服务进行测试处理，测试处理包括以下至少一项：流量拦截、负载均衡、流量治理、服务监测及访问控制。

在一种可能的实现方式中，通过云平台的测试控制平面的控制中心服务，获取目标测试套件服务的服务实例列表，包括：

通过测试套件服务的测试请求方的Sidecar Proxy，调用控制中心服务的服务发现接口，获取目标测试套件服务的服务实例列表。

在一种可能的实现方式中，当测试处理包括流量拦截时，第二处理模块具体用于：

基于测试请求方的Pod在初始化时修改配置的iptables规则，根据服务实例列表中的每个服务实例的地址信息，拦截目标测试套件服务的Inbound流量和Outbound流量。

在一种可能的实现方式中，当测试处理包括流量治理时，第二处理模块具体用于：

测试请求方通过其对应的Sidecar Proxy，从控制中心服务获取预配置的流量治理规则；

根据流量治理规则及服务实例列表中的每个服务实例的地址信息，对Inbound流量和Outbound流量执行相应的治理处理。

在一种可能的实现方式中，当测试处理包括负载均衡时，第二处理模块具体用于：

测试请求方根据预配置的负载均衡策略，从目标测试套件服务中选择目标服务实例，并根据服务实例列表中的每个服务实例的地址信息，连接目标服务实例的地址信息，以对目标测试套件服务进行负载均衡配置。

在一种可能的实现方式中，当测试处理包括服务监测时，第二处理模块具体用于：

当测试请求方与目标测试套件服务进行通信时，根据服务实例列表中的每个服务实例的地址信息，通信双方的Sidecar Proxy分别将监测到的监测数据发送至各自对应的监控测试套件服务的服务器，以用于对通信双方进行服务监测。

在一种可能的实现方式中，当测试处理包括访问控制时，第二处理模块具体用于：

当测试请求方接收到目标测试套件服务的访问请求时，测试请求方通过其对应的Sidecar Proxy，从控制中心服务获取预配置的访问策略；

根据访问策略和服务实例列表中的每个服务实例的地址信息，控制测试请求方与目标测试套件服务之间的访问；

其中，测试请求方与目标测试套件服务之间的访问，包括：

测试请求方同意目标测试套件服务的访问，或者，测试请求方拒绝目标测试套件服务的访问。

本申请实施例提供的装置，基于服务网格Service Mesh的微服务中的测试网格，可以解耦工具业务和公共能力，解决了不同语言实现的异构测试工具间融合和管控困难的问题，充分发挥测试人员技能偏好，使其采用擅长开发语言编写测试代码；通过对测试工具进行微服务化得到测试套件服务，解决了测试工具各模块间因紧密耦合导致的测试工具或框架自身性能下降、扩展复用困难的问题，同时解决了测试工具间缺乏对接标准，测试工具或框架演进实施成本高、复杂度高的问题。

需要说明的是，本实施例为与上述的方法项实施例相对应的装置项实施例，本实施例可与上述方法项实施例互相配合实施。上述方法项实施例中提到的相关技术细节在本实施例中依然有效，为了减少重复，这里不再赘述。相应地，本实施例中提到的相关技术细节也可应用在上述方法项实施例中。

本申请另一实施例提供了一种电子设备，如图5所示，图5所示的电子设备500包括：处理器501和存储器503。其中，处理器501和存储器503相连，如通过总线502相连。进一步地，电子设备500还可以包括收发器504。需要说明的是，实际应用中收发器504不限于一个，该电子设备500的结构并不构成对本申请实施例的限定。

其中，处理器501应用于本申请实施例中，用于实现图4所示的第一处理模块及第二处理模块的功能。收发器504包括接收机和发射机。

处理器501可以是CPU，通用处理器，DSP，ASIC，FPGA或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器501也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线502可包括一通路，在上述组件之间传送信息。总线502可以是PCI总线或EISA总线等。总线502可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器503可以是ROM或可存储静态信息和指令的其他类型的静态存储设备，RAM或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM、CD-ROM或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

存储器503用于存储执行本申请方案的应用程序代码，并由处理器501来控制执行。处理器501用于执行存储器503中存储的应用程序代码，以实现图4所示实施例提供的测试处理装置的动作。

本申请实施例提供的电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时，可实现：通过云平台的测试控制平面的控制中心服务，获取目标测试套件服务的服务实例列表，实例列表中存储有每个服务实例的地址信息，每一测试套件服务及其对应的挎斗式代理Sidecar Proxy位于同一Pod中，每一Pod位于云平台的测试数据平面中、且各个Pod之间相互独立，各个Pod是基于服务网格ServiceMesh的微服务中的测试网格；接着，基于服务实例列表中的每个服务实例的地址信息，对目标测试套件服务进行测试处理，测试处理包括以下至少一项：流量拦截、负载均衡、流量治理、服务监测及访问控制。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现上述实施例所示的方法。其中，基于服务网格Service Mesh的微服务中的测试网格，可以解耦工具业务和公共能力，解决了不同语言实现的异构测试工具间融合和管控困难的问题，充分发挥测试人员技能偏好，使其采用擅长开发语言编写测试代码；通过对测试工具进行微服务化得到测试套件服务，解决了测试工具各模块间因紧密耦合导致的测试工具或框架自身性能下降、扩展复用困难的问题，同时解决了测试工具间缺乏对接标准，测试工具或框架演进实施成本高、复杂度高的问题。

本申请实施例提供的计算机可读存储介质适用于上述方法的任一实施例。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上所述仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种测试处理方法，其特征在于，应用于测试套件服务的测试请求方，包括：

通过云平台的测试控制平面的控制中心服务，获取目标测试套件服务的服务实例列表，所述实例列表中存储有每个服务实例的地址信息，每一测试套件服务及其对应的挎斗式代理Sidecar Proxy位于同一Pod中，每一Pod位于所述云平台的测试数据平面中、且各个Pod之间相互独立，所述各个Pod是基于服务网格Service Mesh的微服务中的测试网格；

基于所述服务实例列表中的每个服务实例的地址信息，对所述目标测试套件服务进行测试处理，所述测试处理包括以下至少一项：流量拦截、负载均衡、流量治理、服务监测及访问控制。

2.根据权利要求1所述的方法，其特征在于，所述通过云平台的测试控制平面的控制中心服务，获取目标测试套件服务的服务实例列表，包括：

通过测试套件服务的测试请求方的Sidecar Proxy，调用所述控制中心服务的服务发现接口，获取目标测试套件服务的服务实例列表。

3.根据权利要求1或2所述的方法，其特征在于，当所述测试处理包括流量拦截时，所述基于所述服务实例列表中的每个服务实例的地址信息，对所述目标测试套件服务进行测试处理，包括：

基于所述测试请求方的Pod在初始化时修改配置的iptables规则，根据所述服务实例列表中的每个服务实例的地址信息，拦截所述目标测试套件服务的Inbound流量和Outbound流量。

4.根据权利要求3所述的方法，其特征在于，当所述测试处理包括流量治理时，所述基于所述服务实例列表中的每个服务实例的地址信息，对所述目标测试套件服务进行测试处理，包括：

所述测试请求方通过其对应的Sidecar Proxy，从所述控制中心服务获取预配置的流量治理规则；

根据所述流量治理规则及所述服务实例列表中的每个服务实例的地址信息，对所述Inbound流量和所述Outbound流量执行相应的治理处理。

5.根据权利要求1或2所述的方法，其特征在于，当所述测试处理包括负载均衡时，所述基于所述服务实例列表中的每个服务实例的地址信息，所述目标测试套件服务进行测试处理，包括：

所述测试请求方根据预配置的负载均衡策略，从所述目标测试套件服务中选择目标服务实例，并根据所述服务实例列表中的每个服务实例的地址信息，连接所述目标服务实例的地址信息，以对所述目标测试套件服务进行负载均衡配置。

6.根据权利要求1或2所述的方法，其特征在于，当所述测试处理包括服务监测时，所述基于所述服务实例列表中的每个服务实例的地址信息，对所述目标测试套件服务进行测试处理，包括：

当所述测试请求方与所述目标测试套件服务进行通信时，根据所述服务实例列表中的每个服务实例的地址信息，通信双方的Sidecar Proxy分别将监测到的监测数据发送至各自对应的监控测试套件服务的服务器，以用于对所述通信双方进行服务监测。

7.根据权利要求1或2所述的方法，其特征在于，当所述测试处理包括访问控制时，所述基于所述服务实例列表中的每个服务实例的地址信息，对所述目标测试套件服务进行测试处理，包括：

当所述测试请求方接收到所述目标测试套件服务的访问请求时，所述测试请求方通过其对应的Sidecar Proxy，从所述控制中心服务获取预配置的访问策略；

根据所述访问策略和所述服务实例列表中的每个服务实例的地址信息，控制所述测试请求方与所述目标测试套件服务之间的访问；

其中，所述测试请求方与所述目标测试套件服务之间的访问，包括：

所述测试请求方同意所述目标测试套件服务的访问，或者，所述测试请求方拒绝所述目标测试套件服务的访问。

8.一种测试处理装置，其特征在于，应用于测试套件服务的测试请求方，包括：

第一处理模块，用于通过云平台的测试控制平面的控制中心服务，获取目标测试套件服务的服务实例列表，所述实例列表中存储有每个服务实例的地址信息，每一测试套件服务及其对应的挎斗式代理Sidecar Proxy位于同一Pod中，每一Pod位于所述云平台的测试数据平面中、且各个Pod之间相互独立，所述各个Pod是基于服务网格Service Mesh的微服务中的测试网格；

第二处理模块，用于基于所述服务实例列表中的每个服务实例的地址信息，对所述目标测试套件服务进行测试处理，所述测试处理包括以下至少一项：流量拦截、负载均衡、流量治理、服务监测及访问控制。

9.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1-7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现权利要求1-7任一项所述的方法。

Images