CN110457197A - 服务测试方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请提供了一种服务测试方法、装置、计算机设备和存储介质，其中，该方法包括：确定提供目标服务所需的服务器组，其中，服务器组中存在多个服务器；为服务器组设置多个测试任务，其中，一个测试任务用于对一个或多个服务器进行性能测试；控制服务器组并行执行多个测试任务，以确定目标服务是否满足预设的性能要求。上述服务测试方法可以实现对目标服务的自动化测试，有效提高应用服务的测试效率，节约人力成本。

Description

服务测试方法、装置、计算机设备和存储介质

技术领域

本申请涉及计算机技术领域，特别涉及一种服务测试方法、装置、计算机设备和存储介质。

背景技术

通常，一种应用服务由一个或多个服务器提供。在实际运行之前，需要对提供该应用服务的服务器进行性能测试，以确定该应用服务是否能够满足预设的性能要求。

目前，只能通过人工逐个对单个服务器进行性能测试，从而实现对整个应用服务的测试。然而，这种方式存在效率低且并发困难的问题。而且，目前的应用服务往往都是分布式集群部署的，因此对单个服务器进行性能测试并不能达到想要的服务测试的目的。

针对上述问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种服务测试方法、装置、计算机设备和存储介质，以解决现有技术中应用服务测试效率低的问题。

本申请实施例提供了一种服务测试方法，包括：确定提供目标服务所需的服务器组，其中，服务器组中存在多个服务器；为服务器组设置多个测试任务，其中，一个测试任务用于对一个或多个服务器进行性能测试；控制服务器组并行执行多个测试任务，以确定目标服务是否满足预设的性能要求。

在一个实施例中，在确定提供目标服务所需的服务器组之后，还包括：接收应用安装指令；响应于应用安装指令，获取目标应用的安装包，其中，目标应用用于执行测试任务；将安装包下发至多个服务器中各服务器，并指示各服务器安装该安装包。

在一个实施例中，在控制服务器组并行执行多个测试任务之后，还包括：接收服务器组中的各服务器返回的各测试任务的执行状态；在确定各测试任务均执行成功的情况下，生成应用卸载指令；将应用卸载指令发送至多个服务器中各服务器，以使得各服务器卸载目标应用并删除安装包。

在一个实施例中，测试任务为混沌实验任务；相应的，控制服务器组并行执行多个测试任务，包括：将多个混沌实验任务中各混沌实验任务发送至对应的服务器，以使服务器执行混沌实验任务；接收服务器组中的各服务器返回的硬件指标；根据硬件指标确定各服务器在执行对应的混沌实验任务时对各服务器的硬件资源使用情况的影响。

在一个实施例中，在将多个混沌实验任务中各混沌实验任务发送至对应的服务器，以使服务器执行混沌实验任务之后，还包括：接收服务器组中的各服务器中返回的软件指标；根据软件指标确定各服务器在执行对应的混沌实验任务时对各服务器上运行的软件的影响。

在一个实施例中，服务器中安装的目标应用包括管理工具和多种故障注入工具；相应的，服务器执行混沌实验任务，包括：管理工具接收对应的混沌实验任务，其中，混沌实验任务中包含至少一个混沌实验事件；管理工具确定混沌实验任务中包含的各混沌实验事件的执行时间和故障注入类型；管理工具根据各混沌实验事件的执行时间调用各混沌实验事件的故障注入类型对应的故障注入工具对服务器进行故障注入。

在一个实施例中，多个服务器包括以下至少之一：虚拟机、物理机和容器；将目标应用的安装包下发至服务器组中的多个服务器中各服务器，包括：基于运维平台将目标应用的安装包下发至服务器组中的多个服务器中的物理机和/或虚拟机；和/或，基于Ansible将目标应用的安装包下发至服务器组中的多个服务器中的容器。

本申请实施例还提供了一种服务测试装置，包括：确定模块，用于确定提供目标服务所需的服务器组，其中，服务器组中存在多个服务器；设置模块，用于为服务器组设置多个测试任务，其中，一个测试任务用于对一个或多个服务器进行性能测试；控制模块，用于控制服务器组并行执行多个测试任务，以确定目标服务是否满足预设的性能要求。

本申请实施例还提供一种计算机设备，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现上述任意实施例中所述的服务测试方法的步骤。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现上述任意实施例中所述的服务测试方法的步骤。

