CN115203035A - 一种基于边车技术的云原生应用测试方法和系统 - Google Patents

Abstract

本申请涉及云原生技术领域，提供了一种基于边车技术的云原生应用测试方法和系统。该方法包括：对云原生应用的资源文件的变化情况进行监听；响应于云原生应用的资源文件新增至少一个测试配置信息，确定云原生应用所在的容器组；根据测试配置信息，以边车容器的形式为容器组注入至少一个测试组件；其中，云原生应用为容器云平台中部署的任一应用，测试组件用于对云原生应用执行相应的测试操作。如此，借助容器云平台能够实时感知资源文件的变化情况的功能特点，基于边车技术对云原生应用进行功能扩展，使其能够根据测试配置信息以边车容器的形式为容器组动态注入测试组件，灵活便捷地对容器云平台中的云原生应用进行测试。

Description

一种基于边车技术的云原生应用测试方法和系统

技术领域

本申请涉及云原生技术领域，特别涉及一种基于边车技术的云原生应用测试方法、系统、计算机可读存储介质和电子设备。

背景技术

在云原生场景下，为了充分验证新版本的云原生应用的质量，会使用真实的访问请求来访问新版本的云原生应用，以对新版本的云原生应用进行类似真实场景的全面测试，并且，在这个过程中不能影响现有版本的云原生应用对访问请求的正常响应。

相关技术中，通过拦截器或者支持访问请求复制的代理软件，对现有版本云原生应用的真实访问请求进行复制，然后将复制的访问请求分发到不同版本的云原生应用，从而实现不同版本的云原生应用的真实场景下的测试。

然而，无论是使用拦截器还是使用代理软件，对访问请求的复制均需要比较复杂的配置操作，将相关技术应用于云原生场景，无法灵活便捷地对应用进行测试，无法满足云原生场景下的应用测试需求。

因此，需要提供一种针对上述现有技术不足的改进技术方案。

发明内容

本申请的目的在于提供一种基于边车技术的云原生应用测试方法、系统、计算机可读存储介质和电子设备，以解决或缓解上述现有技术中存在的问题。

为了实现上述目的，本申请提供如下技术方案：

第一方面，本申请实施例提供了一种基于边车技术的云原生应用测试方法，所述方法应用于应用测试控制器，所述应用测试控制器部署在容器云平台中，包括：

对所述云原生应用的资源文件的变化情况进行监听；

响应于所述云原生应用的资源文件新增至少一个测试配置信息，确定所述云原生应用所在的容器组；

根据所述测试配置信息，以边车容器的形式为所述容器组注入至少一个测试组件；

其中，所述云原生应用为所述容器云平台中部署的任一应用，所述测试组件用于对所述云原生应用执行相应的测试操作。

上述方案中，所述测试配置信息包括请求复制注解，

对应地，

所述响应于所述云原生应用的资源文件新增至少一个测试配置信息，确定所述云原生应用所在的容器组；根据所述测试配置信息，以边车容器的形式为所述容器组注入至少一个测试组件，具体为：

响应于第一应用的资源文件新增至少一个请求复制注解，确定所述第一应用所在的第一容器组；

根据所述请求复制注解，以边车容器的形式为所述第一容器组注入至少一个请求复制组件；

其中，所述请求复制组件用于对向所述第一应用发送的访问请求进行复制，以得到访问请求副本，并将所述访问请求副本、所述访问请求分别转发至第二应用和所述第一应用，以由所述第二应用对所述访问请求副本进行处理，得到所述第二应用的测试结果；其中，所述第一应用为现有版本的所述云原生应用；所述第二应用为新版本的所述云原生应用。

上述方案中，所述测试配置信息包括结果分析注解，

对应地，

所述响应于所述云原生应用的资源文件新增至少一个测试配置信息，确定所述云原生应用所在的容器组；根据所述测试配置信息，以边车容器的形式为所述容器组注入至少一个测试组件，具体为：

响应于所述第二应用的资源文件新增至少一个结果分析注解，确定所述第二应用所在的第二容器组；

根据所述结果分析注解，以边车容器的形式为所述第二容器组注入至少一个结果分析组件；

其中，所述结果分析组件用于处理所述第二应用的测试结果。

上述方案中，所述结果分析注解包括结果分析模型的标识信息，

对应地，

所述结果分析组件具体用于：

根据所述结果分析模型的标识信息，确定所述结果分析模型；

基于所述结果分析模型对所述第二应用的测试结果进行分析，得到分析结果；

将所述第二应用的测试结果以及所述分析结果存储至存储系统。

上述方案中，所述第二应用有多个，多个所述第二应用为不同新版本的所述云原生应用，所述第一应用的资源文件中新增的每个所述请求复制注解分别与每个所述第二应用相对应；

对应地，

所述响应于所述第二应用的资源文件新增至少一个结果分析注解，确定所述第二应用所在的第二容器组；根据所述结果分析注解，以边车容器的形式为所述第二容器组注入至少一个结果分析组件，具体为：

响应于多个所述第二应用的资源文件新增至少一个结果分析注解，确定每个所述第二应用所在的第二容器组；

根据所述结果分析注解，以边车容器的形式为各所述第二容器组注入至少一个结果分析组件。

上述方案中，所述请求复制注解包括所述第二应用所在的第二容器组的标识信息；

