软件可靠性概述

一、软件质量的重要性

当前，人类步入了信息时代，从交通、能源、电信到金融、教育、军事……等等大多数行业都需要计算机的辅助。软件是计算机系统的灵魂，是许多复杂系统的神经中枢，而质量则是软件的命脉。

软件失效造成系统瘫痪、人员伤亡以及重大经济损失的例子时有所闻。特别是一些安全关键软件，一旦发生失效就可能危及人的生命、财产和生态环境。

欧洲航天局Ariane 5号火箭发射失败是因为Ada语言在编译过程的检查失败导致的。将大的浮点数转换成整数是一种常见的程序错误来源。1996年6月4日，对于Ariane 5火箭的初次航行来说，这样一个错误产生了灾难性的后果。发射后仅仅37秒，火箭偏离它的飞行路径，解体并爆炸了。火箭上载有价值5亿美元的通信卫星，还使耗资达80亿美元的开发计划推迟近3年。后来的调查显示，控制惯性导航系统的计算机向控制引擎喷嘴的计算机发送了一个无效数据。这件事可以说是历史上损失最惨重的软件故障事件。

20世纪末，“千年虫”问题震惊世界，各国投入大量的人力和物力，耗资数千亿美元，虫灾才基本上得到控制。千年虫缩写为“Y2K”，又叫做“计算机2000年问题”，“2000年病毒”或“千年病毒”，是指在某些使用了计算机程序的智能系统（包括计算机系统、自动控制芯片等）中，由于其中的年份只使用两位十进制数来表示，因此当系统进行（或涉及到）跨世纪的日期处理运算时（如多个日期之间的计算或比较等），就会出现错误的结果，进而引发各种各样的系统功能紊乱甚至崩溃。

2003年8月14日，美国及加拿大部分地区发生了的史上最大停电事故，这是由位于美国俄亥俄州的第一能源（FirstEnergy）公司下属的电力监测与控制管理系统“XA/21”出现软件错误导致的。……这样的例子不胜枚举，诸如此类由于软件问题引发的事故基本上是由于软件自身质量造成的。

1979年，Fisher和Light将软件质量定义为：表征计算机系统卓越程度的所有属性的集合。1982年，Fisher和Baker将软件质量定义为：软件产品满足明确需求一组属性的集合。20世纪90年代，Norman、Robin等将软件质量定义为：表征软件产品满足明确的和隐含的需求的能力的特性或特征的集合。

根据计算机软件质量保证计划规范GB/T12504-1990中的定义，软件质量是指软件产品中能满足给定需求的各种特性的总和。这些特性称做质量特性，它包括功能性、可靠性、易使用性、时间经济性、资源经济性、可维护性和可移植性等。

ISO9126质量度量模型将质量特性划分为6个方面：

（1）功能性：适合性、准确性、互操作性、依从性和安全性；

（2）可靠性：成熟性、容错性和易恢复性；

（3）易使用性：易理解性、易学习性和易操作性；

（4）效率：时间特性和资源特性；

（5）可维护性：易分析性、易更改性、稳定性和易测试性；

（6）可移植性：适应性、易安装性、一致性和易替换性。

早在1976年，由Boehm等提出软件质量模型的分层方案。1979年McCall等人改进Boehm质量模型又提出了一种软件质量模型。McCall等认为，特性是软件质量的反映，软件属性可用做评价准则，定量化地度量软件属性可知软件质量的优劣。McCall认为软件质量应由11个要素构成，即正确性、可靠性、效率、完整性、可使用性、可维护性、可测试性、灵活性、可移植性、可复用性和互连性，具体介绍参见表1。又可分为面向产品运行、面向产品修改、面向产品转移三种类型，其相互关系如图1所示。

表1McCall等人的软件质量特性定义

图1软件质量要素与产品状态

二、软件可靠性的不确定性

对于可靠性的研究最早可以追溯到20世纪20、30年代关于机器维修的问题，50年代开始对于可靠性的研究进入黄金时代，但是这些研究仍然都是基于硬件的。

直到70年代由于软件危机的存在使得人们开始重视和研究软件可靠性问题。以Jelinski, Shooman, Musa等为代表的一批著名软件工程专家，援引可靠性工程学的观点，对软件可靠性作出定义。他们的措辞虽不尽相同，但基调是一致的。另一批软件工程专家认为软件具有与硬件不同的性质，因而持反对态度。在这场争论中，JeIinski等人的见解得到了系统工程师们的赞同，也逐渐得到了软件工程界多数人的支持。而且从目前的情况来看，这个定义在目前所有的定义中最恰当地反映了软件的可靠性特性，并对解决实际问题发挥了作用。关于软件可靠性的确切含义，学术界曾经有过长期的争论。1983年美国IEEE（Institute for Electrical and Electronic Engineers）计算机学会对“软件可靠性”一词正式给出了具有定量和定性双重含义的定义:

（1）在规定的条件下，在规定的时间内，软件不引起系统失效的概率，该概率是系统输入和系统使用的函数，也是软件中存在错误的函数；系统输入将确定是否会遇到已存在的错误（如果错误存在的话）。

（2）在规定的时间周期内，在所述条件下，程序执行所要求的功能的能力。

在这个定义中，第一部分对软件可靠性进行了定量的描述，第二部分则对软件可靠性进行了定性的描述。因而软件可靠性具有定性的和定量的两层含义。在强调其定量的含义时，工程上常用软件的可靠度函数来说明软件的可靠性。可以看出，在这个定义中，软件和程序两个词汇被明显地混用了。这这个定义经美国标准化研究所批准作为美国的国家标准。1989年，我国国标GB/T-11157采用了这个定义。

在该定义中，“规定条件”是指计算机的软、硬件环境，软件环境包括运行的操作系统、应用程序、编译系统、数据库系统等；硬件环境包括计算机的CPU、CACHE、MEMORY、I/O等。“规定时间”指软件的工作周期，有三种时间度量：日历时间（日、周、月、年）、时钟时间（程序运行从开始到结束时间的秒、分、时，它包括等待时间和其他辅助时间，但不包括计算机停机占用时间）和执行时间（指计算机执行程序实际占用的中央处理器时间，故又称CPU时间）。“执行所要求的功能”通常指软件不出现失效。如果一个系统不能完成其功能，就说明它发生了失效。为了识别一个失效，必须明确要求它完成的功能是什么。规定的功能通常在软件需求规格说明书中定义。

传统的软件可靠性理论基于以下两个基本假设：

（1）概率假设：系统可靠性行为可以完全用概率方式予以刻画。

（2）双态假设：系统只具有两个极端状态，完全正常状态和完全失效状态，系统在任意时刻必处于上述两种状态之一。

下面，我们将主要论述软件可靠性的两个基本的不确定性：随机性和模糊性。

1.软件可靠性的随机性

随机性是指有明确定义但不一定出现的事件中所包含的不确定性，它是由事物的因果关系不确定所造成的。概率论和数理统计就是研究和揭示随机现象的统计规律性的一门学科，它至今已有几百年的研究历史。

具有随机性的事件有以下一些特点：

（1）事件可以在基本相同的条件下重复进行，比如掷骰子。只有单一的偶然过程而无法判定它的可重复性则不称为随机事件。

（2）在基本相同条件下某事件可能以多种方式表现出来，事先不能确定它以何种特定方式发生，如不论怎样控制炮的射击条件，在射击前都不能毫无误差地预测弹着点的位置。只有唯一可能性的过程不是随机事件。

（3）事先可以预见该事件以各种方式出现的所有可能性，预见它以某种特定方式出现的概率，即在重复过程中出现的频率，如大量射击时炮弹的弹着点呈正态分布，每个弹着点在一定范围内有确定的概率。在重复发生时没有确定概率的现象不是同一过程的随机事件。

宏观世界中必然发生的、确定性的事件在其细节上会带有随机性的偏离。微观世界中个别客体的运动状态都是随机的。对于一个随机事件可以探讨其可能出现的概率，反映该事件发生的可能性的大小。大量重复出现的随机事件则表现出统计的规律性。统计规律是大量随机现象的整体性规律，它支配着随机性系统的状态。

造成软件可靠性的随机性，有如下几个方面的原因：

（1）软件操作剖面（Operational Profile）的随机性

由于软件操作剖面的不确定性，即使一个软件通过测试并最终投放市场，它的可靠性也可能会随着环境因素的变化而发生变化。软件可靠性的定义表明，软件可靠性是面向用户的而不是面向开发人员的。软件可靠性与用户操作有关，而不是与程序的设计有关。操作剖面是指软件测试数据输入域，以及各种输入数据的组合使用概率。欧空局（ESA）标准PSS-01-21（1991）“ESA空间系统软件产品保证要求”，定义操作剖面为：“对系统使用条件的定义。系统的输入值都用其按时间的分布或按它们在可能输入范围内的出现概率的分布来定义”。

假设软件的总输入域划分为若干个输入子域，那么这若干个子域都分别对应一个操作剖面。输入数据落入相应子域的可能性称为操作剖面值，显然操作剖面值会因为软件使用环境不同而发生变化。因为软件使用环境的不同，使得软件在不同环境下输入的数据也有所不同，造成了在不同环境下具有不同的剖面值，这样就形成了软件在不同环境下产生不同可靠性的现象。一般来说，操作剖面与发生概率之间的关系是软件输入空间越大，相应的操作剖面值则会越小。

