CN108984397B - 黑盒故障注入方法和系统及介质设备 - Google Patents

Abstract

本发明公开了一种黑盒故障注入方法和系统及介质设备。其注入方法包括下列步骤：追踪待测平台业务调用路径；根据业务调用路径及提取出的信息，生成或者完善相应业务体系结构图；根据业务体系结构图递归推理出能破坏所有已知路径的待测故障场景，并注入待测平台进行测试；在探索出待测系统完整体系结构的基础上，对路径进行优化排序，再针对每条路径生成对应的故障场景。其快速高效的检测待测平台SUT的潜在故障，并保证一定的覆盖率。

Description

黑盒故障注入方法和系统及介质设备

技术领域

本发明涉及计算机测试领域，是一种可应用于系统容错性评估的基于业务调用路径的黑盒故障注入方法和系统及介质设备。

技术背景

故障注入测试(Fault Insertion Test，FIT)是一种评估系统平台可靠性的有效且有用的技术。这种方法的原理就是将特定的故障注入到待测平台 (Software UnderTesting，SUT)中，并监视该待测平台SUT的响应情况，从而观察SUT在面对这样的故障时会发生的行为是否符合预期。

但是实际场景中，待测平台SUT本身可能就存在缺陷(bug)，如某两个组件一起工作时就会发生错误，导致SUT无法正常提供服务。这些隐藏的缺陷(bug)往往难以发现，只有在特定条件下才会被触发，即使发现了也难以重现。

现有的故障注入技术主要关注的依然是待测平台SUT在面对特定故障时的行为是否符合预期，如PREFAIL(是一个专家指导的故障注入方法，测试人员可以通过编写规则指导故障注入)和SAMC(是一个模型检查故障注入方法，通过分析待测系统的语义信息进行故障注入)等，或是评估待测平台 SUT的容错性如在某几个组件同时故障时待测平台SUT会崩溃，而很少关注如何利用故障注入发现这些待测平台SUT固有中的潜在缺陷(bug)。

现有的故障注入技术对这些故障的关注较少，即使可以检测此类故障，一般也要对待测平台SUT进行修改，适用场景不够广泛。

不能检验待测平台SUT在面对特定故障时的反应是否符合预期，而且在实际场景中，待测系统本身可能就存在故障，这些故障往往只有在特定条件下才会被触发，难以发现和重现。

例如，CrystalBall是一种可以预测和预防分布式系统中潜在不一致性的方法，它一边运行一边进行模型检查，用于预测那些只会发生在一个特定的低概率事件序列，如节点重置等之后的故障。

但是，CrystalBall需要修改待测平台SUT，使待测平台SUT的每个节点能预测它们的行动序列检测不一致性并能修改自己的行为避免不一致性。进一步地，这个方法在实际应用时存在很多问题，如事件过滤和安全性检测等，且对待测平台SUT的要求较为苛刻。

发明内容

为解决现有技术中存在的问题，因此本发明的故障注入方法和系统及介质设备，与现有技术不同，其不需要获取待测平台SUT的源码，也不需要对待测平台SUT进行修改，在不知道待测平台SUT的内部体系结构的完全黑盒的情况下，依然可以进行故障注入，寻找待测平台SUT潜在的故障，有效检测待测平台中的潜在故障，快速高效的检测待测平台SUT的潜在故障，并保证一定的覆盖率。

本发明采用如下技术方案：

一种处理待测平台潜在故障的黑盒注入方法，包括以下步骤：

追踪待测平台业务调用路径；

根据业务调用路径及提取出的信息，生成或者完善相应业务体系结构图；

根据业务体系结构图递归推理出能破坏所有已知路径的待测故障场景，并注入待测平台进行测试；

依次生成其对应的故障场景的路径。

作为一种改进，在依次生成路径后，还包括如下步骤：

根据路径对应的故障用例进行故障注入测试。

作为一种改进，在递归推理并注入待测平台进行测试之后，还包括如下步骤：

在探索整个待测系统业务路径体系结构的基础上，对路径进行优化排序，并针对排序后的每条路径设置相应的待注入的故障场景。

作为一种改进，所述优化排序，包括如下步骤：

设优化集S为空，待测平台的所有路径集合P；

随机从待测平台的路径集合P中选取一条路径，将这条路径从路径集P 中删除，并加入优化集S中，此时优化集S中只有一条路径；