对应地，

所述请求复制组件还用于：

根据所述第二应用所在的第二容器组的标识信息，确定所述第二应用所在的第二容器组；

与所述第二容器组建立网络连接，以将所述访问请求副本转发至所述第二应用。

上述方案中，所述方法还包括：

响应于所述云原生应用的资源文件删除至少一个测试配置信息，确定所述云原生应用所在的容器组；

根据所述测试配置信息，删除所述容器组中对应的所述测试组件。

第二方面，本申请实施例提供了一种基于边车技术的云原生应用测试系统，所述系统包括应用测试控制器，所述应用测试控制器部署在容器云平台中，所述应用测试控制器包括资源监听单元、测试配置单元和组件注入单元，其中，

资源监听单元，配置为对所述云原生应用的资源文件的变化情况进行监听；

测试配置单元，配置为响应于所述云原生应用的资源文件新增至少一个测试配置信息，确定所述云原生应用所在的容器组；

组件注入单元，配置为根据所述测试配置信息，以边车容器的形式为所述容器组注入至少一个测试组件；

其中，所述云原生应用为所述容器云平台中部署的任一应用，所述测试组件用于对所述云原生应用执行相应的测试操作。

第三方面，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序为如上任一所述的基于边车技术的云原生应用测试方法。

第四方面，本申请实施例还提供了一种电子设备，包括：存储器、处理器、以及存储在所述存储器中并可在所述处理器上运行的程序，所述处理器执行所述程序时实现如上任一所述的基于边车技术的云原生应用测试方法。

有益效果：

本申请实施例提供的基于边车技术的云原生应用测试方法中，通过在容器云平台中部署应用测试控制器，对云原生应用的资源文件的变化情况进行监听，在云原生应用的资源文件新增至少一个测试配置信息的情况下，确定云原生应用所在的容器组；然后根据所新增的至少一个测试配置信息，以边车容器的形式为容器组注入至少一个测试组件，通过测试组件对云原生应用执行相应的测试操作。如此，借助容器云平台能够实时感知部署其中的云原生应用的资源文件的变化情况的功能特点，基于边车技术对云原生应用的功能进行灵活扩展，以边车容器的形式为容器组动态注入与云原生应用的业务相对独立的测试组件，只需通过简单的配置操作即可进行测试组件配置，灵活便捷地对容器云平台中的云原生应用进行测试，以满足云原生场景下的应用测试需求。

附图说明

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

图1为根据本申请的一些实施例提供的基于边车技术的云原生应用测试方法的流程示意图；

图2为根据本申请的一些实施例提供的云原生应用对访问请求处理的逻辑示意图；

图3为根据本申请的一些实施例提供的基于边车技术的云原生应用测试方法的逻辑示意图；

图4为根据本申请的一些实施例提供的基于边车技术的云原生应用测试系统的结构示意图；

图5为根据本申请的一些实施例提供的电子设备的结构示意图；

图6为根据本申请的一些实施例提供的电子设备的硬件结构图。

具体实施方式

下面将参考附图并结合实施例来详细说明本申请。各个示例通过本申请的解释的方式提供而非限制本申请。实际上，本领域的技术人员将清楚，在不脱离本申请的范围或精神的情况下，可在本申请中进行修改和变型。例如，示为或描述为一个实施例的一部分的特征可用于另一个实施例，以产生又一个实施例。因此，所期望的是，本申请包含归入所附权利要求及其等同物的范围内的此类修改和变型。

在以下描述中，所涉及的术语“第一/第二/第三”仅仅是区别类似的对象，不代表对对象的特定排序，可以理解地，“第一/第二/第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除另有定义，本文所使用的所有的技术和科学术语与属于本公开的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本公开实施例的目的，不是旨在限制本公开。

在计算机软件应用开发过程中，通常需要对开发的应用进行各种测试，并根据测试结果对应用代码进行修改和完善。应用测试大致被分为四个阶段，分别是单元测试、集成测试、系统测试和验收测试，其中验收测试又被称作交付测试，是在应用正式发布之前进行的最终测试，通过验收测试的应用即可正式部署上线。验收测试采用黑盒测试技术，需要使用真实数据对应用进行测试。

验收测试具体又可以分为Alpha测试和Beta测试。Alpha测试是由真实用户在开发环境下进行的测试，或者是软件开发人员在模拟实际操作环境下进行的受控测试，Beta测试是由真实用户在实际使用环境下进行的测试。

在云原生场景下，当对新版本的云原生应用进行Beta测试时，为了达到充分验证新版本的云原生应用的质量并且不影响现有版本的云原生应用的正常访问的目的，通常需要将现有版本的云原生应用和新版本的云原生应用一并部署在容器云平台的环境中，并对访问请求进行复制和分发，使现有版本和新版本的云原生应用同时对访问请求进行处理，然后将现有版本的云原生应用的处理结果作为响应发送给接收方，而将新版本的云原生应用的处理结果作为新版本的云原生应用的测试结果进行分析和留存。

相关技术中，使用拦截器或者支持访问请求复制的代理软件来对访问请求进行复制，并将复制后的访问请求分别发送给不同版本的云原生应用。