在本申请实施例中，提供了一种服务测试方法，在确定提供目标服务所需的服务器组之后，为服务器组设置多个测试任务，其中，一个测试任务用于对一个或多个服务器进行性能测试，控制服务器组并行执行多个测试任务，以确定目标服务是否满足预设的性能要求。上述方案中，通过为服务器组中的多个服务器设置多个测试任务，并控制所述多个测试任务并行执行，可以确定目标服务是否满足预设的性能要求，即实现对目标服务的自动化测试，可以有效提高应用服务的测试效率，节约人力成本。通过上述方案解决了现有的服务测试效率低下的技术问题，达到了有效提升测试效率并节约人力成本的技术效果。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，并不构成对本申请的限定。在附图中：

图1示出了本申请一实施例中服务测试方法的应用场景的示意图；

图2示出了本申请一实施例中的服务测试方法的流程图；

图3示出了本申请一实施例中的服务测试方法中的测试任务的示意图；

图4示出了本申请一实施例中的服务测试装置的示意图；

图5示出了本申请一实施例中的计算机设备的示意图。

具体实施方式

下面将参考若干示例性实施方式来描述本申请的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本申请，而并非以任何方式限制本申请的范围。相反，提供这些实施方式是为了使本申请公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域的技术人员知道，本申请的实施方式可以实现为一种系统、装置设备、方法或计算机程序产品。因此，本申请公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

考虑到现有的应用服务只能通过人工逐个对单个服务器进行性能测试来实现，存在效率低且人力成本高的问题，对此，发明人通过研究发现，可以通过管理平台确定提供目标应用所需的服务器组，并且为服务器组设置多个测试任务，之后控制服务器组执行多个测试任务，以确定目标服务是否满足预设的性能要求，从而实现对目标服务的测试。

基于此，本申请实施例提供了一种服务测试方法。图1示出了本申请一实施例中服务测试方法的应用场景的示意图。如图1所示，示意性地示出了管理平台和服务器组。其中，测试人员可以对管理平台进行操作。测试人员可以向管理平台输入目标服务测试指令。其中，目标服务测试指令中可以携带有目标服务的标识信息。管理平台或者外部数据库中可以存储有目标服务所涉及的服务器组。在管理平台接收到目标服务测试指令之后，可以根据目标服务的标识信息获取提供目标服务所需要的服务器组。其中，服务器组包括多个服务器。在确定提供目标服务所需要的服务器组之后，管理平台可以为服务器组设置多个测试任务。其中，一个测试任务用于对一个或多个服务器进行性能测试。一个服务器只属于一个测试任务。之后，管理平台可以将测试任务发送至对应的服务器，并控制服务器组执行多个测试任务，以确定目标服务是否满足预设的性能要求。

如图1所示，示意性地，服务器组包括9个服务器：服务器1至服务器9。示意性地，管理平台可以为服务器组设置3个测试任务：测试任务1、测试任务2和测试任务3。其中，测试任务1用于对第一组服务器(服务器1和服务器2)进行性能测试。测试任务2用于对第二组服务器(服务器4、服务器5和服务器6)进行性能测试。测试任务3用于对第三组服务器(服务器7)进行性能测试。管理平台将测试任务1发送至服务器1和2，将测试任务2发送至服务器4、服务器5和服务器6，将测试任务3发送至服务器7。进一步地，各服务器接收到测试任务之后，执行测试任务，并返回任务执行状态。管理平台可以根据各任务的执行状态来确定目标服务的测试是否完成。

其中，上述服务器可以是单一的服务器，也可以是服务器集群，或者是云服务器等都可以，具体的组成形成本申请不作限定。上述管理平台可以是计算机或者是安装在计算机中的系统或软件。上述计算机可以是台式电脑、笔记本、手机终端、PDA等，只要是可以向用户或者业务人员进行内容展示和接收操作指令的设备都可以，对于计算机的呈现形成，本申请也不作限定。

图2示出了本申请一实施例中服务测试方法的流程图。虽然本申请提供了如下述实施例或附图所示的方法操作步骤或装置结构，但基于常规或者无需创造性的劳动在所述方法或装置中可以包括更多或者更少的操作步骤或模块单元。在逻辑性上不存在必要因果关系的步骤或结构中，这些步骤的执行顺序或装置的模块结构不限于本申请实施例描述及附图所示的执行顺序或模块结构。所述的方法或模块结构的在实际中的装置或终端产品应用时，可以按照实施例或者附图所示的方法或模块结构连接进行顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至分布式处理环境)。

具体地，如图2所示，本申请一种实施例提供的服务测试方法可以包括以下步骤：

步骤S201，确定提供目标服务所需的服务器组，其中，服务器组中存在多个服务器。

