一种用于软件缺陷核查的故障模式集构建方法及系统

技术领域

本发明属于软件工程数据挖掘技术领域，具体涉及一种用于软件缺陷核查的故障模式集构建方法及系统。

背景技术

软件设计缺陷核查与分析有助于提高软件产品的质量和可靠性，提高发现和排除缺陷的效率。及早发现软件缺陷，可以有效降低软件测试费用和维护成本。

SFMEA(Software Failure Mode and Effects Analysis)通过选取遗留缺陷因子进行软件失效模式和影响分析(详见GJB-Z 1391-2006)，可用于软件设计缺陷核查分析。但对于遗留缺陷的因子的选取不同以及选取的因子对于缺陷的影响程序不同，对于缺陷的分析结果有着不同的影响。同时，随着因子数量的增多，对于模型的结构越复杂，计算效率和推理过程也变得非常缓慢。

并且传统的SFMEA表的故障模式分析，虽然能够对各软件的功能模式分析，但存在以下弊端：

将所有软件的功能、故障模式混合，各专业软件的模式较为分散，不利于各专业软件的功能层级的故障的分析工作；

传统的SFMEA表格，更适用于各软件的通用的故障模式的分析，对于软件的功能层级的分析存在一定的弊端，不利于软件的通用及专用的功能层级的分析。

发明内容

鉴于上述的分析，本发明旨在公开了一种用于软件缺陷核查的故障模式集构建方法及系统，解决目前SFMEA分析存在的问题。

本发明公开了一种用于软件缺陷核查的故障模式集构建方法，包括如下步骤：

对软件系统的各配置项软件进行分类，以确定各配置软件的类型；根据各类型的各配置项软件的执行任务方式，得到各配置项软件的功能模式；

获取与软件系统相关的软件的历史缺陷数据，经过数据处理后，建立故障数据集合；

结合所述各配置项软件的功能模式和故障数据集合挖掘与功能模式对应的故障模式，形成故障模式集。

进一步地，所述历史缺陷数据包括故障现象、故障影响、危害程度、缺陷定位、故障影响、触发方式以及处理措施在内的数据；其中，故障影响包括对于函数级别的影响、对于软件级别的影响以及对于系统层面的影响。

进一步地，采用SFMEA+SFTA的方法进行数据挖掘，建立功能模式和故障模式相对应的故障模式集。

进一步地，所述采用SFMEA+SFTA的方法进行数据挖掘，包括：

1)通过SFMEA的方法对各配置项的功能模式所实现的功能进行分析，识别配置项软件中的故障模式，分析故障模式产生的原因及造成的影响，建立SFMEA表格；

2)通过SFTA的方法，对所述故障数据集合进行分析识别出故障模式建立故障树，将与功能模式相对应的故障树的节或者故障树的叶作为故障模式，补充填写进SFMEA表格，构建得到故障模式集。

进一步地，所述SFTA方法中，针对故障数据集合，结合各配置项软件的功能模式，将与功能模式相关的问题现象作为SFTA的顶事件，即故障树的根，通过分析顶事件发生的原因，将原因与顶事件相连，作为故障树的节，并进一步分析直至已追溯到导致顶事件发生的全部的原因，将底事件作为故障树的叶，建立故障树。

进一步地，所述SFMEA方法中选取配置项类别和功能模式作为遗留缺陷的因子。

进一步地，作为所述故障模式集输出的SFMEA表格项的新增项包括：

配置项类别项，用于填写软件系统中的配置项软件的类型；

功能模式项：用于填写配置项软件的功能模式；

故障模式项：用于填写与功能模式有关的故障模式；

故障类别项：用于填写按照功能模式分类的故障类别。

进一步地，所述故障类别包括：

任务流程类故障，为影响软件任务流程的正常运行的故障，使软件无法按照软件功能实现所要求的任务流程继续执行；

交互过程类故障，为发生在配置项软件与上位机软件交互过程中的故障，导致软件无法正常按要求执行后续功能；

状态切换类故障，为软件无法按照设置的状态切换要求进行切换、状态切换错误，或者状态切换紊乱而产生的故障；

外部输入类故障，为外界的输入信息导致的软件未按照预期结果运行而产生的故障；

