CN114153732A - 故障场景测试方法、装置、电子设备及存储介质 - Google Patents

Abstract

本发明公开了一种故障场景测试方法、装置、电子设备及存储介质，其中，该方法包括：获取待测试应用场景和该待测试应用场景的待模拟故障信息；基于预先设置的故障编排配置，根据所述待测试应用场景和待模拟故障信息生成故障编排流程，所述故障编排配置基于容器和虚拟机的资源类型生成；根据所述故障编排流程对所述待测试应用场景进行测试操作。通过本发明，可以提升测试系统的扩展性，降低系统维护的复杂性。

Description

故障场景测试方法、装置、电子设备及存储介质

技术领域

本发明涉及计算机技术领域，具体涉及一种故障场景测试方法、装置、电子设备及存储介质。

背景技术

混沌工程是一种保证系统健壮性、提升系统稳定性的系统测试工具，作为对混沌工程的落地，故障模拟和故障流程编排是必不可少的一个环节，故障流程编排可以对故障模拟的流程进行编排，使之自动化、可重复。

目前，通用的故障流程编排方案通过如下两种方式来实现：

(1)Argo：容器本地工作流引擎

Argo workflows是一个容器本地工作流引擎，用于在kubernetes上运行作业，基于kubernetesCRD实现，无法支持虚拟机工作流。

(2)JenKins pipeline：对JenkinsCICD过程进行编排的工作流

pipeline将原本独立运行于多个job(任务)或者多个节点的任务统一使用代码的方式进行管理和维护，其中，包含所有执行步骤的jenkinsfile，需要放到对应工程代码的根目录，这种分散的方式使后期的迭代维护成本非常高。

此外，argo中包含了有向无环图，Artifacts工件等元素，pipeline中包含了调试工具等信息，不适用于金融机构故障场景，如使用argo和pipeline引擎，则需要对测试系统进行较大工作量的改进，这会增大测试系统的开销和维护成本。

也就是说，目前尚未有故障流程编排的成熟方案。同时，随着云原生概念的流行，部分企业的应用已经迁移到容器环境，而目前大部分应用仍然部署在虚拟机上，因此，故障模拟和故障流程编排势必须同时兼顾容器和虚拟机两种截然不同的底层应用部署环境。

然而，目前尚未有同时兼顾容器和虚拟机的故障模拟和故障流程编排方案，这是亟待需要解决的问题。

发明内容

有鉴于此，本发明提供一种故障场景测试方法、装置、电子设备及存储介质，以解决上述提及的至少一个问题。

根据本发明的第一方面，提供一种故障场景测试方法，所述方法包括：

获取待测试应用场景和该待测试应用场景的待模拟故障信息；

基于预先设置的故障编排配置，根据所述待测试应用场景和待模拟故障信息生成故障编排流程，所述故障编排配置基于容器和虚拟机的资源类型生成；

根据所述故障编排流程对所述待测试应用场景进行测试操作。

具体地，通过如下方式设置所述故障编排配置：

获取同时存在于容器和虚拟机中的资源类型；

根据预定规则对各资源类型的故障类型进行故障元数据抽象操作，以生成各故障类型的故障元数据；

根据所述各故障类型的故障元数据生成所述故障编排配置。

优选地，根据预定规则对各资源类型的故障类型进行故障元数据抽象操作，以生成各故障类型的故障元数据包括：

基于各资源类型的故障类型确定各故障的产生因素；

根据所述各故障的产生因素对各资源类型的故障类型进行故障元数据抽象操作，以生成各故障类型的故障元数据。

具体地，根据所述各故障类型的故障元数据生成所述故障编排配置包括：

根据预定规则对同时存在于容器和虚拟机的资源类型进行抽象操作，以生成资源元数据；

根据所述资源元数据和所述各故障类型的故障元数据生成故障编排配置。

优选地，当待模拟故障信息包含多个时，根据所述待测试应用场景和待模拟故障信息生成故障编排流程包括：

根据所述待测试应用场景确定各待模拟故障信息的执行方式，所述执行方式包括：顺序执行或并行执行；

基于各待模拟故障信息的执行方式，根据所述待测试应用场景和待模拟故障信息生成故障编排流程。