对路径集合P中的所有路径，分别求解每条路径对应的未被优化集S中路径覆盖的故障组合数；

同样的，对路径集合P中的每条路径，都计算出其包含的未被优化集S 中路径覆盖的故障组合数，然后从中选出未被覆盖故障组合数最多的一条路径加入优化集S中，并从路径集合P中删除这条路径；

此时优化集S中有2条路径；

以此类推，每次都计算路径集合P中所有路径对应的未被优化集S中路径覆盖的故障组合数，并从中选出未被优化集S覆盖故障组合最多的那一条路径加入优化集S，并从路径集合P中删除对应路径，直到路径集合P为空为止；

此时，优化集S中的路径按照加入顺序排序完毕。

作为一种改进，所述排序后的每条路径设置相应的待注入的故障场景，包括如下步骤：

按照S中路径的顺序，依次根据实施例一中的生成方法针对目标路径生成故障组合用例，设第一条路径是A1-B2-D1-F2；

目标路径A1-B2-D1-F2上的故障场景集合为：

Fault＝{Crash(A1)，Omit(A1-B2)，Crash(B2)，…，Crash(F2)}

对于待测平台中的其他路径，同样的找出它们路径上的故障场景集合，设路径A1-B1-D1-F1，记为路径Path1上的故障场景集合为：

F_Path1＝{Crash(A1)，Omit(A1-B1)，Crash(B1)，…，Crash(F1)}

那么，如果想要破坏路径Path1但是同时又不破坏目标路径 A1-B2-D1-F2，对应的故障场景就是存在于F_Path1中但又不存在于Fault的那些故障场景，即：

F_Path1-(F_Path1∩Fault)

求解出来就是 {Omit(A1-B1)，Crash(B1)，Omit(B1-D1)，Omit(D1-F1)，Crash(F1)}；

再看另一条路径A2-B2-D2-F1，记为路径Path2，它路径上的故障场景集合为：

F_Path2＝{Crash(A2)，Omit(A2-B2)，Crash(B2)，…，Crash(F1)}

那么，如果想要破坏路径Path2但是同时又不破坏目标路径 A1-B2-D1-F2，对应的故障场景就是存在于F_Path2中但又不存在于Fault的那些故障场景，即：

F_Path2-(F_Path2∩Fault)

求解出来就是 {Crash(A2),Omit(A2-B2),Omit(B2-D2),Crash(D2),Omit(D2-F1),Crash(F1)}；

那么，如果要破坏路径Path1和Path2同时又不破坏目标路径 A1-B2-D1-F2，对应的故障场景就是把F_Path1-(F_Path1∩Fault)和 F_Path2-(F_Path2∩Fault)求合集，即两个集合中的故障场景的组合，得到结果如下： {Omit(A1-B1)&Crash(A2)，Omit(A1-B1)&Omit(A2-B2)，…，Omit(D1- F1)&Omit(D2-F1)，Crash(F1)} ；

这个集合中的任意一个故障场景在注入后，都可以破坏路径Path2但是同时又不破坏目标路径A1-B2-D1-F2；

类似的，对于待测平台中除了目标路径A1-B2-D1-F2之外的所有路径 Pathj，都求解出能破坏Pathj同时不破坏路径目标路径的故障场景集合，并对这些故障场景集合进行合取，即可得到能破坏除了目标路径之外的其它所有路径的故障场景集合，选取其中最小的一个故障场景作为目标路径对应的故障用例，其中，0<j<所有路径；

对于S中的每一条路径，按顺序依次求解出其对应的故障用例，最后得到待注入的优化排序后的故障用例集合。

为实现本发明目的，本发明还提供一种处理待测平台潜在故障的黑盒注入软件系统，其特征在于，包括所述处理待测平台潜在故障的黑盒注入方法的软件源代码。

为实现本发明目的，本发明更提供一种处理待测平台潜在故障的黑盒注入的介质，其存储所述的软件系统的源代码。

为实现本发明目的，本发明更进一步提供一种处理待测平台潜在故障的黑盒注入的设备，包括中央处理器(CPU)和所述介质；

在设备运行时，所述CPU从所述介质中读取软件系统的源代码，实现处理待测平台潜在故障的黑盒注入。

与现有技术相比，本发明具有如下优点：

