基于功能路径的软件可靠性评估方法

邵明正，齐剑锋，韩 震

SHAO Mingzheng1,QI Jianfeng1,HAN Zhen2

1.军械工程学院 信息工程系，石家庄050003

2.军械工程学院 装备指挥与管理系，石家庄050003

1.Information Engineering Department,Ordnance Engineering College,Shijiazhuang 050003,China

2.Equipment Command and Management Department,Ordnance Engineering College,Shijiazhuang 050003,China

1 引言

软件可靠性直接关系到计算机系统乃至更复杂的系统能否在给条件下完成指定任务，不可靠的软件引发的失效可能给软件的使用者或者软件开发人员带来灾难性的后果。软件可靠性的重要性不言而喻，其相关理论也得到了快速的发展。

广泛意义上的可靠性工程发展至今已经有了完善的理论体系及有效的工程实践方法，相比之下，软件可靠性工程还处于初级阶段，尚有大量的问题需要研究。软件可靠性的理论及方法最初源于硬件的可靠性[1-2]，不可否认这种一致性有利于软硬结合系统的可靠性综合评估，但是软件的固有特性及其与硬件之间的本质差别又决定了它与硬件可靠性的差别。将软件可靠性理论完全建立在硬件的基础上并不能从根本上解决软件可靠性相关的问题。软件与硬件本来是同一层次的概念，其可靠性理论应该有各自的基础，目前软件可靠性大部分的评估方法并不没有充分考虑软件产品的特点，而只是从宏观的角度去描述，其估计方法也难以为用户理解使用。

软件可靠性工程是一项系统性的工程，对可靠性的分析贯穿于软件开发使用的各个阶段[2]，而用户关心的主要是产品运行阶段的可靠性，此阶段的可靠性不呈现出增长特性。本文基于这样的思考，首先分析了软件与硬件可靠性的区别，指出了软件失效与硬件故障本质上的一致性；然后从用户的角度出发，提出了一种基于软件功能路径的可靠性评估方法，并分析了时间因素在软件可靠性中的影响；最后给出了这种评估方法的工程应用步骤。

2 软件可靠性与硬件可靠性

可靠性的概念经过了很长时间的争论，虽然现在没有一个普适的定义，但是以下的定义方式，却是为大多数人认可的：产品在规定的条件下和规定的时间内，完成规定功能的能力[3-4]。最初的可靠性理论是以硬件为研究对象的，显然软件可靠性的定义继承了硬件可靠性的理论体系，但是二者还是有着本质的区别的。

2.1 软件与硬件可靠性的区别与联系

2.1.1 软硬件可靠性之间的区别

由于软件与硬件在固有属性上的不同，二者之间的可靠性有本质的区别，具体的表现形式有很多，但原则性的差别归纳起来主要有四个方面，见表1。

从二者的区别可以看出硬件可靠性是对时间敏感的特性，但是在软件可靠性上过分强调时间因素的作用是不符合软件特征的。考虑一个极端的例子：软件操作界面只有一个按钮，点击这个按钮不会引起软件故障，且各次单击之间没有任何联系，那么可以预见无论点击这个按钮多长时间，软件的可靠性也不会发生变化，始终为1，但是如果是一个键盘上的物理按键，那么该按键的可靠性就与时间有很大关系了。

2.1.2 软硬件故障产生的一致性

产品的故障如果不进行处理，就会影响其功能的实现，也就是产品发生失效[3]。为了简化讨论，本文主要使用“故障”一词进行论述，暂不考虑故障出现后的处理。尽管软件和硬件在失效的根源上是不同的，但是它们发生故障的本质却是一致的，即运行状态触发了产品存在的缺陷，其关系如图1 所示。这里的缺陷可能是设计时的错误，也可能是在使用过程中产生的缺陷。而运行状态可能与时间有关，也可能是无关的。仍然以上述的例子加以说明：假如单击按钮的次数会被记录下来，如果次数超过1 000 次就会产生数组下标越界的错误。在这里，软件就存在一个数组下标越界的软件缺陷，而单击第1 000 次时的运行状态就会触发这个缺陷，产生故障。对于硬件按钮来说，也许按钮本身没有设计缺陷，但是随着时间的流逝，按键弹片发生了锈蚀，这是在使用过程中产生的缺陷，达到它的强度寿命再按下这个按钮，就会引起产品故障。

