CN116909787A - 故障注入的方法、装置、存储介质及终端 - Google Patents

Abstract

本申请提供了一种故障注入的方法、装置、存储介质及终端，该方法涉及故障注入技术领域，包括：接收目标故障场景的信息，其中，目标故障场景包括目标故障对象与目标故障类型，目标故障类型为目标故障对象的故障类型；确定目标故障场景对应的目标故障注入指令；执行目标故障注入指令，得到目标故障场景的故障注入结果。本申请能够实现故障注入测试流程的自动化，并降低人工管理成本。

Description

故障注入的方法、装置、存储介质及终端

技术领域

本申请涉及故障注入技术领域，尤其涉及一种故障注入的方法、装置、存储介质及终端。

背景技术

故障注入测试(Fault Injection Test)是一种评估系统可靠性的有效方法，通过人为地将软件模块故障或硬件故障注入到系统中，并采集测试过程中所产生的相关数据，从而对系统进行可靠性的分析。

相关技术中，通常整个故障注入测试的流程较为复杂且耗时较长，并且对故障注入场景等进行维护所耗费的成本也较高。可见，为解决上述问题，需要提供一种能够提升故障注入测试的效率并降低成本的方案。

发明内容

本申请提供了一种故障注入的方法、装置、存储介质及终端，能够实现故障注入测试流程的自动化，并降低人工管理成本。

第一方面，提供一种故障注入的方法，该方法包括：接收目标故障场景的信息，其中，上述目标故障场景包括目标故障对象与目标故障类型，上述目标故障类型为上述目标故障对象的故障类型；确定上述目标故障场景对应的目标故障注入指令；执行上述目标故障注入指令，得到上述目标故障场景的故障注入结果。

结合第一方面，在一种可能的实现方式中，还包括：根据上述目标故障场景，确定上述目标故障场景对应的故障注入工具；上述执行上述目标故障注入指令，得到上述目标故障场景的故障注入结果，包括：通过上述故障注入工具执行上述目标故障注入指令，得到上述目标故障场景的故障注入结果。

结合第一方面和上述实现方式，在一种可能的实现方式中，上述根据上述目标故障场景，确定上述目标故障场景对应的故障注入工具，包括：根据上述目标故障场景在多个故障注入工具的镜像仓库地址中，确定目标镜像仓库地址，上述目标镜像仓库地址用于安装上述目标故障场景对应的故障注入工具。

结合第一方面和上述实现方式，在一种可能的实现方式中，上述目标故障对象属于第一类故障对象，上述方法还包括：通过第一算法对故障对象集合中的每类故障对象与故障类型集合中的每个故障类型进行组合，得到多个故障场景，上述第一算法包括笛卡尔积算法，上述故障对象集合包括上述第一类故障对象，上述故障类型集合包括上述目标故障类型，上述多个故障场景包括上述目标故障场景；配置上述多个故障场景中每个故障场景对应的故障注入指令，得到预配置的故障注入指令集合；上述确定上述目标故障场景对应的目标故障注入指令，包括：根据上述目标故障场景的信息与上述预配置的故障注入指令集合，确定上述目标故障注入指令。

结合第一方面和上述实现方式，在一种可能的实现方式中，上述根据上述目标故障场景的信息与上述预配置的故障注入指令集合，确定上述目标故障注入指令，包括：根据上述目标故障对象的标识，查找上述目标故障对象的参数信息；若未查找到上述目标故障对象的参数信息，通过应用程序接口获取上述目标故障对象的参数信息；根据上述目标故障对象的参数信息、上述目标故障类型的信息与上述预配置的故障注入指令集合，确定上述目标故障注入指令。

结合第一方面和上述实现方式，在一种可能的实现方式中，在通过应用程序接口获取上述目标故障对象的参数信息之后，上述方法还包括：存储上述目标故障对象的参数信息。

结合第一方面和上述实现方式，在一种可能的实现方式中，上述方法还包括：显示展示界面，上述展示界面中包括可视化图表，上述可视化图表用于展示上述故障注入结果。

第二方面，提供一种故障注入的装置，该装置包括：接收模块，用于：接收目标故障场景的信息，其中，上述目标故障场景包括目标故障对象与目标故障类型，上述目标故障类型为上述目标故障对象的故障类型；确定模块，用于：确定上述目标故障场景对应的目标故障注入指令；以及，执行上述目标故障注入指令，得到上述目标故障场景的故障注入结果。

结合第二方面和上述实现方式，在一种可能的实现方式中，上述确定模块还用于：根据上述目标故障场景，确定上述目标故障场景对应的故障注入工具；通过上述故障注入工具执行上述目标故障注入指令，得到上述目标故障场景的故障注入结果。

结合第二方面和上述实现方式，在一种可能的实现方式中，上述确定模块具体用于：根据上述目标故障场景在多个故障注入工具的镜像仓库地址中，确定目标镜像仓库地址，上述目标镜像仓库地址用于安装上述目标故障场景对应的故障注入工具。

