多因素工业系统的故障快速识别方法

摘要

本发明公开了一种多因素工业系统的故障快速识别方法，该方法首先确定待测试的多因素工业系统的测试用例集Ts，然后用Ts中的测试用例对系统进行测试，运行时发生故障的测试用例组成集合Ts1，其特征在于通过对比Ts1中测试用例，从Ts1中找出所涉及的共同因素，并以此共同因素作为可能导致系统故障原因的重要组成因素，通过逐个替换Ts1中每个发现故障的测试用例所涉及到的每个因素并由此生成一组附加测试用例Cts，然后用这些测试用例重新对系统进行测试，运行时未发生故障的测试用例对应的所有被替换的因素，是有可能导致错误发生的因素。此方法具有科学性、高效性和准确性等特点，还具有针对性、经济性、灵活和可扩展等特性。

权利要求

1.一种多因素工业系统的故障快速识别方法，该方法首先确定待测试的多因素工业系统的测试用例集Ts，然后用测试用例集Ts中的测试用例对系统进行测试，运行时发生故障的测试用例组成集合Ts1，其特征在于通过对比运行时发生故障的测试用例组成集合Ts1中测试用例，从运行时发生故障的测试用例组成集合Ts1中找出所涉及的共同因素，并以此共同因素作为可能导致系统故障原因的重要组成因素，通过逐个替换运行时发生故障的测试用例组成集合Ts1中每个发现故障的测试用例所涉及到的每个因素并由此生成一组附加测试用例Cts，然后用附加测试用例Cts中测试用例重新对系统进行测试，运行时未发生故障的附加测试用例Cts中测试用例对应的所有被替换的因素，是有可能导致错误发生的因素。

2.根据权利要求1所述的多因素工业系统的故障快速识别方法，其特征还在于：当利用运行时发生故障的测试用例组成集合Ts1中每一个形如t＝(v1，v2，…，vn)的测试用例生成一组形如：t1＝(*，v2，…，vn)，t2＝(v1，*，…，vn)，…，tn＝(v1，v2，…vn-1，*)且这里“＊”表示将相应位置上的值替换为测试人员关注的，并异于原来的因素值的附加测试用例Cts，进行下一轮测试时，运行时未发生故障的附加测试用例Cts中测试用例对应的所有被替换的因素，是有可能导致错误发生的因素。

说明书

多因素工业系统的故障快速识别方法

技术领域

[0001] 本发明涉及一种系统故障主要来源于系统中各个因素及其相互作用的多因素工业系统的故障识别方法。

背景技术

[0002] 在一些多因素工业系统的安全测试中，针对某个待测系统受到n个因素影响，每个因素有ti个可能取值的情况，一般设计一组形如(v1，vn，…，vi，…，vn)的因素组合测试用例(其中vi是第i个因素的一个取值)，用于检测该系统中哪些因素或哪些因素的相互作用是否会引发系统故障。因素组合测试方法因能以较少的测试用例实现对被测系统科学有效的测试而得到广泛的研究和应用，特别是对于这些系统错误来源于系统中一些因素和因素之间的相互作用的待测系统。该方法利用组合设计方法产生各种不同组合覆盖程度的测试用例集，来实现对各个因素及相互之间的各种组合的覆盖。有效的针对多因素工业系统的测试及故障诊断方法具有十分重要的意义，可以很好地提高系统测试的效率和质量、降低成本。

发明内容

[0003] 本发明提供一种多因素工业系统的故障识别方法，本发明不但可以迅速确定系统故障原因，而且可以进一步发现多因素工业系统的隐患。

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

[0005] 一种多因素工业系统的故障快速识别方法，该方法首先确定待测试的多因素工业系统的测试用例集Ts，然后用Ts中的测试用例对系统进行测试，运行时发生故障的测试用例组成集合Ts1，通过对比Ts1中测试用例，从Ts1中找出所涉及的共同因素，并以此共同因素作为可能导致系统故障原因的重要组成因素，通过逐个替换Ts1中每个发现故障的测试用例所涉及到的每个因素并由此生成一组附加测试用例Cts，然后用这些测试用例重新对系统进行测试，运行时未发生故障的测试用例对应的所有被替换的因素，是有可能导致错误发生的因素。