进一步地，根据所述故障编排流程对所述待测试应用场景进行测试操作之后，所述方法还包括：

获取测试操作结果，并将所述测试操作结果与预期指标进行比较操作；

根据比较操作结果对待测试应用场景的系统进行评估。

具体地，所述故障编排配置包括：多个编排配置要素，其中，编排配置要素包括：应用场景、故障执行信息、执行控制信息、编排要素编号。

根据本发明的第二方面，提供一种故障场景测试装置，所述装置包括：

测试信息获取单元，用于获取待测试应用场景和该待测试应用场景的待模拟故障信息；

故障编排流程生成单元，用于基于预先设置的故障编排配置，根据所述待测试应用场景和待模拟故障信息生成故障编排流程，所述故障编排配置基于容器和虚拟机的资源类型生成；

测试单元，用于根据所述故障编排流程对所述待测试应用场景进行测试操作。

具体地，所述装置还包括：故障编排配置设置单元，用于设置所述故障编排配置，所述故障编排配置设置单元包括：

资源类型获取模块，用于获取同时存在于容器和虚拟机中的资源类型；

故障元数据生成模块，用于根据预定规则对各资源类型的故障类型进行故障元数据抽象操作，以生成各故障类型的故障元数据；

故障编排配置生成模块，用于根据所述各故障类型的故障元数据生成所述故障编排配置。

优选地，所述故障元数据生成模块包括：

故障产生因素确定子模块，用于基于各资源类型的故障类型确定各故障的产生因素；

故障元数据生成子模块，用于根据所述各故障的产生因素对各资源类型的故障类型进行故障元数据抽象操作，以生成各故障类型的故障元数据。

具体地，所述故障编排配置生成模块包括：

资源元数据生成子模块，用于根据预定规则对同时存在于容器和虚拟机的资源类型进行抽象操作，以生成资源元数据；

故障编排配置生成子模块，用于根据所述资源元数据和所述各故障类型的故障元数据生成故障编排配置。

具体地，当待模拟故障信息包含多个时，所述故障编排流程生成单元包括：

执行方式确定模块，用于根据所述待测试应用场景确定各待模拟故障信息的执行方式，所述执行方式包括：顺序执行或并行执行；

故障编排流程生成模块，用于基于各待模拟故障信息的执行方式，根据所述待测试应用场景和待模拟故障信息生成故障编排流程。

进一步地，所述装置还包括：

结果比较单元，用于获取测试操作结果，并将所述测试操作结果与预期指标进行比较操作；

评估单元，用于根据比较操作结果对待测试应用场景的系统进行评估。

具体地，所述故障编排配置包括：多个编排配置要素，其中，编排配置要素包括：应用场景、故障执行信息、执行控制信息、编排要素编号。

根据本发明的第三方面，提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法的步骤。

根据本发明的第四方面，提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述方法的步骤。

根据本发明的第五方面，提供一种计算机程序产品，包括计算机程序/指令，该计算机程序/指令被处理器执行时实现上述方法的步骤。

由上述技术方案可知，通过获取待测试应用场景及其待模拟故障信息，随后基于预先设置的故障编排配置，根据所述待测试应用场景和待模拟故障信息生成故障编排流程，之后根据故障编排流程对所述待测试应用场景进行测试操作，由于预先设置了基于容器和虚拟机的资源类型生成的故障编排配置，可以实现同时支持容器和虚拟机的故障场景测试，从而可以提升测试系统的扩展性，降低系统维护的复杂性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是相关技术中的虚拟机混沌实验流程图；

图2是相关技术中的容器混沌实验流程图；

图3是根据本发明实施例的故障场景测试方法的流程图；

图4是根据本发明实施例的设置故障编排配置的流程图；

图5是根据本发明实施例的故障元数据抽象操作流程示意图；

图6是根据本发明实施例的故障编排流程示意图；

图7是根据本发明实施例的基于混沌工程的故障场景测试方法的详细流程图；

图8是根据本发明实施例的故障场景测试装置的结构框图；

图9为本发明实施例的电子设备600的系统构成的示意框图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在描述本发明实施例之前，为更好地理解本发明，对以下术语进行解释：

(1)虚拟机

