卞小磊，周锦永，顾吉青，王 赫，张小盈

（国核自仪系统工程有限公司，上海 200241）

0 引言

软件缺陷是软件产品中存在不足，会导致软件的运行与预期不同。从“软件用户”的角度来看，缺陷泛指一切导致软件无法符合预期目标的东西。根据美国国家标准技术研究所（NIST）发布的研究报告称，软件缺陷或错误普遍存在并十分有害，每年给美国造成的经济损失估计达595亿美元，即约占其国内生产总值（GDP）的0.6%[1]。为了保证软件能够正常运行，对软件存在的缺陷进行有效的分析是十分必要的。软件开发公司和个人必须都积极采取有效的方法，尽可能减少缺陷[2]。

缺陷分析是提高核电厂数字化系统软件质量重要的一环。在三代核电控制系统的开发过程中，控制系统测试工程师会在各个测试阶段发现各种测试问题，然后由相关设计工程师进行修改关闭测试问题。在关闭测试问题的过程中，会相应地在项目管理工具中记录该问题的各个属性，如发现阶段、问题类型等。如何对测试过程中的软件缺陷进行管理跟踪和分析，对减少缺陷数目，提高软件质量有着重大现实意义。

核电厂非安全级控制系统采用分散控制的方法来实现核电厂各个功能的实现。电站控制系统实现多个工艺系统的控制功能，各个系统存在若干设备。在如此庞大的设计任务下，详细设计阶段一般会采用分批次进行系统的组态、测试工作。因此，为了提高软件质量，通过前一批次发现的问题得到相应的经验反馈来指导后面的工作是非常必要的。针对项目中对软件缺陷管理的需要，本文首先论述了软件缺陷概述，常见的缺陷分类分析方法，着重介绍正交缺陷分类（ODC）、根本原因分析（RCA）的基本概念，然后应用该方法对项目内发现的问题进行分类、分析，最后得到了分析结果及改进措施。

1 软件缺陷

软件缺陷是指对软件产品期望属性的偏离，软件没有满足规范以及客户要求，造成用户使用不畅。SW-CMM对其定义是：系统或系统成分中能造成他们无法实现其被要求的功能的缺点。如果在执行过程中遇到缺陷，它可能导致系统的失败。

软件生命周期的各个阶段必然或多或少的存在着缺陷，不同软件开发设计阶段产生的缺陷不同。针对已产生问题的分析研究，可能会发现需求阶段引入的缺陷可能会导致设计出的软件偏离客户需求；设计阶段引入的缺陷可能会导致系统无法实现预期功能，还可能增加测试难度；维护阶段引入的缺陷可能会导致原有缺陷已被修改，但会引入更多新的缺陷[3]。

目前针对缺陷的分类分析方法在核电行业还没有固定的标准，问题分析的目的也大多是为了解决问题，而不是去避免这一问题的再次发生。所以选择一个合适的缺陷分类分析方法成为当前核电厂软件缺陷的准则，成为一项重要任务。

2 缺陷分类及分析方法

2.1 缺陷分类方法

目前核电还没有较为广泛的缺陷分类及分析方法，软件行业较为主流的缺陷分类方法有：GJB-437、正交缺陷分类（ODC）、IEEE软件异常分类标准、Thayer分类法。这些方法各有优缺点，对比见表1。

表1 缺陷分类方法对比Table 1 Comparison of defect classification methods

国家军用标准GJB-437根据军用软件错误的来源将软件错误分为3类，分别为：程序错误，运行程序与相应的文档不一致，而文档是正确的；文档错误，运行程序与相应的文档不一致，而程序是正确的；设计错误，虽然运行程序与相应的文档一致，但存在设计缺陷，可能产生错误[4]。该分类方法能分析软件缺陷产生的位置，该分类方法最显著的特点就是简单。但是正由于分类方法太过于简单，对软件缺陷研究可以进一步提升软件质量的作用非常有限。

ODC分类方法适合缺陷的定位排查以及原因分析，缺陷特征所带来的信息能够为缺陷的预防以及软件质量的提升带来较大作用。IBM一直在改进ODC，使其更加的完善。ODC的缺点是分类的过程比较复杂，过程中的缺陷未做考虑。分类过程中缺陷分析人员会根据主观判断，最终影响分类的属性结果。

IEEE Std 1044-2009.Standard Classification for Anomalies软件异常分类标准对软件异常进行了定义并进行了分类[5]。该分类标准提供了异常数据作为软件异常追踪处理的参考，权威性较高。在软件生命周期的各阶段，该分类标准均提供了较为详细的处理分类描述，分类信息丰富。不足之处在于没有考虑软件工程的过程缺陷，并且分类复杂。

Thayer分类是按照软件缺陷的性质分类，将缺陷的性质作为错误分类的信息[6]。通过这种方法对缺陷先进行初步统计，按照缺陷发生的区域分布情况，对发生错误较为集中的组件进行统一的改进。这种分类方式没有结合分类的过程，不容易分析出发生缺陷的原因，对软件质量的提升改进有限。