具体来说，使用拦截器的方案是在现有版本的云原生应用的代码中添加拦截功能模块作为拦截器，拦截器作为现有版本的云原生应用的访问请求入口，在对访问请求进行拦截和复制后，让访问请求正常进入现有版本的云原生应用，并将复制生成的访问请求副本发送至新版本的云原生应用。

使用代理软件的方案是在容器云平台的环境中部署代理软件，在代理软件中进行访问请求复制的功能配置和访问请求转发的配置，将原先指向现有版本的云原生应用的访问请求发送至代理软件进行复制，再将复制得到的两份相同的访问请求分别发送至现有版本的云原生应用和新版本的云原生应用。

然而，相关技术中，使用拦截器进行访问请求复制时，需要在现有版本的云原生应用的源代码中增加功能模块，即需要对每一个相关的云原生应用进行代码修改，导致拦截器与云原生应用的功能实现高度耦合，从而使得基于拦截器的云原生应用测试的实施和维护难度较高。

使用代理软件进行访问请求复制时，需要依赖代理软件的请求复制和请求转发功能，并且，请求复制和请求转发功能也需要在代理软件中进行相应的规则配置，这些配置不仅操作繁琐，而且无法通过自动化的方式实现，大大降低了云原生应用的测试效率。

随着云原生技术的发展，微服务架构逐步成为了云原生领域的主流架构。在微服务架构下，业务系统被拆分为多个微服务应用作为业务模块，每个业务模块分别提供一部分业务功能，共同对外提供服务。整体上属于同一个业务系统的不同业务模块之间在对外提供服务过程中存在复杂的调用关系。

也就是说，微服务架构对云原生应用的测试管理效率和测试灵活性提出了更高的要求。一方面，不同微服务应用之间需要相互发送访问请求，使得整个业务系统的访问请求传输路径十分复杂。基于此，当需要用真实访问请求对新版本的云原生应用进行测试时，不论是使用拦截器进行访问请求复制的代码修改，还是使用代理软件进行访问请求复制时请求转发规则的配置，其难度和复杂程度均大幅度提高，导致云原生应用的测试管理效率较低。另一方面，在微服务架构下需要频繁地对不同的微服务应用进行升级，每次升级前都需要对新版本的微服务应用进行测试。在此场景下，由于无论是使用拦截器还是使用代理软件，都无法灵活地设置或者取消对访问请求的复制，无法满足微服务应用频繁升级时对测试灵活性的需求。

此外，相关技术中，对新版本的云原生应用对访问请求副本的处理结果也缺乏有效的管理和控制。比如，需要在拦截器或者代理软件做特定的配置，以避免新版本的云原生应用对访问请求副本的处理结果和现有版本的云原生应用对访问请求的处理结果都被当作响应发送给响应接收方。

由此可见，现有技术存在的操作繁琐、缺乏灵活性等不足，使其无法适应微服务架构下新版本的微服务应用的测试需求。

为了解决在云原生场景下应用测试操作繁琐、缺乏灵活性等问题，申请人提供了一种基于边车技术的云原生应用测试方法，通过在容器云平台中部署应用测试控制器，对所有云原生应用的资源文件的变化情况进行监听，当检测到云原生应用的资源文件新增至少一个测试配置信息时，通过云原生应用的资源文件确定云原生应用所在的容器组，并以边车容器的形式为云原生应用所在的容器组注入至少一个测试组件。这样，借助容器云平台能够实时感知部署其中的云原生应用的资源文件的变化情况的功能特点，充分利用边车技术能够对同一容器组中的云原生应用进行功能拓展的优势，以边车容器的形式动态注入测试组件，以执行相应的测试操作，使得测试组件无需与云原生应用的代码耦合，也不需要对测试所需的请求复制和请求转发规则进行配置，通过简单、快捷的配置即可实现云原生应用灵活、高效的测试。

示例性方法

本申请实施例提供一种基于边车技术的云原生应用测试方法，如图1、图2、图3所示，该方法应用于应用测试控制器，应用测试控制器部署在容器云平台中，该方法包括：

步骤S101、对云原生应用的资源文件的变化情况进行监听。

这里，云原生应用指的是以云计算的思想构建并适用于云计算环境的应用，是独立的、小规模松散耦合的、互相协作的可部署单元，其通过频繁发布、快来交付、快速反馈以满足用户的需求变化。

本申请实施例中，云原生应用可以是容器云平台中部署的任一应用。

其中，容器云平台是依靠容器技术，结合云原生技术，采用容器、容器编排、服务网格、微服务等技术构建的一种轻量化PaaS平台。

资源文件是云原生应用所需资源的配置信息的集合，每一个云原生应用对应至少一个资源文件。具体来说，容器云平台中的所有内容都被抽象为资源，用户需要通过操作资源来管理整个容器云平台。容器云平台的资源具体可以分为内置资源(KubernetesResources)和自定义资源(Custom Resources)，通过资源描述文件(Manifest File)进行定义，资源描述文件又被称作资源文件。

在云原生场景下，容器云平台能够感知资源文件的变化情况，当资源文件的内容发生变化时，容器云平台将资源文件的变化情况传递给容器云平台的组件，以针对资源文件的变化情况对云原生应用相关资源进行相应的变更。

本申请实施例中，通过在容器云平台中预先部署应用测试控制器，用于对容器云平台所有云原生应用的资源文件的变化情况进行监听。