结合第二方面和上述实现方式，在一种可能的实现方式中，上述目标故障对象属于第一类故障对象，上述确定模块还用于：通过第一算法对故障对象集合中的每类故障对象与故障类型集合中的每个故障类型进行组合，得到多个故障场景，上述第一算法包括笛卡尔积算法，上述故障对象集合包括上述第一类故障对象，上述故障类型集合包括上述目标故障类型，上述多个故障场景包括上述目标故障场景；配置上述多个故障场景中每个故障场景对应的故障注入指令，得到预配置的故障注入指令集合；上述确定模块具体用于：根据上述目标故障场景的信息与上述预配置的故障注入指令集合，确定上述目标故障注入指令。

结合第二方面和上述实现方式，在一种可能的实现方式中，上述确定模块具体用于：根据上述目标故障对象的标识，查找上述目标故障对象的参数信息；若未查找到上述目标故障对象的参数信息，通过应用程序接口获取上述目标故障对象的参数信息；根据上述目标故障对象的参数信息、上述目标故障类型的信息与上述预配置的故障注入指令集合，确定上述目标故障注入指令。

结合第二方面和上述实现方式，在一种可能的实现方式中，上述装置还包括：存储模块，上述存储模块，用于：存储上述目标故障对象的参数信息。

结合第二方面和上述实现方式，在一种可能的实现方式中，显示模块，上述显示模块，用于：显示展示界面，上述展示界面中包括可视化图表，上述可视化图表用于展示上述故障注入结果。

第三方面，提供一种终端，包括存储器、处理器以及存储在存储器中并可在处理器上运行的计算机程序，处理器执行计算机程序时，使得终端执行如第一个方面所述的故障注入的方法。

第四方面，提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现第一个方面所述的故障注入的方法。

第五方面，提供一种计算机程序产品，当计算机程序产品在处理器上运行时，使得处理器执行时实现第一个方面所述的故障注入的方法。

本申请所提供的故障注入的方法中，首先接收目标故障场景的信息，其中，目标故障场景包括目标故障对象与目标故障类型，目标故障类型包括目标故障对象的故障类型。确定目标故障场景后，确定其对应的目标故障注入指令，并执行该目标故障注入指令，从而得到目标故障对象的故障注入结果；由于本申请的方案无需用户自行维护故障注入的测试场景，也无需用户手动记录故障注入结果；因此，通过本申请的方案能够实现故障注入测试的自动化，从而实现故障注入测试流程的自动化，并降低维护测试场景等信息所需的成本。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请提供的一例故障注入的方法的流程图；

图2是本申请提供的一例故障注入的场景图；

图3a～图3c为本申请提供的另一例故障注入的方法的流程图；

图4a～图4b是本申请提供的一例确定故障场景的示意图；

图5是本申请提供的一例故障注入报告的示意图；

图6是本申请提供的一例故障注入的装置的结构图；

图7是本申请提供的另一例故障注入的装置的结构图；

图8是本申请提供的一例终端的结构图。

具体实施方式

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

下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请的描述中，需要理解的是，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本申请中的具体含义。此外，在本申请的描述中，除非另有说明，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

相关技术中，用户在对测试对象(例如：云主机、容器等等)进行故障注入的过程中，若测试对象有若干个，则需要一一确定每个测试对象所对应的测试类型(例如：内存负载、网络延迟等等)，并将测试对象所对应的测试类型进行记录，生成故障场景集合。而若在每一次故障注入的过程中，需要更改每个测试对象所对应的测试类型，则又会产生新的故障场景集合，如此一来，对于测试场景的维护成本会较高(需要更多的存储空间)且效率低下。

并且，在故障注入测试完成后，用户还需要自行记录测试数据，还可能需要根据测试数据自行整合故障注入的测试报告，从而使得人工成本较高，耗时较长且效率低下。

本申请提供了一种故障注入的方法、装置、存储介质及终端，能够实现故障注入测试流程的自动化，并降低成本。

图1是本申请提供的一例故障注入的场景图。

如图1所示，本申请所提供的故障注入方法可以应用于故障注入测试平台100。故障注入测试平台100具体可以为服务器或服务器集群，它与各个故障对象可以通过云端等方式进行通信连接，从而便于获取故障对象的相关信息。故障注入测试平台100能够接收客户端110所发送的相关请求，并通过本申请所提供的方法对故障对象进行故障注入测试，并且，可以记录故障注入结果并生成故障注入报告，以使客户端110将故障注入报告向用户进行展示。

图2是本申请提供的一例故障注入的方法的流程图。

如图2所示的故障注入的方法包括S210至S230；

S210，接收目标故障场景的信息。

S220，确定目标故障场景对应的目标故障注入指令。

S230，执行目标故障注入指令，得到目标故障场景的故障注入结果。

以下结合图1对图2所示实施例进行介绍：