虚拟机(Virtual Machine)指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。在实体计算机中能够完成的工作在虚拟机中都能够实现。在计算机中创建虚拟机时，需要将实体机的部分硬盘和内存容量作为虚拟机的硬盘和内存容量。每个虚拟机都有独立的CMOS、硬盘和操作系统，可以像使用实体机一样对虚拟机进行操作。

(2)容器

有效的将单个操作系统的资源划分到孤立的组中，以便更好的在孤立的组之间平衡有冲突的资源使用需求，这种技术就是容器技术。

(3)Kubernetes

Kubernetes，简称K8s，是用8代替8个字符“ubernete”而成的缩写。Kubernetes是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效(powerful)，Kubernetes提供了应用部署、规划、更新、维护的机制。

(4)混沌工程

混沌工程是一种通过实验探究的方式来让我们理解系统行为的方法。混沌工程通过设计和执行一系列实验，帮助我们发现系统中潜在的、可以导致灾难的或让我们的用户受损的脆弱环节，推动我们主动解决这些环节存在的问题。

(5)故障模拟

故障模拟是通过模拟现实世界中可能发生的事情比如宕机、网络故障等操作，对系统进行故障注入来测试系统的响应，达到提升系统的容错能力的目的。

(6)故障流程编排

故障流程编排是对故障进行一定的编排，使其按照规定的流程执行。主要是因为故障场景通常由多个故障步骤构成，如果不进行一定的编排，容易导致各个故障杂乱无序地执行，难以达到实现针对性目标的故障演练目的。

在实现本发明的过程中，申请人发现如下相关技术：

图1是虚拟机混沌实验流程图，如图1所示，虚拟机混沌实验(即，测试)流程包括：部署并启动应用程序，部署并启动虚拟机混沌实验工具，随后查看系统CPU、内存、磁盘、网络等性能指标，查看应用进程的进程信息，并根据上述信息以及实验目的执行具体的实验命令，设置相应的参数，之后，通过各种性能监控工具观察实验结果，对比实验结果与预期指标，得到测试结论。

图2是容器混沌实验流程图，如图2所示，容器混沌实验流程与虚拟机混沌实验流程基本一致，两者混沌实验技术中均包含了部署应用程序、启动应用程序等多个相同的操作步骤，这在一定程度上反映了操作的可重复性、低效性。

针对这一特点，本发明实施例对混沌实验流程进行了统一的流程抽象和编排，使其同时支持容器和虚拟机这两种不同底层技术的实验，从而可以提高混沌实验的效率。

鉴于目前尚未有同时兼顾容器和虚拟机的故障模拟和故障流程编排方案，本发明实施例提供一种故障场景测试方案，该方案可以同时支持容器和虚拟机的故障场景编排，通过设计相应场景的编排流程模型，可以提升测试系统的扩展性，降低系统维护的复杂性。以下结合附图来详细描述本发明实施例。

图3是根据本发明实施例的故障场景测试方法的流程图，如图3所示，该流程包括：

步骤301，获取待测试应用场景和该待测试应用场景的待模拟故障信息；

步骤302，基于预先设置的故障编排配置，根据所述待测试应用场景和待模拟故障信息生成故障编排流程，所述故障编排配置基于容器和虚拟机的资源类型生成；

步骤303，根据所述故障编排流程对所述待测试应用场景进行测试操作。

通过获取待测试应用场景及其待模拟故障信息，随后基于预先设置的故障编排配置，根据所述待测试应用场景和待模拟故障信息生成故障编排流程，之后根据故障编排流程对所述待测试应用场景进行测试操作，由于预先设置了基于容器和虚拟机的资源类型生成的故障编排配置，可以实现同时支持容器和虚拟机的故障场景测试，从而可以提升测试系统的扩展性，降低系统维护的复杂性。

在一个实施例中，如图4所示，上述故障编排配置可以通过如下步骤401-403来设置：

步骤401，获取同时存在于容器和虚拟机中的资源类型。资源类型可以包括：CPU资源、内存资源、网络资源、IO资源、磁盘资源等。

具体地，可以分别获取容器和虚拟机的资源类型，之后取两者的交集，即可得到同时存在于容器和虚拟机的资源类型。

步骤402，根据预定规则对各资源类型的故障类型进行故障元数据抽象操作，以生成各故障类型的故障元数据。

