一种故障测试方法和系统，及存储介质与流程

1.本发明涉及故障测试技术领域，尤其涉及一种故障测试方法和系统，及存储介质。


背景技术：

2.故障注入测试也称为混沌实验，是指按照选定的故障模型，用人工的方法有意识地产生故障并施加于特定的目标对象中，以加速该系统的错误和失效的发生，并通过分析系统的反应信息得到测试结果。按照所注入的故障类型，故障注入可以分为软件故障注入和硬件故障注入。
3.混合故障测试是指对目标对象所依赖的多个软件环境、多个硬件环境或软硬件相结合的环境进行的混合故障注入测试，用于评估目标对象在多个依赖条件发生故障的情况下的运作情况。例如，对于一些大型分布式系统或复杂的微服务架构的系统来说，故障注入测试往往需要对被测系统依赖的多个服务同时或间隔故障注入，模拟复杂生产环境中可能遇到的各种故障问题。
4.在现有技术中，通常选定一个混沌测试工具对一个目标对象进行故障测试，然而目标对象在实际应用时，往往运行于多个软件或硬件环境中，而这些运行环境可能同时或陆续发生故障，因此，如何同时对目标对象的多个运行环境进行故障注入测试是目前亟待解决的问题；其次，故障注入测试可能是在秒级别的时间内完成的，对被测目标系统或目标对象进行模拟故障注入，没有全自动化的流程或指标收集监控方法，人工方法很难在短时间内完成数据分析及故障效果呈现；并且现有的故障测试技术中往往缺少对被测目标的运行健康指标参数的监控，不能实时观察故障注入对被测目标对象带来的影响，还需要人工介入，自动化程度不高。


技术实现要素：