本发明是一种快速探索并发现待测平台SUT潜在故障的故障注入方法和系统及介质设备，是对现有故障注入技术的一种补充，它检测待测平台SUT，特别是分布式待测平台SUT中隐藏的故障，即使在完全不知道待测平台SUT 内部业务体系结构的情况下，也能快速探索并检测待测平台SUT中潜在的故障，并确保每条路径都至少被覆盖了一次，在测试成本有限时，能快速高效的检测待测平台SUT的潜在故障，并保证一定的覆盖率。

附图说明

图1是本发明实施例一的流程图；

图2是本发明实施例二的节点结构示意图；

图2-1～9是本发明实施例二的节点图2遍历过程结构示意图；

图3是本发明软件系统示例图一；

图4是本发明软件系统示例图二。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图1-4 对本发明实施例的处理潜在故障方法和系统及介质设备的具体实施方式进行说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

首先本发明提供一种处理待测平台潜在故障的黑盒注入方法，获取到待测平台SUT正常运行时的业务调用路径，根据调用路径生成待测平台业务体系结构图；根据业务体系结构图生成故障场景注入待测平台，破坏所有的已知路径；如果待测平台依然能正确运行，就追踪新的业务调用路径，继续完善待测平台的业务体系结构图，以此类推，直到待测平台的完整业务体系结构都被探索出来；在探索出完整的业务体系结构之后，以“每条路径都至少运行一次”为目标，设置故障场景集合，用于检测每一条路径上的潜在故障。

作为一种可实施方式，为了提高效率，进一步地，对路径及其对应的故障场景进行组合排序。实验表明，组合排序后检测使得测试人员可以只测前 20％的故障用例就能覆盖80％的潜在故障。

实施例一：

本发明实施例一的一种处理待测平台潜在故障的黑盒注入方法，如图1 所示，包括以下步骤：

步骤S100，追踪待测平台业务调用路径。

作为一种可实施方式，步骤S100包括如下步骤：

追踪待测平台的业务调用路径，然后将待测平台追踪到的调用链传给进行处理，并提取其中的调用链信息。

步骤S200，根据业务调用路径及提取出的信息，生成或者完善相应业务体系结构图。

作为一种可实施方式，步骤S200包括如下步骤：

将业务调用路径中的业务映射成相应待测平台业务体系结构图中对应的点，调用关系映射成相应的体系结构图中的边，并以层次区分逻辑时间顺序。

步骤S300，根据业务体系结构图递归推理出能破坏所有已知路径的待测故障场景，并注入待测平台进行测试。

作为一种可实施方式，步骤S300包括如下步骤：

如果待测平台依然正常运行，说明还未探索出完整的体系结构，仍有其他业务路径可以替代，此时返回步骤S100继续追踪新的业务调用路径；

如果待测平台无法正常运行，通过进一步的验证，确保待测平台的完整业务结构已经被完全探索出来。

较优地，本发明实施例的黑盒注入方法，还包括如下步骤：

在完整的业务体系结构图的基础上，对待测平台的所有路径进行排序。

一个复杂的系统的路径空间是巨大的，对应生成的故障场景用例数也是巨大的。考虑到测试成本有限，在本实施例中，以快速覆盖更多的组合为目标，较优地，对路径进行排序(详见实施例三)，从而更快的检测到待测系统中潜在的故障。

步骤S400，依次生成其对应的故障场景的路径。

作为一种可实施方式，步骤S400包括如下步骤：

业务体系结构图中的每一条路径，都要至少运行一次，每条路径都对应本实施例生成的一条故障场景，用于破坏所有其他路径，让待测平台只能选择目标路径。

步骤S500，根据路径对应的故障用例进行故障注入测试。

作为一种可实施方式，步骤S500包括如下步骤：

如果待测平台的对应路径上没有潜在故障，对应的故障用例注入后，待测平台应当仍然正常运行；

如果某条故障场景用例注入后，待测平台无法得到正常结果，说明检测到对应路径上存在潜在故障。

实施例二：

设待测平台的完整内部业务体系结构如图2所示。记节点m崩溃故障为 Crash(n)，节点m与n之间的信息丢失故障为Omit(m-n)。

(1)如图2-1所示，追踪第一条调用链:

L1:A1-B1-D1-F1