时间约束类故障，为未在规定的时间内、规定的时间间隔、或在规定的时间之后完成软件功能而产生的故障；

功能逻辑类故障，为功能未考虑完全、未覆盖到具体实现要求，或者设计逻辑错误而产生的故障。

进一步地，在所述SFMEA表格项中，将软件配置项类别、单元项的软件单元与功能模式项中模式相对应，将功能模式作为SFMEA分析的内容，归纳总结出功能模式所对应的故障模式以及故障类别。

本发明还公开了一种用于软件缺陷核查的故障模式集构建系统，包括：

功能模式获取模块，用于对软件系统的各配置项软件进行分类，以确定各配置软件的类型；对于各类型的各配置项软件进行执行任务方式归纳，得到各配置项软件的功能模式；

故障数据集合建立模块，用于收集整理与软件系统相关的专业软件的历史缺陷数据，并进行数据采集和处理，建立故障数据集合；

故障模式集构建模块，用于结合所述各配置项软件的功能模式和故障数据集合挖掘与功能模式对应的故障模式，采用SFMEA+SFTA的方法，构建故障模式集。

本发明至少可实现以下有益效果之一：

本发明采用聚类分析的方法，通过制定固定的因子，结合SFMEA+SFTA的方法，生成的故障模式集合具有专用特性，针对某一特定软件可从软件的功能层面有效预测软件的缺陷，同时基于功能模式，可有效解决状态爆炸的问题，达到优化测试资源分配和提高软件产品质量的目的。

附图说明

附图仅用于示出具体实施例的目的，而并不认为是对本发明的限制，在整个附图中，相同的参考符号表示相同的部件。

图1为本实施例一中的故障模式集构建方法流程图；

图2为本实施例一中的故障数据集合建立方法流程图；

图3为本实施例一中的建立软件故障树的部分符号示例及说明；

图4为本实施例二中的故障模式集构建系统流程图。

具体实施方式

下面结合附图来具体描述本发明的优选实施例，其中，附图构成本申请一部分，并与本发明的实施例一起用于阐释本发明的原理。

实施例一

本实施例公开了一种用于软件缺陷核查的故障模式集构建方法，如图1所示，包括如下步骤：

步骤S1、对软件系统的各配置项软件进行分类，以确定各配置软件的类型；根据各类型的各配置项软件的执行任务方式，得到各配置项软件的功能模式；

大型软件系统通常包括多个配置项软件，从不同的维度进行分类，确认软件所属的分类类型；对于各类型的各配置项软件进行执行任务方式归纳，得到各配置项软件在软件系统中所属层次、涉及的软件组成部分、执行的组织实施方式，关注的某个方面特征等内容。

具体的，功能模式包括基本行为功能模式、任务流程行为模式、状态切换行为模式、交互构成行为模式、外部输入行为模式、外部输出行为模式、时间约束行为模式、功能逻辑行为模式以及数学算法行为模式等方面。

更具体的，在本实施例中通过使用UML语言对各专业软件的功能模式进行分析，描述各软件的关联、依赖、包含的三类关系，通过视图的方式，分析配置项软件的逻辑结构图、典型的运行剖面图，分析配置项软件执行每一项任务的具体方式，包括功能在软件系统中所属层次、涉及的软件组成部分、执行的组织实施方式关注的某个方面特性等内容，确定各配置软件的功能以及对应的实现方式，分解出各配置项软件的功能模式。

步骤S2、获取与软件系统相关软件的历史缺陷数据，经过数据处理后，建立故障数据集合；

采用基于数据挖掘方法，从大量的以往故障数据中，收集整理出故障数据集合，如图2所示，具体包括以下步骤：

步骤S201、数据采集步骤：

所述数据采集内容包含对相关专业软件的历年的故障现象、故障的影响、危害程度、缺陷定位、故障影响、触发方式以及处理措施等方面的数据。所述故障影响包括对于函数级别的影响、对于软件级别的影响以及对于系统层面的影响。

步骤S202、数据预处理步骤：