具体地，以Kubernetes集群为例，应用测试控制器可以通过API-Server组件对Kubernetes集群中的所有应用的资源文件的变化情况进行监听。

步骤S102、响应于云原生应用的资源文件新增至少一个测试配置信息，确定云原生应用所在的容器组。

本申请实施例中，通过应用测试控制器实时监听云原生应用的资源文件的变化情况，当云原生应用的资源文件新增至少一个测试配置信息时，根据云原生应用的资源文件，确定该云原生应用所在的容器组。

可以理解，在将云原生应用部署到容器云平台时，其对应的资源文件中记录有云原生应用所在的容器组的标识信息。当云原生应用的资源文件新增至少一个测试配置信息时，应用测试控制器通过测试配置信息标识出需要执行测试操作的云原生应用，并根据资源文件中记录的云原生应用所在的容器组的标识信息，确定该云原生应用所在的容器组，以根据测试配置信息对该容器组进行相应的配置。

需要说明的是，在资源文件中，测试配置信息以键值对(key-value)的形式存在，其中，key用于标识测试配置信息的类型，value用于存储测试配置信息的具体内容。

步骤S103、根据测试配置信息，以边车容器的形式为容器组注入至少一个测试组件。

其中，测试组件用于对云原生应用执行相应的测试操作。

这里，边车也称Sidecar，对应生活中三轮摩托车，通过对一个两轮摩托车加上一个边车，来拓展两轮摩托车的能力，使其不改变原来的功能，而增加新的功能。

类似地，在软件架构中，云原生应用所在的容器用于实现业务功能，简称业务容器，边车容器如同业务容器的边车，与业务容器位于同一容器组，通过边车容器中的边车应用，为业务容器中的主应用扩展或者增强功能。

需要说明的是，在以边车容器的形式为容器组注入至少一个测试组件后，容器组中将包括边车容器和业务容器，其中，云原生应用部署在业务容器中，测试组件部署在边车容器中。边车容器具有主动拦截进出同一容器组中业务容器的访问请求的能力，也就是说，边车容器会主动拦截同一容器组中发向云原生应用的访问请求，以及主动拦截云原生应用发出的访问请求，以由边车容器中的测试组件进行相应的处理。

使用边车技术可以为云原生应用扩展或者增强功能，而无需额外第三方组件的配置和代码，对于一些与业务容器中的主应用的核心功能不相关的辅助功能可以由边车容器中的边车应用具体实现，边车应用与主应用程序松散耦合，边车应用不需要关心业务的实现逻辑和语言框架等信息。

具体到本申请实施例，根据测试配置信息，基于边车技术为云原生应用进行功能扩展，以边车容器的形式为云原生应用所在的容器组注入测试组件，使其能够执行相应的测试操作。

本申请实施例中，由边车容器中的测试组件实现对云原生应用的测试，其中，对云原生应用进行测试并不是一项云原生应用的核心功能，可以看作是云原生应用的辅助功能，该功能可以通过边车容器中的测试组件具体实现。如此，基于边车技术，使得测试组件与云原生应用松散耦合，测试组件无需关心云原生应用的业务实现逻辑和语言框架等信息，降低了测试组件开发的成本和实现难度。

此外，基于边车技术为容器组注入测试组件时，无需额外配置第三方组件，也无需在云原生应用中修改代码，借助容器云平台能够实时感知部署其中的云原生应用的资源文件的变化情况的功能特点，只需在云原生应用的资源文件中新增测试配置信息，即可对云原生应用进行测试，从而使得对云原生应用的测试灵活便捷，不仅提高了测试组件的部署速度，还最大限度提高了应对云原生应用测试需求变化的速度。

基于前述说明可知，为了使用真实的访问请求对新版本的云原生应用进行测试，本申请实施例需要将新版本的云原生应用与现有版本的云原生应用部署在同一个容器云平台中，并在该容器云平台中设置应用测试控制器，使得应用测试控制器能够对新版本的云原生应用和现有版本的云原生应用的资源文件变化情况进行监听。

为了能够对向现有版本的云原生应用发送的访问请求进行复制，并将访问请求副本转发至新版本的云原生应用，以使用访问请求副本对新版本的云原生应用进行测试，本申请实施例为现有版本的云原生应用新增至少一个请求复制注解，下面进行详细说明。

在一些实施例中，测试配置信息包括请求复制注解，对应地，响应于云原生应用的资源文件新增至少一个测试配置信息，确定云原生应用所在的容器组；根据测试配置信息，以边车容器的形式为容器组注入至少一个测试组件，具体为：响应于第一应用的资源文件新增至少一个请求复制注解，确定第一应用所在的第一容器组；根据请求复制注解，以边车容器的形式为第一容器组注入至少一个请求复制组件。

其中，请求复制组件用于对向第一应用发送的访问请求进行复制，以得到访问请求副本，并将访问请求副本、访问请求分别转发至第二应用和第一应用，以由第二应用对访问请求副本进行处理，得到第二应用的测试结果；其中，第一应用为现有版本的云原生应用；第二应用为新版本的云原生应用。

本申请实施例中，将现有版本的云原生应用称为第一应用，第一应用所在的容器组称为第一容器组；将新版本的云原生应用称为第二应用，第二应用所在的容器组称为第二容器组。