图1 产品故障产生的一致性

就软件而言，运行状态触发缺陷的直接原因是由软件的操作所引起的[5]，而硬件运行状态的变化除了使用操作，还包括时间对硬件性能造成的影响。图2 表示了软件故障产生的根本过程，将软件看成是从输入空间到输出空间的一种转变过程。对软件的操作就是通过不同的输入数据来改变软件的运行状态，以期实现正常的功能，而有些输入可能会激活隐藏在软件中的缺陷，从而产生故障。

图2 软件故障产生的过程

2.2 软件可靠性评估方法分析

对软件可靠性的评估一般是根据软件可靠性数据以统计方法给出软件可靠性的估计值或预测值[6]。目前已经开发出近百种方法用于可靠性的评估，而且新的方法还在不断发表[7-11，16]。根据数据对象的不同，评估方法可以分为动态分析方法与静态分析方法。动态分析方法在时间因素的基础上分析软件失效的时间与失效的次数。静态分析方法不考虑软件运行的时间因素，这类方法可以进一步分为缺陷播种、基于数据域和基于经验的方法[5]。表2 列出了几种典型的软件可靠性评估方法，表中“√”表示隶属关系。

表1 软件与硬件可靠性的主要区别

表2 典型软件可靠性评估方法

目前的软件评估方法与软件实际存在较大差异，由于各种评估方法都有一定的假设前提，比如假设故障排除是完全独立的，并不会引起新故障的产生[12]，这就限制了评估方法的使用范围和有效性。不同的软件类型、同一软件不同的开发阶段往往需要采用不同的评估方法，到目前为止，并没有一种普适的软件可靠性评估方法[2]。由于软件本身的特性以及获取有效的可靠性评估数据方面的困难，实现完全反映软件可靠性的方法非常困难。通过2.1 与2.2 节的分析可知，软件可靠性从本质上体现的是一种静态特性，软件本身并不会随时间而变化，所以本文认为分析其可靠性应当从软件自身的属性出发，研究其在不同触发条件下的运行结果，进而结合统计特征计算软件的可靠性。

3 基于功能路径的可靠性评估方法

通过上述的分析可知，产品故障的本质是运行状态触发产品中的缺陷，而软件故障产生的本质与其是一致的，为了更为清楚地描述软件的故障本质与其可靠性，从面向用户使用的角度出发，提出一种便于用户理解和使用的软件可靠性的概念。

3.1 基本概念

定义1（运行状态）软件在运行过程中，所占有的资源处于不同状态，称为软件不同的运行状态。其中资源可以是内存、硬盘、外设等计算机资源。

定义2（操作）使软件的运行状态发生改变的输入，并且对它的处理与其他操作有显著的不同。操作的发起者可以是用户、系统本身或外部系统。

定义3（路径）完成某个功能的一系列操作。

对于操作的概念，处理上明显的不同是指操作作为一个实体，包含的错误在其他操作中是很难出现的。对于一个操作可以有不同的输入，但这些输入只属于一个操作。表3 说明了功能、路径与操作之间的关系。一个功能可能有多条路径实现，比如功能F2可通过R2、R3两条路径实现。而一个操作可能在不同路径中出现，如操作O21分别应用在路径R2、R3中。一个软件在功能上是有限的，实现功能的路径也是有限的，但是操作中的输入却可能是无限的，这就导致了在软件的系统测试中不能实现穷举测试。

表3 功能、路径、操作三者之间的关系