这里的预定规则可以是进行故障元数据抽象操作的预定流程。例如，可以先基于各资源类型的故障类型确定各故障的产生因素；之后根据所述各故障的产生因素对各资源类型的故障类型进行故障元数据抽象操作，以生成各故障类型的故障元数据。

步骤403，根据所述各故障类型的故障元数据生成所述故障编排配置。

具体而言，可以根据预定规则对同时存在于容器和虚拟机的资源类型进行抽象操作，以生成资源元数据；之后，根据所述资源元数据和所述各故障类型的故障元数据生成故障编排配置。

这里的预定规则可以是进行资源类型抽象操作的预定流程。表1为虚拟机和容器资源数据的抽象结果：

资源名	解释
		机器名	虚拟机机器名，容器metadata中的name，或pod名字
进程名	虚拟机中的进程名，或容器中的进程名
		IP地址	虚拟机的IP地址，k8s集群中容器所在的pod IP
网络	虚拟机和k8s集群中pod的网络资源
		CPU	虚拟机和k8s集群中pod的CPU资源
内存	虚拟机和k8s集群中pod的内存资源
		IO	虚拟机和k8s集群中pod的IO
目录	虚拟机的目录，k8s集群中容器所在的pod挂载卷的目录
		文件	虚拟机的文件，k8s集群中容器所在的pod挂载卷的文件

表1

图5是根据本发明实施例的故障元数据抽象操作流程示意图，如图5所示，该流程包括：定位所有系统资源，选择其中一种资源，判断该资源是否同时在虚拟机和容器(和Kubernetes)中存在，如果都存在，则判断该资源是否可以形成如下状态：错误、或者饱和状态、或者高使用率，如果是，则对该资源进行抽象，并对该资源构造上述状态的故障进行抽象。

例如，在进行故障元数据抽象操作之前，首先需要定位虚拟机和容器上可能有的资源类型，包括：CPU资源、内存资源、网络资源、IO资源、磁盘资源等，容器还包括不同的数据存储方式等。

由于内存资源在虚拟机和容器中均存在，因而以下以内存资源为例，结合图5所示流程，来描述该资源的抽象过程，可以从以下3个方面进行抽象：

(1)判断是否可以形成错误->是->构造内存错误类型故障->如malloc()分配内存失败；

(2)判断是否可以形成饱和状态->是->构造内存饱和类型故障->如OOM；

(3)判断是否可以形成高使用率->是->构造内存高使用率类型故障->通过启动大量消耗内存的进程来使内存达到一个高使用率的状态。

随后，分析分配内存失败、OOM和内存高使用率这三种故障类型的构成方法，例如，分配内存失败可以通过使malloc()方法返回失败构造、OOM需要明确待构造的进程号、高使用率可以通过施加内存类型的压力来构造。之后，对于内存资源，可以抽象出如表2所示的底层的故障元数据：

表2

与上述内存资源是故障元数据抽象操作类似地，其余资源的故障元数据抽象也可以依据上述图5所示的流程进行操作。

以下给出7种资源故障元数据抽象的结果，如表3-表9所示：

(1)进程故障模拟元数据

表3

(2)网络故障模拟元数据

表4

(3)IO故障模拟元数据

表5

(4)DNS故障模拟元数据

故障类型	DNS服务器故障、随机分配IP
		匹配模式	当故障类型为随机分配IP时，设置匹配模式匹配要分配的IP

表6

(5)内存故障类型元数据

表7

(6)CPU故障类型元数据

故障类型	ECC事件、长分配队列长度、CPU压力
		压力数量	用于控制发压进程的数量，数量越多，压力越大
分配队列长度	用于构造长分配队列长度故障，该数值越大，分配队列长度越长

表8

(7)磁盘故障类型元数据

表9

通过上述抽象得到的资源元数据和各故障类型的故障元数据，就可以生成故障编排配置。在实际操作中，该故障编排配置包括：多个编排配置要素，应用场景(例如，场景描述等)、故障执行信息(例如，执行方式等)、执行控制信息(例如，执行时间等)、编排要素编号等。具体地，编排配置要素如表10所示：

表10