探索出A1,B1,D1,F1四个节点，及对应的3条边；

返回的故障模式集为：

F1＝{Omit(A1-B1)&Omit(B1-D1)&Omit(D1-F1)}。

(2)如图2-2所示，将F1注入到待测平台中，测试结果为SUCCESS，追踪第二条调用链：

L2:A1-B2-D1-F2

探测出B2,F2两个节点，及3条边；

返回的故障模式集为：

F2＝F1&{Omit(A1-B2)&Omit(B2-D1)&Omit(D1-F2)}

(3)如图2-3所示，将F2注入到待测平台中，测试结果为SUCCESS，追踪到第三条调用链：

L3:A1-C1-E1-F1

探测出C1,E1两个节点，及3条边；

返回的故障模式集为：

F3＝F2&{Omit(A1-C1)&Omit(C1-E1)&Omit(E1-F1)}

(4)如图2-4所示，将F3注入到待测平台中，测试结果为SUCCESS，追踪到第四条调用链：

L4:A1-C2-E1-F2

探测出C2一个节点，以及三条边；

返回的故障模式集为：

F4＝F3&{Omit(A1-C2)&Omit(C2-E1)&Omit(E1-F2)}

(5)如图2-5所示，将F4注入到待测平台中，测试结果为SUCCESS，追踪到第五条调用链：

L5:A2-B1-D2-F1

探测出A2一个节点，及3条边；

返回的故障模式集为：

F5＝F4&{Omit(A2-B1)&Omit(B1-D2)&Omit(D2-F1)}

(6)如图2-6所示，将F5注入到待测平台中，测试结果为SUCCESS，追踪到第六条调用链：

L6:A2-B2-D2-F2

探测出3条边；

返回的故障模式集为：

F6＝F5&{Omit(A2-B2)&Omit(B2-D2)&Omit(D2-F2)}

(7)如图2-7所示，将F6注入到待测平台中，测试结果为SUCCESS，追踪到第七条调用链：

L7:A2-C1-E2-F1

探测出3条边；

返回的故障模式集为：

F7＝F6&{Omit(A2-C1)&Omit(C1-E2)&Omit(E2-F1)}

(8)如图2-8所示，将F7注入到待测平台中，测试结果为SUCCESS，追踪到第八条调用链：

L8:A2-C2-E2-F2

探测出3条边；

返回的故障模式集为：

F8＝F7&{Omit(A2-C2)&Omit(C2-E2)&Omit(E2-F2)}

(9)将F8注入到待测平台中，测试结果为FAIL，表明F8可以破坏当前系统，所以需要更新F8，弱化F8的故障集合，所以分别生成3个子故障：

F7&{Omit(A2-C2)}，F7&{Omit(C2-E2)}，F7&{Omit(E2-F2)}

首先令F8＝F7&{Omit(A2-C2)}，将F8注入到待测平台中，测试结果为 FAIL，需要继续更新F8。

再令F8＝F7&{Omit(C2-E2)}，将F8注入到待测平台中，测试结果为 SUCCESSS，故而不需要继续更新F8，追踪到第9条调用链为:

L9:A2-C2-E3-F1

探测出E3节点，及2条边；

返回的故障模式集为：

F9＝F8&{Omit(C2-E3)&Omit(E3-F1)}

作为一种可实施例，本发明实施例中，因为之前F8有过测试，所以没有加入Omit(A2-C2)。

(10)如图2-9所示，将F9注入到待测平台中，测试结果为FAIL，表明 F9可以破坏当前系统，所以需要更新F9，弱化F9的故障集合，所以分别生成2个子故障：

F8&{Omit(C2-E3)}，F8&{Omit(E3-F1)}，分别赋值给F9发现前者测试为FAIL，后者测试为SUCCESS，并追踪到第10条调用链。

L10:A2-C2-E3-F2

探测出3条边；

返回的故障模式集为：

F10＝F9&{Omit(E3-F2)}

从而，观察图2-9发现，除了边C1-E3没有被探测完(A2-C2和E2-F2 在第8轮时已经被探索出来)，其他所有边都已被探测出来，注入故障轮数为 10次，共探测出10条调用链。