在示例性的实施例中，可以将各个故障对象分为不同的类别，例如：云服务器、容器(对服务器中的应用程序的虚拟化)、虚拟机(对服务器整体的虚拟化，包括操作系统、应用程序、磁盘、中央处理器(Central Processing Unit，CPU))等等。目标故障对象即为上述某一类对象中的具体的故障对象，例如：云服务器中的云服务器A、容器中的容器B、虚拟机中的虚拟机C，等等。

故障类型为故障对象的故障类型，例如：网络故障注入(网络组网相关的接口、链路等)、资源类故障注入(动态内存、消息队列、CPU、磁盘等)、数据类故障注入(数据库、文件等)、接口类故障注入(各种接口协议消息)等等。目标故障类型即为上述故障类型中的一种，例如：网络故障、CPU故障、磁盘故障、内存故障等等。

故障注入测试平台100中可以将上述各类故障对象和故障类型进行存储，从而可以方便用户通过客户端110选择出需要进行故障注入的某一类对象和目标故障类型。

目标故障场景是目标故障对象和目标故障类型之间所形成的组合，例如，若目标故障对象为服务器A，目标故障类型为网络故障，则目标故障场景即为：服务器A-网络故障，也就是对服务器A进行网络故障的测试。

目标故障注入指令(或称，目标故障注入命令)即是将目标故障对象的相关参数传入预配置的故障注入指令(或称，故障注入命令)所得到的，它用于对目标故障场景执行故障注入测试。

故障注入结果为故障注入测试平台100对目标故障场景进行故障注入测试后所得到的结果，其中包含了多个故障注入数据，例如，在目标类型为CPU故障的情况下，所得到的故障注入数据可以包括CPU利用率的变化情况、进程的运行情况，等等。

本申请所提供的故障注入的方法中，用户可以在客户端110中进行相关操作，以确定目标故障场景，从而使得故障注入测试平台100接收客户端110发送的该目标故障场景。

接着，故障注入测试平台100根据目标故障场景确定其对应的目标故障注入指令，并执行该目标故障注入指令，从而得到目标故障对象的故障注入结果。从而，本申请能够实现故障注入测试的自动化，无需用户自行维护故障注入的测试场景，也无需用户手动记录故障注入结果，能够实现故障注入测试流程的自动化，并降低维护测试场景等信息所需的成本。

以下以图1所示实施例为基础对本申请提供的故障注入的方法进行更进一步的说明。

图3a～图3c为本申请提供的另一例故障注入的方法的流程图。

在示例性的实施例中，如图3a所示。用户在客户端110中可以进行录入用于故障注入测试的各类故障对象和各种故障类型的操作(S310)。故障注入平台100获取到用户所录入的各类故障对象(记作：故障对象集合)和各种故障类型(记作：故障类型集合)后，可以根据第一算法对故障对象集合和故障类型集合进行组合，从而得到不同的故障注入的故障场景(记作：故障场景集合)(S320)。

示例性的，参考表1所示的故障对象集合，以及表2所示的故障类型集合：

表1

云服务器
	容器
虚拟机

表2

CPU故障
	网络故障
磁盘故障
	内存故障

假设表1中的各类故障对象和表2中的故障类型为用户所录入的。用户所录入的对象包括云服务器、容器和虚拟机共3种，用户所录入的故障类型包括CPU故障、网络故障、磁盘故障和内存故障共4种。

接下来，故障注入平台100可以利用笛卡尔积(一个集合中的所有元素与另外一个集合中的所有元素的所有组合)来对表1的故障对象集合和表2的故障类型集合进行组合，所得到的故障场景集合可参考表3所示：

表3

在云服务器这一维度下，能够组合出的故障场景包括：云服务器-CPU故障、云服务器-网络故障、云服务器-磁盘故障和云服务器-内存故障；

在容器这一维度下，能够组合出的故障场景包括：容器-CPU故障、容器-网络故障、容器-磁盘故障和容器-内存故障；

同样地，在虚拟机这一维度下，能够组合出的故障场景包括：虚拟机-CPU故障、虚拟机-网络故障、虚拟机-磁盘故障和虚拟机-内存故障。

需要说明的是，上述根据第一算法得到故障场景集合的方式仅为示例，本实施例中对确定故障场景集合的方式不做限定。

在得到故障场景集合后，故障注入平台100可以对故障场景集合中的每一个故障场景关联对应的故障注入指令(这些故障注入指令可以是提前配置好的指令模板)(S321)，从而得到预配置的故障注入指令集合。

也就是说，每一个故障注入指令关联有对应的故障注入场景。故障注入指令中包含有计算机指令，在其中传入与故障对象的相关参数后便可对故障注入场景执行故障注入测试。例如，对于容器-CPU故障的场景，其关联的故障注入指令可以为：/blade create k8spod-cpu fullload--cpu-percent 100--names pod--namespace--kubeconfig/root/.kube/config；对于容器-内存故障的场景，其关联的故障注入指令可以为：./bladecreate k8s pod-mem load--mem-percent 100--names pod--namespace-kubeconfig/root/.kube/config。