管理平台可以接收用户输入的目标服务测试指令。其中，目标服务测试指令中携带有所述目标服务的标识信息。响应于该目标服务测试指令，管理平台可以从自身的存储器或者外部数据库获取预先存储的与目标服务对应的服务器组。其中，服务器组用于提供所述目标服务。服务器中存在多个服务器。示例性地，在确定提供目标服务所需的服务器组之前，可以将提供目标服务所需的服务器组中的各服务器的标识信息输入至管理平台所在的计算机中。其中，标识信息可以是服务器的IP地址等。

步骤S202，为服务器组设置多个测试任务，其中，一个测试任务用于对一个或多个服务器进行性能测试。

在确定提供目标服务所需的服务器组之后，为服务器组设置多个测试任务。其中，一个测试任务用于对一个或多个服务器进行性能测试。一个服务器仅属于一个测试任务。示例性地，可以由测试人员选定第一组服务器，并确定针对第一组服务器的第一测试任务，选定第二组服务器，并确定针对第二组服务器的第二测试任务，选定第三组服务器，并确定针对该第三组服务器的第三测试任务。管理平台可以获取测试人员选定的服务器的标识信息以及测试人员确定的测试任务的用例，并根据获得的标识信息和用例生成多个测试任务，其中，每个测试任务中携带有对应的服务器的标识信息。例如，第一测试任务中携带有第一组服务器中各服务器的标识信息，第二测试任务中携带有第二组服务器中各服务器的标识信息，第三测试任务中携带有第三组服务器中各服务器的标识信息。

步骤S203，控制服务器组并行执行多个测试任务，以确定目标服务是否满足预设的性能要求。

在为服务器组设置多个测试任务之后，管理平台可以控制服务器组并行执行多个测试任务，以确定目标服务是否满足预设的性能要求。其中，预设的性能要求可以由测试人员来设置。管理平台可以控制服务器组并行执行多个测试任务。例如，管理平台控制第一组服务器执行第一测试任务，控制第二组服务器执行第二测试任务，控制第三组服务器执行第三测试任务。

上述方案中，通过为服务器组中的多个服务器设置多个测试任务，并控制所述多个测试任务并行执行，可以确定目标服务是否满足预设的性能要求，即实现对目标服务的自动化测试，可以有效提高应用服务的测试效率，节约人力成本。通过上述方案解决了现有的服务测试效率低下的技术问题，达到了有效提升测试效率并节约人力成本的技术效果。

进一步地，在本申请一些实施例中，在确定提供目标服务所需的服务器组之后，还可以包括：接收应用安装指令；响应于应用安装指令，获取目标应用的安装包，其中，目标应用用于执行测试任务；将安装包下发至多个服务器中各服务器，并指示各服务器安装该安装包。

在一些情况下，各测试任务可能需要应用软件来执行。在管理平台确定提供目标服务所需的服务器组之后，测试人员可以向管理平台输入应用安装指令。响应于应用安装指令，管理平台可以获取对应的目标应用的安装包。其中，所述目标应用用于执行测试任务。管理平台将获得的安装包下发至服务器组中的各服务器中，并指示各服务器安装该安装包。通过上述方式，可以由管理平台统一下发安装包，并指示各服务器进行安装，使得各服务器中安装有用于执行测试任务的目标应用，可以有效提高服务测试的效率。

上述实施例中，管理平台接收用户输入的应用安装指令。在本申请其他实施例中，在确定提供目标服务所需的服务器组之后，管理平台可以直接自动生成应用安装指令。上述实施例中应用安装指令的产生方式仅是示例性的，本申请对此不作限制。

上述实施例中，管理平台可以将目标应用的安装包发送至服务器组中的所有服务器。在其他实施例中，在确定提供目标服务所需的服务器组之后，管理平台可以接收测试人员选定的进行测试的一部分服务器，并将目标应用的安装包发送至选定的那一部分服务器。例如，如图1所示，可以将目标应用的安装包仅发送至第一组服务器(服务器1和服务器2)、第二组服务器(服务器4、服务器5和服务器6)和第三组服务器(服务器7)。

进一步地，在本申请一些实施例中，多个服务器可以包括以下至少之一：虚拟机、物理机和容器；将目标应用的安装包下发至服务器组中的多个服务器中各服务器，可以包括：基于运维平台将目标应用的安装包下发至服务器组中的多个服务器中的物理机和/或虚拟机；和/或，基于Ansible将目标应用的安装包下发至服务器组中的多个服务器中的容器。