把软件的运行抽象为由节点和路径组成的一个网络，如图3 所示，其中节点代表软件不同的运行状态，而路径则表示运行状态的转移，即一系列操作。软件功能的实现就是按照不同的路径，达到期望的运行状态。软件出现故障的原因是某些路径会触发软件固有的缺陷，当软件状态的转移遇到了这些路径，便会发生故障。

图3 软件运行状态转移

3.2 评估模型

为了清楚地讨论，可以从两个方面来说明软件可靠性这个概念，从定性的角度来讲，软件的可靠性可以用其他定量指标来度量，比如软件可靠度、失效强度、平均故障间隔时间等[13]；从定量的角度来讲，可靠性本身也可以作为一个定量的指标，比如IEEE对其做出的定义[1]。本文将软件可靠性和软件可靠度作为不同的定量指标来描述。

根据软件可靠性的特点，可以将软件可靠度描述为软件从输入数据计算出正确的输出数据的概率[14]。

由该定义导出它的数学描述：设非空集合D为软件的输入空间，D′为输出空间。将软件P看作D上的函数，P*为功能期望函数，则P，P*:D→D′。让Pr为D上的一个给定的概率分布。当输入变量为xi时，软件P在概率分布Pr下相对于功能期望P*的可靠度定义为：

如果软件的各次输入是相互独立的，则软件在进行n次输入后的可靠度为：

实际情况要复杂得多，因为软件的各次输入之间不能是完全独立的[15]，它们之间可能有着各种各样的联系，输入的选取也可能是按照一定的顺序。而且这样理论上的表达并不能应用于工程实践。因此，以此为基础，借助于路径、操作的概念建立一种更易理解和使用的可靠性度量方法。

对于用户来讲，软件在运行上是以完成某些功能为目标的，因此基于用户的功能需求，通过建立路径的概念来分析软件的可靠性。其基本思路如下：

（3）路径Ri是一个包含有限个元素的操作序列Oi={Oij|j=1，2，…}，这些操作是根据功能需求按照一定的顺序选取的，且各路径操作的个数不相等。

（4）由于软件S 本身存在缺陷，某些操作Oe的执行会触发这些缺陷，路径不能完成，影响了软件功能的实现，即产生软件故障。这些不能完成的路径称为故障路径。

一条路径Ri的完成或产生执行故障的过程，称为软件S 的一次运行。在实际工作中，用户往往不会均匀地选择路径，而是有的路径被选择的概率大，有的路径被选择的概率小。这种特定的需求用概率分布pi来描述：pi是路径Ri从集合R中被选中的概率。路径Ri执行的结果取决于其中操作的结果，更深刻地，操作的结果由操作所涉及的输入决定，由于输入的不确定性，操作是否产生故障是随机性的，所以路径是否是故障路径也是有概率的。为了计算软件运行的故障率，定义路径故障概率yi，它表示路径出现故障的可能性。

软件运行一次出现故障的概率p等于所选路径出现故障的概率，即

式中，Rel1表示软件依概率分布pi从R 中选择一条路径正确运行的概率，即为运行一次的软件可靠性，也就是软件可靠度。那么，软件连续运行s次的可靠性为：

接下来考虑，路径故障概率yi的确定。一条路径是一个工作序列，路径中只要有一个操作出现问题，则整条路径就是故障的路径。如果路径Ri中包含k个操作，操作出现故障的概率用Bij来表示，则路径能成功运行的前提是所有的操作不出现故障，路径故障概率yi可写成如下表达式：

于是，软件可靠度为：

3.3 时间因素影响分析

时间对于硬件的影响不仅体现在对硬件的操作上，更重要的是它影响了硬件本身的理化性能。而时间对软件的影响仅仅体现在操作上，对已经发布的软件系统本身没有影响。

3.3.1 可靠性影响因素分析

软件可靠度是软件正确运行一次的概率，从公式（7）中可知，影响软件可靠度的有：路径选择的概率分布pi、操作结果Bij、路径数目n及操作数目k。这些因素都是软件本身所固有属性，并不随时间而产生变化。