本申请实施例中，测试配置信息包括请求复制注解，当第一应用的资源文件中新增至少一个请求复制注解时，应用测试控制器根据第一应用的资源文件确定第一应用所在的第一容器组，并以边车容器的形式为第一容器组注入至少一个请求复制组件。

基于前述内容可知，请求复制注解以键值对(key-value)的形式存在，其中，key用于标识注解的类型为请求复制注解。应用测试控制器根据请求复制注解中的key所标识注解的类型，在边车容器中部署请求复制组件，并动态将边车容器部署在第一应用所在的第一容器组中。

此时，第一容器组中包括第一应用所在的业务容器和请求复制组件所在的边车容器，边车容器主动拦截进出第一应用所在的业务容器的访问请求，即拦截发向第一应用的访问请求和第一应用发出的访问请求的处理结果，以由请求复制组件对这些访问请求进行相应的处理。

实际应用中，当边车容器主动拦截到第一应用发出的访问请求的处理结果时，请求复制组件对第一应用发出的访问请求的处理结果并不做处理，而是将其作为访问请求的响应直接转发给指定的接收方。如此，在对云原生应用的新版本进行测试时，云原生应用的现有版本仍然正常对访问请求进行响应，保证了业务系统的正常运行。

当边车容器主动拦截到发向第一应用的访问请求时，请求复制组件对发向第一应用的访问请求进行复制得到访问请求副本，并将访问请求和访问请求副本分别发送至第一应用所在的第一容器组和第二应用所在的第二容器组，从而实现访问请求的复制和转发。

具体地，当容器云平台为Kubernetes集群时，作为示例，参见图2，如果需要对Kubernetes集群中部署的第二应用进行测试，则将第一应用与第二应用部署在同一个Kubernetes集群中，并在该Kubernetes集群中设置应用测试控制器，用于根据API-Server组件对集群中的所有云原生应用的资源文件变化情况的监听结果进行相应的监听。

可以理解，API-Server组件对所有原生应用的资源文件变化情况进行监听，这里，所有原生应用，既包括第一应用，也包括第二应用。当第一应用的资源文件或者第二应用的资源文件发生变化，API-Server组件将相应的变化情况传递至应用测试控制器，以由应用测试控制器针对第一应用的资源文件的变化情况或者第二应用的资源文件的变化情况执行相应的操作。

具体实施时，第一应用、第二应用部署完成后并且第一应用的资源文件没有新增测试配置信息时，第一应用从第三应用(这里，第三应用可以是集群中除第一应用、第二应用以外的其它任一应用)接收访问请求，并在完成对访问请求的处理后，将响应发送给指定的接收方(比如第四应用)。

当应用测试控制器通过API-Server组件检测到第一应用的资源文件新增至少一个测试配置信息，且所新增的测试配置信息包括请求复制注解时，需要对第三应用发向第一应用的访问请求进行拦截。

本申请实施例中，通过请求复制组件对第三应用发向第一应用的访问请求进行拦截。

具体地，参见图3，应用测试控制器将根据请求复制注解的key所标识注解的类型，以边车容器的形式为第一应用所在的第一容器组注入请求复制组件。

请求复制组件通过边车容器对第三应用向第一应用发出的访问请求进行主动拦截，并对该访问请求进行复制，以得到访问请求副本；随后将访问请求副本、访问请求分别转发至第二应用和第一应用。

本申请实施例中，在对访问请求进行复制得到访问请求副本后，请求复制组件将访问请求发送至第一应用，不会影响第三应用对第一应用的正常访问。

请求复制组件将访问请求副本发送至第二应用，以由第二应用对访问请求副本进行处理，得到第二应用的测试结果。

需要说明的是，通过请求复制组件对访问请求进行复制得到的访问请求副本，与真实的访问请求一模一样，从而能够对第二应用进行类似真实场景的全面测试。

在一些实施例中，请求复制注解包括第二应用所在的第二容器组的标识信息；对应地，请求复制组件还用于：根据第二应用所在的第二容器组的标识信息，确定第二应用所在的第二容器组；与第二容器组建立网络连接，以将访问请求副本转发至第二应用。

本申请实施例中，请求复制注解以键值对(key-value)的形式存在，其中，value为第二应用所在的第二容器组的标识信息。

请求复制组件根据value所记录的第二应用所在的第二容器组的标识信息，确定第二应用所在的第二容器组，然后与第二容器组建立网络连接，以将访问请求副本转发至第二应用，从而实现基于真实访问请求对第二应用进行测试。

为了能够对新版本的云原生应用的测试结果进行分析，本申请实施例为新版本的云原生应用新增至少一个结果分析注解，下面进行详细说明。

在另一些实施例中，测试配置信息包括结果分析注解，对应地，响应于云原生应用的资源文件新增至少一个测试配置信息，确定云原生应用所在的容器组；根据测试配置信息，以边车容器的形式为容器组注入至少一个测试组件，具体为：响应于第二应用的资源文件新增至少一个结果分析注解，确定第二应用所在的第二容器组；根据结果分析注解，以边车容器的形式为第二容器组注入至少一个结果分析组件。

其中，结果分析组件用于处理第二应用的测试结果。