其中，服务器组中的多个服务器的类型可以包括以下至少之一：虚拟机、物理机和容器。对于服务器为虚拟机或物理机的情况，管理平台可以基于运维平台将目标应用的安装包下发至对应的虚拟机或物理机。对于服务器为容器的情况，管理平台可以基于Ansible将目标应用的安装包下发至对应的容器中。其中，Ansible是基于Python开发的自动化运维工具，可以实现批量系统配置、批量程序部署、批量运行命令等功能。通过上述方式，可以将目标应用的安装包下发至对应的服务器中，并指示各服务器安装目标应用的安装包。

在本申请一些实施例中，在控制服务器组并行执行多个测试任务之后，还可以包括：接收服务器组中的各服务器返回的各测试任务的执行状态；在确定各测试任务均执行成功的情况下，生成应用卸载指令；将应用卸载指令发送至多个服务器中各服务器，以使得各服务器卸载目标应用并删除安装包。

在控制服务器组并行执行多个测试任务之后，服务器组中的各服务器返回各测试任务的执行状态。管理平台接收各服务器返回的各测试任务的执行状态。在确定各测试任务均执行成功的情况下，说明目标服务的测试完成，可以卸载各服务器中的目标应用，以免占用各服务器的资源。因此，在确定各测试任务均执行成功的情况下，管理平台生成应用卸载指令。管理平台将生成的应用卸载指令发送至各服务器，以使得各服务器卸载目标应用并删除安装包。通过上述方式，可以在目标服务的测试完成之后，卸载执行测试任务的目标应用和安装包，从而节约各服务器的资源。

上述实施例中，在确定各测试任务均执行成功的情况下生成应用卸载指令。上述实施例仅是示例性的，本申请并不限于此。在本申请其他实施例中，可以在确定目标应用满足预设的性能要求的情况下，生成应用卸载指令，并将生成的应用卸载指令发送至各服务器，以使得各服务器卸载目标应用并删除安装包。

在本申请一些实施例中，测试任务为混沌实验任务；相应的，控制服务器组并行执行多个测试任务，可以包括：将多个混沌实验任务中各混沌实验任务发送至对应的服务器，以使服务器执行混沌实验任务；接收服务器组中的各服务器返回的硬件指标；根据硬件指标确定各服务器在执行对应的混沌实验任务时对各服务器的硬件资源使用情况的影响。

其中，混沌实验任务的类型可以包括CPU满载、内存占满、磁盘IO忙碌、网络延时、和丢包等。在确定目标应用所需要的服务器组之后，管理平台可以为服务器组设置多个混沌实验任务。一个混沌实验任务用于对一个或多个服务器执行故障注入。在设置多个混沌实验任务之后，管理平台将多个混沌实验任务中各混沌实验任务发送至对应的服务器。在一些实施例中，管理平台可以将多个混沌实验任务发送至调度系统，调度系统根据多个实验任务生成多个混沌实验作业，并将混沌实验作业发送至对应的服务器中。

服务器接收到对应的混沌实验任务之后，可以执行对应的混沌实验任务，并返回硬件指标。其中，硬件指标可以包括但不限于以下至少之一：CPU使用率、内存使用率、磁盘IO性能参数等。比如，对某一些服务器执行CPU满载的混沌实验任务，那正常情况应该是可以看到执行混沌实验任务的服务器的CPU占用增加。可以根据硬件指标确定混沌实验任务对硬件资源使用情况的影响。进一步地，还可以根据硬件指标，确定服务器的混沌实验任务是否真的成功执行了。通过上述方式，可以实时获取服务器的硬件指标，并确定混沌实验任务对服务器的硬件资源使用情况的影响。

在本申请一些实施例中，在将多个混沌实验任务中各混沌实验任务发送至对应的服务器，以使服务器执行混沌实验任务之后，还可以包括：接收服务器组中的各服务器中返回的软件指标；根据软件指标确定各服务器在执行对应的混沌实验任务时对各服务器上运行的软件的影响。

服务器接收到对应的混沌实验任务之后，可以执行对应的混沌实验任务，并返回软件指标。管理平台接收各服务器的软件指标，可以根据软件指标确认在执行混沌实验任务过程中，是否对服务器或者整个服务器组产生影响以及产生何种影响。在执行混沌实验任务时，服务器对应的软件运行应该是会受到影响的，比如软件运行会比正常情况下缓慢一些，或者可能在并发较大的情况下，会有一些软件运行失败的场景。通过上述方式，可以实时接收服务器返回的软件指标参数，并确定混沌实验作业对服务器上运行的软件的影响。