示例性的，在进行关联时，可以为每个故障场景与其对应的故障注入指令设置相应的标识，从而使得故障注入平台100在后续能够根据故障场景的标识来找到其对应的故障注入指令。例如，对于容器-CPU故障的场景，为该故障场景和其对应的故障注入指令A设置标识为1，对于容器-内存故障的场景，为该故障场景和其对应的故障注入指令B设置标识为2，等等。从而在确定容器-CPU故障的场景所对应的故障注入指令时，找到标识1为的故障注入指令即可。

需要说明的是，上述对故障场景及其对应的故障注入指令进行的关联方式仅为示例，本实施例中不做限定。

通过上述方案，可以实现对故障场景维护的自动化，无需用户进行人工维护，从而降低了维护故障场景的成本，节省了人力。

在示例性的实施例中，如图3b所示，用户可以通过客户端110从故障场景集合中选择出所需要的场景，该场景中包括第一类对象与目标故障类型(S312)。从而，故障注入平台100响应于用户的上述选择操作(记作：第二操作)，并获取上述第一类对象与目标故障类型，以及从预配置的故障注入指令集合中获取与该故障场景对应的故障注入指令(S323)。

参考图4a～图4b所示的一例确定故障场景的示意图。

示例性的，客户端110可以展示如图4a所示的列表，让用户从对象列表和故障注入类型列表中选择出第一类故障对象和目标故障类型。例如，用户在对象列表中选择的第一类对象为云服务器，在故障注入类型列表中选择的目标故障类型为CPU故障。则故障注入平台100响应于用户的选择操作，并获取到用户所选择的故障场景为：云服务器-CPU故障。接着，故障注入平台100便可以从预配置的故障注入指令集合中获取与“云服务器-CPU故障”场景关联的故障注入指令。

可选地，用户所选择的故障场景还可以为多个，也就是说，故障注入平台100可以在一次故障注入测试中对不同的场景进行故障注入。在用户选择了多个故障场景的情况下，故障注入平台100从预配置的故障注入指令集合中获取与多个故障场景分别对应的故障注入指令后，可以进一步地对不同的故障注入指令之间的执行顺序进行确定。

例如，假设用户在一次故障注入测试中选择的场景为“云服务器-CPU故障”、“云服务器-内存故障”、“容器-CPU故障”共3个场景，故障注入平台100根据上述3个场景从预配置的故障注入指令集合中获取到的故障注入指令分别为：故障注入指令A、故障注入指令B和故障注入指令C。那么，故障注入平台100可以确定这3个故障注入指令的执行顺序为：先执行故障注入指令C，再执行故障注入指令A，最后故障注入指令B。

需要说明的是，上述执行顺序仅为示例，本实施例中对确定多个场景执行故障注入的顺序的方式不做限定。

继续参考图3b。用户在选择第一类故障对象和目标故障类型之后，再通过客户端110提供第一类故障对象中的目标故障对象的信息(S314，记作：第一操作)，从而使得故障注入平台100响应于该第一操作，并确定目标故障场景。可以理解的是，目标故障场景是由目标故障对象和上述目标故障类型所组成的。也就是说，用户在选择故障注入的对象类别之后，还需要进一步在该类别下确定具体的故障对象。

其中，目标故障对象的信息用于对故障对象进行标识，并与其他给对象进行区分，例如，目标故障对象的信息可以是该对象的名称、数字标号等等，本实施例中不做限定。

示例性的，假设用户从故障场景集合中所选择的故障场景为云服务器-CPU故障，那么接下来用户需要确定具体是要对哪一台云服务器进行故障注入，则用户可以通过提供某一台云服务器的信息来使得故障注入平台100确定出需要进行故障测试的具体对象。例如，若云服务器A为目标故障对象，则用户提供云服务器A的信息即可。

如图4b所示，可选地，用户还可以通过客户端110直接输入所需要进行故障注入测试的目标故障场景。在此种情况下，故障注入平台100在获取到目标故障场景后，可以对目标故障场景中的目标故障对象和目标故障类型进行提取，从而根据目标故障对象确定其所属的对象类型，并根据目该对象类型和目标故障类型，从预配置的故障注入指令集合中获取对应的故障注入指令。同样地，用户可以在一次故障注入测试中输入多种目标故障场景。

例如，假设用户确定的目标故障场景1为：云服务器8d396-CPU故障，目标故障场景2为：云服务器8d398-网络故障。则故障注入平台100获取到目标故障场景1和目标故障场景2后，提取出“云服务器8d396”这一信息，并根据该信息确定所需要进行故障注入的对象为云服务器，从而根据“云服务器-CPU故障”这一场景获取与其相关联的故障注入指令；以及，提取出“云服务器8d398”这一信息，并根据该信息确定所需要进行故障注入的对象为云服务器，从而根据“云服务器-网络故障”这一场景获取与其相关联的故障注入指令。

继续参考图3b。在确定目标故障场景及其对应的预配置的故障注入指令之后，还需要获取目标故障对象的参数信息，并将参数信息传入至上述预配置的故障注入指令中，从而得到目标故障注入指令。