数据预处理主要是解决数据集中存在一些错误实例的情况，其主要目的是清理数据集中的错误数据，通过核查填写缺损值，平滑噪声数据，识别并删除异常数据，实现对数据质量的维护。脏数据(包含缺损值、噪声数据、孤立点等)对数据挖掘结果的准确性有很大的影响，有时甚至会产生一些误导决策的结果，即通常所说的垃圾入垃圾出。因此，在进行数据挖掘任务前就应该对收集到的数据进行一些针对性的预处理，以此来保证数据质量。

具体的，数据预处理包括以下几个步骤

1)数据分析：数据分析是指从数据中发现控制数据的一般规则，比如字段域、业务规则等。通过对数据的分析，可定义出数据清理的规则，并选择合适的清理算法。

2)数据检测：数据检测是指根据预定义的清理规则及相关数据清理算法，检测数据是否正确，比如是否满足字段域、业务规则等，或检测记录是否是重复记录。

3)数据修正：数据修正是指手工或自动地修正检测到的错误数据或处理重复的记录。

步骤S203、建立故障数据集合

在建立故障数据集合前，还可以通过数据规约删除一些与数据挖掘任务无关或者相关性弱的数据实例或属性，以达到在保证数据挖掘质量的前提下减少使用的数据量的目的。

数据规约的方法主要包括：数据立方体聚集、属性子集选择、维度归约、数值归约、离散化和概念分层产生。数据规约的目的是进步去除冗余属性，简化数据维度，使得后续的数据挖掘过程变得简单一点。

步骤S3、结合所述各配置项软件的功能模式和故障数据集合挖掘与功能模式对应的故障模式，形成故障模式集。

具体的，采用SFMEA+SFTA的方法，从任务流程、交互过程、状态切换、外部输入、外部输出、时间约束、功能逻辑、数学算法等方面，挖掘功能单元、或功能模块之上的软件故障模式，形成故障模式集；

步骤S301、通过SFMEA的方法对各配置项的功能模式所实现的功能进行分析，识别配置项软件中的故障模式，分析故障模式产生的原因及造成的影响，建立SFMEA表格；

具体的，通常的SFMEA方法中可选取遗留缺陷的因子包括：软件类型、功能模块、功能单元、功能点、故障模式描述、故障原因、局部影响、软件级功能、性能故障、系统级影响、严酷度、频繁度、检测难度等。对于遗留缺陷的因子的选取不同以及选取的因子对于缺陷的影响程序不同，对于缺陷的分析结果有着不同的影响。同时，随着因子数量的增多，对于模型的结构越复杂，计算效率和推理过程也变得非常缓慢，有可能会出现状态爆炸的问题。

本实施例中，在缺陷遗留因子的选取上只选取配置项类别和功能模式，作为缺陷遗留因子。鉴于本实施例所涉及的是软件系统各配置项软件的功能模式，即为各配置项软件的功能的全集，由于各配置项软件的功能较为固定，因此，经过分析后，各配置项软件功能模式全集的数量可以根据实现的功能设置为固定的数量，以此有效的解决了状态爆炸的问题。

为更好的实现软件的功能级别的故障模式的提炼，将传统的SFMEA方法进行优化，对传统的SFMEA表进行更新得到本实施例的SFMEA表格。

具体的，本实施例的SFMEA表格具体包括配置项类别、软件单元、功能模式、故障模式、故障类别、故障影响、严酷度类别、改进措施和备注；所述故障影响包括局部影响、高一层次影响和最终影响。

更具体的，在表格中，

(1)配置项类别：为本实施例方法新增的表格项，用于填写软件系统中的软件配置项(CSCI)的类别；通过增加配置项类别作为故障模式分析的要点，可以通过对软件进行分类，更快速进行后续设计缺陷的预测。

(2)单元：将传统SFMEA表格中的单元项限定为在CSCI、CSC或CSU的软件单元；

(3)功能模式：为本实施例方法的表格修改项，通过将功能修改为功能模式，使单元项的主要功能与功能模式对应；将功能模式作为分析的内容，一方面可以更好的归纳总结出某一功能模式对应的全部故障模式；另一方面，可以体现故障模式与功能模式的对应关系。