操作剖面在可靠性评估过程中有着重要的作用，准确的操作剖面能使我们得到准确、可信度高的评估结果，否则，结果的可信度就会降低。事实上，由于在使用软件之前测试员不可能完全知道软件的使用情况，特别是对于大众性的软件来说更是如此，因此就无法准确地定义操作剖面。在实际检测过程中，检测人员通常是用一个固定剖面代替实际剖面进行测试，利用所得到的近似结果来判断软件可靠性的优劣。显然这种方法是不合适的，既然我们无法知道软件的实际运行剖面，那么在使用近似剖面替代时，就应该讨论结果的可信度，以及分析近似剖面发生变化对评估结果的影响。

（2）软件测试的随机性

由于软件错误具有离散性，从而对于样本空间中某输入数据的输出很难用来代表相邻输入数据的输出。软件测试的结果常常会随样本空间选择的不同而发生较大的变化。影响样本空间选择的随机因素，诸如测试工具、测试员的素质、计算机环境、失效数据收集的时间标准等，通过样本空间间接影响软件的测试结果。这些测试结果直接决定了软件可靠性模型参数，然而现有的软件可靠性模型往往没有考虑这种随机性。

（3）软件可靠性模型的随机性

软件可靠性的研究始于20世纪70年代，至今已有30多年的历史，建立的软件可靠性模型超过百种。这些模型中的一部分在特定的领域内得到了较为充分的应用，然而迄今为止，还不存在具有普适性的软件可靠性模型。由于受一些主、客观不确定因素的制约，软件可靠性模型不能完全准确地描述软件的失效行为，从而造成评估结果中存在大量误差。工程应用中常常凭经验对这种误差进行评估。Shooman曾提出，“概率软件可靠性模型的平均相对误差一般为37%”。

不同的软件可靠性模型对同一组失效数据的评估结果可能呈现很大的不一致性；应用同一可靠性模型对同一组数据的不同阶段，或者将同一模型用于不同的失效数据组，其评估质量都可能呈现不一致性。

为了数学处理上的方便或是由于人们对软件失效的内在机理的不完全认识，研究人员在建模之初都做出了一系列的假设，其中不乏失实情况。这类假设有：①失效间隔时间具有独立性；②软件失效相互独立；③软件所有错误检测率相同；④一旦发现软件错误就立即被清除掉，而且清除过程中不会引起新的软件错误；等等。显然这些假设与现实相悖，这就造成了软件可靠性理论值与实际值存在一定的偏差。

目前需要考虑软件可靠性的领域大多是关系国计民生的关键系统，正是由于上述问题，使得基于可靠性模型的测评结果在可信度上大打折扣。刘宏伟基于多组软件失效数据集对G-O模型进行了分析，指出该模型参数的稳定性较差。Littlewood, Podgurski等人指出：由于精度和稳定性差，软件可靠性增长模型不适合于对软件可靠性评价结果精确度和可信度要求比较高的领域。

2.软件可靠性的模糊性

软件可靠性的模糊性主要表现在以下三个方面：

（1）由于软件具有唯一性，软件可靠性行为本质上是模糊的

软件的唯一性主要表现在软件复制无差别和调试过程不会重复。由于可能性反映样本的特殊性，所以在样本之间不存在重复性以及小样本的情形下，可能性更适合于刻画软件系统的可靠性行为。在软件系统可靠性评价问题上，概率假设面临着定量数据短缺的挑战。应用概率方法处理实际问题必须满足四个前提：①事件定义明确；②大量样本存在；③样本具有概率重复性并具有较好的分布规律；④不受人为因素影响。但在实际工程问题中，这四个条件往往并不满足。有些全新开发的高可靠性软件，由于无使用先例，要么失效数据极少，要么根本无法获得失效数据。许多软件系统即使有大样本数据，也不一定能找到统计规律，即使有了统计规律也不一定是典型的，而非典型的过程是难以处理的。

目前，大多数软件可靠性模型都是基于概率统计的观点建模的，由于软件可靠性评估方法还远远没有硬件发展那样成熟，现有方法同硬件相比其适用的局限性要大得多，没有一种方法得到普遍的承认。Harris指出,“评定软件可靠性时是否适用可靠性概率的概念，这个问题还是悬而未决的。尽管软件企业界清楚地了解可靠性问题，也知道需要评定可靠性，使他们自己相信确已满足可靠性要求，却很少有人认为可靠性的概率定义是适用的。这种情况并不是由于对有关软件的问题了解不够，而是由于所了解的只是情况己经发生。软件企业界的大多数人宁愿把可靠性看作是正确性的表示，但是像概率一样，正确性也是一个直觉的观念，只有在正式的数学框架之内才能做到准确、客观和严谨”。因此不论将软件可靠性视为概率的定义，还是将软件可靠性视为正确性，软件可靠性都是一种直觉的观念。