5.本技术提供了一种故障测试方法和系统，及存储介质，能够同时对目标对象的多个运行环境进行故障测试，优化了故障测试的功能性，提高了故障测试的有效性。
6.本技术的技术方案是这样实现的：
7.第一方面，本技术提供了一种故障测试方法，所述方法包括：
8.根据目标对象的测试场景确定至少一个测试工具；
9.确定所述至少一个测试工具对应的至少一个执行信息；其中，所述至少一个执行信息中的每一个执行信息包括执行顺序、执行环境以及执行时间；
10.根据所述至少一个测试工具和所述至少一个执行信息生成所述目标对象对应的测试任务；
11.根据所述测试任务进行故障测试处理，获得所述目标对象对应的测试结果。
12.第二方面，本技术提供了一种故障测试系统，所述故障测试系统包括：确定单元、生成单元以及获取单元，
13.所述确定单元，用于根据目标对象的测试场景确定至少一个测试工具；确定所述
至少一个测试工具对应的至少一个执行信息；其中，所述至少一个执行信息中的每一个执行信息包括执行顺序、执行环境以及执行时间；
14.所述生成单元，用于根据所述至少一个测试工具和所述至少一个执行信息生成所述目标对象对应的测试任务；
15.所述获取单元，用于根据所述测试任务进行故障测试处理，获得所述目标对象对应的测试结果。
16.第三方面，本技术提供了一种故障测试系统，所述故障测试系统还包括处理器、存储有所述处理器可执行指令的存储器，当所述指令被所述处理器执行时，实现如上所述的故障测试方法。
17.第四方面，本技术提供了一种计算机可读存储介质，其上存储有程序，应用于故障测试系统中，所述程序被处理器执行时，实现如上所述的故障测试方法。
18.本技术提供了一种故障测试方法和系统，及存储介质，故障测试系统根据目标对象的测试场景确定至少一个测试工具；确定至少一个测试工具对应的至少一个执行信息；其中，至少一个执行信息中的每一个执行信息包括执行顺序、执行环境以及执行时间；根据至少一个测试工具和至少一个执行信息生成目标对象对应的测试任务；根据测试任务进行故障测试处理，获得目标对象对应的测试结果。也就是说，在本技术的实施例中，在对目标对象进行故障测试时，不是选择单一的测试工具对目标对象进行故障测试，而是根据选择的测试场景确定至少一个测试工具，进而能够根据至少一个测试工具确定相应的执行信息并生成测试任务，以进行故障测试，能够同时对目标对象的多个运行环境进行故障测试，从而优化了故障测试的功能性，提高了故障测试的有效性。
附图说明
19.图1为本技术提出的故障测试方法的实现流程示意图一；
20.图2为本技术提出的执行顺序的示意图一；
21.图3为本技术提出的执行顺序的示意图二；
22.图4为本技术提出的执行顺序的示意图三；
23.图5为本技术提出的故障测试方法的实现流程示意图二；
24.图6为本技术提出的故障测试方法的实现流程示意图三；
25.图7为本技术提出的故障测试方法的实现流程示意图四；
26.图8为本技术提出的故障测试方法的实现流程示意图五；
27.图9为本技术提出的故障测试方法的实现流程示意图六；
28.图10为本技术提出的故障测试方法的实现流程示意图七；
29.图11为本技术提出的故障测试系统的组成结构示意图一；
30.图12为本技术提出的故障测试方法的实现框架图；
31.图13为本技术提出的故障测试系统的组成结构示意图二；
32.图14为本技术提出的故障测试系统的组成结构示意图三。
具体实施方式
33.下面将结合本技术中的附图，对本技术中的技术方案进行清楚、完整地描述。可以
理解的是，此处所描述的具体实施例仅用于解释相关申请，而非对该申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关申请相关的部分。
34.为了解决现有技术所存在的问题，本技术提供了一种故障测试方法，故障测试系统及存储介质，具体地，根据目标对象的测试场景确定至少一个测试工具；确定至少一个测试工具对应的至少一个执行信息；其中，至少一个执行信息中的每一个执行信息包括执行顺序、执行环境以及执行时间；根据至少一个测试工具和至少一个执行信息生成目标对象对应的测试任务；根据测试任务进行故障测试处理，获得目标对象对应的测试结果。实现了同时对目标对象的多个运行环境进行故障测试，优化了故障测试的功能性，提高了故障测试的有效性。
35.下面将结合本技术中的附图，对本技术中的技术方案进行清楚、完整地描述。
36.实施例一
37.本技术提供了一种故障测试方法，图1为故障测试系统的实现流程示意图一，如图1所示，故障测试方法可以包括以下步骤：
38.步骤101、根据目标对象的测试场景确定至少一个测试工具。
39.在本技术的实施例中，故障测试系统需要首先根据目标对象的测试场景确定至少一个测试工具，进而实现故障测试。
40.需要说明的是，在本技术的实施例中，目标对象是指需要进行故障测试的被测对象，其可以为一个工作系统或软件等。
41.进一步地，测试场景是指要对目标对象进行故障测试的目标场景，由于目标系统可能运行于多个不同的软件环境或硬件环境中，因此，需要对这些不同的软件或硬件环境进行故障测试，相应的，测试场景可以是这些软件环境或硬件环境中的多个环境。完成故障测试任务首先需要根据测试场景确定测试工具，因此需要针对目标对象不同的测试场景确定相应的测试工具，从而使得确定的测试工具的数量为至少一个，也就是说，可以根据多个测试场景确定多个测试工具。
42.需要说明的是，在本技术的实施例中，测试工具用于生成目标对象的故障信息，从而将生成的故障信息注入至目标对象中实现故障测试。测试工具的类型可以为chaosblade或自定义的混沌实验工具。
43.在本技术的实施例中，故障测试系统可以根据目标对象的测试场景确定至少一个测试工具，进而能够利用至少一个测试工具对目标对象进行故障测试，实现对目标对象的多个运行环境下的故障测试。
44.步骤102、确定至少一个测试工具对应的至少一个执行信息；其中，至少一个执行信息中的每一个执行信息包括执行顺序、执行环境以及执行时间。
45.在本技术的实施例中，故障测试系统在根据目标对象的测试场景确定至少一个测试工具之后，确定至少一个测试工具对应的至少一个执行信息；其中，至少一个执行信息中的每一个执行信息包括执行顺序、执行环境以及执行时间。
46.需要说明的是，在本技术的实施例中，执行信息用于确定测试工具的具体实施方式，执行信息可以包括执行顺序、执行环境以及执行时间；执行顺序是指测试工具的执行顺序，执行环境是指测试场景所在的服务器节点；执行时间是指开始执行故障测试的时间。
47.进一步地，在本技术的实施例中，利用测试工具对测试场景进行故障测试，每个测
试场景进行故障测试的顺序可能不同，相应地，测试工具的执行顺序也就不同，也就是说，测试场景进行故障测试的顺序对应于测试工具的执行顺序，测试工具的执行顺序即表示测试场景进行故障测试的顺序。
48.需要说明的是，在本技术的实施例中，执行顺序可以根据实际测试需求进行设置，例如：需要同时对各个测试场景进行故障测试，那么就可以将执行顺序设置为同时执行；需要依次对各个测试场景进行故障测试时，那么就可以将执行顺序设置为依次执行；需要同时对各个测试场景中的部分场景进行故障测试，而依次对其余场景进行故障测时，那么就可以将执行顺序设置为部分同时执行，其余依次执行。
49.示例性的，在本技术的实施例中，假设需要对目标对象的三个测试场景进行故障测试，三个测试场景为a、b以及c，图2为本技术提出的执行顺序的示意图一，如图2所示，测试场景a、b以及c的执行顺序可以为：测试场景a和测试场景b同时执行，测试场景c在测试场景a和测试场景b之后进行。
50.图3为本技术提出的执行顺序的示意图二，如图3所示，测试场景a、b以及c的执行顺序可以为：测试场景a、测试场景b以及测试场景c依次执行，且测试场景a最先执行，测试场景b在测试场景a之后执行，测试场景c在测试场景b之后执行。
51.图4为本技术提出的执行顺序的示意图三，如图4所示，测试场景a、b以及c的执行顺序可以为：测试场景a、测试场景b以及测试场景c同时执行。
52.步骤103、根据至少一个测试工具和至少一个执行信息生成目标对象对应的测试任务。
53.在本技术的实施例中，故障测试系统在确定至少一个测试工具对应的至少一个执行信息之后，根据至少一个测试工具和至少一个执行信息生成目标对象对应的测试任务。
54.需要说明的是，在本技术的实施例中，测试任务中可以包括多个子任务，每个子任务对应于一个测试工具和一个测试场景，故障测试系统在根据测试工具和执行信息生成测试任务以后，就可以根据测试任务进行故障测试处理。
55.需要说明的是，测试任务是根据执行信息生成的，而执行信息中包括执行顺序，因此，测试任务中的多个子任务在执行时的执行顺序可以有多种方式，例如可以是测试任务中的所有子任务同时执行；或者所有子任务依次执行；还可以是所有子任务中的部分子任务同时执行，其余的子任务依次执行等。
56.需要说明的是，在测试任务中，同时执行的子任务之间的执行时间是一样的，例如，若测试任务中的所有子任务同时执行，则所有子任务的执行时间为统一的时间；若测试任务中的部分子任务同时执行，其余的子任务依次执行时，则同时执行的部分子任务的执行时间是一样的，其余依次执行的子任务的执行时间依次晚于前一个执行的子任务的执行时间；若测试任务中的各个子任务依次执行，则各个子任务的执行时间均不同，在后执行的子任务的执行时间晚于前一个执行的子任务的执行时间。
57.步骤104、根据测试任务进行故障测试处理，获得目标对象对应的测试结果。
58.在本技术的实施例中，故障测试系统在根据至少一个测试工具和至少一个执行信息生成目标对象对应的测试任务之后，根据测试任务进行故障测试处理，获得目标对象对应的测试结果。
59.需要说明的是，故障测试处理是指对目标系统进行故障注入，进而观察目标系统
对故障的反应情况。
60.图5为本技术提出的故障测试方法的实现流程示意图二，如图5所示，在本技术的实施例中，故障测试系统根据测试任务进行故障测试处理，获得目标对象对应的测试结果的方法可以包括以下步骤：
61.步骤104a、对测试任务进行任务拆分处理，获得任务集。
62.在本技术的实施例中，故障测试系统根据测试任务进行故障测试处理，获得目标对象对应的测试结果，具体地，可以先对测试任务进行任务拆分处理，获得任务集。
63.需要说明的是，在本技术的实施例中，由于测试任务中可能包括多个子任务，多个子任务之间的执行时间可能不同，因此，在进行具体地故障测试时，需要首先对测试任务进行任务拆分处理。具体地，拆分处理是指将测试任务中同时执行的子任务拆分出来，并将这些同时执行的子任务划分为一个子任务集，例如测试任务中包括三个子任务，其中第一个子任务和第二个子任务的执行时间是一样的，第三个子任务在第一个子任务和第二个子任务之后执行，那么对测试任务进行拆分处理时，可以将第一个子任务和第二个子任务拆分出来，并将第一个子任务和第二个子任务划分为一个子任务集，第三个子任务单独划分为另一个子任务集，由此获得任务集，且这个任务集中包括两个子任务集。也就是说，通过对测试任务进行拆分处理获得的任务集中可以包括子任务集，而子任务集中可以包括子任务。
64.步骤104b、根据任务集生成任务执行表。
65.在本技术的实施例中，故障测试系统在对测试任务进行任务拆分处理，获得任务集之后，根据任务集生成任务执行表。
66.需要说明的是，在本技术的实施例中，获取了任务集之后，需要根据任务集生成任务执行表，进而根据任务执行表进行故障测试处理。
67.需要说明的是，在本技术的实施例中，任务执行表是根据任务集生成的，因此任务执行表的数量也相应的包括至少一个。
68.进一步地，故障测试系统根据任务集生成任务执行表后，还可以对任务执行表进行存储。
69.步骤104c、根据测试工具和任务执行表生成至少一个故障测试信息。
70.在本技术的实施例中，故障测试系统根据任务集生成任务执行表之后，根据测试工具和任务执行表生成至少一个故障测试信息。
71.需要说明的是，故障测试信息用于注入目标系统，进而实现对目标系统的故障测试处理。
72.需要说明的是，故障测试信息是根据测试工具和任务执行表生成的，由于测试工具和任务执行表的数量均为至少一个，因此，故障测试信息的数量也为至少一个。
73.步骤104d、利用故障测试信息对目标对象进行故障注入处理，获得目标对象对应的测试结果。
74.在本技术的实施例中，故障测试系统在根据测试工具和任务执行表生成至少一个故障测试信息之后，利用故障测试信息对目标对象进行故障注入处理，获得目标对象对应的测试结果。
75.需要说明的是，在本技术的实施例中，通过对目标对象进行故障注入处理，获得目
标对象对应的测试结果，来观察目标对象对故障测试信息的反应情况，从而达到对目标对象进行故障测试的目的。
76.图6为本技术提出的故障测试方法的实现流程示意图三，如图6所示，在本技术的实施例中，在故障测试系统根据测试工具和任务执行表生成至少一个故障测试信息之后，即步骤104c之后，故障测试方法还可以包括以下步骤：
77.步骤104e、在利用故障测试信息对目标对象进行故障注入处理时，生成故障注入码。
78.在本技术的实施例中，故障测试系统在利用故障测试信息对目标对象进行故障注入处理时，生成故障注入码。
79.需要说明的是，在本技术的实施例中，故障测试系统在对目标对象进行故障注入处理的同时，生成故障注入码，故障注入码由服务器标识信息、测试工具标识信息以及任务集标识信息组成。其中，服务器标识信息是指在进行故障注入处理时，所在的服务器节点的标识信息；测试工具标识信息是利用故障测试信息进行故障注入处理对应使用的测试工具的标识信息；任务集标识信息是指任务集中每个子任务对应的标识信息。
80.步骤104f、存储故障注入码。
81.在本技术的实施例中，故障测试系统在利用故障测试信息对目标对象进行故障注入处理时，生成故障注入码之后，存储故障注入码。
82.在本技术的实施例中，在生成故障注入码之后，还可以将故障注入码进行存储，进而可以在结束故障测试之后，利用存储的故障注入码进行测试销毁处理。
83.图7为本技术提出的故障测试方法的实现流程示意图四，如图7所示，故障测试系统在对测试任务进行任务拆分处理，获得任务集之后，即步骤104a之后，故障测试方法还可以包括以下步骤：
84.步骤104g、获取监控指令。
85.在本技术的实施例中，故障测试系统在对测试任务进行任务拆分处理，获得任务集之后，还可以获取监控指令。
86.需要说明的是，在本技术的实施例中，监控指令用于指示故障测试系统开启对故障测试处理过程的监控功能，从而可以监控对目标对象进行了故障注入处理以后的状态，达到实时了解目标对象的状态信息的目的，提升了故障测试的功能性和自动化程度。
87.步骤104h、响应监控指令，对目标对象进行监控处理，获得目标对象对应的第一指标信息。
88.在本技术的实施例中，故障测试系统在获取监控指令之后，响应监控指令，对目标对象进行监控处理，获得目标对象对应的第一指标信息。
89.需要说明的是，在本技术的实施例中，第一指标信息是指在进行了故障注入处理以后，对目标对象的状态进行监控获得的指标信息，第一指标信息表征目标系统在故障测试信息注入以后的健康状态。
90.在本技术的实施例中，监控处理的具体实施方式是按照一定的时间间隔收集目标系统的第一指标信息，例如每隔3秒收集目标系统的第一指标信息；与此同时，在收集到目标系统的第一指标信息以后，还可以利用第一指标信息绘制指标图谱，指标图谱可以更直观的反映目标系统的健康状态的变化情况。
91.图8为本技术提出的故障测试方法的实现流程示意图五，如图8所示，故障测试系统在根据测试任务进行故障测试处理，获得目标对象对应的测试结果之后，即步骤104之后，故障测试方法还可以包括以下步骤：
92.步骤105、根据执行顺序和故障注入码对任务集进行销毁处理。
93.在本技术的实施例中，故障测试系统在根据测试任务进行故障测试处理，获得目标对象对应的测试结果之后，还可以根据执行顺序和故障注入码对任务集进行销毁处理。
94.需要说明的是，在本技术的实施例中，在结束了故障测试处理以后，还需要令目标系统恢复到正常工作状态，因此，故障测试系统在根据测试任务进行故障测试处理之后，可以通过对任务集进行销毁处理来达到停止故障测试的目的。
95.具体地，在本技术的实施例中，根据故障注入码定位至进行销毁处理的地址，然后依据进行故障测试处理时的执行顺序，采用逆序的方式对各个任务集进行销毁处理，例如，执行顺序为子任务a第一个执行，然后执行子任务b，最后执行子任务c，那么销毁处理的方式为最先对子任务c进行销毁处理，然后对子任务b进行销毁处理，最后销毁子任务a。
96.图9为本技术提出的故障测试方法的实现流程示意图六，如图9所示，故障测试系统根据执行顺序和故障注入码对任务集进行销毁处理之后，即步骤105之后，故障测试方法还可以包括以下步骤：
97.步骤106、生成停止指令。
98.在本技术的实施例中，故障测试系统根据执行顺序和故障注入码对任务集进行销毁处理之后，还可以生成停止指令。
99.需要说明的是，在本技术的实施例中，在完成了对任务集的销毁之后，还需要令故障测试系统停止执行故障测试处理，停止指令的作用即为停止对目标系统的故障测试处理。
100.步骤107、响应停止指令，停止对目标对象的故障测试处理。
101.在本技术的实施例中，故障测试系统生成停止指令之后，响应停止指令，停止对目标对象的故障测试处理。
102.具体地，在本技术的实施例中，响应停止指令，故障测试系统停止进行故障测试处理。
103.图10为本技术提出的故障测试方法的实现流程示意图七，如图10所示，在本技术的实施例中，故障测试系统响应停止指令，停止对目标对象的故障测试处理之后，即步骤107之后，故障测试方法还可以包括以下步骤：
104.步骤108、继续对目标对象进行监控处理，获得目标对象对应的第二指标信息。
105.在本技术的实施例中，故障测试系统响应停止指令，停止对目标对象的故障测试处理之后，可以继续对目标对象进行监控处理，获得目标对象对应的第二指标信息。
106.需要说明的是，在本技术的实施例中，故障测试系统在停止对目标对象的故障测试处理之后，还需要停止对目标对象的监控功能，但是监控功能的停止是需要条件的，需要结合第二指标信息确定是否要停止对目标系统的监控。
107.进一步地，在本技术的实施例中，第二指标信息表征目标对象在停止了故障测试处理之后的指标信息。
108.步骤109、若第二指标信息为正常，则停止对目标对象进行监控处理。
109.在本技术的实施例中，故障测试系统在继续对目标对象进行监控处理，获得目标对象对应的第二指标信息之后，若第二指标信息为正常，则停止对目标对象进行监控处理。
110.需要说明的是，在本技术的实施例中，若第二指标信息为正常，则说明此时目标对象已经恢复到正常工作状态，不需要继续对目标对象的状态进行监控了，因此，停止对目标对象的监控处理。
111.具体地，停止对目标对象的监控处理，即停止对目标对象的第二指标信息的收集。
112.步骤110、若第二指标信息为异常，则继续对目标对象进行监控处理。
113.在本技术的实施例中，故障测试系统在继续对目标对象进行监控处理，获得目标对象对应的第二指标信息之后，若第二指标信息为异常，则继续对目标对象进行监控处理。
114.需要说明的是，在本技术的实施例中，若第二指标信息为异常，则说明此时目标对象还未恢复到正常工作状态，还需要继续监控目标对象，因此，继续对目标对象进行监控处理，直到第二指标信息为正常时，停止对目标对象进行监控处理。
115.本技术提供了一种故障测试方法和系统，及存储介质，故障测试系统根据目标对象的测试场景确定至少一个测试工具；确定至少一个测试工具对应的至少一个执行信息；其中，至少一个执行信息中的每一个执行信息包括执行顺序、执行环境以及执行时间；根据至少一个测试工具和至少一个执行信息生成目标对象对应的测试任务；根据测试任务进行故障测试处理，获得目标对象对应的测试结果。也就是说，在本技术的实施例中，在对目标对象进行故障测试时，不是选择单一的测试工具对目标对象进行故障测试，而是根据选择的测试场景确定至少一个测试工具，进而能够根据至少一个测试工具确定相应的执行信息并生成测试任务，以进行故障测试，能够同时对目标对象的多个运行环境进行故障测试，从而优化了故障测试的功能性，提高了故障测试的有效性。
116.实施例二
117.图11为本技术提出的故障测试系统的组成结构示意图一，如图11所示，在本技术的实施例中，故障测试系统10可以包括配置中心11、任务中心12、执行中心13以及监控中心14；其中，执行中心13包括执行单元131，执行单元131的数量包括至少一个，且每一个执行单元131中均包括一个调度中心1311。
118.在本技术的实施例中，配置中心主要用于在进行故障测试处理之前，进行相关的配置工作以生成测试任务，配置工作包括根据目标场景确定测试工具，并确定执行信息，在根据测试工具和执行信息生成测试任务以后，配置中心将测试任务传输至任务中心。
119.进一步地，任务中心在接受到测试任务以后，将测试任务进行拆分处理，获得任务集，然后根据任务集生成任务执行表。
120.需要说明的是，任务中心可以依据测试任务在执行中心部署预置了测试工具的执行单元，并且执行单元位于执行测试任务所在的服务器节点，由于测试工具的数量为至少一个，相应的，执行单元的数量也为至少一个；然后自动启动执行单元，当执行单元启动成功之后，以restful接口形式向任务中心发送安装成功通知信息，任务中心在接收到安装成功通知信息以后，将任务执行表传输至执行单元，等待执行中心进行具体的故障注入处理。
121.需要说明的是，执行单元还设置有预设启动次数，如果存在执行单元启动失败的情况，则尝试重新启动执行单元，若重新启动的次数达到预设启动次数，但执行单元仍然启动失败时，则调度中心暂停本次故障测试实验。
122.需要说明的是，任务中心在接收到安装成功通知信息以后，还可以生成监控指令，并将监控指令发送至监控中心以建立监控功能。
123.进一步地，当满足执行时间时，每个执行单元中的调度中心进行启动，开始执行故障注入处理，同时执行单元还可以生成故障注入码，将故障注入码发送至任务中心，同时存储故障注入码。
124.需要说明的是，当调度中心开始执行故障注入处理时，监控中心开始监控处理，按照一定的时间间隔收集目标对象的指标信息，并根据指标信息绘制指标图谱，从而实时反映目标对象的运行状态。
125.进一步地，在完成了对目标对象的故障测试处理以后，任务中心根据故障注入码、并按照执行顺序的逆序形式向各个执行单元发送销毁指令，以销毁任务集。
126.进一步地，在完成了销毁处理之后，执行中心向任务中心发送销毁确认信息，然后任务中心生成停止指令，并将停止指令发送至各个执行单元以停止进行故障注入处理。
127.进一步地，通过监控中心观察目标对象的指标信息此时是否恢复正常，如果指标信息为正常，则由任务中心向监控中心发送停止监控指令，以停止监控；如果指标信息还未恢复正常，则继续进行监控，直到指标信息为正常时才停止对目标对象的监控。
128.示例性的，图12为本技术提出的故障测试方法的实现框架图，如图12所示，故障测试方法的整体流程可以为：
129.在配置中心，针对服务器上运行的目标对象所依赖的软硬件环境及测试用例要求，选择一个或多个chaosblade或自定义的混沌作业实验工具，如果选择了多个混沌作业实验工具，可以通过页面图层，以拖拉拽的方式，设置执行顺序，执行顺序可以根据实际测试用例需要进行，另外，还需要配置各混沌实验工具执行的目标服务器节点信息、执行时间等。
130.在完成了相关的配置工作，生成测试任务之后，配置中心将测试任务提交至任务中心，由任务中心进行任务拆分；其中，对于需要同时执行的子任务，会构建一个子任务集，处于同一个子任务集的子任务，会配置共用的启动执行时间，由调度中心统一触发执行，对于不同执行次序的子任务，分别生成各自独立的子任务集及其执行时间。
131.任务中心进行了任务拆分之后，会预先向目标对象的测试场景所在的服务器节点发送预置了混沌实验工具的作业执行agent，并自动化启动执行作业agent，为测试执行做好准备。当执行agent启动成功后，执行agent以restful接口形式向任务中心发送安装成功通知信息。任务中心收到执行agent成功安装消息通知后，向每个执行agent发送相对应的任务执行信息表，存储在内存中，并触发各个执行agent内置的调度中心，等待测试执行。如果存在执行agent启动失败情况，会尝试重新启动该执行agent，若失败次数达到预设启动次数后依旧未启动成功，通知调度中心，暂停本次混沌作业实验，不下发具体的测试任务。
132.任务中心收到各个执行agent的启动成功确认信息后，向监控中心注册目标对象的健康指标收集指令，监控agent收到指令后，启动收集健康指标数据。
133.当所有执行agent启动成功，并且已达到执行时间，由调度中心按照预设置的执行顺序，启动所属的执行agent开始测试作业，各执行agent启动测试作业成功后，记录故障注入码，存于内存中，并发送至任务中心。
134.监控中心每隔一定时间接到监控agent发送的健康指标数据，并绘制指标图谱，实
时观察按序执行各个故障注入程序前后目标对象的运行状态。
135.实验结束后，在任务中心生成实验销毁指令，任务中心会根据执行顺序和故障注入码，以执行顺序的逆序形式向各个执行agent发出实验销毁指令，以销毁测试任务，从而恢复目标对象的环境，待各个执行agent完成实验销毁后，向任务中心发出实验销毁结束确认信息，由任务中心统一发出各个执行agent停止运行指令。
136.在实验销毁的过程中，可以通过监控中心观察实验销毁后，目标对象的健康指标数据是否恢复到正常水平，待目标对象的健康指标数据恢复正常后，可通过任务中心向监控中心发出停止指标收集指令。
137.本技术提供了一种故障测试方法和系统，及存储介质，故障测试系统根据目标对象的测试场景确定至少一个测试工具；确定至少一个测试工具对应的至少一个执行信息；其中，至少一个执行信息中的每一个执行信息包括执行顺序、执行环境以及执行时间；根据至少一个测试工具和至少一个执行信息生成目标对象对应的测试任务；根据测试任务进行故障测试处理，获得目标对象对应的测试结果。也就是说，在本技术的实施例中，在对目标对象进行故障测试时，不是选择单一的测试工具对目标对象进行故障测试，而是根据选择的测试场景确定至少一个测试工具，进而能够根据至少一个测试工具确定相应的执行信息并生成测试任务，以进行故障测试，能够同时对目标对象的多个运行环境进行故障测试，从而优化了故障测试的功能性，提高了故障测试的有效性。
138.实施例三
139.基于上述实施例，在本技术的另一实施例中，图13为本技术提出的故障测试系统的组成结构示意图二，如图13所示，本技术提出的故障测试系统10可以包括确定单元15、生成单元16、获取单元17，存储单元18以及处理单元19，
140.所述确定单元15，用于根据目标对象的测试场景确定至少一个测试工具；确定所述至少一个测试工具对应的至少一个执行信息；其中，所述至少一个执行信息中的每一个执行信息包括执行顺序、执行环境以及执行时间。
141.所述生成单元16，用于根据所述至少一个测试工具和所述至少一个执行信息生成所述目标对象对应的测试任务。
142.所述获取单元17，用于根据所述测试任务进行故障测试处理，获得所述目标对象对应的测试结果。
143.进一步地，所述获取单元17，具体用于对所述测试任务进行任务拆分处理，获得任务集。
144.进一步地，所述生成单元16，还用于根据所述任务集生成任务执行表；根据所述测试工具和所述任务执行表生成至少一个故障测试信息。
145.进一步地，所述获取单元17，还具体用于利用所述故障测试信息对目标对象进行故障注入处理，获得所述目标对象对应的测试结果。
146.进一步地，所述生成单元16，还用于在利用所述故障测试信息对目标对象进行故障注入处理时，生成故障注入码。
147.所述存储单元18，用于存储所述故障注入码。
148.进一步地，所述获取单元17，还用于获取监控指令；响应所述监控指令，对所述目标对象进行监控处理，获得所述目标对象对应的第一指标信息。
149.所述处理单元19，用于根据所述执行顺序和所述故障注入码对所述任务集进行销毁处理。
150.进一步地，所述生成单元16，还用于生成停止指令。
151.进一步地，所述处理单元19，还用于响应所述停止指令，停止对所述目标对象的所述故障测试处理。
152.进一步地，所述获取单元17，还用于继续对所述目标对象进行监控处理，获得所述目标对象对应的第二指标信息。
153.进一步地，所述处理单元19，还用于若所述第二指标信息为正常，则停止对所述目标对象进行监控处理；若所述第二指标信息为异常，则继续对所述目标对象进行监控处理。
154.图14为本技术提出的故障测试系统的组成结构示意图三，如图14所示，本技术提出的故障测试系统10还可以包括处理器110、存储有处理器110可执行指令的存储器111，进一步地，故障测试系统10还可以包括通信接口112，和用于连接处理器110、存储器111以及通信接口112的总线113。
155.在本技术的实施例中，上述处理器110可以为特定用途集成电路(application specific integrated circuit，asic)、数字信号处理器(digital signal processor，dsp)、数字信号处理装置(digital signal processing device，dspd)、可编程逻辑装置(programmable logic device，pld)、现场可编程门阵列(field programmable gate array，fpga)、中央处理器(central processing unit，cpu)、控制器、微控制器、微处理器中的至少一种。可以理解地，对于不同的设备，用于实现上述处理器功能的电子器件还可以为其它，本技术不作具体限定。处理器110还可以包括存储器111，该存储器111可以与处理器110连接，其中，存储器111用于存储可执行程序代码，该程序代码包括计算机操作指令，存储器111可能包含高速ram存储器，也可能还包括非易失性存储器，例如，至少两个磁盘存储器。
156.在本技术的实施例中，总线113用于连接通信接口112、处理器110以及存储器111以及这些器件之间的相互通信。
157.在本技术的实施例中，存储器111，用于存储指令和数据。
158.进一步地，在本技术的实施例中，上述处理器110，用于根据目标对象的测试场景确定至少一个测试工具；确定所述至少一个测试工具对应的至少一个执行信息；其中，所述至少一个执行信息中的每一个执行信息包括执行顺序、执行环境以及执行时间；根据所述至少一个测试工具和所述至少一个执行信息生成所述目标对象对应的测试任务；根据所述测试任务进行故障测试处理，获得所述目标对象对应的测试结果。
159.在实际应用中，上述存储器111可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，ram)；或者非易失性存储器(non-volatile memory)，例如只读存储器(read-only memory，rom)，快闪存储器(flash memory)，硬盘(hard disk drive，hdd)或固态硬盘(solid-state drive，ssd)；或者上述种类的存储器的组合，并向处理器110提供指令和数据。
160.另外，在本实施例中的各功能模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。
161.集成的单元如果以软件功能模块的形式实现并非作为独立的产品进行销售或使用时，可以存储在一个计算机可读取存储介质中，基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或processor(处理器)执行本实施例方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
162.本技术提供了一种故障测试方法和系统，及存储介质，故障测试系统根据目标对象的测试场景确定至少一个测试工具；确定至少一个测试工具对应的至少一个执行信息；其中，至少一个执行信息中的每一个执行信息包括执行顺序、执行环境以及执行时间；根据至少一个测试工具和至少一个执行信息生成目标对象对应的测试任务；根据测试任务进行故障测试处理，获得目标对象对应的测试结果。也就是说，在本技术的实施例中，在对目标对象进行故障测试时，不是选择单一的测试工具对目标对象进行故障测试，而是根据选择的测试场景确定至少一个测试工具，进而能够根据至少一个测试工具确定相应的执行信息并生成测试任务，以进行故障测试，能够同时对目标对象的多个运行环境进行故障测试，从而优化了故障测试的功能性，提高了故障测试的有效性。
163.本技术提供一种计算机可读存储介质，其上存储有程序，该程序被处理器执行时实现如上所述的故障测试方法。
164.具体来讲，本实施例中的一种暴力破解的检测对应的程序指令可以被存储在光盘，硬盘，u盘等存储介质上，当存储介质中的与一种故障测试方法对应的程序指令被一电子设备读取或被执行时，包括如下步骤：
165.根据目标对象的测试场景确定至少一个测试工具；
166.确定所述至少一个测试工具对应的至少一个执行信息；其中，所述至少一个执行信息中的每一个执行信息包括执行顺序、执行环境以及执行时间；
167.根据所述至少一个测试工具和所述至少一个执行信息生成所述目标对象对应的测试任务；
168.根据所述测试任务进行故障测试处理，获得所述目标对象对应的测试结果。
169.本领域内的技术人员应明白，本技术的实施例可提供为方法、系统、或计算机程序产品。因此，本技术可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
170.本技术是参照根据本技术的方法、设备(系统)、和计算机程序产品的实现流程示意图和/或方框图来描述的。应理解可由计算机程序指令实现流程示意图和/或方框图中的每一流程和/或方框、以及实现流程示意图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在实现流程示意图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
171.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在实现流程示意图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
172.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在实现流程示意图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
173.以上所述，仅为本技术的较佳实施例而已，并非用于限定本技术的保护范围。