在本申请一些实施例中，管理平台可以综合各服务器返回的硬件指标和软件指标确定目标服务是否满足预设的性能要求。例如，确定服务器的稳定性是否满足预设要求。管理平台可以根据接收到的硬件指标和软件指标生成分析报告，并进行显示，以供测试人员查看。

在本申请一些实施例中，服务器中安装的目标应用包括管理工具和多种故障注入工具；相应的，服务器执行混沌实验任务，可以包括：管理工具接收对应的混沌实验任务，其中，混沌实验任务中包含至少一个混沌实验事件；管理工具确定混沌实验任务中包含的各混沌实验事件的执行时间和故障注入类型；管理工具根据各混沌实验事件的执行时间调用各混沌实验事件的故障注入类型对应的故障注入工具对服务器进行故障注入。

一个混沌实验任务可以包括多个混沌实验事件。请参考图3，图3示出了本申请一实施例中的服务测试方法中的多个测试任务的示意图。如图3所示，示意性地，管理平台为目标服务所需的服务器组设置三个混沌实验任务：混沌实验任务1、混沌实验任务2和混沌实验任务3。其中，混沌实验任务1针对IP地址为IP1、IP2和IP3的服务器进行故障注入。混沌实验任务1可以包括四个混沌实验事件：事件1(CPU100％)、事件2(内存80％)、事件3(磁盘占满)和事件4(网络延迟高)。IP地址为IP1、IP2和IP3的服务器在各混沌实验事件的开始执行时间执行各混沌实验事件，并持续设置的时间段。混沌实验任务2针对IP地址为IP4、IP5和IP6的服务器进行故障注入。混沌实验任务2可以包括四个混沌实验事件：事件1(CPU100％)、事件2(内存80％)、事件3(磁盘占满)和事件4(网络延迟高)。IP地址为IP4、IP5和IP6的服务器在各混沌实验事件的开始执行时间执行各混沌实验事件，并持续设置的时间段。混沌实验任务3针对IP地址为IP7、IP8和IP9的服务器进行故障注入。混沌实验任务3可以包括四个混沌实验事件：事件1(CPU 100％)、事件2(内存80％)、事件3(磁盘占满)和事件4(网络延迟高)。IP地址为IP7、IP8和IP9的服务器在各混沌实验事件的开始执行时间执行各混沌实验事件，并持续设置的时间段。其中，各混沌实验时间的开始执行时间可以是相对时间，即相对于混沌实验任务的开始时间的相对时间。上述三个混沌实验任务可以并行执行。

各服务器中安装的目标应用可以包括管理工具和故障注入工具。管理工具接收到混沌实验任务之后，可以确定混沌实验任务中包含的多个混沌实验事件的故障注入类型和执行时间。其中，故障注入类型可以包括但不限于以下至少之一：CPU满载、内存占满、磁盘IO忙碌、网络延时、丢包等。混沌实验事件的执行时间可以包括混沌实验事件的开始时间和持续时间段。管理工具可以根据混沌实验事件的执行时间，在开始时间调用对应的故障注入工具来执行故障注入类型对应的故障并持续所述持续时间段。管理工具还可以监控各混沌实验事件的执行状态，生成状态报告，并返回给管理平台。

其中，故障注入工具可以包括但不限于以下之一：ChaosBlade、Stress等。其中，ChaosBlade支持的混沌实验场景不仅覆盖基础资源，如CPU满载、磁盘IO高、网络延迟等，还包括运行在JVM上的应用实验场景，如调用超时和调用异常、指定方法延迟或抛异常以及返回特定值等，同时涉及容器相关的实验，如杀容器和杀Pod等。Stress是一种压测工具，可以用来对系统CPU、内存、以及磁盘IO生成负载。管理工具可以根据混沌实验事件的类型选择对应的故障注入工具进行故障注入。

目标应用还可以提供Http服务，同时保留一个端口用于自身跟外界交互，这样可以避免模拟网络故障时无法接收请求。

在测试环境下，各服务器的时间可能是不一致的，为了保证混沌实验任务运行的统一，管理平台在分发任务时，将当前的系统时间一并传给目标应用，由目标应用与自身服务器的时间进行对比后校正。例如，管理平台发送请求时的时间为10点，要求任务在10点05分执行，目标应用收到请求时，该服务器时间为9点，那么，需要做一个1小时的校正，任务应该在该服务器时间为9点05分时开始执行。通过上述方式，可以进行时间校正，从而保证混沌实验任务运行的统一。

