软件可靠性及其验证
国防科工委可靠性工程技术中心 何国伟
本期专题: 软件的可靠性
目前,软件在系统中所处的地位越来越重要。众所周知,系统中的硬件有可靠性指标的要
求,并必须经过验证。但如果系统中软件没有可靠性指标要求,或不要求验证,那么整个系统
的可靠性仍是没有保证的。目前,由于软件可靠性原因而造成的灾难性事故时有发生。为此
,本期专题将集中介绍软件可靠性的有关问题,包括如下内容:
1.软件可靠性及其验证
本文在回顾了软件可靠性发展历程的基础上,介绍了一些重要的软件可靠性指标及其验
证方法,并结合我国软件工业发展的实际,提出了我国应该如何合理地制定一些软件可靠性指
标。
2.软件容错与软件故障树技术的结合使用
本文介绍了在软件系统方案研究、设计及编码、测试等各阶段如何将软件容错技术与软
件故障树技术结合,开发出了高可靠性软件系统。
3.软件可靠性工程实践
如何保证软件的可靠性已成为一项重要的工程内容。本文介绍了一种在实际中实施软件
可靠性工程的方法。
4.软件可靠性测试
进行软件可靠性测试的目的是正确估计软件产品的可靠性。本文介绍了软件可靠性测试
的基本概念、应注意的问题和具体的测试步骤。
5.航天控制软件的可靠性工程管理
本文分析了目前航天控制软件可靠性工程管理存在的问题,针对这些问题,提出了一些软
件工程化管理、软件预先分析及可靠性度量的设想,旨在促进航天控制软件可靠性工程管理
的系统化、规范化。
本期专期责任编辑 刘学习
一、引言
当前,软件的可靠性问题已经暴露得相当突出。欧洲空间局发射的阿丽亚娜5号火箭由于
软件故障造成损失数亿美元。国内也出现了由于软件故障损失数以百万计的事故。凡此种种
,已不胜枚举。
作者曾与美国宇航局的友人就软件可靠性交换过意见。根据美国宇航局的经验,他们的
软件可靠性大体上比硬件低一个数量级。而美国宇航局的软件是严格按软件工程组织的,承
担软件开发的单位都要经受美国SEI(软件工程研究所)规定的五级标准考核。因此,我们的软
件可靠性水平大体上也不会比硬件高,这是一种符合情理的估计。
现在愈来愈多的民用、军用系统采用了愈来愈多的软件。硬件有可靠性要求,并且要求
验证,例如按我国军标GJB899考核验证硬件是否达到MTBF(平均无故障时间)的最低可接受值
。但是,国内对软件基本上还没有提出可靠性指标,也不要求验证。这样,由于软件的可靠性
无法保证,因此即使硬件的可靠性达到了要求的指标,但整个系统的可靠性仍无法保证。这种
状况显然与对民用、军用系统的需要是不适应的。对软件不提可靠性指标,对提高软件的可
靠性没有动力;而对提出的指标不要求验证,对软件开发单位没有压力。因此,对软件提可靠
性指标的关键不是提多少,不是模仿硬件可靠性那样去分配到元器件,而首先是如何验证。
美国国家标准ANSI/AIAA R—013 1992《推荐的软件可靠性的实践》指出"最合理的软件
故障率的可验证要求大约在10-4/h左右",亦即MTBF在1万小时左右。我国的软件开发水平低
于美国,因此软件的MTBF宜定在1000小时到10000小时之间,这应该算是一个先进的指标。
软件可靠性当前最重要的指标是MTBF指标。其它的指标还有待进一步探讨,例如硬件有
MTTR(平均维修时间)指标。但对软件而言,使用者一般不应自行修改软件,在没有严格配置管
理下的软件修改很可能愈改愈糟。一般情况下,软件出现故障后由原开发单位修改,还必需经
过大量的必要的回归测试后才能再交付使用,而这一段时间往往相当长。因此,如何确定MTT
R就是一个有待很好探讨的问题。本篇谈的可靠性指标暂且只局限于MTBF。
二、软件的缺陷、故障、故障率及平均寿命
国内不少人对软件可靠性的基本概念还是不太清楚。因此本文先澄清一些基本概念。
从提出软件产品的任务开始到产品不能使用为止的时间叫软件的"生存周期"(即"寿命周
期")。在软件生存周期的各个阶段,人的行动会使软件在一定条件下不能或将不能完成规定
功能。例如:
·用户提出的需求是不完整的。
·软件生产单位误解了用户的需求。
·软件生产单位没有完全实现用户需求。
·软件生产过程的下一道工序没有完全实现上一道工序的要求。
·适用的算法或判别逻辑不正确或不完整。
·人为疏漏等。
上述种种人的行动使软件存在出现错误的根源,这叫"缺陷"。
一个软件可能存在若干个缺陷。但是软件执行一次任务时并不总是用到所有的程序组成
部分,如果未用到有缺陷的部分程序,则软件仍能正确完成任务;如果在执行一次任务时要用
到有缺陷的部分程序,则软件或软件的一部分输出就与规定的不符,即出故障(Fault)。所以
出故障是缺陷所在的程序通路被敏化而在此特定条件下的暴露。
软件的组成部分在执行任务中被用到的频率是不尽相同的,有些部分被频繁地用到,有些
部分则极少被用到,亦即不同缺陷引起故障的可能性是不尽相同的,并且可以有几个数量级的
差异。
对于某一个软件缺陷来说,软件执行任务而出一次故障的平均时间叫这一缺陷的平均寿
命MTBF,记为θ。其倒数记为λ=1/θ,叫作这个缺陷的故障率。
美国的E.N.Adams曾在1984年的IBM研究开发杂志上,对有代表性的9个IBM软件产品的缺
陷作了统计。他将软件缺陷分为八档,每档MTBF的代表值为(单位年):
1.58, 5, 15.8, 50, 158, 500, 1580, 5000
第i档的MTBF代表值为θi,该档的总缺陷数为di,于是软件总缺陷为
@@16103000.GIF;公式1@@
第i档的总缺陷数占软件总缺陷数的百分比为 ri=di/d,第i档缺陷的总故障率为λi,软
件总故障率为。
@@16103001.GIF;公式2@@
第i档缺陷的总故障率占软件总故障率的百分 比为fi=λi/λ,如表1所示。
@@16103002.GIF;表1 Adams统计表@@
从统计表中可以得到一些重要概念:软件缺陷的故障率可以相差3～4个数量级;故障率高
的大缺陷数少,故障率低的小缺陷数多;极少数故障率高的大缺陷(例如占总缺陷数39%的1、
2、3档缺陷)占了总故障率的绝大部分(上述三档占总故障率的72.5%)。
因此,软件的缺陷数与软件的故障率无直接关系。
如果对用户交付一个软件,并说还有10个缺陷,那么用户是不放心的。因为如果还有十个
第一档的缺陷,则可能一、二个月就会出故障。反之,如果是第8档的平均5000年出一次故障
的缺陷,则有100个也可安心接受。
因此对用户来说,他最关心的是:"不论你交付的软件有多少个缺陷,它们总的MTBF或λ是
多少?"
三、软件各种缺陷故障率的Pareto图
设一个软件的若干缺陷按其故障率的大小从大到小依次排列为:λ1≥λ2≥λ3≥……
从理论上来说,可以把诸λ排成Pareto图,其示意如图1所示。
@@16103003.GIF;图1 软件缺陷故障率理论上的Pareto图@@
对硬件来说,这种Pareto图不仅理论上存在,而且还可以通过可靠性预计得到。每个电子
设备组成件的故障率可以通过GJB299-A(国产)及MIL-STD-217F(进口)查算出来。但对软件来
说,缺陷的故障率是无从估算的。
如电视机有一个故障率的Pareto图,其中显像管的高频头故障率最高,但除了几个故障率
高的组成部分外,其它如集成电路、电阻、电容元件等的故障率都很低。而别的电子产品却
是另一种规律。不同的电子产品硬件的Pareto图可能很不相似。硬件的Pareto图没有统一的
规律。
对硬件来说,客观存在且可以预计的Pareto图并不存在可以外推的规律。例如电视机有
五个较大故障率的故障,但从第六个起,故障率就大幅度下降。因此得到连续五个大故障并不
能外推出第六个故障是较大故障!
比起硬件设计来,可靠性设计技术远远不成熟的软件,有什么理由说有λi=Φβi-1等规
律存在呢?
@@16103004.GIF;公式3@@
客观上软件存在一个Pareto图,但一个软件一个规律,适合于这个软件的规律不见得适合
于另一软件。另外,适合于前几个缺陷故障率的规律不见得能外推到以后的故障。
如果说软件故障率存在一定规律,那就是:在t=0时,软件的故障率是
@@16103005.GIF;公式4@@
到t=t1时,出现第一个故障,排除相应的缺陷后,故障率降为:
@@16103006.GIF;公式5@@
@@16103007.GIF;图2 λ(t)-t图@@
因此,λ(t)是一条阶梯形下降的折线,如图2所示,这是一个普遍规律。
有的作者提出,在排除软件缺陷的过程中,可能出现新的缺陷,甚至是故障率很大的缺陷
,于是λ(t)还可能反弹。因此假设了有一个反弹概率及反弹率的概率分布,致使λ(t)模型极
其复杂。然而,从工程实际看,在严格的配置管理下,引入新缺陷可以立即被判断出来,不会出
现一个反弹。
四、故障率λ(t)的测试及估计问题
设软件的故障率为λ,相应的平均寿命为θ,并设软件于t=0时投入运行,到t=T时出现故
障,则T是指数分布的随变量,它的累积分布函数为:
@@16103008.GIF;公式5@@
如果软件投入运行,一出现故障就排除相应的缺陷再投入运行,则再投入运行时的故障率
已经下降。亦即相应于故障率λ,只有一个测试数据T。根据上述统计规律,可得:
T有80%的概率落在(0.105θ, 2.303θ)之间;
T有90%的概率落在(0.0513θ, 2.996θ)之间;
T有95%的概率落在(0.0253θ,3.689θ)之间。
由此可以看出,T值波动二、三十倍还算正常。这是因为T的标准偏差σ等于均值θ,亦即
波动远远超过真值。
如果软件在运行过程中,一出故障就排除缺陷再投入运行,则λ(t)变化为:
λ(0)→λ(t1)→λ(t2)→……
但对每一个λ(ti)只有一个测试数据,而测试数据的误差又有较大的波动,因此企图从测
试数据估计出较精确的λ(t)规律是不可能的。
从上述统计分析看,对每一个λ(ti)而言,其测试值ti+1-ti是一个很粗糙的量值,有些作
者企图用模糊数学来描述。即使要用模糊数学描述,其隶属函数也不是一般的三角图形函数
,更不是正态分布函数,而是散布极宽的函数,用模糊数学处理是得不出多少有实用意义的成
果的。
五、软件运行剖面及可靠性数据
软件有种种可能的输入,各种可能输入的出现概率并不相同。因此软件的可能输入值要
与出现概率联系起来。例如一个生产控制软件,正常情况下的出现概率较大,异常情况下的出
现概率一般较小。软件的一组可能输入构成输入空间的一个点P。这些P点的全体为输入空间
S。在S上,定义一个概率密度函数f(p)。
设G是S的一个子点集,则输入点P落在子点集G内的概率为:
P = ∫g f(p)dp
{S,f(p)}叫软件的"运行剖面"
软件使用方必须明确软件的运行剖面,这里既包括软件的正常情况下的输入,也包括
可能的非正常输入。软件的需求包括在正常输入下应该得到正常输出,也包括在可能的非正
常输入下应该有正确反应。例如空间卫星上用的计算机软件,它的正常输入是根据各种先前
的卫星状态信息、当前的传感器测得的数据、地面或宇航员传来的指令和信息,来控制卫星
。
但是由于宇航空间的重粒子轰击,可能使计算机的存储器中的数码产生0与1的突变。这
是可能的不正常输入,对此软件需要作出既定的正确响应。
软件的一个缺陷Di只影响S中的一个点集Gi,当输入点P∈Gi,则缺陷Di使软件出故障,其
概率为
@@16103009.GIF;公式6@@
相应故障率为λi。设诸λi相应的故障域Gi是相互独立的,则
@@16103010.GIF;公式7@@
λ(t)=Σλii(t)。
必须注意,软件的可靠性是规定条件下的可靠性,即实际运行条件下完成任务的可能性。
如果不是实际运行条件,那就不反映真正的可靠性。
举一个极端的例子,如果用一个运行正确的例子,反复输入几千次,那永远是正确的,但这
并不反映软件有高可靠性。正因为如此,不少软件在鉴定时,只用不多的几个测试用例演示一
下就算通过,这说明不了多少可靠性。就算通过了一百个测试用例,也不能说明其可靠性是高
的。"只有在按运行剖面随机输入条件下,软件的故障率才能正确反映软件的可靠性"。
因此软件的可靠性只可能在两种情况下取得:软件在实际运行下统计得到的故障率;软件
在模拟实际运行条件下的随机输入测试下统计得到的故障率。
由于不应把未经充分测试的软件交付现场运行,因此软件在交付前必须在模拟实际运行
条件下用大量的随机输入点作测试用例,来考核软件,统计其故障率,并以此作为可靠性评估
的基本数据。
按照软件工程进行的软件白盒子等测试的统计故障率也不能作为可靠性评估的依据。白
盒子测试等是提高软件可靠性的重要手段之一。但白盒子测试不是按运行剖面随机测试,从
而统计数据不反映可靠性。例如白盒子测试的语句覆盖率达100%,都正确,但并不能说明软件
的可靠性就很高了。有的较严格的白盒子测试要求分支覆盖率为85～95%,程序路径覆盖率为
60～80%。即使这些控制的分支、程序路径都正确,也不能保证已达到了很高的可靠性。
因为毕竟只覆盖了一部份,也许在未覆盖的部分仍存在着故障率很高的缺陷。软件工程
中的种种测试是提高软件可靠性所必需的,但其统计数据并不表示软件的可靠性。
为很多软件模型研究者引用的NTDS软件数据是一个典型,它在开发阶段有26个数据,在测
试阶段有5个数据……。不少作者把这些数据作为可靠性评定用的数据。实际上,这是不正确
的。
六、软件的可靠性验证试验
在按运行剖面随机输入的条件下,软件的可靠性为指数分布。这样软件的可靠性验证试
验可以引用GJB899(或MIL-STD-781D)《可靠性鉴定与验收试验》。
软件MTBF的目标值(Goal)是软件期望达到的使用指标。
软件MTBF的门限值(Threshold)是软件必须达到的使用指标。
软件MTBF的规定值(Specified Value)是软件研制任务书或合同中期望达到的合同指标
。它是承制方进行软件可靠性设计的依据。规定值依据目标值来确定。
软件MTBF的最低可接受值(Minimum acceptable value)是软件研制任务书或合同中规定
的必须达到的合同指标,它是进行验证的依据。规定值依据目标值来确定。
MTBF的检验下限θ1是最低可接受的MTBF值。MTBF的检验上限θ0是参考规定值确定的。
鉴别比d=θ0/θ1。一般选d=1.5、2.0、3.0。
生产方风险α是MTBF的真值等于θ0时产品被判为不通过的概率,使用方风险β是MTBF的
真值等于θ1时,产品被判为通过的概率。一般选α、β的值为10%、20%,特殊情况下可取高
风险率30%。
试验时间是θ1的倍数。
Ac为判决为通过的故障数,Re为判决为不通过的故障数。
根据鉴别比及α、β值,GJB899提供了如表2的定时试验方案。
@@16103011.GIF;表2 GJB899提供的定时试验方案@@
例如方案17的d=3.0,即θn=3θ1、α=20%、β=20%,试验时间为4.3θ1,如果试验期内出
现的故障数r≤2,则通过;r≥3,则不通过。
推荐的方案是19到21。当然也可选用适当的GJB899的序贯试验方案。
即使软件通过了验证试验,在试验中暴露的故障,也必须找出引起故障的缺陷,加以排除
,进行回归测试,确认未引入新的缺陷后再交付使用。
采取定时试验的原因是便于制订试验计划。
试验时间是任意若干台计算机软件同时进行可靠性试验的累计试验时间。在上例中,如
θ1=1000h,则试验时间为4300h,如取三台计算机同时随机验证,则花费1433h即可结束。
验证试验期间不排除缺陷的原因,是因为排除缺陷需要一整套严格的管理及技术过程,更
改后还需要进行回归测试,排除缺陷的周期一般都较长。
验证试验的通过说明已通过软件MTBF的最低可接受值,并不说明已通过软件MTBF的规定
值。
在接收后,还应继续软件的SRGT,并汇集交付使用后暴露的故障,继续排除缺陷,使软件可
靠性继续增长,达到规定值。