在一个实施例中，当步骤301的待模拟故障信息包含多个时，则步骤302的根据所述待测试应用场景和待模拟故障信息生成故障编排流程包括：根据所述待测试应用场景确定各待模拟故障信息的执行方式，所述执行方式包括：顺序执行或并行执行；之后基于各待模拟故障信息的执行方式，根据所述待测试应用场景和待模拟故障信息生成故障编排流程。

具体而言，可以基于上述表10所示的编排配置要素，结合应待测试用场景和待模拟故障信息生成故障编排流程。

图6是根据本发明实施例的故障编排流程示意图，如图6所示，该流程可以包括：故障阶段、故障步骤和故障动作。基于应用场景的混沌实验流程可能包含多个故障阶段，每个故障阶段可以包括多个故障步骤，每个步骤可以包括多个故障动作，为了使得整个混沌实验的层次更加清晰，按照实验操作命令不可划分的最小粒度原则，设计了图6所示的故障编排流程。

例如，在一个实验故障编排工作流中，该实验包含两个故障实验阶段，这两个实验阶段的执行方式为顺序方式。故障阶段一为网络类型故障，故障阶段二为压力类型故障。基于图6，设计的故障编排流程如下：

故障阶段一包含2个并行方式执行的故障步骤，步骤1为网络包损坏，步骤2为网络延迟。其中，步骤1由2个顺序执行的故障动作构成，包损坏20％持续5s，包损坏50％持续10s；步骤2只包含1个故障动作，网络延迟60s。

故障阶段二包含2个顺序方式执行的故障步骤，步骤1为CPU压力，步骤2为内存压力。其中，步骤1由2个并行执行的故障动作构成，CPU占用70％持续5s，CPU占用90％持续20s；步骤2同样由2个并行执行的故障动作构成，内存占用40％持续5s，内存占用60％持续20s。

在一个实施例中，执行方式的元数据可以加入到上述的编排配置要素中，其中，表11为顺序方式元数据，表12为并行方式元数据：

前置步骤编号	顺序执行的前一步故障编号
		后置步骤编号	顺序执行的后一步故障编号

表11

元素编号

并行执行的故障编号

表12

以下以被测应用环境为应用网关服务为例，结合图7所示的基于混沌工程的故障场景测试(或称为实验)流程来详细描述本发明实施例。

参见图7，在测试开始之前，首先在被测环境中部署该网关服务的应用程序，并且启动该程序。然后，在该环境中部署并启动混沌实验工具，以上述实验故障编排工作流为例并且根据编排配置要素生成本次实验的编排案例(即，故障编排流程)，根据编排配置要素，来确定本次测试需要执行的基础设施环境。最后，混沌实验工具根据已生成的编排案例流程来执行本次测试实验，在测试实验结束之后，测试人员可以人工观察实验结果，并将实验的结果与预期的实验指标进行对比，对被测应用环境的系统进行评估，得出关于被测系统健壮性、稳定性等方面有关问题的结论。至此，整个实验的过程将全部结束，根据实验结论进一步迭代优化整个系统即可。

由以上描述可知，本发明实施例通过对底层虚拟机和容器、kubernetes等的特征进行抽象，以及对各种故障类型元数据进行抽象和建模，使得故障编排可以忽略底层实现的差异，实现了全新的基于混沌工程的故障模拟编排方式，有效解决了人工编排效率低且不可重复的问题。

基于相似的发明构思，本发明实施例还提供一种故障场景测试装置，该装置优选地可用于实现上述故障场景测试方法。

图8是该故障场景测试装置的结构框图，如图8所示，该故障场景测试装置包括：测试信息获取单元1、故障编排流程生成单元2和测试单元3，其中：

测试信息获取单元1，用于获取待测试应用场景和该待测试应用场景的待模拟故障信息。

故障编排流程生成单元2，用于基于预先设置的故障编排配置，根据所述待测试应用场景和待模拟故障信息生成故障编排流程，所述故障编排配置基于容器和虚拟机的资源类型生成。

具体地，故障编排配置包括：多个编排配置要素，例如，应用场景、故障执行信息、执行控制信息、编排要素编号。

测试单元3，用于根据所述故障编排流程对所述待测试应用场景进行测试操作。