[0006] 本发明还可以进一步采取以下技术措施：

[0007] 所述的附加测试用例的生成方法是将Ts1中每一个形如t＝(v1，v2，…，vn)的测试用例，逐个修改其涉及到的因素值，相应生成一组测试用例Cts，形如：t1＝(*，v2，…，vn)，t2＝(v1，*，…，vn)，…，tn＝(v1，v2，…vn-1，*)，其中，“*”表示将相应位置上的值替换为测试人员关注的，并异于原来的因素值。运行Cts进行下一轮测试时，所有未发生故障的测试用例对应的被替换的因素，是有可能导致错误发生的因素，例如，如果t1，t3，t5在测试中没有发现问题，则触发故障的因素组合可能包含v1，v2和v5。

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

[0009] ①本发明是组合测试方法的自然延伸，因而具有科学性、高效性和准确性特点。

[0010] ●关于科学性。组合测试方法将暴露出来的系统故障归结为由测试用例涉及到的因素及因素的组合所造成，测试中发现错误的测试用例一定包含了触发故障的因素和因素组合，正确运行的测试测试用例不涉及触发故障的因素和因素组合。因此，本发明中将Ts1中共同涉及的因素，以及附加测试用例Cts中所有正确运行测试用例对应的被替换因素作为可能的故障因素是科学的。

[0011] ●关于高效性。对于一个具有n个参数的系统，当某条测试数据在测试中发现故n障时，直接导致故障的所有可能的因素及因素组合有2-1个，通过对比所有发现故障测试用例，从中找出所涉及的共同因素，并以此共同因素作为可能导致系统故障原因的重要组成因素，因而该方法具有高效性。

[0012] ●关于准确性。由于在多因素工业系统(例如：软件系统)中，导致系统故障的原因是很复杂的，本发明利用附加测试用例进行下一轮测试时，所有未发生故障的测试用例对应的被替换的因素，是有可能导致错误发生的因素，这个结果大大排除了各种可能导致系统故障的因素或因素的组合，具有较高的准确性。

[0013] ②本发明具有针对性、经济性、灵活和可扩展的优良特性。

[0014] ●针对性。虽然传统方法中有关于实验结果分析的方法，如直观分析方法、方差分析方法等，但是这些方法并不适合于对测试结果的分析。本发明针对在组合测试中发现故障的测试用例t＝(v1，v2，…，vn)设计一组新的形如t1＝(*，v2，…，vn)，t2＝(v1，*，…，vn)，…，tn＝(v1，v2，…vn-1，*)的测试用例进行第二轮测试，因而具有很强的针对性。

[0015] ●经济性。本方法只对发现故障的测试用例设计新测试用例进行第二轮测试，由于在实际测试中，能发现错误的测试用例比较少，如果有很多测试用例发现错误，一般通过比对这些发现错误的测试用例，就可以找出错误原因。所以，本方法可以有效地提高效率、降低成本，因而很经济实用。

[0016] ●灵活和可扩展性。如果对于一个具体的多因素工业系统，组合测试没有发现故障，就无需使用本方法；如果在第二轮测试中仍无法确定故障原因，可以对该轮测试中发现故障的测试用例再设计运行下一轮测试，直到找出故障原因为止。所以，本方法的使用可以根据具体软件系统的测试情况进行调整，而不是千篇一律的固定方法，因此，具有优良的灵活性和可扩展性。

附图说明

[0017] 图1是本发明的多因素工业系统故障诊断方法流程图。

具体实施方式

[0018] 实施例1