目标应用部署在服务器内部，可以接收外部编排好的故障事件，之后在系统内部通过目标应用根据预先编排的计划逐步执行任务，并在执行过程中，不断监控执行情况，并汇报给管理平台。通过上述方式，将管理工具和故障注入工具集成在一个目标应用中，通过管理工具可以分析混沌实验任务，确定所包含的混沌实验事件以及混沌实验事件的执行时间和故障注入类型，并根据执行时间和故障注入类型调用对应的故障注入工具进行故障注入，因而可以提高故障注入的效率和准确性。进一步地，管理工具可以获取各混沌实验事件的执行状态以及各服务器的软件指标和硬件指标，并返回至管理平台，方便测试人员及时获取任务执行状态以及执行任务对各服务器的影响，并确定目标应用是否满足预设的性能要求。

下面结合一个具体实施例对上述方法进行说明，然而，值得注意的是，该具体实施例仅是为了更好地说明本申请，并不构成对本申请的不当限定。

在本实施例中，服务测试方法包括以下步骤：

步骤1，管理平台接收用户输入的服务测试指令，其中，服务测试指令中携带有目标服务的标识信息；

步骤2，管理平台响应于服务测试指令，获取提供目标服务所需的服务器组，其中，目标服务所需的服务器组的信息可以在之前由应用管理员输入到管理平台中；

步骤3，管理平台获取测试人员选定的多个服务器，并接收测试人员输入的应用安装指令，执行测试时，并不一定要用到服务器组中的所有服务器，比如要模拟网络故障，可能只需要让一半的机器断网，看看另外一半正常的机器能否保证整个服务正常运行；

步骤4，响应于所述应用安装指令，管理平台获取目标应用的安装包，并将目标应用的安装包发送至选定的多个服务器中，并指示选定的多个服务器对接收到的安装包进行安装；

步骤5，选定的多个服务器中各服务器安装所述目标应用的安装包，并启动目标应用；

步骤6，管理平台为选定的多个服务器设置多个混沌实验任务，其中，一个混沌实验任务用于对一个或多个服务器进行故障注入，一个服务器仅属于一个混沌实验任务，其中，多个混沌实验任务可以是根据预设的模型生成的，也可以是管理平台根据使用过程中的任务设置通过智能学习生成的；

步骤7，管理平台将设置的多个混沌实验任务发送至调度系统，调度系统将混沌实验任务发送至对应的服务器；

步骤8，各服务器中的目标应用中的管理工具接收混沌实验任务，并确定混沌实验任务所包含的混沌实验事件的执行时间和故障注入类型；

步骤9，管理工具根据混沌实验事件的执行时间调用对应的故障注入工具对服务器进行故障注入类型对应的故障注入；

步骤10，管理工具监控各混沌实验时间的执行状态以及各服务器的硬件指标和软件指标，并将获得的执行状态、硬件指标和软件指标返回至管理平台；

步骤11，管理平台根据接收到的执行状态、硬件指标和软件指标返回至管理平台生成混沌实验报告；

步骤12，管理平台确定各混沌实验任务是否执行成功，在确定各混沌实验任务均执行成功的情况下，生成应用卸载指令，并将生成的应用卸载指令发送至选定的多个服务器；

步骤13，各服务器响应于应用卸载指令，卸载目标应用并删除安装包。

上述实施例中，由管理平台生成故障演练流程，然后将生成的故障实验任务发送至对应的服务器，各服务器并行执行多个故障实验任务，可以有效提高混沌实验的执行效率，从而提高服务测试的效率。进一步地，将目标应用部署在服务器内部，可以接收外部编排好的混沌实验流程，之后在系统内部根据预先编排的流程执行混沌实验任务中的混沌实验事件，并在执行过程中，不断监控执行情况和服务器的软硬件指标，并汇报给管理平台。管理平台接收到执行情况和服务器的软硬件指标生成完整的分析报告，供测试人员查看和分析。而且，在测试完成后，卸载各服务器中安装的目标应用和安装包，可以避免对服务器资源的占用。在管理平台设置混沌实验任务时，按时间轴在每个时间段设置不同的混沌实验事件，以控制多个任务并行执行，同一个服务器只能属于一个任务。在设置混沌实验时间的开始执行时间时，采用的是相对时间，例如某一个混沌实验事件是2分钟后执行，那么是任务开始时间后的两分钟执行。

基于同一发明构思，本申请实施例中还提供了一种服务测试装置，如下面的实施例所述。由于服务测试装置解决问题的原理与服务测试方法相似，因此服务测试装置的实施可以参见服务测试方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。图4是本申请实施例的服务测试装置的一种结构框图，如图4所示，包括：确定模块401、设置模块402和控制模块403，下面对该结构进行说明。