而软件可靠性在一段时间内表现出的是一种累积结果，它是软件按照功能要求在若干次运行内一直保持正确运行的概率。从公式（5）和公式（6）中可以看出，影响软件可靠性的主要因素有四个：路径选择的概率分布pi、操作结果Bij、路径数目n及软件运行次数s。其中，Bij和n是由软件本身所确定的，而pi和s则是由用户使用所决定。同样，时间因素对于软件可靠性并无直接的影响，但是它与运行次数s有一定的关系。

3.3.2 软件可靠性与时间的关系

软件可靠性中的时间更具体的分为执行时间和日历时间，日历时间更容易为普通用户所理解[3]，因此以日历时间作为研究对象，设Δt表示软件运行一次的平均时间，那么软件运行s次的总时间t=sΔt。则，

图4 显示了软硬件可靠性、可靠度与时间的关系。图4（a）（c）说明软件与硬件在一段时间内连续无故障运行的概率都是随时间而降低，这是概率累积的结果。但是在可靠度方面，软硬件分别表现出了不同的特点。图4（b）图表示软件可靠度不随时间而变化，在任意时刻，软件独立运行出现故障的可能性从统计上来讲都是一样的。而硬件在其寿命的不同阶段性能会发生变化，呈现出不同的可靠度。比如硬件在磨合期与正常运行期出现故障的概率是不同的。

图4 软硬件可靠性与时间的关系

软件在使用期间，更能为用户所理解的时间概念是使命时间[16-17]，也就是在特定的时间内完成特定的任务，后一阶段的任务是前一阶段的重复，比如飞机导航控制软件，它的任务随着飞机的每次飞行而呈现阶段性的重复，每次飞行时间就可以看作是软件的使命时间。在软件的整个生命周期内，不考虑软件的升级维护，软件的可靠性会随着使命时间呈现出周期性的变化，如图5所示。

图5 软件使用周期内的可靠性变化规律

4 软件可靠度测试

确定软件可靠度，需要对软件进行可靠性测试，以获得相应的失效数据，按照一定的评估模型通过概率统计的方法估计出软件可靠度。测试策略分为代表性随机测试和非代表性随机测试两种[13]，本文所提出的模型适用代表性随机测试的策略。

4.1 软件可靠度的测试流程

在实际应用中，基于功能路径的可靠度评估方法可以按照：功能→路径→操作→输入的顺序来分析软件可靠度。由公式（7）知，验证软件可靠度需要如下的数据：路径选择的概率分布pi、操作结果Bij、路径数目n及操作数目k。路径选择的概率分布pi可以根据功能区分来确定；操作结果Bij则需要分析操作的输入空间，通过测试来估计；路径数目n及操作数目k可以根据软件的具体构成得知。测试流程如图6。

图6 基于功能路径的软件可靠度测试流程图

根据软件实际情况确定每条路径对应的操作序列，根据各操作的输入空间，制定覆盖全面的测试用例。执行测试之后，利用统计出的失效数据，由公式（7）计算出软件整体的可靠度。

4.2 确定操作故障率

路径选择的概率分布pi、路径数目n及操作数目k可由开发、测试人员通过分析软件功能和开发文档得到，所以如何确定每个操作的故障率Bij是重点。由于操作涉及的输入数量巨大，甚至是无穷的，所以确定操作的故障率需要采用统计分析的方法进行估计。

确定某一操作的故障率的步骤：

第一步：假设该操作的输入数量总数为N个，根据操作输入空间的大小，依等价类划分策略从输入空间中选取n个输入。

第二步：针对每一输入设计相应的测试用例。

第三步：根据测试用例将软件进行n次操作，则必定会出现有的输入产生正确的输出，有的输入导致运行故障，每次出现故障时都不排错，只收集故障数据。

4.3 实例验证