本申请实施例中，测试配置信息包括结果分析注解。当第二应用的资源文件中新增至少一个结果分析注解时，应用测试控制器通过第二应用的资源文件确定第二应用所在的第二容器组，并以边车容器的形式为第二容器组注入至少一个结果分析组件。

结果分析注解以键值对(key-value)的形式存在，其中，key用于标识注解的类型为结果分析注解。应用测试控制器根据结果分析注解中的key所标识注解的类型，确定在边车容器中部署结果分析组件，并将边车容器部署在第二应用所在的第二容器组中。

此时，第二容器组中包括第二应用所在的业务容器和结果分析组件所在的边车容器，边车容器主动拦截发向第二应用的访问请求副本和第二应用发出的对访问请求副本的处理结果(即第二应用的测试结果)，以由结果分析组件进行相应的处理。

在一些实施例中，结果分析注解包括结果分析模型的标识信息，对应地，结果分析组件具体用于：根据结果分析模型的标识信息，确定结果分析模型；基于结果分析模型对第二应用的测试结果进行分析，得到分析结果；将第二应用的测试结果以及分析结果存储至存储系统。

本申请实施例中，结果分析注解以键值对(key-value)的形式存在，其中，value为结果分析模型的标识信息。

具体实施时，当边车容器主动拦截到发向第二应用的访问请求副本时，结果分析组件对访问请求副本并不做任何处理，由第二应用对访问请求副本进行处理，得到第二应用的测试结果。

结果分析组件通过边车容器主动拦截第二应用发出的第二应用的测试结果后，根据value所记录的结果分析模型的标识信息，确定对第二应用的测试结果所采用的结果分析模型，并基于结果分析模型对第二应用的测试结果进行分析，以得到分析结果，然后，结果分析组件将第二应用的测试结果和分析结果存储至存储系统中，以供应用开发人员取用。

继续参见图3，应用测试控制器将根据结果分析注解的key所标识注解的类型，以边车容器的形式为第二应用所在的第二容器组注入结果分析组件。

结果分析组件通过边车容器对第二应用发出的第二应用的测试结果后进行主动拦截，根据结果分析注解的value所记录的结果分析模型的标识信息，使用结果分析模型对第二应用的测试结果进行分析，以得到分析结果，然后将第二应用的测试结果和分析结果存储至存储系统中。

需要说明的是，当结果分析组件有多个时，只需将每个结果分析模型与每个结果分析组件相对应，即可采用多个结果分析模型对同一个第二应用的测试结果进行分析，得到针对同一个第二应用的测试结果的多个分析结果。

本申请实施例中，无需做任何特定的配置，即可通过边车容器中的结果分析组件对访问请求副本和第二应用的测试结果进行分别处理，避免了将访问请求副本的处理结果和访问请求的处理结果都被当作响应发送给响应接收方，实现了对第二应用的测试结果进行有效的分析、管理和控制。

在一些实施例中，第二应用有多个，多个第二应用为不同新版本的云原生应用，第一应用的资源文件中新增的每个请求复制注解分别与每个第二应用相对应；对应地，响应于第二应用的资源文件新增至少一个结果分析注解，确定第二应用所在的第二容器组；根据结果分析注解，以边车容器的形式为第二容器组注入至少一个结果分析组件，具体为：响应于多个第二应用的资源文件新增至少一个结果分析注解，确定每个第二应用所在的第二容器组；根据结果分析注解，以边车容器的形式为各第二容器组注入至少一个结果分析组件。

本申请实施例中，第二应用有多个，也就是说，允许对多个不同新版本的云原生应用同时进行测试。

当对多个不同新版本的云原生应用同时进行测试时，只需将这些第二应用与对应的第一应用(即现有版本的云原生应用)部署在同一个容器云平台中，并在第一应用的资源文件中新增多个请求复制注解，并且，所新增的每个请求复制注解分别与每个第二应用相对应。

此时，应用测试控制器同时对该多个第二应用的资源文件进行监听，当多个第二应用的资源文件新增至少一个结果分析注解时，根据每个第二应用的资源文件，确定每个第二应用所在的第二容器组，并根据结果分析注解，以边车容器的形式为各个第二容器组注入至少一个结果分析组件。

如此，通过在第一应用的资源文件中新增多个请求复制注解，每个请求复制注解与每个第二应用相对应，从而允许使用相同的访问请求同时对多个不同新版本的云原生应用进行测试，并对不同新版本的云原生应用的测试结果进行比对，以实现对云原生应用的回归测试。

在一些实施例中，所提供的方法还包括：响应于云原生应用的资源文件删除至少一个测试配置信息，确定云原生应用所在的容器组；根据测试配置信息，删除容器组中对应的测试组件。

实际应用中，应用测试控制器对云容器平台中的所有云原生应用的资源文件的变化情况进行持续的监听。当应用测试控制器检测到云原生应用的资源文件删除至少一个测试配置信息时，确定云原生应用所在的容器组，并根据所删除的测试配置信息，动态删除容器组中对应的测试组件。

具体地，以Kubernetes集群为例，应用测试控制器可以通过API-Server组件对Kubernetes集群中的所有应用的资源文件变化情况进行持续监听，当应用测试控制器检测到资源文件中请求复制注解或者结果分析注解被删除，则对第一容器组中的请求复制组件或者第二容器组中的结果分析组件进行动态删除。

