软件可靠性工程范文.docx

软件可靠性工程范文.docx

《软件可靠性工程范文.docx》由会员分享，可在线阅读，更多相关《软件可靠性工程范文.docx（9页珍藏版）》请在冰豆网上搜索。

软件可靠性工程范文

软件可靠性工程

1.软件可靠性定义

1.1.广义

是指一切旨在避免、减少、处理、度量软件故障（错误、缺陷、失效）的分析、设计、测试等方法、技术和实践活动。

于是有诸多相关术语，如软件可靠性度量、软件可靠性设计、软件可靠性建模、软件可靠性测试、软件可靠性管理等。

1.2.狭义

指软件无失效运行的定量度量，尤其是那些面向用户的定量度量。

主要有：

软件可靠度：

表示软件在规定的运行环境中和规定的运行时间内无失效运行的机会。

软件无失效运行的机会多以概率度量，但也可以模糊数学中的可能性加以度量，有时也在数据域上将软件可靠度表示为软件成功执行一个回合的概率。

软件失效强度：

其物理解释是单位时间内软件发生失效的机会。

在概率范畴内，它

与软件可靠度有明确的数学关系（R（t）＝1－F（t），R（t）为可靠度，F（t）为失效强度）。

软件平均失效时间（MTTF）：

表示软件投入运行到出现一个新失效的时间。

上述度量与硬件可靠性中的相应概念本质上是一致的。

“失效”是指程序的功能在某方面没有达到用户的需求。

“没有像用户需求的那样工作”是一个很广的定义。

因此，可靠性结合了与程序执行相关联的所有属性。

例如，它包括正确性、安全性和可使用性的操作方面，以及对用户的友好性。

请注意，安全性实际上是软件可靠性的一个特殊子类。

可靠性不包括可移植性、可修改性或文档的可理解性。

有关，因此可靠性是动态的，而不是静态的。

可靠性考虑问题出现的频率，直接与操作经验和在经验中错误的影响相关。

因此，可以很容易地将可靠性与成本联系起来。

可靠性很适合检查发展趋势的重要性、设定目标和预测什么时候可以达到目标。

可靠性使人们可以使用同样的术语对硬件和软件的系统可靠性进行分析，而在真实系统中硬件和软件都同时存在。

所以，可靠性度量比错误度量要有用得多。

2.软件可靠性工程的研究范围

软件可靠性工程涉及以下四方面活动和有关技术：

2.1.软件可靠性分析

进行软件可靠性的需求分析、指标分配、故障树分析、失效模式和影响分析、软件开发过程中有关软件可靠性的的特性分析、⋯⋯等。

2.2.软件可靠性设计和实现

进行防错设计、容错设计、检错设计、纠错设计、故障恢复设计、软件可靠性增长、⋯⋯等。

2.3.软件可靠性测量、测试和评估

在软件生存周期各阶段进行有关软件可靠性设计、制造和管理方面的属性测量，进行基于软件运行剖面的测试用例随机输入的软件测试、软件可靠性预计、软件可靠性估计、软件可靠性验证、⋯⋯等。

2.4.软件可靠性管理

确定影响软件可靠性的因素，制定必要的设计和实现准则以及对软件开发各阶段软件可靠性相关的过程和产品的要求，依据上述有关测量数据和分析结果控制和改进开发过程，行风险管理（不仅考虑安全性等技术风险，而且考虑进度和经费方面的风险），改进费用效益关系，改进开发过程，对采购或重用的软件进行可靠性管理，⋯⋯等。

实施软件可靠性工程要解决三个问题，即软件可靠性指标的确定与分配，软件可靠性要求的实现和软件可靠性的验证。

上面提到对有关属性的测量，涉及对软件可靠性测试、评估、预计、估计。

3.软件可靠性工程的思想

软件可靠性工程之所以有效，在于它运用了两个思想：

第一，通过定量描述产品的使用方式，可以更有效地开发产品的功能并且使用这些信息，以便：

将资源精确地集中到最常用和最关键的功能上。

使测试工作真实地反映实际条件。

第二，软件可靠性工程平衡用户对可靠性、开发时间和开发费用的需求，从而更加有效。

为此，软件可靠性工程要像对开发时间和开发费用设置定量目标那样，对可靠性也设置定量目标，要制定策略来达到这些目标。