以某系统指控软件的文电子模块为实验对象，该模块设计可实现27 项子功能，依据不同的操作方法，功能实现路径有49 条，每条路径由不同数量的操作组成。按照4.2 节所述方法，为每一操作制定测试用例[18]，测试并记录运行结果。部分功能路径测试结果如表4 所示。

依公式（7）及表3 的数据，可计算出软件可靠度Rel1=0.990 4，为了验证扩展模型的性能，将数据进行转化并结合所记录时间因素，利用著名的时间域模型J-M 模型求得该子模块的缺陷个数为41 个，可靠性Rel=0.932 5。由于本方法对时间因素理解上的不同，使得测试结果与传统方法有一定出入。从计算过程可以看出，本方法能较为直观地得到软件可靠度，对于衡量软件本身的可靠程度有一定的参考价值。

表4 部分测试结果

5 结论

软硬件固有属性上的差别决定了它们可靠性理论的不同，本文提出的基于功能路径的可靠性评估方法，从软件故障产生的根源出发，利用路径、操作和输入的概念阐述了软件可靠性度量方法，该方法具有良好的理论基础，面向用户操作，层次清晰、便于使用，适用于软件使用阶段的可靠性验证。另外，本方法要求测试人员对于软件的功能路径要有清晰的把握，了解用户的使用习惯，如何合理地确定路径选择的概率是下一步研究的重点。

[1] 尚珊珊，赵轶群.软件可靠性综述[J].软件导刊，2006，2（8）：3-5.

[2] 孙志安，裴晓黎.软件可靠性工程[M].北京：北京航空航天大学出版社，2009.

[3] Musa J D.软件可靠性工程[M].韩柯，译.北京：机械工业出版社，2003.

[4] 陆文，徐锋，吕建.一种开放环境下的软件可靠性评估方法[J].计算机学报，2010，33（3）：352-361.

[5] Munson J C.Software faults，software failures and software reliability modeling[J].Information and Software Technology，1996，38：687-699.

[6] 孙志华.面向多用户软件可靠性评估和测试方案研究[J].计算机工程与科学，2004，26（1）：70-72.

[7] Wang W L，Pan D，Chen M H.Architecture-based software reliability modeling[J].The Journal of Systems and Software，2006，79：132-146.

[8] Crespo A N，Jino M.A binomial software reliability model based on coverage of structural testing criteria[J].Empire Software Eng，2008，13：185-209.

[9] 楼俊钢，江建慧，靳昂.考虑软件不同失效过程偏差的软件可靠性模型[J].计算机学报，2010，33（7）：1263-1270.

[10] 樊林波，吴智，赵明.基于构件的软件可靠性分析[J].计算机科学，2007，34（5）：266-268.

[11] 李海峰，王栓奇，刘畅，等.考虑测试工作量与覆盖率的软件可靠性模型[J].软件学报，2013，24（43）：749-760.

[12] Ferneda E，Cornelio N N，Filho A H.Prediction of software quality based on variables from the development process[J].Lecture Notes in Computer Science，2013，7828（1）：78-87.

[13] Jung H，Hong S.The quality control of software reliability based on functionally reliability and usability[J].Lecture Notes in Computer Science，2012，7709（1）：119-126.

[14] Palviainen M，Evesti A，Ovaska E.The reliability estimation，prediction and measuring of component-based software[J].Journal of Systems and Software，2011，84（6）：112-129.

[15] 朱鸿.软件可靠性估计与计算复杂性的关系浅析[J].软件学报，1998，9（9）：713-717.

[16] 韩峰岩，覃征，王昕.一种考虑数据截尾的非参数软件可靠性模型[J].西安交通大学，2006，40（6）：667-671.

[17] Huang C Y，Lin C T.Software reliability analysis by considering fault dependency and debugging time lag[J].IEEE Trans on Reliability，2006，55（3）：436-450.

[18] 张旭.基于使用剖面的软件可靠性测试用例生成方法[J].计算机仿真，2009，26（12）：66-69.