其中，目标故障对象的参数信息可以包括目标故障对象的网际协议地址(Internet Protocol Address，IP Address)、命名空间(Namespace)等等，故障注入平台100中部署的故障注入工具需要根据目标故障对象的参数信息来查找到目标故障对象。

在获取目标故障对象的参数信息时，故障注入平台100可以通过应用程序接口(Application Programming Interface，API)或是相关指令(例如：Kubernetes的API接口、Kubernetes中的相关指令等)来根据目标故障对象的信息找到目标故障对象，并从目标故障对象中获取其参数信息。

可选地，在获取到参数信息后，可以将目标故障对象的信息及其参数信息进行关联，并存储至数据库中，由此逐渐建立存储有目标故障对象的信息及其参数信息的数据库。如此一来，在每一次获取目标故障对象的参数信息的过程中，可以首先在该数据库中根据目标故障对象的信息来查找该目标故障对象的参数信息(S324)。

在查找到的情况下，故障注入平台100则可直接根据目标故障对象的参数信息和对应的故障注入指令确定目标故障注入指令(S325)。具体地，故障注入平台100将目标故障对象的参数信息传入至上述从预配置的故障注入指令集合中获取的故障注入指令中，得到目标故障注入指令。

在未查找到的情况下，故障注入平台100再通过上述API或相关指令来获取目标故障对象的参数信息(S326)，并在获取到参数信息后，将目标故障对象的信息及其参数信息进行关联，并存储至数据库中。

可选地，用户还可以通过客户端110选择执行故障注入测试时的测试环境(例如，可以包括对目标故障场景进行故障注入时所需要的操作系统、网络环境等等)。在进行故障注入测试时，如果不搭建专用的测试环境，则可能会导致故障注入平台100的其他业务无法正常运行，所以可以指定专用的测试环境来进行故障注入。

通过上述方案，可以首先在数据库中查找目标故障对象的信息，从而在数据库中存储有该参数信息的情况下无需调用API来获取参数信息，能够节省调用API所需的资源和时间。

在示例性的实施例中，如图3c所示，接下来，用户可以通过客户端110执行对上述目标故障场景的故障注入测试(S316)，也就是用户通过点击客户端110中的“执行故障注入”按钮等操作，以向故障注入平台100发送故障测试指令，从而触发故障注入平台100对目标故障场景的故障注入测试。

可以理解的是，对于不同的目标故障场景，有的故障注入工具可以支持，而有的工具则无法支持。例如，常用的一些故障注入工具包括ChaosBlade、Chaos Mesh等等，ChaosBlade可以支持大多数的故障注入场景，但在对Java虚拟机(Java Virtual Machine，JVM)进行CPU故障注入时，ChaosBlade就不能很好的支持，这时需要用到Chaos Mesh来进行故障注入才能达到所需要的效果。因此，故障注入平台100需要对不同的目标故障场景选择合适的故障注入工具(记作：目标故障注入工具)来进行故障注入测试。

从而，故障注入平台100响应于客户端110发送的故障测试指令后，根据目标故障场景确定目标故障注入工具(S327)。

可以理解的是，由于大部分故障注入工具的开源代码地址都在外网，因此若故障注入平台100通过上述开源代码地址或镜像地址安装故障注入工具，便可能因网络原因而导致安装速度很慢或者安装失败。从而，若在故障注入平台100中配置故障注入工具的镜像仓库地址后，便可以提升故障注入工具的安装效率。

具体地，用户可以预先通过客户端110配置多个故障注入工具的镜像仓库地址，并由故障注入平台100获取这些镜像仓库地址，或是由故障注入平台100自动从互联网中获取多个故障注入工具的镜像仓库地址，等等。从而，故障注入平台100可以根据镜像仓库地址对多个故障注入工具进行安装及部署，并在响应于上述故障注入指令后，便可根据目标故障场景在已部署的多个故障注入工具中选择出上述目标故障注入工具。

之后，故障注入平台100通过目标故障注入工具执行上述目标故障注入指令，以对目标故障场景进行故障注入测试。在目标故障注入工具执行目标故障注入指令的过程中，故障注入平台100可以实时地获取所产生的故障注入数据(S328)，并将该故障注入数据存储至非关系型数据库中。其中，故障注入数据可以包括目标故障场景、测试时长、目标故障对象的运行数据等等。其中，非关系型数据库相较于关系型数据库来说具有更好的写入性能，从而便于对故障注入数据进行实时记录。

在目标故障注入工具完成对目标故障注入指令的执行的情况下，故障注入平台100可从上述非关系型数据库中获取由多个故障注入数据组成的故障注入结果，并根据故障注入结果和预配置的故障注入报告模板生成故障注入报告(S329)，在故障注入报告中可以对故障注入结果以可视化的图表等方式呈现，并将该故障注入报告发送至客户端110，以使客户端110对故障注入报告进行展示(S318)，从而方便用户的查看与分析。