至此，本实施例二还需要进行进一步的验证，确保探索到待测平台完整的业务体系结构，不能有遗漏。本实施例根据当前探索到的体系结构图生成崩溃(Crash)故障集合，逐条注入这些崩溃(Crash)故障集合。如果追踪到新的调用链，则继续完善系统业务体系结构。若待测平台失败(FAIL)则测试下一条，若待测平台成功(SUCCESS)则追踪新的调用链，继续注入故障 (Crash)场景，最终完全探测出体系结构图之后，生成的故障场景集合是需要全部进行测试的，这是因为结束条件就是生成的待注入故障场景集合全部测试结果为失败(FAIL)，否则很难保证待测平台还有没有冗余路径存在。最终，所有的路径都会被探索出来，本实施例得到待测平台完整的业务体系结构图。

实施例三：

本实施例中，给出实施例一中的步骤S300和S500的排序优化的具体过程。

本发明在实施例二探索出完整的待测系统业务路径体系结构(如图2所示)的基础上，对路径进行优化排序，并针对排序后的每条路径设计相应的待注入的故障场景。

在利用LDFI(Linear Discriminant Analysis，线性判别分析)方法探索出完整的待测平台业务体系结构之后，可以获取到待测平台的全部路径集合P 如表1：

表1：

如表1所示，待测平台一共有40条路径。

根据本实施例的优化排序方法，作为一种可实施方式，包括如下步骤：

首先，优化集S为空，随机从待测平台的路径集合P中选取一条路径，如选择A1-B2-D1-F2,将这条路径从路径集P中删除，并加入优化集S中。此时优化集S中只有一条路径A1-B2-D1-F2。

接着，对路径集合P中的所有39条路径，分别求解每条路径对应的未被优化集S中路径覆盖的故障组合数。如路径A1-B1-D1-F1中包含的故障组合如表2所示。

表2：

路径A1-B1-D1-F1中一共含有15个可能的故障组合，其中未被优化集S 中路径覆盖的故障组合有12个。

同样的，对路径集合P中的每条路径，都计算出其包含的未被优化集S 中路径覆盖的故障组合数，然后从中选出未被覆盖故障组合数最多的一条路径A2-B1-D2-F1加入优化集S中，并从路径集合P中删除这条路径。此时优化集S中有2条路径，路径集合P中还剩38条。

以此类推，每次都计算路径集合P中所有路径对应的未被优化集S中路径覆盖的故障组合数，并从中选出未被优化集S覆盖故障组合最多的那一条路径加入优化集S，并从路径集合P中删除对应路径，直到路径集合P为空为止。

此时，优化集S中的路径按照加入顺序已经排序完毕。

值得一提的是，如果路径比较长，计算成本有限，不能把所有的故障组合都列出来，作为一种可实施例，此时本实施例可以设定一个最高排序维度，如6维，就表示只考虑6个或6个以下的故障组合进行排序。

接着，按照S中路径的顺序，依次根据实施例一中的生成方法针对目标路径生成故障组合用例。如S中的第一条路径是A1-B2-D1-F2。

目标路径A1-B2-D1-F2上的故障场景集合为：

Fault＝{Crash(A1)，Omit(A1-B2)，Crash(B2)，…，Crash(F2)}

对于待测平台中的其他路径，同样的找出它们路径上的故障场景集合，如路径A1-B1-D1-F1(记为路径Path1)上的故障场景集合为：

F_Path1＝{Crash(A1)，Omit(A1-B1)，Crash(B1)，…，Crash(F1)}

那么，如果想要破坏路径Path1但是同时又不破坏目标路径 A1-B2-D1-F2，对应的故障场景就是存在于F_Path1中但又不存在于Fault的那些故障场景，即：

F_Path1-(F_Path1∩Fault)

求解出来就是 {Omit(A1-B1)，Crash(B1)，Omit(B1-D1)，Omit(D1-F1)，Crash(F1)}。

再看另一条路径A2-B2-D2-F1(记为路径Path2)，它路径上的故障场景集合为：

F_Path2＝{Crash(A2)，Omit(A2-B2)，Crash(B2)，…，Crash(F1)}

那么，如果想要破坏路径Path2但是同时又不破坏目标路径 A1-B2-D1-F2，对应的故障场景就是存在于F_Path2中但又不存在于Fault的那些故障场景，即：

F_Path2-(F_Path2∩Fault)

求解出来就是 {Crash(A2),Omit(A2-B2),Omit(B2-D2),Crash(D2),Omit(D2-F1),Crash(F1)}。