通过测试信息获取单元1获取待测试应用场景及其待模拟故障信息，随后故障编排流程生成单元2基于预先设置的故障编排配置，根据所述待测试应用场景和待模拟故障信息生成故障编排流程，之后测试单元3根据故障编排流程对所述待测试应用场景进行测试操作，由于预先设置了基于容器和虚拟机的资源类型生成的故障编排配置，可以实现同时支持容器和虚拟机的故障场景测试，从而可以提升测试系统的扩展性，降低系统维护的复杂性。

在一个实施例中，上述装置还包括：故障编排配置设置单元，用于设置所述故障编排配置。

该故障编排配置设置单元包括：资源类型获取模块、故障元数据生成模块和故障编排配置生成模块，其中：

资源类型获取模块，用于获取同时存在于容器和虚拟机中的资源类型。

故障元数据生成模块，用于根据预定规则对各资源类型的故障类型进行故障元数据抽象操作，以生成各故障类型的故障元数据。

具体地，该故障元数据生成模块包括：故障产生因素确定子模块和故障元数据生成子模块，其中：故障产生因素确定子模块，用于基于各资源类型的故障类型确定各故障的产生因素；故障元数据生成子模块，用于根据所述各故障的产生因素对各资源类型的故障类型进行故障元数据抽象操作，以生成各故障类型的故障元数据。

故障编排配置生成模块，用于根据所述各故障类型的故障元数据生成所述故障编排配置。

具体地，该故障编排配置生成模块包括：资源元数据生成子模块和故障编排配置生成子模块，其中：资源元数据生成子模块，用于根据预定规则对同时存在于容器和虚拟机的资源类型进行抽象操作，以生成资源元数据；故障编排配置生成子模块，用于根据所述资源元数据和所述各故障类型的故障元数据生成故障编排配置。

当待模拟故障信息包含多个时，所述故障编排流程生成单元2包括：执行方式确定模块和故障编排流程生成模块，其中：

执行方式确定模块，用于根据所述待测试应用场景确定各待模拟故障信息的执行方式，所述执行方式包括：顺序执行或并行执行；

故障编排流程生成模块，用于基于各待模拟故障信息的执行方式，根据所述待测试应用场景和待模拟故障信息生成故障编排流程。

在具体实施时，上述装置还包括：结果比较单元和评估单元，其中：

结果比较单元，用于获取测试操作结果，并将所述测试操作结果与预期指标进行比较操作；

评估单元，用于根据比较操作结果对待测试应用场景的系统进行评估。

通过上述结果比较单元和评估单元，可以关于被测应用场景的系统健壮性、稳定性等方面有关问题的结论。

上述各单元、各模块、各子模块的具体执行过程，可以参见上述方法实施例中的描述，此处不再赘述。

在实际操作中，上述各单元、各模块、各子模块可以组合设置、也可以单一设置，本发明不限于此。

本实施例还提供一种电子设备，该电子设备可以是台式计算机、平板电脑及移动终端等，本实施例不限于此。在本实施例中，该电子设备可以参照上述方法实施例进行实施及故障场景测试装置的实施例进行实施，其内容被合并于此，重复之处不再赘述。

图9为本发明实施例的电子设备600的系统构成的示意框图。如图9所示，该电子设备600可以包括中央处理器100和存储器140；存储器140耦合到中央处理器100。值得注意的是，该图是示例性的；还可以使用其他类型的结构，来补充或代替该结构，以实现电信功能或其他功能。

一实施例中，故障场景测试功能可以被集成到中央处理器100中。其中，中央处理器100可以被配置为进行如下控制：

获取待测试应用场景和该待测试应用场景的待模拟故障信息；

基于预先设置的故障编排配置，根据所述待测试应用场景和待模拟故障信息生成故障编排流程，所述故障编排配置基于容器和虚拟机的资源类型生成；

根据所述故障编排流程对所述待测试应用场景进行测试操作。

从上述描述可知，本申请实施例提供的电子设备，通过获取待测试应用场景及其待模拟故障信息，随后基于预先设置的故障编排配置，根据所述待测试应用场景和待模拟故障信息生成故障编排流程，之后根据故障编排流程对所述待测试应用场景进行测试操作，由于预先设置了基于容器和虚拟机的资源类型生成的故障编排配置，可以实现同时支持容器和虚拟机的故障场景测试，从而可以提升测试系统的扩展性，降低系统维护的复杂性。