(4)故障模式：填写与配置项的功能模式有关的故障模式，提炼的为功能层次的故障，而非函数级别与系统级别交叉的内容，所提炼为同一层次的内容。

(5)故障类别：为本实施例方法新增的表格项，用于填写按照功能模式分类的故障类别；包括任务流程、交互过程、状态切换、外部输入、时间约束和功能逻辑类类故障；通过故障类别划分更有利于对故障模式进行提炼，可以根据功能模式，从故障类别的几个方面综合考虑，有针对性的对其进行定位，使故障模式分析的侧重点更为精确。

(6)故障影响：包括局部影响项、高一层次影响和最终影响，其中局部影响项将单元的影响作为局部影响；高一层次影响将对于该配置项软件的影响作为高一层次影响；最终影响将对于系统的影响作为最终影响。

(7)严酷度类别：填写按故障最终影响严重程度确定的严酷度类别；

(8)改进措施：填写根据影响的严酷度等级简要描述改进措施；

(9)备注：主要记录对其他栏的注释和补充说明。

更具体的，在SFMEA表格中增加故障类别，包括以下类别：

任务流程类故障，为会影响软件任务流程的正常运行的故障，在配置项软件故障发生后，软件无法按照软件功能实现所要求的任务流程继续执行。

交互过程类故障，为发生在配置项软件与上位机软件交互过程中的故障，导致软件无法正常按要求执行后续功能。具体的包括由于本配置项软件或上位机软件在软件的具体实现过程中由于未达到软件协议、交互要求等要求发生的故障。

状态切换类故障，为软件无法按照设置的状态切换要求进行切换、状态切换错误，或者状态切换紊乱而产生的故障；各配置项软件在实现相应功能时，需按照其制定的状态进行相应的切换以达到其功能要求，当发生状态切换类故障时，会导致软件功能异常。

外部输入类故障，为外界的输入信息导致的软件未按照预期结果运行而产生的故障；各配置项软件与外界硬件设备、外界系统、以及外界软件会发生交互，由于外界的输入信息导致的外部输入类故障会使软件未按照预期结果运行。

时间约束类故障，为未在规定的时间内、规定的时间间隔、或在规定的时间之后完成软件功能而产生的故障；系统各配置项软件均需按照系统要求，在规定的时间内、按照规定的时间间隔、或在规定的时间之后，完成相应的功能实现；若软件故障发生后，软件无法完成在规定的时间内、规定的时间间隔、或在规定的时间之后完成系统所规定的软件功能。

功能逻辑类故障，为功能未考虑完全、未覆盖到具体实现要求，或者设计逻辑错误而产生的故障。

通过对SFMEA表格项进行新增和修改，将软件配置项类别、单元项的软件单元与功能模式项中模式相对应，将功能模式作为SFMEA分析的内容，归纳总结出功能模式所对应的故障模式以及故障类别；通过这些对应关系，能够更好的分析各配置项软件的功能层级的故障模式，完成各配置项软件的故障模式的提炼，形成系统各配置项软件的故障模式集，在后续的软件设计缺陷核查时，基于故障模式集建立的上述对应关系，可以基于不同维度进行缺陷的核查。

步骤S302、通过SFTA的方法，对现有的故障数据集合进行分析识别出故障模式，将与功能模式相对应的故障树的节或者故障树的叶作为故障模式，作为SFMEA的补充，填写改进的SFMEA表格，完成了SFMEA表作为故障模式集的构建。

具体的，通过SFTA建立故障树的过程包括：

将与功能模式相关的问题现象作为SFTA的顶事件，即故障树的根，通过分析顶事件发生的原因，采用如图3所示的软件故障树的符号，将原因与顶事件相连，作为故障树的节，并进一步分析直至已追溯到导致顶事件发生的全部的原因，将底事件作为故障树的叶，完成了故障树的建立。

由此，通过本实施例的SFMEA+SFTA的方法，一方面，通过对各配置项的功能模式所实现的功能进行分析，识别配置项软件中的故障模式，研究分析各种故障模式产生的原因及造成的影响，另一方面，通过SFTA的方法，将与功能模式相对应的故障树的节或者故障树的叶作为故障模式，补充填写改进的SFMEA表格，完成了SFMEA表作为故障模式集的构建。