[0019] 一种用于确定工业系统故障因素的多因素工业系统的故障识别方法，该方法首先根据待测试的多因素工业系统的安全性要求、安全测试的成本预算或时间等要求确定测试用例集Ts，确定测试用例集Ts的方法可以采用根据测试人员自己的兴趣和关注点进行任意指定，或根据组合覆盖标准生成，或者将这两个方面结合起来，既考虑测试人员的关注点又兼顾组合覆盖标准。然后用Ts中的测试用例对系统进行测试，运行时发生故障的测试用例组成集合Ts1，对比Ts1中测试用例所涉及到的因素，其共同涉及的因素以及因素的各种组合是所有可能导致系统故障的原因。通过逐个修改Ts1中每个发现故障的测试用例涉及到的每个因素生成一组附加测试用例Cts。然后用这些测试用例重新对系统进行测试，运行时未发生故障的测试用例对应的原测试用例中因素，是有可能导致错误发生的成分。在本实施例中，确定测试用例集Ts的方法是根据待测试的多因素工业系统的测试要求等因素确定不同组合覆盖要求的测试用例集Ts，可以根据测试人员关注点指定一些测试用例，也可以根据组合覆盖的充分性准则进行选取，例如，选择规模较小的单因素覆盖测试用例集覆盖所有参数的各个取值，也可以选择规模适中的两两组合覆盖测试用例集覆盖任意两个参数间的两两组合，或者选择规模稍大一点的三三组合覆盖测试用例集等，这些选择取决于该工业系统的测试要求和现有的测试条件等；暴露出来的系统故障归结为由测试用例涉及到的因素所造成，即系统故障原因是由Ts1的测试用例涉及的系统因素；附加测试用例Cts的生成方法是将Ts1中每一个形如t＝(v1，v2，…，vn)的测试用例，逐个修改其涉及到的因素值，相应生成一组测试用例，形如：t1＝(*，v2，…，vn)，t2＝(v1，*，…，vn)，…，tn＝(v1，v2，…vn-1，*)，进行下一轮测试，其中，“*”表示将原来测试用例t中相应位置的因素值替换为测试人员关注，且异于被替换的因素值。运行这组测试用例时，未发生故障的测试用例对应的原测试用例中因素，是有可能导致错误发生的成分，例如，如果t1，t2在测试中顺利通过，则可以确定导致故障的因素包括v1和v2。

[0020] 实施例2

[0021] 针对多因素工业系统的安全测试和故障诊断的方法，首先分析用组合测试用例集Ts中的测试用例对系统进行测试，如果没有发现故障，那么当然就无需进行故障诊断。所以，该方法共分四步进行：第一步，根据待测试的多因素工业系统的测试要求，测试关注点等因素确定不同组合覆盖要求的测试用例集Ts，用Ts中的测试用例对系统进行测试，并将运行时发生故障的测试用例组成的集合记为Ts1。第二步，对集合Ts1中测试用例进行分析；第三步，生成附加测试用例集Cts以辅助故障诊断；第四步，根据附加测试用例的运行情况重新进行故障诊断的分析验证，如果仍然发现故障，转第三步，直到不发现故障为止。

[0022] 第一步：确定组合测试用例集并进行测试

[0023] 根据待测试的多因素工业系统的测试要求，测试关注点，以及组合覆盖标准等因素确定测试用例集Ts，用Ts中的测试用例对系统进行测试，并将运行时发生故障的测试用例组成的集合记为Ts1。

[0024] 第二步：对测试结果进行初步分析

[0025] 组合测试模型把暴露出来的系统故障归结为由测试用例涉及到的各种因素的值或值的组合所造成，即系统故障有可能由Ts1中测试用例涉及到的因素或因素组合所引发。因此，将Ts1中测试用例共同涉及到因素及因素组合成分找出来，这些元素很可能就是直接导致故障的原因，可为进一步分析和确认故障原因提供非常重要的依据。

[0026] 第三步：生成附加测试用例以辅助故障诊断

[0027] 为每个发现故障的测试用例生成相应附加测试用例，例如，如果t＝(v1，v2，…，vn)是首轮测试发现故障的测试用例，逐个替换其涉及到的因素值，相应生成一组测试用例：t1＝(*，v2，…，vn)，t2＝(v1，*，…，vn)，…，tn＝(v1，v2，…vn-1，*)。然后用这些测试用例重新对系统进行测试，下一步将对测试结果进行处理。

[0028] 第四步：根据附加测试用例的运行情况重新进行分析和验证

[0029] 附加测试用例的运行后，其中未发生故障的测试用例对应的原测试用例中因素，是有可能导致错误发生的成分，例如，对于首轮测试发现故障的测试用例t＝(v1，v2，…，vn)，在第二轮测试中如果它的附加测试用例t1和t2通过，则触发系统故障的原因包含因素v1和v2。