可以理解，当请求复制组件和结果分析组件被动态删除后，发向第一应用的访问请求将不再被拦截和复制，而是直接到达第一应用。如此，通过动态新增或者删除云原生应用的资源文件中的测试配置信息，能够快速设置或者取消对云原生应用的测试配置，达到灵活便捷地对云原生应用进行测试的效果。

综上所述，本申请中，通过在容器云平台中部署应用测试控制器，对云原生应用的资源文件的变化情况进行监听，在云原生应用的资源文件新增至少一个测试配置信息的情况下，确定云原生应用所在的容器组；然后根据所新增的至少一个测试配置信息，以边车容器的形式为容器组注入至少一个测试组件，通过测试组件对云原生应用执行相应的测试操作。如此，借助容器云平台能够实时感知部署其中的云原生应用的资源文件的变化情况的功能特点，基于边车技术对云原生应用进行灵活的功能拓展，以边车容器的形式为容器组动态注入与云原生应用的业务相对独立的测试组件，只需通过简单的配置操作即可进行测试组件配置，灵活便捷地对容器云平台中的云原生应用进行测试，以满足云原生场景下的应用测试需求。

本申请中，借助边车技术能够对应用进行功能拓展的优势，使用边车容器对业务容器发出的访问请求进行主动拦截，并在边车容器设置请求复制组件对业务容器发出的访问请求进行复制，请求复制组件无需与业务容器中的应用实现耦合，也就无需对应用的代码进行修改，从而降低了对云原生应用测试的工作量。

本申请中，采用在云原生应用的资源文件中新增请求复制注解的方式标记出需要进行访问请求复制的第一应用，并根据第一应用的资源文件中请求复制注解的新增和删除自动以边车容器的形式在该应用所在的容器组中动态注入和删除请求复制组件，方案的实现灵活多变，可以满足云原生场景下应用测试的需要。

本申请中，采用在云原生应用的资源文件中新增结果分析注解的方式标记出需要进行测试结果分析的第二应用，并根据结果分析注解的新增和删除自动以边车容器的形式在第二应用所在的容器组中动态注入和删除结果分析组件，能够根据测试需求，使用不同类型的结果分析模型对测试结果进行分析。

示例性系统

本申请实施例提供一种基于边车技术的云原生应用测试系统，图4为根据本申请的一些实施例提供的基于边车技术的云原生应用测试系统的结构示意图。如图4所示，系统包括应用测试控制器，应用测试控制器部署在容器云平台中，应用测试控制器包括资源监听单元401、测试配置单元402和组件注入单元403，其中，

资源监听单元401，配置为对云原生应用的资源文件的变化情况进行监听；

测试配置单元402，配置为响应于云原生应用的资源文件新增至少一个测试配置信息，确定云原生应用所在的容器组；

组件注入单元403，配置为根据测试配置信息，以边车容器的形式为容器组注入至少一个测试组件；

其中，云原生应用为容器云平台中部署的任一应用，测试组件用于对云原生应用执行相应的测试操作。

本申请实施例提供的边车技术的云原生应用测试系统能够实现上述任一的边车技术的云原生应用测试方法的流程、步骤，并达到相同的技术效果，在此不再一一赘述。

示例性设备

图5为根据本申请的一些实施例提供的电子设备的结构示意图；如图5所示，该电子设备包括：

一个或多个处理器501；

计算机可读介质，可以配置为存储一个或多个程序502，一个或多个处理器501执行一个或多个程序502时，实现如下步骤：对云原生应用的资源文件的变化情况进行监听；响应于云原生应用的资源文件新增至少一个测试配置信息，确定云原生应用所在的容器组；根据测试配置信息，以边车容器的形式为容器组注入至少一个测试组件；其中，云原生应用为容器云平台中部署的任一应用，测试组件用于对云原生应用执行相应的测试操作。

图6为根据本申请的一些实施例提供的电子设备的硬件结构；如图6所示，该电子设备的硬件结构可以包括：处理器601、通信接口602、计算机可读介质603和通信总线604。

其中，处理器601、通信接口602、计算机可读存储介质603通过通信总线604完成相互间的通信。

可选地，通信接口602可以为通信模块的接口，如GSM模块的接口。

其中，处理器601具体可以配置为：对云原生应用的资源文件的变化情况进行监听；响应于云原生应用的资源文件新增至少一个测试配置信息，确定云原生应用所在的容器组；根据测试配置信息，以边车容器的形式为容器组注入至少一个测试组件；其中，云原生应用为容器云平台中部署的任一应用，测试组件用于对云原生应用执行相应的测试操作。

处理器601可以是通用处理器，包括中央处理器(central processing unit，简称CPU)、网络处理器(Network Processor，简称NP)等，还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

本申请实施例的电子设备以多种形式存在，包括但不限于：