（2）失效数据可能带有模糊性

工程实践中，往往很难收集到大量的第一手数据，通常失效概率或其他参数只能通过其相关领域的参考数据，根据专家的主观判断和不精确的经验来估计。大量存在的来自于生产者、使用者的经验、专家判断等定性信息，工作环境信息及各种任务要求等，一般都是以自然语言等非定量形式表达，如“这个子系统（或模块）的可靠性较高”、“这是系统可靠性的薄弱环节”等等。这些用自然语言表达的信息，基于大样本数据概率模型和以统计为基础的传统可靠性理论却无法应用，难以给出高置信度的评价结论。为解决数据短缺问题，对定性知识的定量转换至关重要。

（3）软件状态的模糊性

由于可靠性是一个本身没有明确外延的定性概念，根据实际系统的模糊或不精确信息，基于二值逻辑（或多值逻辑）严格分明的判断系统状态“正常”、“失效”（或“正常”、“小失效”、“大失效”、“完全失效”等），这是不合理的，不符合人们的通常的思维特点和对客观事物的一般认识。实际上，软件也会老化（Software Aging），从而系统中很多状态会呈现出既不是正常也不是失效的中间状态，软件出现性能退化的主要原因是操作系统资源的耗损，数据损坏和错误累积。显然，这种划分在有些情况下严重脱离工程实际，它不能区别同一部分内不同指标间的差异，而不同部分交界处的相邻指标点间并无性能上的本质差异，却被硬性划分到不同的状态。即使将系统指标的取值范围划分成许多部分，从而使对系统性能的描述变得较为细致，但在本质上所采用的失效判断依然是严格分明的。

三、软件可靠性定性评估的意义

通常，人们更多关注的是软件系统能在多大程度上保持其规定功能的能力。从定性的角度而言，软件系统完成规定功能的能力是有程度差别的，工程经验中常用很多种定性语言值来描述这种程度。在软件可靠性工程项目中，目前大多专家评分方法中，专家需综合许多不确定因素对系统的可靠性进行评价，但是专家往往存在这样的疑惑，是给“0.7”还是“0.8”，似乎均可。这时，专家通过比较分析，往往倾向于用“很高”、“极低”……等语气化词或者“大约是0.7”、“好像是0.8”、“近似于0.9”……等模糊化数量词对其可靠性进行评价。此外，不同专家的评价又具有随机性。由于系统的复杂性，这种不确定性语言值方法常常比精确数值方法甚至更确切、更本质、更高效。

由于软件的复杂性和不确定性，系统的失效很难避免，但准确的可靠性评价，可使我们理解系统的失效原因、制定合理的应对策略，进而采取恰当的措施减少系统失效，提高系统的可靠性。在软件可靠性工程中，会遇到大量的不确定因素，只有充分考虑这些不确定因素的存在和影响，得出的结果才是合理的。

为了处理现实中广泛存在的模糊现象，1965年美国控制论专家扎德（Zadeh, L.A.）教授首次提出了模糊集、隶属度等概念，用以刻画模糊事物的亦此亦彼性，从而开创了模糊数学分支。他认为，模糊性是绝对的，而清晰性或精确性是相对的。所谓精确性或清晰性是人们对不确定性实行了一种分离，是一种简单化和理想化。他同时总结出一条互克性原则：随着系统复杂性的增长，对其特性作出精确而有意义的描述能力相应降低，直到达到一个阈值，一旦超过它，精确性和有意义性（或贴近性）几乎成为两个相互排斥的特征。这个原则说明模糊性来源于复杂性，复杂程度越高，模糊性越强，精确化程度也就越低。自从创立“模糊数学”以来，模糊数学己被广泛应用于自动控制、人工智能、系统分析等诸多领域，并取得了惊人的成果。引入模糊数学方法不是为了把问题模糊化，而是把实际中的模糊事件用精确的数学表达式表示，使问题精确化。随着可靠性研究的不断深入，人们已经逐渐认识到了常规可靠性的种种不合理性，因此人们对可靠性中存在的不确定性的研究开始引入了模糊数学方法。

然而，一旦人为假定一个精确的隶属函数来描述模糊概念，“硬化”成精确数值后，模糊概念就被强行纳入到精确数学的王国，不符合人们对自然语言中概念的理解。这样，在后继相关概念的定义、定理的叙述及证明等经典数学式的演绎中，就不再有丝毫的模糊性了。这正是传统模糊理论的不彻底性。

针对这些问题，20世纪90年代初期，李德毅在传统模糊数学和概率统计的基础上提出了定性定量不确定性互换模型——云模型，它把自然语言中定性概念的模糊性和随机性有机地综合在一起，实现了定性语言值与定量数值之间的有效转换。

长按二维码识别关注我们