那么，如果要破坏路径Path1和Path2同时又不破坏目标路径 A1-B2-D1-F2，对应的故障场景就是把F_Path1-(F_Path1∩Fault)和 F_Path2-(F_Path2∩Fault)求合集，即两个集合中的故障场景的组合，得到结果如下： {Omit(A1-B1)&Crash(A2)，Omit(A1-B1)&Omit(A2-B2)，…，Omit(D1- F1)&Omit(D2-F1)，Crash(F1)}

这个集合中的任意一个故障场景在注入后，都可以破坏路径Path2但是同时又不破坏目标路径A1-B2-D1-F2。

类似的，对于待测平台中除了目标路径A1-B2-D1-F2之外的所有路径 Pathj(0<j<39)，都求解出能破坏Pathj同时不破坏路径目标路径的故障场景集合，并对这些故障场景集合进行合取，即可得到能破坏除了目标路径之外的其它所有路径的故障场景集合，选取其中最小的一个故障场景作为目标路径对应的故障用例。

对于S中的每一条路径，按顺序依次根据实施例一求解出其对应的故障用例，最后得到待注入的优化排序后的故障用例集合。

为实现本发明目的，本发明实施例还提供一种处理待测平台潜在故障的黑盒注入的软件系统，其包括所述的处理待测平台潜在故障的黑盒注入方法的软件源代码，并获得基本相同的技术效果。

本发明实施例还提供一种处理待测平台潜在故障的黑盒注入的介质，其存储所述的软件系统的源代码。

本发明实施例更进一步提供一种处理待测平台潜在故障的黑盒注入的设备，包括中央处理器(CPU)和所述介质，在设备运行时，所述CPU从所述介质中读取软件系统的源代码，实现处理待测平台潜在故障的黑盒注入。

本发明的伪代码如图3和图4所示。

本发明实施例是一种快速探索并发现待测平台SUT潜在故障的故障注入方法和系统及介质设备，快速探索并发现待测平台SUT潜在故障，是对现有故障注入技术的一种补充，它检测待测平台SUT，特别是分布式待测平台SUT 中隐藏的故障，即使在完全不知道待测平台SUT内部业务体系结构的情况下，也能快速探索并检测待测平台SUT中潜在的故障，并确保每条路径都至少被覆盖了一次；进一步地，通过在不同规模(例如路径数100到10万)的待测平台SUT中注入不同数量级(例如10到10万)的预埋故障，再进行故障注入测试。实验结果表明，生成的故障场景集合经过优化排序，可以达到只测前20％的故障用例，就能检测80％的潜在故障。在测试成本有限时，能快速高效的检测待测平台SUT的潜在故障，并保证一定的覆盖率。

尽管本发明的实施方案已公开如上，但其并不仅限于说明书和实施方式中的运用，它完全可以被适用于各种适合本发明的领域，对于熟悉本领域的人员而言，可容易地实现另外的修改，因此在不背离权利要求及等同范围所限定的一般概念下，本发明并不限于特定的细节和这里示出与描述的图例。

Claims (7)

1.一种处理待测平台潜在故障的黑盒注入方法，其特征在于，包括以下步骤：

首先，追踪待测平台业务调用路径；

其次，根据业务调用路径及提取出的信息，生成或者完善相应业务体系结构图；

然后，根据业务体系结构图递归推理出能破坏所有已知路径的待测故障场景，并注入待测平台进行测试，并依次生成其对应的故障场景的路径；

最后，在递归推理并注入待测平台进行测试之后，还包括如下步骤：

在探索整个待测系统业务路径体系结构的基础上，对路径进行优化排序，并针对排序后的每条路径设置相应的待注入的故障场景对系统进行测试；

具体来看，所述优化排序，包括如下步骤：

设优化集S为空，待测平台的所有路径集合P；

随机从待测平台的路径集合P中选取一条路径，将这条路径从路径集P中删除，并加入优化集S中，此时优化集S中只有一条路径；

对路径集合P中的所有路径，分别求解每条路径对应的未被优化集S中路径覆盖的故障组合数；

同样的，对路径集合P中的每条路径，都计算出其包含的未被优化集S中路径覆盖的故障组合数，然后从中选出未被覆盖故障组合数最多的一条路径加入优化集S中，并从路径集合P中删除这条路径；