确定模块401用于确定提供目标服务所需的服务器组，其中，服务器组中存在多个服务器。

设置模块402用于为服务器组设置多个测试任务，其中，一个测试任务用于对一个或多个服务器进行性能测试。

控制模块403用于控制服务器组并行执行多个测试任务，以确定目标服务是否满足预设的性能要求。

在本申请一些实施例中，该还可以包括安装模块，所述安装模块可以具体用于：在确定提供目标服务所需的服务器组之后，接收应用安装指令；响应于应用安装指令，获取目标应用的安装包，其中，目标应用用于执行测试任务；将安装包下发至多个服务器中各服务器，并指示各服务器安装该安装包。

在本申请一些实施例中，该还可以包括卸载模块，所述卸载模块可以具体用于：在控制服务器组并行执行多个测试任务之后，接收服务器组中的各服务器返回的各测试任务的执行状态；在确定各测试任务均执行成功的情况下，生成应用卸载指令；将应用卸载指令发送至多个服务器中各服务器，以使得各服务器卸载目标应用并删除安装包。

在本申请一些实施例中，测试任务可以为混沌实验任务；相应的，控制模块可以具体用于：将多个混沌实验任务中各混沌实验任务发送至对应的服务器，以使服务器执行混沌实验任务；接收服务器组中的各服务器返回的硬件指标；根据硬件指标确定各服务器在执行对应的混沌实验任务时对各服务器的硬件资源使用情况的影响。

在本申请一些实施例中，在将多个混沌实验任务中各混沌实验任务发送至对应的服务器，以使服务器执行混沌实验任务之后，还可以包括：接收服务器组中的各服务器中返回的软件指标；根据软件指标确定各服务器在执行对应的混沌实验任务时对各服务器上运行的软件的影响。

在本申请一些实施例中，服务器中安装的目标应用包括管理工具和多种故障注入工具；相应的，服务器执行混沌实验任务，可以包括：管理工具接收对应的混沌实验任务，其中，混沌实验任务中包含至少一个混沌实验事件；管理工具确定混沌实验任务中包含的各混沌实验事件的执行时间和故障注入类型；管理工具根据各混沌实验事件的执行时间调用各混沌实验事件的故障注入类型对应的故障注入工具对服务器进行故障注入。

在本申请一些实施例中，多个服务器可以包括以下至少之一：虚拟机、物理机和容器；将目标应用的安装包下发至服务器组中的多个服务器中各服务器，可以包括：基于运维平台将目标应用的安装包下发至服务器组中的多个服务器中的物理机和/或虚拟机；和/或，基于Ansible将目标应用的安装包下发至服务器组中的多个服务器中的容器。

从以上的描述中，可以看出，本申请实施例实现了如下技术效果：通过为服务器组中的多个服务器设置多个测试任务，并控制所述多个测试任务并行执行，可以确定目标服务是否满足预设的性能要求，即实现对目标服务的自动化测试，可以有效提高应用服务的测试效率，节约人力成本。通过上述方案解决了现有的服务测试效率低下的技术问题，达到了有效提升测试效率并节约人力成本的技术效果。

本申请实施方式还提供了一种计算机设备，具体可以参阅图5所示的基于本申请实施例提供的服务测试方法的计算机设备组成结构示意图，所述计算机设备具体可以包括输入设备51、处理器52、存储器53。其中，所述存储器53用于存储处理器可执行指令。所述处理器52执行所述指令时实现上述任意实施例中所述的服务测试方法的步骤。

在本实施方式中，所述输入设备具体可以是用户和计算机系统之间进行信息交换的主要装置之一。所述输入设备可以包括键盘、鼠标、摄像头、扫描仪、光笔、手写输入板、语音输入装置等；输入设备用于把原始数据和处理这些数的程序输入到计算机中。所述输入设备还可以获取接收其他模块、单元、设备传输过来的数据。所述处理器可以按任何适当的方式实现。例如，处理器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式等等。所述存储器具体可以是现代信息技术中用于保存信息的记忆设备。所述存储器可以包括多个层次，在数字系统中，只要能保存二进制数据的都可以是存储器；在集成电路中，一个没有实物形式的具有存储功能的电路也叫存储器，如RAM、FIFO等；在系统中，具有实物形式的存储设备也叫存储器，如内存条、TF卡等。

在本实施方式中，该计算机设备具体实现的功能和效果，可以与其它实施方式对照解释，在此不再赘述。