(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括：智能手机(例如：iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备：这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备包括：音频、视频播放器(例如：iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)服务器：提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

(5)其它具有数据交互功能的电子装置。

需要指出，根据实施的需要，可将本申请实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可以将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本申请实施例的目的。

上述根据本申请实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器存储介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，RAM、ROM、闪存等)，当软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的基于边车技术的云原生应用测试方法。此外，当通用计算机访问用于实现在此示出的方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的方法的专用计算机。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和涉及约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其它实施例的不同之处。尤其，对于设备及系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。

以上所描述得设备及系统实施例仅仅是示意性的，其中作为分离不见说明的单元可以使或者也可以不是物理上分开的，作为单元提示的不见可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的优选实施例，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种基于边车技术的云原生应用测试方法，其特征在于，所述方法应用于应用测试控制器，所述应用测试控制器部署在容器云平台中，包括：

对所述云原生应用的资源文件的变化情况进行监听；

响应于所述云原生应用的资源文件新增至少一个测试配置信息，确定所述云原生应用所在的容器组；

根据所述测试配置信息，以边车容器的形式为所述容器组注入至少一个测试组件；

其中，所述云原生应用为所述容器云平台中部署的任一应用，所述测试组件用于对所述云原生应用执行相应的测试操作。

2.根据权利要求1所述的基于边车技术的云原生应用测试方法，其特征在于，所述测试配置信息包括请求复制注解，

对应地，

所述响应于所述云原生应用的资源文件新增至少一个测试配置信息，确定所述云原生应用所在的容器组；根据所述测试配置信息，以边车容器的形式为所述容器组注入至少一个测试组件，具体为：

响应于第一应用的资源文件新增至少一个请求复制注解，确定所述第一应用所在的第一容器组；

根据所述请求复制注解，以边车容器的形式为所述第一容器组注入至少一个请求复制组件；

其中，所述请求复制组件用于对向所述第一应用发送的访问请求进行复制，以得到访问请求副本，并将所述访问请求副本、所述访问请求分别转发至第二应用和所述第一应用，以由所述第二应用对所述访问请求副本进行处理，得到所述第二应用的测试结果；其中，所述第一应用为现有版本的所述云原生应用；所述第二应用为新版本的所述云原生应用。

3.根据权利要求2所述的基于边车技术的云原生应用测试方法，其特征在于，所述测试配置信息包括结果分析注解，

对应地，

所述响应于所述云原生应用的资源文件新增至少一个测试配置信息，确定所述云原生应用所在的容器组；根据所述测试配置信息，以边车容器的形式为所述容器组注入至少一个测试组件，具体为：

响应于所述第二应用的资源文件新增至少一个结果分析注解，确定所述第二应用所在的第二容器组；

根据所述结果分析注解，以边车容器的形式为所述第二容器组注入至少一个结果分析组件；

其中，所述结果分析组件用于处理所述第二应用的测试结果。

4.根据权利要求3所述的基于边车技术的云原生应用测试方法，其特征在于，所述结果分析注解包括结果分析模型的标识信息，

对应地，

所述结果分析组件具体用于：

根据所述结果分析模型的标识信息，确定所述结果分析模型；

基于所述结果分析模型对所述第二应用的测试结果进行分析，得到分析结果；

将所述第二应用的测试结果以及所述分析结果存储至存储系统。

5.根据权利要求3所述的基于边车技术的云原生应用测试方法，其特征在于，所述第二应用有多个，多个所述第二应用为不同新版本的所述云原生应用，所述第一应用的资源文件中新增的每个所述请求复制注解分别与每个所述第二应用相对应；

对应地，

所述响应于所述第二应用的资源文件新增至少一个结果分析注解，确定所述第二应用所在的第二容器组；根据所述结果分析注解，以边车容器的形式为所述第二容器组注入至少一个结果分析组件，具体为：

响应于多个所述第二应用的资源文件新增至少一个结果分析注解，确定每个所述第二应用所在的第二容器组；

根据所述结果分析注解，以边车容器的形式为各所述第二容器组注入至少一个结果分析组件。

6.根据权利要求2所述的基于边车技术的云原生应用测试方法，其特征在于，所述请求复制注解包括所述第二应用所在的第二容器组的标识信息；

对应地，

所述请求复制组件还用于：

根据所述第二应用所在的第二容器组的标识信息，确定所述第二应用所在的第二容器组；

与所述第二容器组建立网络连接，以将所述访问请求副本转发至所述第二应用。

7.根据权利要求1所述的基于边车技术的云原生应用测试方法，其特征在于，所述方法还包括：

响应于所述云原生应用的资源文件删除至少一个测试配置信息，确定所述云原生应用所在的容器组；

根据所述测试配置信息，删除所述容器组中对应的所述测试组件。

8.一种基于边车技术的云原生应用测试系统，其特征在于，所述系统包括应用测试控制器，所述应用测试控制器部署在容器云平台中，所述应用测试控制器包括资源监听单元、测试配置单元和组件注入单元，其中，

资源监听单元，配置为对所述云原生应用的资源文件的变化情况进行监听；

测试配置单元，配置为响应于所述云原生应用的资源文件新增至少一个测试配置信息，确定所述云原生应用所在的容器组；

组件注入单元，配置为根据所述测试配置信息，以边车容器的形式为所述容器组注入至少一个测试组件；

其中，所述云原生应用为所述容器云平台中部署的任一应用，所述测试组件用于对所述云原生应用执行相应的测试操作。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序为如权利要求1-7任一项所述的基于边车技术的云原生应用测试方法。

10.一种电子设备，其特征在于，包括：存储器、处理器、以及存储在所述存储器中并可在所述处理器上运行的程序，所述处理器执行所述程序时实现如权利要求1-7任一项所述的基于边车技术的云原生应用测试方法。

Images