综合以上分类方法，本文选取ODC正交缺陷分类法对本核电项目进行缺陷的分类。

ODC（Orthogonal Defect Classification）是IBM Waston Research Center的R.Chillarege等人于1990年提出的缺陷分类方法[7]，经过数年的完善，目前已经得到较为广泛的应用，取得了较好的应用效果。ODC方法适用于多周期、多版本、高复杂度的软件开发过程。ODC提供了一套捕捉缺陷数据关键特性的方案，并就如何对分类的缺陷数据进行分析给出了指导[8]。

ODC分类法将缺陷特征分解为8个属性：发现缺陷的活动、缺陷影响、缺陷触发事件、缺陷载体、缺陷年龄、缺陷来源、缺陷类型和缺陷限定词[7]。ODC中最重要的一个属性就是缺陷类型，缺陷类型被分为7大类：赋值、检验、算法、时序、接口、功能、关联。这些属性中有很多是有目的地反映了产品周期中生成这些属性的阶段。

2.2 缺陷分析方法

将软件缺陷进行ODC分类可以产生较多的定量分析的方法，如统计分析缺陷的来源、统计分析缺陷的分布、统计分析打开/关闭等，事实上项目人员也采用了这些分析方法。数据的分析也可以量化衡量产品质量，作为分析软件可靠性的一种手段，但还需结合定性的缺陷分析方法作为补充。定性分析也能够对一些容易忽略的个别缺陷进行分析，弥补一些遗漏的缺陷原因。定性的缺陷分析方法应用最广泛的为根本原因分析（RCA），其方法在工业和医疗领域应用广泛。

RCA可定义为：使用结构化的过程和方法，识别问题产生的根本原因并制定相应的解决方案，使问题不会重复发生。RCA是一种结构化的缺陷预防技术，它通过分析事件前后的因果关系，目的是能够找到解决措施来消除发现的问题原因[9]。RCA研究是为了找出预防性方法，以消除单一缺陷或者整整一类缺陷。

RCA分为6个不同的步骤和缺陷，依次为事件确定、数据收集、数据分析与评估、纠正操作、通知与应用、遵循测量和报告。

数据分析与评估基本步骤如下：

1） 确保识别了缺陷事件并组织相关数据。

2） 评估其重要性。

3） 确定与该问题直接相关的原因。

4） 确定为什么会存在这些原因，并继续工作，利用“5个为什么”方法和其他方法回溯找到根本原因。

5） 对这一阶段所识别的所有原因进行分类。

通知与应用主要是将纠正操作向上游传递，上游反馈其执行情况的过程。遵循、测量和报告是对整个闭环的数据趋势和模式的分析，最后给出书面结论和建议。

根本原因的优点：在开始时可以开展小型试验分析，然后进行相应发展；对已按照缺陷类型进行分类的缺陷可以批量分析；可能是确定和纠正故障原因的最短路径。

3 缺陷分类应用结果

考虑到核电仪控项目多周期、多版本、高复杂度的特点，软件开发过程迭代较多，不适用于对过程要求严格的IEEE异常分类标准；Thayer分类法无法满足通过缺陷分类来达到改善软件开发过程，缺陷预防的目的也不适用；而对于ODC分类，其分类不依赖于软件过程，对于其分类标准难以把握，可以通过ODC定义本地化的调整来解决。综合比较投入的时间成本以及通过缺陷分析出的原因（产出），本文采用的缺陷分类方法为正交缺陷分类。

根据ODC分类定义，软件设计阶段的缺陷按以下3个阶段、7个缺陷类别进行细分。分类的数据统计见表2。

表2 缺陷分类数量统计Table 2 Defect classification quantity statistics

4 原因分析及纠正措施

对缺陷进行分类和数据统计后，可以对缺陷进行定量和定性的原因分析。定量的原因分析主要用了缺陷分布分析，对各类缺陷在全部缺陷中的占比进行分析；定性的分析采用了根本原因分析的方法，对同一类的问题进行分析，从而得出纠正操作向上游传递。

4.1 缺陷分布分析

下面以某项目核电厂测试阶段发现的问题为例进行分析。在此项目中，厂内测试共分为4层，Level 0层一般为零件测试，由供应商提供；Level 1层为单元测试，软件部分主要是逻辑宏、画面宏的测试；Level 2层软件部分为控制应用软件测试，包括逻辑测试与静态画面测试；Level 3层软件部分为子系统集成测试。下面以Level 2和Level 3层测试阶段所产生的缺陷为例进行分类分析。

4.1.1 逻辑、画面测试阶段

图1为逻辑、画面测试阶段的缺陷分布统计。

由图1项目人员可以得到几点初步结果，如下：

图1 逻辑、画面测试缺陷分布统计图Fig.1 Distribution statistics of logic and picture testing defects

1） 赋值/初始化、算法、接口、功能/类/对象的缺陷密度很大，故先考虑此类型的详细分类，之后对详细分类进行根本原因分析。

2） 由于触发条件的限制，画面测试发现的问题类别较少。故应该增加触发条件，丰富测试用例的内容。

3） 缺陷类型为文档的缺陷不存在，也侧面说明了项目内的输入评审已经较为完善。