最后，软件可靠性工程在测试过程中跟踪产品的可靠性，并用来作为产品是否可以发布的标准。

通过软件可靠性工程，你可以交付“正好合适”的可靠性的产品，并且既避免了不必要的资金和时间成本，又避免了发生由不够可靠的产品导致的用户不满和问题。

4.软件失效的根源与机理

软件失效的根源在于设计错误，而硬件失效的主要根源通常在于物理变质。

然而，为软件可靠性开发的概念和理论确实可以应用于任何设计活动，包括硬件设计。

一旦软件（设计）缺陷被适当地修复，通常就被永久性修复了。

失效通常只发生在当程序（设计）运行在并非它所开发和测试时面向的环境中的情况。

尽管制造过程也可能影响物理组件的质量，但是软件（设计）的复制过程很简单，并且其质量水平很高。

软件失效机理可描述为：

软件错误—>软件缺陷—>软件故障—>软件失效。

各自具体含义为：

软件错误（error）：

在可以预见的时间内，软件仍将由人开发。

软件错误是指在软件开发过程中出现的不希望或不能接受的人为错误，其结果是导致软件缺陷的产生。

软件缺陷（defect）：

软件缺陷是指存在于软件（程序、文档、数据）中的那些不希望或不可接受的偏差，如少一逗点、多一语句等，其结果是软件运行于某一特定条件时出现故障。

当软件特指程序时，软件缺陷（defect）与软件（程序）污点（bug）同义。

软件故障（fault）：

软件故障是指软件运行时出现的一种不希望或不可接受的内部状态，譬如，软件处于执行一个多余的循环时，我们说软件出现故障。

此时若无适当措施（容错）加以及时处理，便产生软件失效。

软件失效（failure）：

软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果。

5.软件可靠性工程测试分类

包括两种类型：

可靠性增长测试和确认测试。

这两种类型与不同测试阶段无关，例如单元测试、子系统测试、系统测试或β测试，而是与测试的目标相关。

可靠性增长测试的目标是找到并清除错误。

5.1.可靠性增长测试

包括特性测试、负载测试和回归测试。

在特性测试中，操作都是独立运行的，运行场地环境的影响和交互作用被减小到最低程度。

有时通过在操作之间重新初始化系统来减小交互作用。

负载测试是指同时运行很多操作，并且是以相同的频率，在其他现场将会出现的相同环境条件下。

这样就可以产生与在现场中可能出现的情况相同的交互作用和环境条件的影响。

验收测试和性能测试都属于负载测试。

回归测试是在系统发生重要改变之后进行的，包括一些（通常是随机选取的）或全

部特性测试。

在回归测试中应该包括所有关键操作。

5.2.确认测试

确认测试不包括调试过程，不会试图通过引起定位错误后再清除错误来解决所发现的失效。

被测系统必须是稳定的，不能出现任何改变，不管是由于增加了新特性还是由于错误的清除。

通过确认测试，得到一个二选一的结论：

或者接受这个软件，或者拒绝它并把它退回给提供商。

在确认测试中，所需要的失效数据样本的数量要少得多。

事实上，如果无失效运行的时间足够长，那么可以在出现任何失效之前就作出结论。

通常只在负载测试（不是特性或回归测试）中使用确认测试。

6.软件可靠性增长模型

软件可靠性增长建模实施于软件测试阶段，主要由软件开发人员完成，旨在从可靠性角度判断软件何时可以停止测试，以交付用户验收。

在软件测试阶段，被发现的缺陷不断被剔除，因而可靠性呈增长趋势。

软件可靠性增长建模的一个基本假设是测试用例选取代表着软件实际运行环境（剖面）。

目前采用的主要方式是将软件视为黑箱功能系统，针对测试过程中收集的软件可靠性数据运用概率或模糊软件可靠性模型加以建模、分析，以获得软件可靠性定量指标的估计值或预测值。

软件可靠性增长模型主要分以下三类。

6.1.缺陷播种模型

假设在软件内部预先设置一些缺陷，再通过分析测试过程中发现的预先设置的缺陷数目占发现的软件缺陷总数之比例，以估计软件缺陷残留数。

目的是直接用程序中现存的错误数的多少来反映程序的可靠性。

优点：

模型的结果直观。

缺点：