[0030] 本发明基于以下原理工作：

[0031] (1)根据多因素工业系统的安全性要求、安全测试的成本预算和时间等要求，选择不同覆盖程度(具体有覆盖所有系统因素各个取值的单因素覆盖、覆盖系统任意两个因素间所有组合的两两组合覆盖等等，关于这些不同覆盖程度的测试用例集生成已有很多公开的研究成果可以直接使用)的组合测试用例集Ts，也可以根据测试关注点直接指定一些测试用例，或者将这两个方面进行有机结合，这样既兼顾测试人员关注点，又满足多因素工业系统安全测试的组合覆盖要求。

[0032] (2)如果一个测试用例在执行中发现故障，在多因素工业系统中可能是对应的某些因素组合触发了这个系统故障。例如，当t＝(2，1，4)在测试时发现系统故障，对应的触发故障的系统因素及其组合可能是：(2，-，-)，(-，-，4)，(-，1，-)，(-，1，4)，(2，-，4)，(2，1，-)，(2，1，4)。没有发现故障的测试用例不会包含故障的触发因素及其组合，所以比对发现系统故障的测试用例集，其共同涉及的系统因素及组合可能是触发系统故障的原因。

[0033] (3)为了进一步确定出是哪些因素或因素组合导致了软件故障，并充分利用测试结果，检查是否有新的隐错存在，为Ts1中每个运行时发生故障的测试用例t＝(v1，v2，…，vi，…，vn)设计n个附加测试用例：t1＝(*，v2，…，vi，…，vn)，t2＝(v1，*，…，vi，…，vn)，…，tn＝(v1，v2，…，vn-1，*)，其中“*”号表示我们可以用任意不同于原来测试用例t＝(v1，v2，…，vi，…，vn)相应位置因素的取值来代入。这样产生的一组测试用例为附加测试用例集，记为CTs。

[0034] (4)运行附加测试用例集CTs，如果t＝(v1，v2，…，vi，…，vn)的n个附加测试用例中t1和t2在测试中正确运行，其他都发现类似故障，则触发系统故障的因素一定包含组合v1v2。因为其他测试用例t3…tn中都包含该组合，只有t1和t2中不包含.

[0035] 实施例3

[0036] 本实施例涉及电信系统交换机通话功能的测试，本实施例以4个参数作为这个测试模型的输入，分别为呼叫种类、资费方式、接入方式和状态。对于这4个参数变量的每一个参数均可以有3种不同的状态，如表1所示。

[0037] 第一步：确定组合测试用例集并进行测试

[0038] 如果要把表1中的所有情况都测试到，那么将需要34＝81个测试用例来遍历所有的测试情况。一般认为81次测试的工作量太大，而且没有必要进行完全测试，所以需要根据该系统的测试要求、现有的测试资源等选择测试用例集。如果考虑只覆盖待测系统中的各个因素，只需要按照表1设计三个测试用例就可以了；如果考虑对任意两个因素的两两组合进行覆盖，需要选择一组两两组合覆盖的测试用例集(如表2)，表2中每一行都给出了一个测试用例，9条测试用例实现了对任意两个因素间所有值组合的完全覆盖，都至少出现一次。当然，要求更高时，可以设计使用三三组合覆盖测试用例(至少需要27条测试用例)、四四组合覆盖测试用例(在本例中即为完全测试)等等.也可以根据测试人员的关注点指派一些测试用例，然后再在此基础上实现某个覆盖要求。这里我们假定表2中前两个测试用例是测试人员指定的，其余的测试用例是在此基础上对待测试系统实现两两组合覆盖测试。

[0039] 表1待测系统SUT的测试需求

[0040]呼叫种类 资费方式 接入方式 状态
市话 被叫方 环路 成功
长途 集中 综合业务 忙
国际 免费 专用分组 阻塞