此时优化集S中有2条路径；

以此类推，每次都计算路径集合P中所有路径对应的未被优化集S中路径覆盖的故障组合数，并从中选出未被优化集S覆盖故障组合最多的那一条路径加入优化集S，并从路径集合P中删除对应路径，直到路径集合P为空为止；

此时，优化集S中的路径按照加入顺序排序完毕；

所述的黑盒注入方法，其特征在于，所述排序后的每条路径设置相应的待注入的故障场景，包括如下步骤：

按照S中路径的顺序，依次根据路径对应故障进行合取计算，针对目标 路径生成故障组合用例，设第一条路径是A1-B2-D1-F2；

目标路径A1-B2-D1-F2上的故障场景集合为：

Fault＝{Crash(A1)，Omit(A1-B2)，Crash(B2)，…，Crash(F2)}

对于待测平台中的其他路径，同样的找出它们路径上的故障场景集合，设路径A1-B1-D1-F1，记为路径Path1上的故障场景集合为：

F_Path1＝{Crash(A1)，Omit(A1-B1)，Crash(B1)，…，Crash(F1)}

那么，如果想要破坏路径Path1但是同时又不破坏目标路径A1-B2-D1-F2，对应的故障场景就是存在于F_Path1中但又不存在于Fault的那些故障场景，即：

F_Path1-(F_Path1∩Fault)

求解出来就是{Omit(A1-B1)，Crash(B1)，Omit(B1-D1)，Omit(D1-F1)，Crash(F1)}；

再看另一条路径A2-B2-D2-F1，记为路径Path2，它路径上的故障场景集合为：

F_Path2＝{Crash(A2)，Omit(A2-B2)，Crash(B2)，…，Crash(F1)}

那么，如果想要破坏路径Path2但是同时又不破坏目标路径A1-B2-D1-F2，对应的故障场景就是存在于F_Path2中但又不存在于Fault的那些故障场景，即：

F_Path2-(F_Path2∩Fault)

求解出来就是{Crash(A2)，Omit(A2-B2)，Omit(B2-D2)，Crash(D2)，Omit(D2-F1)，Crash(F1)}；

那么，如果要破坏路径Path1和Path2同时又不破坏目标路径A1-B2-D1-F2，对应的故障场景就是把F_Path1-(F_Path1∩Fault)和F_Path2-(F_Path2∩Fault)求合集，即两个集合中的故障场景的组合，得到结果如下：{Omit(A1-B1)&Crash(A2)，Omit(A1-B1)&Omit(A2-B2)，...，Omit(D1-F1)&Omit(D2-F1)，Crash(F1)}；

这个集合中的任意一个故障场景在注入后，都可以破坏路径Path2但是同时又不破坏目标路径A1-B2-D1-F2；

类似的，对于待测平台中除了目标路径A1-B2-D1-F2之外的所有路径Pathj，都求解出能破坏Pathj同时不破坏目标路径的故障场景集合，并对这些故障场景集合进行合取，即可得到能破坏除了目标路径之外的其它所有路径的故障场景集合，选取其中包含故障个数最少的一个故障场景作为目标路径对应的故障用例，其中，0＜j＜所有路径；

对于S中的每一条路径，按顺序依次求解出其对应的故障用例，最后得到待注入的优化排序后的故障用例集合。

2.根据权利要求1所述的黑盒注入方法，其特征在于，依次生成路径后，还包括如下步骤：

根据路径对应的故障用例进行故障注入测试。

3.根据权利要求1所述的黑盒注入方法，其特征在于，所述探索使用线性判别分析方法进行。

4.根据权利要求1所述的黑盒注入方法，其特征在于，进行排序的故障组合中故障个数不超过6个。

5.一种处理待测平台潜在故障的黑盒注入软件系统，其特征在于，包括所述权利要求1-4任一项的处理待测平台潜在故障的黑盒注入方法的软件源代码。

6.一种处理待测平台潜在故障的黑盒注入的介质，其存储如权利要求5所述的软件源代码。

7.一种处理待测平台潜在故障的黑盒注入的设备，包括CPU和如权利要求6所述介质；

在设备运行时，所述CPU从所述介质中读取软件系统的源代码，实现处理待测平台潜在故障的黑盒注入。

Images