不能反映可靠度与时间的关系。

6.2.基于数据域模型

认为软件的运行过程由一系列基本执行过程（称为回合）顺序组成，软件可靠性则由一个回合成功执行的概率来表示。

目的是建立软件的可靠性与输入数据的联系，用程序运行中的失效次数与成功次数的比例作为软件可靠性的度量。

优点：

概念清晰易懂，易于应用。

缺点：

模型与时间度量没有直接的关系，在实现硬－软件系统综合时有一定困难，必须经过附加的数学处理，才能用时间尺度表示可靠度。

6.3.基于时间域模型

以时间作为基准，研究软件的可靠性特征随时间变化的规律。

它关注的是一定时间内软

件成功运行的机会，在时间域内度量软件可靠性。

目前使用得最多的是基于时间域模型。

这类模型按其对数据的需求，可分为两个子类：

失效时间间隔模型（TBF模型）：

模型所使用的数据使失效时间间隔，分析方

法建立在以失效时间间隔服从特定的概率分布的基础上。

失效计数模型（FC模型）：

模型所使用的数据是一定的时间间隔中的失效数，分析方法大多建立在Poisson过程理论的基础上。

优点：

模型建立的基础及模型得出的结果，完全符合软件可靠性定义的要求，且与硬件可靠性的概念兼容，可以满足硬、软件系统综合分析的要求。

因此备受青睐，是最重要、品种最多的模型。

缺点：

假设的条件很高，很难完全满足，影响了模型的准确性和人们对其的信心。

前景：

经过20多年的研究、发展，情况有了很大改善，加上模型的数量多，选择余地大，因此应用前景广阔。

7.

软件可靠性模型的另一种分类（随机性分类法）

8.软件可靠性确认（验收）模型

与硬件可靠性验收的情形类似，软件可靠性验收模型与软件可靠性验收的试验方案一

一对应，其作用是根据软件可靠性验收的试验结果（收集的数据）给出软件可靠性的定量估计值，以便从可靠性角度判断是否接受该软件，在我们谈论具体的软件可靠性验收模型时，实际上包含着相应的试验方案。

目前已提出的软件可靠性验收模型有Nelson模型、定时截尾寿命验收模型、序贯寿命验收模型和模糊模型。

9.许多软件可靠性模型有下列要素的解析描述

任何时间点所经历的平均失效数

段时间间隔内的平均失效数

任何时间点的失效强度失效间隔的概率分布

好的软件可靠性模型应该具有一些重要特性：

给出未来失效行为的好的映射计算一些有用的量

简单可广泛应用

基于可靠的假设

10.评价可靠性模型的准则

通常认为，评价软件可靠性模型对一个给定项目的支持时应使用下列准则：

在这方面的度量是，准确

预计有效性：

每个模型的预计质量方面的性能和正确性。

性、趋势、偏移和噪声。

容易进行参数测定：

测定每个模型的参数所产生的资源需求和影响，即：

模型所需要的参数数量以及估计这些参数的难度。

假设的质量：

该准则是指假设与真实情况的接近程度，以及对特殊环境的适应性。

能力：

能力指模型对与可靠性有关的量的估计能力如何。

适用性：

对软件在测试和运行环境中的演变和修改的处理能力。

简单性：

模型建模原理、数据采集、程序实现和确认的容易程度。

对噪声的不敏感性：

尽管在输入数据和参数中有小的差别，模型仍能产生结果，同时对显著差别又不丢失相应的能力。

11.软件可靠性模型的假设存在的问题

从许多假设来看，有很多是与软件开发实际不相符合的，许多软件工程师与软件管理人员无法接受。

许多现存模型（特别是那些早期的软件可靠性模型），考虑到排错引入新的错误会使问题复杂化，于是假设排错不引入新的错误。

这样做的结果虽然使理论上的处理简单了，但与实际情况相距太远。

软件的开发靠人完成，则排错问题要人完成，人类行为的不可预测性无论在开发还是排错，同样要表现出来。

事实上，由于排错时的某些处置失当，往往会产生许多副作用，引入一些始料不及的新错误，是十分自然的。

这也正好解释了我们在对软件中出现的错误进行观察记录时，为什么经常会大幅度地振荡的原因。

引入新错，另一方面的原因还在于软件产品各模块（指结构化的软件产品而言）间的