利用本实施例方法得到的故障模式集可以用于软件系统的故障预测以及故障核查等具体的应用。

其中，在进行软件设计缺陷核查中的具体方法包括：

步骤1、以故障模式集为基础构建基于文本查询的缺陷核查模型；

具体的，建立过程包括以下步骤：

1)文本预处理：将SFMEA表格中的配置项类别、单元、功能模式、故障模式等内容作为缺陷核查数据集，其中90％作为训练集Training Dataset，10％作为测试集TestingDataset，完成数据的初步过滤工作。

2)中文分词：采用Jieba分词工具，在通用词典的基础上，加入软件故障常见的专业术语描述，构成配置项软件的专业领域词典，在软件故障文本分词时，用于识别描述软件故障的专业词汇。

3)文本特征提取：

首先进行软件故障数据文本特征序列的人工标注；接着使用Word2vec对标注的序列进行词向量的转换，然后搭建软件故障文本特征提取模型，采用训练集训练模型，迭代计算Loss函数进行模型优化，实现文本特征提取。

具体的，搭建软件故障文本特征提取模型为基于Bi-LSTM+CRF的神经网络模型

更具体的，所述模型包含文本标注层、词向量转换层、Bi-LSTM+CRF特征提取层和模型生成层4层。

其中，

文本标注层：首先制定软件故障特征提取的标准和规范。将软件故障文本数据转换为字符串序列，通过BIO标记法按照每个字符所属实体类型进行标记，形成原始语料。

为使计算机识别采用word2vec的Skip-gram模型实现词向量的表示，利用神经网络学习类似word embedding查找表预测概率最大的输出词。

词向量转换层：将系统配置项软件故障预测库的预训练词向量融合得到wordembedding查找表。由前述生成的标记序列，经由word embeding查找表生成对应的词向量的序列。通过迭代训练以及学习更新，输出当前余量最匹配的词向量序列。互连之后，输入至Bi-LSTM+CRF特征提取层。

Bi-LSTM+CRF特征提取层：随机初始化Bi-LSTM层的参数矩阵，将词向量序列输入至LSTM层，加入Dropout机制，输出双向LSTM，输入至CRF层。结合上下文语义信息，对CRF模型进行调参。为提升命名实体的识别率，通过对配置项软件故障特征命名实体全局特征的学习。

模型生成层：对前述模型迭代训练生成的实体序列与标注的实体序列二者进行分析，最小化Loss函数，反复训练调整参数，直至得到最优模型。

4)分类与性能评估

具体的分类是通过SVM分类器，将提取到的文本特征按照故障数据集的对应关系映射到高维特征空间，完成软件故障分类；

性能评估，使用测试集进行测试，对文本特征提取模型的有效性进行验证与评估。

步骤2、在软件系统核查时，通过所述缺陷核查模型将需核查功能点与故障模式相匹配，发现软件系统中的设计缺陷。

具体的，通过缺陷核查模型的分类结果，将匹配到的故障模式进行推送，通过文档审查、代码审查等方式，参照提取的故障模式，完成在软件设计、验证阶段的缺陷核查。

综上所述，本发明采用聚类分析的方法，通过制定固定的因子，结合SFMEA+SFTA的方法，生成的故障模式集合具有专用特性，针对某一特定软件可从软件的功能层面有效预测软件的缺陷，同时基于功能模式，可有效解决状态爆炸的问题，达到优化测试资源分配和提高软件产品质量的目的。

实施例二

本实施例公开了一种用于软件缺陷核查的故障模式集构建系统，如图4所示，包括

功能模式获取模块，用于对软件系统的各配置项软件进行分类，以确定各配置软件的类型；对于各类型的各配置项软件进行执行任务方式归纳，得到各配置项软件的功能模式；

故障数据集合建立模块，用于获取与软件系统相关的专业软件的历史缺陷数据，进行数据处理，建立故障数据集合；

故障模式集构建模块，用于结合所述各配置项软件的功能模式和故障数据集合挖掘与功能模式对应的故障模式，形成故障模式集。

本实施例的具体技术细节和有益效果与实施例一相同，在此就不一一赘述了。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。