本申请实施方式中还提供了一种基于服务测试方法的计算机存储介质，所述计算机存储介质存储有计算机程序指令，在所述计算机程序指令被执行时实现上述任意实施例中所述服务测试方法的步骤。

在本实施方式中，上述存储介质包括但不限于随机存取存储器(Random AccessMemory,RAM)、只读存储器(Read-Only Memory,ROM)、缓存(Cache)、硬盘(Hard DiskDrive,HDD)或者存储卡(Memory Card)。所述存储器可以用于存储计算机程序指令。网络通信单元可以是依照通信协议规定的标准设置的，用于进行网络连接通信的接口。

在本实施方式中，该计算机存储介质存储的程序指令具体实现的功能和效果，可以与其它实施方式对照解释，在此不再赘述。

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。

应该理解，以上描述是为了进行图示说明而不是为了进行限制。通过阅读上述描述，在所提供的示例之外的许多实施方式和许多应用对本领域技术人员来说都将是显而易见的。因此，本申请的范围不应该参照上述描述来确定，而是应该参照前述权利要求以及这些权利要求所拥有的等价物的全部范围来确定。

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

Claims (10)

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

确定提供目标服务所需的服务器组，其中，所述服务器组中存在多个服务器；

为所述服务器组设置多个测试任务，其中，一个测试任务用于对一个或多个服务器进行性能测试；

控制所述服务器组并行执行所述多个测试任务，以确定所述目标服务是否满足预设的性能要求。

2.根据权利要求1所述的方法，其特征在于，在确定提供目标服务所需的服务器组之后，还包括：

接收应用安装指令；

响应于所述应用安装指令，获取目标应用的安装包，其中，所述目标应用用于执行所述测试任务；

将所述安装包下发至所述多个服务器中各服务器，并指示所述各服务器安装所述安装包。

3.根据权利要求2所述的方法，其特征在于，在控制所述服务器组并行执行所述多个测试任务之后，还包括：

接收所述服务器组中的各服务器返回的各测试任务的执行状态；

在确定各测试任务均执行成功的情况下，生成应用卸载指令；

将所述应用卸载指令发送至所述多个服务器中各服务器，以使得所述各服务器卸载所述目标应用并删除所述安装包。

4.根据权利要求2所述的方法，其特征在于，所述测试任务为混沌实验任务；

相应的，控制所述服务器组并行执行所述多个测试任务，包括：

将多个混沌实验任务中各混沌实验任务发送至对应的服务器，以使所述服务器执行所述混沌实验任务；

接收所述服务器组中的各服务器返回的硬件指标；

根据所述硬件指标确定所述各服务器在执行对应的混沌实验任务时对所述各服务器的硬件资源使用情况的影响。

5.根据权利要求4所述的方法，其特征在于，在将多个混沌实验任务中各混沌实验任务发送至对应的服务器，以使所述服务器执行所述混沌实验任务之后，还包括：

接收所述服务器组中的各服务器中返回的软件指标；

根据所述软件指标确定所述各服务器在执行对应的混沌实验任务时对所述各服务器上运行的软件的影响。

6.根据权利要求4所述的方法，其特征在于，所述服务器中安装的目标应用包括管理工具和多种故障注入工具；

相应的，所述服务器执行所述混沌实验任务，包括：

所述管理工具接收对应的混沌实验任务，其中，所述混沌实验任务中包含至少一个混沌实验事件；

所述管理工具确定所述混沌实验任务中包含的各混沌实验事件的执行时间和故障注入类型；

所述管理工具根据所述各混沌实验事件的执行时间调用所述各混沌实验事件的故障注入类型对应的故障注入工具对所述服务器进行故障注入。

7.根据权利要求2所述的方法，其特征在于，所述多个服务器包括以下至少之一：虚拟机、物理机和容器；

将所述目标应用的安装包下发至所述服务器组中的多个服务器中各服务器，包括：

基于运维平台将所述目标应用的安装包下发至所述服务器组中的多个服务器中的物理机和/或虚拟机；和/或

基于Ansible将所述目标应用的安装包下发至所述服务器组中的多个服务器中的容器。

8.一种服务测试装置，其特征在于，包括：

确定模块，用于确定提供目标服务所需的服务器组，其中，所述服务器组中存在多个服务器；

设置模块，用于为所述服务器组设置多个测试任务，其中，一个测试任务用于对一个或多个服务器进行性能测试；

控制模块，用于控制所述服务器组并行执行所述多个测试任务，以确定所述目标服务是否满足预设的性能要求。

9.一种计算机设备，其特征在于，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现权利要求1至7中任一项所述方法的步骤。

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