逻辑关系错综复杂、互为因果，故而使得局部的某些改动甚至可能产生牵涉全局性的许多问题。

随后的一些模型，虽然允许可以引入的错误数为1、2或其它，正是由于看到了这

一问题，才作了一些调整变动，但仍未能从根本上解决问题。

关于测试时的输入空间“覆盖”使用空间的假设，也是不现实的。

为了尽量保证测试能充分反映出软件产品将来所有可能的使用情况，有必要在设计测试的数据和条件时，使它们能尽可能地反映出软件产品将来使用时的情况、条件和环境。

但这并

不意味着测试就一定是完全的。

测试时的输入空间充其量也只能是从使用时的输入集合的全集合中选取的子集合。

如果使用时的问题空间是无穷集合（大多数实际情

况也正是如此），则这样选出的子集合，无论如何也不可能“覆盖”问题空间。

假如一定要做到“覆盖”，只有使测试无限制地进行下去，而这也正是我们力图要避免的。

由"覆盖"问题引伸出的测试环境与使用运行环境一致的问题，也是同样性质的，这

一假设也是人们一种良好愿望的反映。

特别对于那些包括软件的无法进行试验的系统，则这一假设更显得不合实际。

不同软件产品的开发过程，由于参加者不同，他们各自的训练、业务经历、程序设计风格都不相同。

因此，通过他们各自的大脑思维所产生出来的"逻辑产品"，个性

多于共性，这是一种必然现象，也正是软件工程所面临的一大难题。

模型假设的局限性太多，势必影响到它们的应用范围。

目前，软件工程界对于软件可靠性模型的诸多疑虑，也多半来自于此。

如何改进它们，是软件可靠性今后理论研究的重大课题之一。

它的突破，也就会消除软件工程界的疑虑，使软件可靠性理

论得到更广泛的应用，从而，必然反过来又促进软件可靠性理论的发展。

软件可靠性模型没有普适性，一个模型可能仅对一个或几个软件做出较为准确的评估和预计，因此，如何选择、评价模型就成为一个很有必要研究的课题。

12.当前软件可靠性领域面临的主要问题

12.1.软件可靠性设计

就是要大力发展以保证和提高软件可靠性为主要目标的软件设计技术的研究和实践，特别是：

定性分析：

就是要开发利用针对软件设计过程中的软件错误、缺陷的定性分析技术。

容错实用技术：

目前软件容错的基本方法是N文本技术和恢复块技术，但离工程上简单实用的要求还有一定距离。

12.2.软件可靠性测试

软件可靠性测试是适用于软件确认阶段的一种测试形式，旨在给出软件可靠性的定量估计值，有别于其他测试形式。

软件可靠性测试在软件开发过程中很重要，甚至必不可少，是对软件需求规范给出的软件可靠性定量目标的回答，但目前在这方面的研究很薄弱，急需开展。

12.3.软件可靠性建模的统一方法

尽管软件可靠性建模是软件可靠性领域研究最早、最多，成果也最丰富的一个方面，但也可能是争论最激烈的一个方面，至今无统一方法，即不能确定是用概率方法还是模糊方法，甚至连软件可靠度的定义也有时间域与数据域之别，所以应寻找软件可靠性建模的统一方法。

寻找统一方法的一个途径是广泛开展现有软件可靠性模型的确认（验证）工作。

12.4.混合硬件-软件系统可靠性

软件不能独立起作用，如果硬件不可靠，软件可靠便失去意义。

保证软件可靠性是为了保证混合硬件-软件系统可靠性，因此研究混合硬件-软件系统可靠性这一问题非常重要。

但硬件可靠性行为与软件可靠性行为是否本质上一致？

是将硬件-软件视为不加区分或不可分

的一体还是将其视为硬件、软件两个子系统以某种方式（譬如串联方式）联结而成？

类似问题均需回答。

12.5.软件可靠性管理

软件可靠性管理方面还没有建立起具有权威性的管理体系和规范。

比如，如何描述软件可靠性、如何测试、如何评估、如何设计、如何提高等。

由于目前国内外对于软件可靠性模型的研究多集中在软件的研制阶段，而很少有涉及测试与评估阶段的可靠性模型，所以从事软件可靠性测试与评估研究是一个有理论价值和实际意义、并且存在一定难度的课题。