参考图5所示的一例故障注入报告的示意图。

示例性的，如图5所示，假设目标故障场景为对云服务器A进行CPU满载测试，所输出的故障注入报告中可以展示所测试的目标故障场景、测试时长、测试的开始时间、评估结果、CPU利用率变化情况的折线图、云服务器A中的进程总数、进程运行的成功数、失败数以及成功率等等。

例如，所测试的目标故障场景为“云服务器A-CPU满载测试”，测试时长为50s，测试的开始时间为2023年6月30日的18:36:31。

在CPU利用率的折线图中，记录了从18:36:31至18:37:21的时间内CPU利用率的变化情况，可以看出，CPU在18:36:31时利用率接近于0，之后CPU的利用率持续上升，在18:36:41至18:37:01的时间内CPU利用率达到100％，之后CPU的利用率逐渐下降，在18:37:11时CPU利用率下降至40％，在18:37:21时CPU利用率接近于0。

在对CPU进行满载故障测试的过程中，云服务器A中总共运行的进程数量为215个，而其中有5个进程运行失败，其余的210个进程成功运行，从而计算得到进程运行的成功率大约为97.7％(210/215)。

故障注入平台100可以根据进程运行的成功率来对云服务器A的CPU性能进行评估，例如，得到对云服务器A的评估结果为：CPU性能良好。

需要说明的是，图5所示的故障注入报告中所包含的内容和展示方式仅为示例，本实施例中不做限定。

在上述方案中，可以通过故障注入平台100自动化地实时获取故障注入过程中所产生的故障注入数据，并自动根据故障注入数据(故障注入结果)生成可视化图表并通过客户端110进行展示，从而无需用户人工记录故障注入结果，节省了用户的时间，提升了整理、分析故障注入数据的效率。

本申请所提供的故障注入的方法中，用户可以在客户端110中确定目标故障场景，从而使得故障注入测试平台100接收客户端110发送的该目标故障场景。

接着，用户在客户端110中提供目标故障对象的信息，以使故障注入测试平台100根据该信息获取到目标故障对象的参数信息，并将该参数信息传入至与目标故障场景相关联的故障注入指令中，得到目标故障注入指令。故障注入测试平台100在接收到对目标故障场景进行故障注入测试的指令后，执行上述目标故障注入指令，从而得到目标故障对象的故障注入结果。

通过上述方案，本申请能够实现故障注入测试的自动化，无需用户自行维护故障注入的测试场景，也无需用户自行获取目标故障对象的参数信息以及手动记录故障注入结果，从而能够实现故障注入测试流程的自动化，并降低维护测试场景等信息所需的成本。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图6是本申请提供的一例故障注入的装置的结构图。

本申请实施例中的故障注入的装置600包括：接收模块610，以及确定模块620。

接收模块610，用于：接收目标故障场景的信息，其中，目标故障场景包括目标故障对象与目标故障类型，目标故障类型为目标故障对象的故障类型。

确定模块620，用于：确定目标故障场景对应的目标故障注入指令；以及，执行目标故障注入指令，得到目标故障场景的故障注入结果。

图7是本申请提供的另一例故障注入的装置的结构图。

一种可能的实现方式中，上述确定模块620还用于：根据目标故障场景，确定目标故障场景对应的故障注入工具；通过故障注入工具执行目标故障注入指令，得到目标故障场景的故障注入结果。

一种可能的实现方式中，上述确定模块620具体用于：根据目标故障场景在多个故障注入工具的镜像仓库地址中，确定目标镜像仓库地址，目标镜像仓库地址用于安装目标故障场景对应的故障注入工具。

一种可能的实现方式中，目标故障对象属于第一类故障对象，上述确定模块620还用于：通过第一算法对故障对象集合中的每类故障对象与故障类型集合中的每个故障类型进行组合，得到多个故障场景，第一算法包括笛卡尔积算法，故障对象集合包括第一类故障对象，故障类型集合包括目标故障类型，多个故障场景包括目标故障场景；配置多个故障场景中每个故障场景对应的故障注入指令，得到预配置的故障注入指令集合；上述确定模块620具体用于：根据目标故障场景的信息与预配置的故障注入指令集合，确定目标故障注入指令。

一种可能的实现方式中，上述确定模块620具体用于：根据目标故障对象的标识，查找目标故障对象的参数信息；若未查找到目标故障对象的参数信息，通过应用程序接口获取目标故障对象的参数信息；根据目标故障对象的参数信息、目标故障类型的信息与预配置的故障注入指令集合，确定目标故障注入指令。

可选地，上述装置还包括：存储模块630。

一种可能的实现方式中，上述存储模块630，用于：存储目标故障对象的参数信息。

可选地，上述装置还包括：显示模块640。

一种可能的实现方式中，上述显示模块640，用于：显示展示界面，展示界面中包括可视化图表，可视化图表用于展示故障注入结果。