[0041] 当我们用这组测试用例对交换机进行测试后，如果没有发现问题，那么就说明交换机功能在这个水平上的测试是合格的。当然不能因此就说交换机肯定没有问题，因为任何测试只能证明被测对象的不完美性，而无法证明它的完美性。如果这组测试用例中有一个或几个运行时发生了故障，那么作为测试应该说是比较成功的，因为经过测试我们发现了系统故障。接下来的重要工作就是分析故障的原因，对它进行定位，并排除故障。我们不能撇开前面所做的测试工作，泛泛地去重新分析、检查系统，而应该以前面所做的测试工作为基础，进行全面分析。如果能迅速找出错误原因，将大大提高软件测试的效率，缩短时间，并降低成本。

[0042] 表2组合测试的测试用例

[0043]呼叫种类 资费方式 接入方式 状态
市话 集中 专用分组 忙
长途 免费 环路 忙
国际 被叫方 综合业务 忙
市话 免费 综合业务 阻塞
长途 被叫方 专用分组 阻塞
国际 集中 环路 阻塞
市话 被叫方 环路 成功
长途 集中 综合业务 成功
国际 免费 专用分组 成功

[0044] 不失一般性，下面我们仅考虑当用表2中这组测试用例对交换机进行测试时，系统运行时发生某个故障的测试用例组成的集合Ts1(见表3)，即表2中第二个和第六个测试用例。不发生该故障的测试用例集合是表2中剩下的七个测试用例。

[0045] 表3发生某个故障的测试用例集Ts1

[0046]呼叫种类 资费方式 接入方式 状态
国际 集中 环路 阻塞
长途 免费 环路 忙

[0047] 第二步：对测试结果进行初步分析

[0048] 对比测试中发现故障的两条测试用例：(国际，集中，环路，阻塞)，(长途，免费，环路，忙)，故障的触发原因可能包含因素：接入方式”环路”。

[0049] 第三步：生成附加测试用例以辅助故障诊断

[0050] 为了进一步找出导致系统故障的因素，通过逐个修改Ts1中测试用例涉及的因素值，设计一个附加测试用例集Cts，如表4，其中*号表示相应位置的参数值取任意一个测试人员感兴趣的，不同于原来出错测试用例在相应位置的值(在本例中取括号内的值)。

[0051] 表4附加测试用例集Cts

[0052]呼叫种类 资费方式 接入方式 状态
t1 *(长途) 集中 环路 阻塞
t2 国际 *(免费) 环路 阻塞
t3 国际 集中 *(专用分组) 阻塞
t4 国际 集中 环路 *(忙)
t5 *(市话) 免费 环路 忙
t6 长途 *(被叫方) 环路 忙
t7 长途 免费 *(综合业务) 忙
t8 长途 免费 环路 *(阻塞)

[0053] 用这组测试用例再对交换机进行测试。

[0054] 第四步：根据附加测试用例的运行情况重新进行分析和验证

[0055] 根据测试结果我们就可以确定出导致故障的原因，针对不同的测试结果我们可以给出不同结论，我们只以以下几种情况为例进行讨论：

[0056] 情形1：这八个测试用例的运行都没有发生原先的故障。我们可以判定此时因素组合(长途，免费，环路，忙)和(国际，集中，环路，阻塞)是可能导致故障的因素。

[0057] 情形2：只有某一个测试用例运行时发生故障，例如是表4中第二个测试用例t2。可以判定此时导致故障的可能原因是因素组合(国际，-，环路，阻塞)，(长途，免费，环路，忙)。

[0058] 情形3：有某5个测试用例测试时发生故障，例如Ts1＝{t3，t4，t5，t6，t7}，此时可以根据t1，t2运行正常，判定导致故障的原因应该包含因素组合(国际，集中，-，-)，根据t8运行正常，判定导致故障的原因应该包含因素组合(-，-，-，忙)。

[0059] 类似地，我们可以讨论其他各种情形。由此我们看出，在组合测试的基础上，并辅之以一些必要的相关测试用例，我们可以对导致系统故障的因素进行有效的定位；在产生故障的测试用例比较多的情况下，分析过程比较复杂。但由于多数情况下，导致系统出错的测试用例数量很少(这种测试用例对软件测试来说是高质量的测试用例)，如果这种导致系统出现错误的测试用例数量多，说明系统质量太低，需要进行广泛的重新分析和检查。所以，不论什么情况，基于组合测试的基础，并辅之以一些必要的新的相关测试用例，对故障原因进行分析是非常重要的，也是非常有效的。