在另一个实施方式中，故障场景测试装置可以与中央处理器100分开配置，例如可以将故障场景测试装置配置为与中央处理器100连接的芯片，通过中央处理器的控制来实现故障场景测试功能。

如图9所示，该电子设备600还可以包括：通信模块110、输入单元120、音频处理单元130、显示器160、电源170。值得注意的是，电子设备600也并不是必须要包括图9中所示的所有部件；此外，电子设备600还可以包括图9中没有示出的部件，可以参考现有技术。

如图9所示，中央处理器100有时也称为控制器或操作控件，可以包括微处理器或其他处理器装置和/或逻辑装置，该中央处理器100接收输入并控制电子设备600的各个部件的操作。

其中，存储器140，例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息，此外还可存储执行有关信息的程序。并且中央处理器100可执行该存储器140存储的该程序，以实现信息存储或处理等。

输入单元120向中央处理器100提供输入。该输入单元120例如为按键或触摸输入装置。电源170用于向电子设备600提供电力。显示器160用于进行图像和文字等显示对象的显示。该显示器例如可为LCD显示器，但并不限于此。

该存储器140可以是固态存储器，例如，只读存储器(ROM)、随机存取存储器(RAM)、SIM卡等。还可以是这样的存储器，其即使在断电时也保存信息，可被选择性地擦除且设有更多数据，该存储器的示例有时被称为EPROM等。存储器140还可以是某种其它类型的装置。存储器140包括缓冲存储器141(有时被称为缓冲器)。存储器140可以包括应用/功能存储部142，该应用/功能存储部142用于存储应用程序和功能程序或用于通过中央处理器100执行电子设备600的操作的流程。

存储器140还可以包括数据存储部143，该数据存储部143用于存储数据，例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器140的驱动程序存储部144可以包括电子设备的用于通信功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。

通信模块110即为经由天线111发送和接收信号的发送机/接收机110。通信模块(发送机/接收机)110耦合到中央处理器100，以提供输入信号和接收输出信号，这可以和常规移动通信终端的情况相同。

基于不同的通信技术，在同一电子设备中，可以设置有多个通信模块110，如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通信模块(发送机/接收机)110还经由音频处理器130耦合到扬声器131和麦克风132，以经由扬声器131提供音频输出，并接收来自麦克风132的音频输入，从而实现通常的电信功能。音频处理器130可以包括任何合适的缓冲器、解码器、放大器等。另外，音频处理器130还耦合到中央处理器100，从而使得可以通过麦克风132能够在本机上录音，且使得可以通过扬声器131来播放本机上存储的声音。

本发明实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时以实现上述故障场景测试方法的步骤。

综上所述，本发明实施例通过对混沌工程下故障模拟进行编排，可以有效解决人工编排效率低且不可重复的问题，大大提升了进行混沌测试的效率，从而提升被测系统的稳定性和可容错能力，是混沌工程落地中不可缺失的一环。同时，对于容器和虚拟机的元数据抽象和对故障类型元数据的抽象，可以消除底层物理系统的差距，使得上层的编排模型更具可维护性，且能对底层资源进行综合调度，可降低资源管理和流程调度的复杂度。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于硬件+程序类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

本说明书实施例中的术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

本领域技术人员应明白，本说明书的实施例可提供为方法、系统或计算机程序产品。因此，本说明书实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本说明书实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书实施例的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

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

Claims (17)

1.一种故障场景测试方法，其特征在于，所述方法包括：

获取待测试应用场景和该待测试应用场景的待模拟故障信息；

基于预先设置的故障编排配置，根据所述待测试应用场景和待模拟故障信息生成故障编排流程，所述故障编排配置基于容器和虚拟机的资源类型生成；

根据所述故障编排流程对所述待测试应用场景进行测试操作。

2.根据权利要求1所述的方法，其特征在于，通过如下方式设置所述故障编排配置：

获取同时存在于容器和虚拟机中的资源类型；

根据预定规则对各资源类型的故障类型进行故障元数据抽象操作，以生成各故障类型的故障元数据；

根据所述各故障类型的故障元数据生成所述故障编排配置。

3.根据权利要求2所述的方法，其特征在于，根据预定规则对各资源类型的故障类型进行故障元数据抽象操作，以生成各故障类型的故障元数据包括：