需要说明的是，上述实施例提供的故障注入的装置在执行故障注入的方法时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的故障注入的装置与故障注入的方法实施例属于同一构思，因此对于本申请装置实施例中未披露的细节，请参照本申请上述的故障注入的方法的实施例，这里不再赘述。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

本申请实施例还提供了一种终端，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时实现上述任一实施例方法的步骤。

图8是本申请提供的一例终端的结构图。请参见图8所示，终端800可以包括于自动驾驶系统中，终端800包括有：处理器801和存储器802。

本申请实施例中，处理器801为计算机系统的控制中心，可以是实体机的处理器，也可以是虚拟机的处理器。处理器801可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器801可以采用数字信号处理(Digital Signal Processing，DSP)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)、可编程逻辑阵列(Programmable Logic Array，PLA)中的至少一种硬件形式来实现。处理器801也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称中央处理器(Central Processing Unit，CPU)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。

在本申请实施例中，上述处理器801具体用于：

接收目标故障场景的信息，其中，上述目标故障场景包括目标故障对象与目标故障类型，上述目标故障类型为上述目标故障对象的故障类型；确定上述目标故障场景对应的目标故障注入指令；执行上述目标故障注入指令，得到上述目标故障场景的故障注入结果。

进一步地，上述处理器801还用于：根据上述目标故障场景，确定上述目标故障场景对应的故障注入工具；上述处理器801具体用于：通过上述故障注入工具执行上述目标故障注入指令，得到上述目标故障场景的故障注入结果。

可选地，上述处理器801具体用于：根据上述目标故障场景在多个故障注入工具的镜像仓库地址中，确定目标镜像仓库地址，上述目标镜像仓库地址用于安装上述目标故障场景对应的故障注入工具。

可选地，上述处理器801还用于：通过第一算法对故障对象集合中的每类故障对象与故障类型集合中的每个故障类型进行组合，得到多个故障场景，上述第一算法包括笛卡尔积算法，上述故障对象集合包括上述第一类故障对象，上述故障类型集合包括上述目标故障类型，上述多个故障场景包括上述目标故障场景；配置上述多个故障场景中每个故障场景对应的故障注入指令，得到预配置的故障注入指令集合；上述处理器801具体用于：根据上述目标故障场景的信息与上述预配置的故障注入指令集合，确定上述目标故障注入指令。

可选地，上述处理器801具体用于：根据上述目标故障对象的标识，查找上述目标故障对象的参数信息；若未查找到上述目标故障对象的参数信息，通过应用程序接口获取上述目标故障对象的参数信息；根据上述目标故障对象的参数信息、上述目标故障类型的信息与上述预配置的故障注入指令集合，确定上述目标故障注入指令。

可选地，上述处理器801还用于：存储上述目标故障对象的参数信息。

可选地，上述处理器801还用于：显示展示界面，上述展示界面中包括可视化图表，上述可视化图表用于展示上述故障注入结果。

存储器802可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器802还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储终端、闪存存储终端。在本申请的一些实施例中，存储器802中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器801所执行以实现本申请实施例中的方法。

一些实施例中，终端800还包括有：外围设备接口803和至少一个外围设备。处理器801、存储器802和外围设备接口803之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口803相连。具体地，外围设备包括：显示屏804、摄像头805和音频电路806中的至少一种。

外围设备接口803可被用于将输入/输出(Input/Output，I/O)相关的至少一个外围设备连接到处理器801和存储器802。在本申请的一些实施例中，处理器801、存储器802和外围设备接口803被集成在同一芯片或电路板上；在本申请的一些其他实施例中，处理器801、存储器802和外围设备接口803中的任意一个或两个可以在单独的芯片或电路板上实现。本申请实施例对此不作具体限定。

显示屏804用于显示用户界面(User Interface，UI)。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏804是触摸显示屏时，显示屏804还具有采集在显示屏804的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器801进行处理。此时，显示屏804还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在本申请的一些实施例中，显示屏804可以为一个，设置终端800的前面板；在本申请的另一些实施例中，显示屏804可以为至少两个，分别设置在终端800的不同表面或呈折叠设计；在本申请的再一些实施例中，显示屏804可以是柔性显示屏，设置在终端800的弯曲表面上或折叠面上。甚至，显示屏804还可以设置成非矩形的不规则图形，也即异形屏。显示屏804可以采用液晶显示屏(Liquid Crystal Display，LCD)、有机发光二极管(OrganicLight-Emitting Diode，OLED)等材质制备。

摄像头805用于采集图像或视频。可选地，摄像头805包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及虚拟现实(Virtual Reality，VR)拍摄功能或者其它融合拍摄功能。在本申请的一些实施例中，摄像头805还可以包括闪光灯。闪光灯可以是单色温闪光灯，也可以是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，可以用于不同色温下的光线补偿。

音频电路806可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器801进行处理。出于立体声采集或降噪的目的，麦克风可以为多个，分别设置在终端800的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。