4.1.2 逻辑画面集成测试阶段

图2为逻辑、画面测试阶段问题的缺陷分布统计。

图2 集成测试阶段缺陷分布统计图Fig.2 Statistical diagram of defect distribution in integration test phase

由图2，项目人员可以得到几点初步结果，如下：

1） 集成测试缺陷集中最多的依然是赋值/初始化，此类占比例最大的问题是画面与逻辑中的点名不匹配或缺失。

2） 功能/类/对象的问题比例相对于预测试阶段有了提高，所以下一步分析的要点应该为预测试阶段之后发现的此类问题的内容。

3） 接口问题在逻辑中主要来源于I/O的连接；画面中为管道、连接线的问题。

4） 算法问题主要是CFG（Configuration）参数和个别基本功能块的缺失。

4.1.3 缺陷类别总占比

图3为整个测试阶段缺陷分布统计。

图3中的数据可以指导项目人员对缺陷密度较大的几类问题优先进行根本原因分析。比例较小的缺陷类型除考虑详细分类外，应考虑测试规程在测试用例的类型上是否能够更加丰富，增加触发条件。另外，根据缺陷的集群性原则，应对发生错误较多的缺陷类型进行更加完善、严格的测试，使软件的可靠性大大提高。

图3 总体缺陷分布统计图Fig.3 Overall defect distribution statistics

4.1.4 缺陷分类各阶段对比分析

通过各个测试阶段的缺陷类型占比可以得到哪类的缺陷分步比较密集，可以通过原因分析反馈到各个设计阶段，提高软件质量。测试阶段的横向对比可以得到项目人员的测试程度是否达到预期的目标，因此将各个阶段的分类占比和ODC典型占比分布做了比较，用来反馈到各个测试阶段，提高测试的有效性。图4、图5是Level 1～Level 3 3个阶段的缺陷占比的横向比较图和典型分布图。

通过图4、图5的对比和各类问题，可以得到以下几点结论：

图4 缺陷横向对比图Fig.4 Horizontal ccomparison of defects

图5 缺陷类型分布趋势图Fig.5 Defect type distribution trend chart

1） 赋值/初始化：在单元测试（宏测试）阶段开始都应该呈下降趋势，但统计结果显示一直呈上升趋势，导致这一问题的原因是在执行前一阶段时未能严格按照规程执行，导致后面测试还是会出现原来本应发现的问题。

2） 功能/类/对象：测试类型与典型类型趋势大致一样，随着测试阶段的进行，问题逐渐减少。

3） 检查：按照典型趋势，应逐步减少，但实际中逐渐增多，导致的原因可能是宏测试阶段中触发条件较少，之后会根据具体问题深入分析。

4） 接口：趋势与典型趋势一致，在检测各个模块间的接口主要是在逻辑测试阶段进行，故逻辑阶段发现的最多。

5） 算法：趋势与典型趋势一致，随着测试的进行逐步减少。

4.2 产生原因分析及纠正措施

经过事件确定和数据收集，需进行数据分析与评估的问题主要为赋值/初始化，这一类别在宏测试阶段、逻辑/画面测试阶段和逻辑画面集成测试阶段的总占比为54.98%，比例最高。以下以这一类别为例进行分析说明。

第一步：此类问题为赋值/初始化。

第二步：相关数据为前文统计的结果，包括的内容有发现问题的阶段、解决方案、引入阶段等。

第三步：赋值/初始化此类问题发生后影响逻辑与画面集成，无法达到控制和显示要求，直接影响了软件的功能，重要性高。

第四步：产生该问题的直接原因是逻辑/画面组态中参数填写错误。

第五步、第六步：通过“5个为什么”分析，将得出的参数填写错误的原因进行了归类整理如下：

技术原因包括：①画面宏参数未完全按照组态规范实施；②测试规程中未列出点名检查清单。

技术管理原因包括：①逻辑组态中间点未有效管控；②培训未覆盖点命名规范。

根据其原因可以得到第4个步骤纠正操作的具体内容。纠正操作也分为技术上和技术管理上两个部分：

技术上：在控制逻辑测试规程中详细列出点名检查清单。

技术管理上：①对组态规范实施进行统一培训；②共享管理服务器内建立中间点管理库，规范点命名管理；③对点命名规则进行统一培训。

5 结论

基于ODC缺陷类型方法在工程实践中的应用，按照此方法进行缺陷的分类、量化问题，进而通过缺陷分布分析对缺陷进行量化的分析，得到改进的措施。对于部分分布比例较大而且严重程度较高的缺陷使用了根本原因分析的方法，对此类缺陷进行定性分析，得到改进的措施，弥补了通过缺陷分析来得到技术、管理等方面的经验反馈这一空白。

后续可以从两个方面深入研究，一是ODC方法，尝试应用ODC中的其他属性，如分类属性中的缺陷触发（Triggers）、缺陷影响（Impact），可以更加丰富数据多样性，进而得到更多反馈信息。其次，对后续组态测试问题进行缺陷分析并做横向对比，通过数据分析来给出建议。