基于各资源类型的故障类型确定各故障的产生因素；

根据所述各故障的产生因素对各资源类型的故障类型进行故障元数据抽象操作，以生成各故障类型的故障元数据。

4.根据权利要求2所述的方法，其特征在于，根据所述各故障类型的故障元数据生成所述故障编排配置包括：

根据预定规则对同时存在于容器和虚拟机的资源类型进行抽象操作，以生成资源元数据；

根据所述资源元数据和所述各故障类型的故障元数据生成故障编排配置。

5.根据权利要求1所述的方法，其特征在于，当待模拟故障信息包含多个时，根据所述待测试应用场景和待模拟故障信息生成故障编排流程包括：

根据所述待测试应用场景确定各待模拟故障信息的执行方式，所述执行方式包括：顺序执行或并行执行；

基于各待模拟故障信息的执行方式，根据所述待测试应用场景和待模拟故障信息生成故障编排流程。

6.根据权利要求1所述的方法，其特征在于，根据所述故障编排流程对所述待测试应用场景进行测试操作之后，所述方法还包括：

获取测试操作结果，并将所述测试操作结果与预期指标进行比较操作；

根据比较操作结果对待测试应用场景的系统进行评估。

7.根据权利要求1至6中任一项所述的方法，其特征在于，所述故障编排配置包括：多个编排配置要素，其中，编排配置要素包括：应用场景、故障执行信息、执行控制信息、编排要素编号。

8.一种故障场景测试装置，其特征在于，所述装置包括：

测试信息获取单元，用于获取待测试应用场景和该待测试应用场景的待模拟故障信息；

故障编排流程生成单元，用于基于预先设置的故障编排配置，根据所述待测试应用场景和待模拟故障信息生成故障编排流程，所述故障编排配置基于容器和虚拟机的资源类型生成；

测试单元，用于根据所述故障编排流程对所述待测试应用场景进行测试操作。

9.根据权利要求8所述的装置，其特征在于，所述装置还包括：故障编排配置设置单元，用于设置所述故障编排配置，

所述故障编排配置设置单元包括：

资源类型获取模块，用于获取同时存在于容器和虚拟机中的资源类型；

故障元数据生成模块，用于根据预定规则对各资源类型的故障类型进行故障元数据抽象操作，以生成各故障类型的故障元数据；

故障编排配置生成模块，用于根据所述各故障类型的故障元数据生成所述故障编排配置。

10.根据权利要求9所述的装置，其特征在于，所述故障元数据生成模块包括：

故障产生因素确定子模块，用于基于各资源类型的故障类型确定各故障的产生因素；

故障元数据生成子模块，用于根据所述各故障的产生因素对各资源类型的故障类型进行故障元数据抽象操作，以生成各故障类型的故障元数据。

11.根据权利要求9所述的装置，其特征在于，所述故障编排配置生成模块包括：

资源元数据生成子模块，用于根据预定规则对同时存在于容器和虚拟机的资源类型进行抽象操作，以生成资源元数据；

故障编排配置生成子模块，用于根据所述资源元数据和所述各故障类型的故障元数据生成故障编排配置。

12.根据权利要求8所述的装置，其特征在于，当待模拟故障信息包含多个时，所述故障编排流程生成单元包括：

执行方式确定模块，用于根据所述待测试应用场景确定各待模拟故障信息的执行方式，所述执行方式包括：顺序执行或并行执行；

故障编排流程生成模块，用于基于各待模拟故障信息的执行方式，根据所述待测试应用场景和待模拟故障信息生成故障编排流程。

13.根据权利要求8所述的装置，其特征在于，所述装置还包括：

结果比较单元，用于获取测试操作结果，并将所述测试操作结果与预期指标进行比较操作；

评估单元，用于根据比较操作结果对待测试应用场景的系统进行评估。

14.根据权利要求8至13中任一项所述的装置，其特征在于，所述故障编排配置包括：多个编排配置要素，其中，编排配置要素包括：应用场景、故障执行信息、执行控制信息、编排要素编号。

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

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

17.一种计算机程序产品，包括计算机程序/指令，其特征在于，该计算机程序/指令被处理器执行时实现权利要求1至7中任一项所述方法的步骤。

Images