电源807用于为终端800中的各个组件进行供电。电源807可以是交流电、直流电、一次性电池或可充电电池。当电源807包括可充电电池时，该可充电电池可以是有线充电电池或无线充电电池。有线充电电池是通过有线线路充电的电池，无线充电电池是通过无线线圈充电的电池。该可充电电池还可以用于支持快充技术。

本申请实施例中示出的终端结构框图并不构成对终端800的限定，终端800可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述任一实施例方法的步骤。其中，计算机可读存储介质可以包括但不限于任何类型的盘，包括软盘、光盘、DVD(Digital Video Disc，数字通用光盘)、CD-ROM(Compact Disc Read-Only Memory，紧凑型光盘只读储存器)、微型驱动器以及磁光盘、ROM(Read-Only Memory，只读储存器)、RAM(Random Access Memory，随机存取存储器)、EPROM(Erasable Programmable Read-Only Memory，可擦除可编程只读存储器)、EEPROM(Electrically Erasable Programmable Read Only Memory，带电可擦可编程只读存储器)、DRAM(Dynamic Random Access Memory，动态随机存取存储器)、VRAM(Video RandomAccess Memory，影像随机接达记忆器)、闪速存储器设备、磁卡或光卡、纳米系统(包括分子存储器IC)，或适合于存储指令和/或数据的任何类型的媒介或设备。

在本申请中，术语“第一”、“第二”等仅用于描述的目的，而不能理解为指示或暗示相对重要性或顺序；术语“多个”则指两个或两个以上，除非另有明确的限定。术语“安装”、“相连”、“连接”、“固定”等术语均应做广义理解，例如，“连接”可以是固定连接，也可以是可拆卸连接，或一体地连接；“相连”可以是直接相连，也可以通过中间媒介间接相连。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本申请中的具体含义。

本申请的描述中，需要理解的是，术语“上”、“下”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本申请和简化描述，而不是指示或暗示所指的装置或单元必须具有特定的方向、以特定的方位构造和操作，因此，不能理解为对本申请的限制。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (10)

1.一种故障注入的方法，其特征在于，包括：

接收目标故障场景的信息，其中，所述目标故障场景包括目标故障对象与目标故障类型，所述目标故障类型为所述目标故障对象的故障类型；

确定所述目标故障场景对应的目标故障注入指令；

执行所述目标故障注入指令，得到所述目标故障场景的故障注入结果。

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

根据所述目标故障场景，确定所述目标故障场景对应的故障注入工具；

所述执行所述目标故障注入指令，得到所述目标故障场景的故障注入结果，包括：

通过所述故障注入工具执行所述目标故障注入指令，得到所述目标故障场景的故障注入结果。

3.如权利要求2所述的方法，其特征在于，所述根据所述目标故障场景，确定所述目标故障场景对应的故障注入工具，包括：

根据所述目标故障场景在多个故障注入工具的镜像仓库地址中，确定目标镜像仓库地址，所述目标镜像仓库地址用于安装所述目标故障场景对应的故障注入工具。

4.如权利要求1至3中任一项所述的方法，其特征在于，所述目标故障对象属于第一类故障对象，所述方法还包括：

通过第一算法对故障对象集合中的每类故障对象与故障类型集合中的每个故障类型进行组合，得到多个故障场景，所述第一算法包括笛卡尔积算法，所述故障对象集合包括所述第一类故障对象，所述故障类型集合包括所述目标故障类型，所述多个故障场景包括所述目标故障场景；

配置所述多个故障场景中每个故障场景对应的故障注入指令，得到预配置的故障注入指令集合；

所述确定所述目标故障场景对应的目标故障注入指令，包括：

根据所述目标故障场景的信息与所述预配置的故障注入指令集合，确定所述目标故障注入指令。

5.如权利要求4所述的方法，其特征在于，所述根据所述目标故障场景的信息与所述预配置的故障注入指令集合，确定所述目标故障注入指令，包括：

根据所述目标故障对象的标识，查找所述目标故障对象的参数信息；

若未查找到所述目标故障对象的参数信息，通过应用程序接口获取所述目标故障对象的参数信息；

根据所述目标故障对象的参数信息、所述目标故障类型的信息与所述预配置的故障注入指令集合，确定所述目标故障注入指令。

6.如权利要求5所述的方法，其特征在于，在通过应用程序接口获取所述目标故障对象的参数信息之后，所述方法还包括：

存储所述目标故障对象的参数信息。

7.如权利要求1至3中任一项所述的方法，其特征在于，所述方法还包括：

显示展示界面，所述展示界面中包括可视化图表，所述可视化图表用于展示所述故障注入结果。

8.一种故障注入的装置，其特征在于，包括：

接收模块，用于：接收目标故障场景的信息，其中，所述目标故障场景包括目标故障对象与目标故障类型，所述目标故障类型为所述目标故障对象的故障类型；

确定模块，用于：确定所述目标故障场景对应的目标故障注入指令；以及，执行所述目标故障注入指令，得到所述目标故障场景的故障注入结果。

9.一种终端，其特征在于，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时，使得所述终端执行如权利要求1至7中任一项所述的故障注入的方法。

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