第9章 软件可靠性基础知识

9.1软件可靠性基本概念

探讨软件可靠性的概念、模型、设计、测试以及评价等相关技术。

9.1.1软件可靠性定义Software Reliability

定义：是软件产品再规定的条件下和规定的时间区间完成归档功能的能力。简而言之，规定时间周期内，在所述条件下程序执行所要求的功能的能力。

规定的条件：

直接与软件运行相关的使用该软件的计算机系统的状态和软件的输入条件，或统称为软件运行时的外部输入条件。

只要指运行环境，运行所需的各种支持要素，环境涉及的硬件、OS、数据库、中间件。。。

规定的时间区间：

软件的实际运行时间区间。

软件可靠性只体现在软件运行阶段，所以运行时间是规定时间的度量。运行时间包括工作与挂起。

由于软件运行的环境与程序路径选取的随机性，软件的失效为随机事件，所以运行时间属于随机变量。

规定的功能：

提供给定的服务，必备的功能。

软件可靠性与规定的任务和功能有关。由于要完成的任务不同，运行情况也有区别，调用的子模块不同，可靠性也不同，所以度量软件系统可靠性必须明确任务和功能。

软件可靠性定义具有的特点：

①用内在的“缺陷”和外在的“失效”关系来描述可靠性，更能深刻地体现软件的本质特点。

②定义使人们对软件可靠性进行量化评估成为可能。对于软件的可靠性这样一个质量特性，很难用一个明确直观的数值去体现。而依据这个定义，人们有可能通过分析影响可靠性的因素，用函数的形式，按照不同的目的建立各种数学模型去分析软件可靠性。

③用概率的方法去描述可靠性是比较科学的。前面讲到，软件失效是随机的外部表现，完全是一个随机事件，而软件缺陷是软件固有的没有损耗的内在特点。定义用规定时间内其操作 不出现软件失效的概率，也就是输入未碰到软件缺陷的概率来描述可靠性，这种方法就是用概率来描述纯粹的随机事件，是比较合理的，也是可行的。

9.1.2软件可靠性的定量描述

1.规定时间

执行时间：指软件运行过程中，中央处理器(CPU)执行程序指令所用的时间总和。

人们使用执行时间来度量软件的可靠性最为准确，效果也最好。

2.失效概率

3.可靠度

软件系统在规定条件下，规定的时间内不发生失效的概率。1减去失效率就是可靠度：1 - F(t)

4.失效强度

失效强度(Failure Intensity)：单位时间软件系统出现失效的概率。

5.平均失效时间

系统平均失效前时间(Mean Time To Failure,MTTF)定义为从t=0时到故障发生时系统的持续运行时间的期望值。不包括老化时间，还有，对于不可修复的系统，这个时间就是寿命了。

6.平均恢复时间

平均恢复前时间(Mean Time To Restoration,MTTR)是随机变量恢复时间的期望值，就是从出现故障到修复成功中间的这段时间，它包括确认失效发生所必需的时间，记录所有任务的时间，还有将设备重新投入使用的时间。MTTR越短表示易恢复性越好。

就是出现故障那一刻到修复后重新开始运行那一刻，两者间隔，这包括失效时间，以及修复时间，还有重新投入使用的时间。

7.平均故障时间

MTBF(Mean Time Between Failures,平均故障间隔时间)定义为：失效或维护中所需的平均时间，包括故障时间以及检测和维护设备的时间。

对于可靠度服从指数分布的系统，从任一时刻到达故障的期望时间都是相等的，因此有：

MTBF=MTTF+MTTR。

以下是对可靠性度量指标的补充说明(前提条件)：

9.1.3可靠性目标

可靠性不仅仅取决于失效发生的概率，还和软件失效的严重程度有关----失效严重程度类(Flure Severity Class)。

失效严重程度的分级有不同标准，比如成本影响、系统能力影响等。

例如：

可靠性目标是指客户对软件性能满意程度的期望。通常用可靠度、故障强度和平均失效时

间(MTTF)等指标来描述，根据不同项目的不同需要而定。建立定量的可靠性指标需要对可靠

性、交付时间和成本进行平衡。为了定义系统的可靠性指标，必须确定系统的运行模式，定义

故障的严重性等级，确定故障强度目标。

9.1.4可靠性测试的意义

(1)软件失效可能造成灾难性的后果。

(2)软件的失效在整个计算机系统失效中的比例较高。

(3)相比硬件可靠性技术，软件可靠性技术很不成熟，这就加剧了软件可靠性问题的重要性。

(4)与硬件元器件成本急剧下降形成鲜明对比的是，软件费用呈有增无减的势头，而软件可靠性问题是造成费用增长的主要原因之一。

(5)计算机技术获得日益广泛的应用，随着计算机应用系统中软件成分的不断增加，使得

系统对于软件的依赖性越来越强，软件对生产活动和社会生活的影响越来越大，从而增加了软

件可靠性问题在软件工程领域乃至整个计算机工程领域的重要性。

9.1.5广义的可靠性测试与狭义的可靠性测试

广义的软件可靠性测试是指为了最终评价软件系统的可靠性而运用建模、统计、试验、分 

析和评价等一系列手段对软件系统实施的一种测试。

狭义的软件可靠性测试是指为了获取可靠性数据，按预先确定的测试用例，在软件的预期使用环境中，对软件实施的一种测试。狭义的软件可靠性测试也叫“软件可靠性试验” (Software Reliability Test),它是面向缺陷的测试，以用户将要使用的方式来测试软件，每一次测试代表用户将要完成的一组操作，使测试成为最终产品使用的预演。这就使得所获得的测试数据与软件的实际运行数据比较接近，可用于软件可靠性评价。

可靠性测试是对软件产品的可靠性进行调查、分析和评价的一种手段。它不仅仅是为了用测试数据确定软件产品是否达到可靠性目标，还要对检测出的失效的分布、原因及后果进行分析，并给出纠正建议。总的来说，可靠性测试的目的可归纳为以下3个方面。

(1)发现软件系统在需求、设计、编码、测试和实施等方面的各种缺陷。

(2)为软件的使用和维护提供可靠性数据。

(3)确认软件是否达到可靠性的定量要求。

9.2软件可靠性建模

9.2.1影响软件可靠性的因素

软件可靠性模型 (Software Reliability Model)是指为预计或估算软件的可靠性所建立的可靠性框图和数学模型。

影响软件可靠性的因素： 主要有：缺陷的引入、发现和清除。

缺陷的引入主要取决于软件产品的特性和软件的开发过程特性。

软件产品的特性指软件本身的性质，开发过程特性包括开发技术、开发工具、开发人员的水平、需求的变化频度等。

缺陷的发现依靠用户对软件的操作方式、运行环境等，也就是运行剖面。

缺陷的清除依赖于失效的发现和修复活动及可靠性方面的投入。

从技术的角度来看，影响软件可靠性的主要因素如下。

运行剖面(环境)。

软件规模。

软件内部结构。

软件的开发方法和开发环境。

软件的可靠性投入。

软件可靠性评估的时候，我们不得不提到软件可靠性模型。为了构建软件的可靠性模型，首先要来分析一下影响软件可靠性的因素

9.2.2软件可靠性的建模方法

一个软件可靠性模型组成：

1).模型假设：

模型是实际情况的简化或规范化，总要包含若干假设，例如测试的选取代表实际运行剖面，不同软件失效独立发生等。

2).性能度量：

软件可靠性模型的输出量就是性能度量，如失效强度、残留缺陷数等。在软件可靠性模型中性能度量通常以数学表达式给出。

3).参数估计方法

某些可靠性度量的实际值无法直接获得，例如残留缺陷数，这时需通过一定的方法估计参数的值，从而间接确定可靠性度量的值。当然，对于可直接获得实际值的可靠性度量，就无须参数估计了。

4)数据要求

个软件可靠性模型要求一定的输入数据，即软件可靠性数据。不同类型的软件可靠性模型可能要求不同类型的软件可靠性数据。

绝大多数的模型包含3个共同假设。这些假设至今主宰着软件可靠性建模的研究发展，人们尚未找到克服这些假设局限性的有效方法。

1)代表性假设。

认为：测试用例代表实际运行剖面，随机选取的。此假设实质是可用测试产生的软件可靠性数据预测实际运行行为。

2)独立性假设。

认为：软件失效独立发生不同时刻，互不影响。

例如在概率范畴，假设相邻软件失效间隔构成一组独立随机变量，或假设一定时间内软件失效次数构成一个独立增量过程。在模糊数学范畴，则相邻软件失效间

隔构成一组不相关的模糊变量。

3)相同性假设。

认为：所有软件失效后果相同，不分失效严重等级。

通过各种估计和预测的方法来确定模型的参数。估计是通过收集到的失效数据进行统计分析，利用一定的推导过程归纳出模型的参数；预测是使用软件产品自身的属性和开发过程来确定模型的参数，这种方法可以在程序执行前完成。

各种估计预测的方法比如：

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

2)一段时间间隔内的平均失效数。

3)任何时间点的失效强度。

4)失效区间的概率分布。

软件模型使用注意点：

• 对将来故障预测注意：1).保证模型参数值不会发生变化。2).在进行预测时发现引入了新的错误，或修复行为使新的故障不断发生，应暂停，等足够多故障后再继续，这样模型实用性才会更准确。

• 一般来说，软件可靠性模型是以在固定不变的运行环境中运行的不变的程序作为估测实体的，程序的代码和运行剖面都不发生变化，但实际是变化的，所以要进行分段处理的方式。因此模型主要集中注意力于排错。

• 对于已发行并正在运行的程序，应暂缓安装新的功能和对下一次发行的版本的修复。 如果能保持一个不变的运行剖面，则程序的故障密度将显示为一个常数。

• 一般来说，一个好的软件可靠性模型增加了关于开发项目的交流，并对了解软件开发过程提供了一个共同的工作基础

一个好的软件可靠性模型应该具有如下重要特性。

(1)基于可靠的假设。

(2)简单。

(3)计算一些有用的量。

(4)给出未来失效行为的好的映射。

(5)可广泛应用。

9.2.3软件的可靠性模型分类---简单看看即可

很多种，大体分10类：

●种子法模型。

●失效率类模型。

●曲线拟合类模型。

●可靠性增长模型。

●程序结构分析模型。

●输入域分类模型。

●执行路径分析方法模型。

●非齐次泊松过程模型。

●马尔可夫过程模型。

●贝叶斯分析模型。

1.种子法模型

种子法模型利用捕获一再捕获抽样技术估计程序中的错误数，在程序中预先有意“播种”

一些设定的错误“种子”,然后根据测试出的原始错误数和发现的诱导错误的比例，来估计程序

中残留的错误数。

优点：简便易行；缺点是诱导错误的“种子”与实际的原始错误之间的类比性估量困难。

2.失效率类模型

● Jelinski-Moranda的De-eutrophication模型。

●Jelinski-Moranda的几何De-eutophication模型。

● Schick-Wolverton模型。

●改进的Schick-Wolverton模型。

● Moranda的几何泊松模型。

● Goal和Okumoto不完全排错模型。

3.曲线拟合类模型

曲线拟合类模型用回归分析的方法研究软件复杂性、程序中的缺陷数、失效率、失效间隔

时间，包括参数方法和非参数方法两种。

4.可靠性增长模型

这类模型预测软件在检错过程中的可靠性改进，用增长函数来描述软件的改进过程。这类

模型如下。

● Duane模型。

● Weibull模型。

● Wagoner的Weibull改进模型。

● Yamada和Osaki的逻辑增长曲线。

● Gompertz的增长曲线。

5.程序结构分析模型

程序结构分析模型是根据程序、子程序及其相互间的调用关系，形成一个可靠性分析网络。

● Littewood马尔可夫结构模型。

● Cheung的面向用户的马尔可夫模型。

6.输入域分类模型

输入域分类模型选取软件输入域中的某些样本“点”运行程序，根据这些样本点在“实际”

使用环境中的使用概率的测试运行时的成功/失效率，推断软件的使用可靠性。

● Nelson模型。

● Bastani的基于输入域的随机过程模型。

7.执行路径分析方法模型

执行路径分析方法类模型的分析方法与上面的模型相似，先计算程序各逻辑路径的执行概

率和程序中错误路径的执行概率，再综合出该软件的使用可靠性。

8.非齐次泊松过程模型

非齐次泊松过程模型(NHPP),是以软件测试过程中单位时间的失效次数为独立泊松随机

变量，来预测在今后软件的某使用时间点的累计失效数。这类模型如下。

● Musa的指数模型。

● Goel和Okumoto的NHPP模型。

●S_型可靠性增长模型。

●超指数增长模型。

● Pham改进的NHPP模型。

9.马尔可夫过程模型

●完全改错的线性死亡模型。

●不完全改错的线性死亡模型。

●完全改错的非静态线性死亡模型。

10.贝叶斯模型

贝叶斯模型是利用失效率的试验前分布和当前的测试失效信息，来评估软件的可靠性。这

是一类当软件可靠性工程师对软件的开发过程有充分地了解，软件的继承性比较好时具有良好

效果的可靠性分析模型。这类模型如下。

●连续时间的离散型马尔可夫链。

● Shock模型。

另外，Musa和Okumoto依据模型的不同属性对可靠性模型进行以下分类。

●时间域：有两种，自然或日历时间与执行(CPU)时间。

●失效数类：取决于无限时间内发生的失效数是有限的还是无限的。

●失效数分布：相对于时间系统失效数的统计分布形式，主要的两类是泊松分布型和二项

分布型。

●有限类：对有限失效数的类别适用，用时间表示的失效强度的函数形式。

●无限类：对无限失效数的类别适用，用经验期望失效数表示的失效强度的函数形式。

9.3软件可靠性管理

为了进一步提高软件可靠性，人们又提出了软件可靠性管理的概念，把软件可靠性活动贯穿于软件开发的全过程。

对象：软件可靠性活动。

内容： 括软件工程各个阶段的可靠性活动的目标、计划、进度、任务和修正措施等。

阶段：根据需要增减

1.需求分析阶段

(1)确定软件的可靠性目标。

(2)分析可能影响可靠性的因素。

(3)确定可靠性的验收标准。

(4)制定可靠性管理框架。

(5)制定可靠性文档编写规范。

(6)制订可靠性活动初步计划。

(7)确定可靠性数据收集规范。

2.概要设计阶段

(1)确定可靠性度量。

(2)制定详细的可靠性验收方案。

(3)可靠性设计。

(4)收集可靠性数据。

(5)调整可靠性活动计划。

(6)明确后续阶段的可靠性活动的详细计划。

(7)编制可靠性文档。

3.详细设计阶段

(1)可靠性设计。

(2)可靠性预测(确定可靠性度量估计值)。

(3)调整可靠性活动计划。

(4)收集可靠性数据。

(5)明确后续阶段的可靠性活动的详细计划。

(6)编制可靠性文档。

4.编码阶段

(1)可靠性测试(含于单元测试)。

(2)排错。

(3)调整可靠性活动计划。

(4)收集可靠性数据。

(5)明确后续阶段的可靠性活动的详细计划。

(6)编制可靠性文档。

5.测试阶段

(1)可靠性测试(含于集成测试、系统测试)。

(2)排错。

(3)可靠性建模。

(4)可靠性评价。

(5)调整可靠性活动计划。

(6)收集可靠性数据。

(7)明确后续阶段的可靠性活动的详细计划。

(8)编制可靠性文档。

6.实施阶段

(1)可靠性测试(含于验收测试)。

(2)排错。

(3)收集可靠性数据。

(4)调整可靠性模型。

(5)可靠性评价。

(6)编制可靠性文档。

9.4软件可靠性设计-----重点

测试阶段，收集测试数据，利用软件可靠性模型，可评估或预测软的可靠性。这些软件可靠性测试活动虽然能查错和排错，但不嫩从根本上提高可靠性，所以为了保障软件系统可靠性，在设计阶段增加可靠性设计的概念(措施)。

为啥在设计阶段：实践证明，保障软件可靠性最有效、最经济、最重要的手段是在

软件设计阶段采取措施进行可靠性控制。

可靠性设计其实就是在常规的软件设计中，应用各种方法和技术，使程序设计在兼顾用户

的功能和性能需求的同时，全面满足软件的可靠性要求，即采用一些技术手段，把可靠性“设

计”到软件中去。软件可靠性设计技术就是以提高和保障软件的可靠性为目的，在软件设计阶

段运用的一种特殊的设计技术。

可靠性设计技术与普通的软件设 计技术没有明显的界限，但遵循一定原则：

1).它是设计的一部分，必须在软件的总体设计框架中使用，并且不能与其他原则冲突。

2).满足提高软件质量的前提下，以提高和保障软件可靠性为目标。

3).得确定可靠性目标，不能无限的扩大化，而且排在功能、需求、成本之后。

软件可靠性设计技术主要有：容错设计、检错设计、降低复杂度设计。

提高系统可靠性的技术：可以分为避错(排错)技术和容错技术。避错是通过技术评审、系统测试和正确性证明等技术，在系统正式运行之前避免、发现和改正错误。

容错：是指系统在运行过程中发生一定的硬件故障或软件错误时，仍能保持正常工作而不影响正确结果的一种性能或措施。容错技术主要是采用冗余方法来消除故障的影响。

• 冗余：是指在正常系统运行所需的基础上加上一定数量的资源，包括信息、时间、硬件和软件。冗余是容错技术的基础，通过冗余资源的加入，可以使系统的可靠性得到较大的提高。主要的冗余技术有结构冗余(静态、动态、混合)、信息冗余、时间冗余和冗余附加4种。

软件容错：的主要方法是提供足够的冗余信息和算法程序，使系统在实际运行时能够及时发现程序设计错误，采取补救措施，以提高系统可靠性，保证整个系统的正常运行。

软件容错技术：主要有N版本程序设计、恢复块方法和防卫式程序设计等。

9.4.1容错设计技术

软件失效后果严重的场合，容错技术，如飞行控制、空中交通管制、核反应堆控制等系统。

1).恢复块设计（动态冗余/主动冗余）

系统的执行可看作一些操作，恢复快设计就是选择一组操作(比较重要的)，作为容错设计单元。构造恢复块的可以是模块、过程、子程序、程序段等等。

它采取的是后向恢复策略，后恢复策略就是，从当前出错时刻往回走，走到一个无错误的点。

其主要方式是多重模块待机储备，当系统检测到某工作模块出现错误时，就用一个备用的模块来替代它并重新运行。
各备用模块在其待机时，可与主模块一样工作，也可以不工作(一般来说是不工作的)。前者叫热备份系统(双重系统),后者叫冷备份系统(双工系统、双份系统)。

恢复块设计是一种动态冗余系统设计的方法。所谓动态冗余，就是在发现故障之后，利用冗余资源对有故障的部件进行替换，或对系统进行重构和恢复。

        在恢复块设计中，有N个业务功能相同的独立系统。将一个系统定为主块，其他系统定为备用块。当主块正常运行时，备用块停机。将主块的结果进行验证，如果发现结果质量不合格，那么就启用备用块1进行重新计算，如果还不行就启用备用块2，直到结果合格。

        比如一个人口年龄分布情况统计，由3个冗余系统组成，主块率先进行计算，其他后备块不运行，对主块的统计结果进行验证。数据验证逻辑要求每个年龄段的占比在0%~100%之间，所有年龄段占比之和为100%。如果统计结果中80岁以上的人群占比120%,那么验证出主块计算结果有误，启用后备块1重新计算。以此类推。

        恢复块设计应保证实现主块和后备块之间的独立性，避免相关错误的产生，使主块和备份块之间的共性错误降到最低程度。当然,恢复块设计必须保证验证测试程序的正确性。

总结：设置了N个业务功能相同的独立系统，其中一个当主块，其他的备用，主块运行结果后，验证结果是否合格，不合格启用其中一个备用块重新运行，结果再验证，还不合格，再启用一个备用块重新运行。。。直到结果合格，再返回。

2).N版本程序控制(静态冗余)

静态的故障屏蔽技术，采用前向恢复的策略，当前正在执行的进程从执行到某一点时，并对损坏和丢失的数据进行补偿，某一点继续执行。

N版本程序设计是一种静态冗余系统设计的方法。所谓静态冗余，就是利用冗余资源把故障的后果屏蔽掉，而不对原有系统结构进行改变称之为静态冗余。

        有多个独立的团队进行开发相同版本的独立系统。将N个版本的运行结果进行汇总到表决器中，利用表决机制得到一个最终结果。通常应用在信号领域、硬件系统中，比如高铁信号系统，航空系统。假设有3个版本的同时运行，当一个系统运行出的结果偏差较大，利用少数服从多数的表决机制得到正确的结果。这样可以避免系统业务的突然中断，以及结果准确。

        N版本程序设计与通常的软件开发过程不同的是，它新增了三个新的阶段：相异成分规范评审，相异性确认，背对背测试。N版本程序设计中需要关注的问题是，不同版本间的程序同步，版本程序之间的通信，表决算法(全等表决、非精确表决，Cosmetie表决)、一致比较问题、数据相异性等。
 

总结：类似投票表决，设计出多个模块或不同版本（每个版本有不同的人独立设计，使用不同的方法、语言、工具等等），但是功能一样的，这样大家一起运行，每个版本的结果汇总由表决器的表决算法来决定正确结果，比如少数服从多数。

3).防卫式程序设计

对于程序中存在的错误和不一致性，通过在程序中包含错误检查代码和错误恢复代码，使得一旦错误产生，程序能够撤销错误状态，恢复到已知的正确状态中去。比如错误检测，破坏估计、错误恢复，以及常见的 try...catch...机制等。

        防卫式程序设计就是通过经验预判哪些地方可能会出现异常，然后提前在代码中添加好对应异常处理逻辑。

4).双机容错技术

这是一种软硬件结合的容错方案。该方案由两台服务器和一个外接共享磁盘阵列及相应的刷个那就软件组成。

◆双机容错系统采用“心跳”方法保证主系统与备用系统的联系。所谓心跳，是指主从系统之间相互按照一定的时间间隔发送通信信号，表明各自系统当前的运行状态。一旦心跳信号表明主机系统发生故障，或者备用系统无法收到主系统的心跳信号，则系统的高可用性管理软件认为主系统发生故障，立即将系统资源转移到备用系统上，备用系统替代主系统工作，以保证系统正常运行和网络服务不间断。

◆工作模式：双机热备模式；双机互备模式；双机双工模式。

• 双机热备模式就是两台服务器都部署对应的代码包，但是起初只有服务器A运行，服务器B不允许，利用心跳线或者其他通信机制，实时让主服务器A通知备用服务器B "A还在正常运行"。当B收不到心跳消息时，服务器B开机完成业务功能。
• 双机互备模式，就是两台服务器都是自身运行的主要业务的主服务器，其他业务的备用服务器。比如A服务器部署业务①和业务②，但是平常只有业务①运行，B服务器部署业务①和业务②，但是平常只有业务②行。当A服务器异常时，利用心跳机制让B启动业务①的运行。这种方法，当发生异常时资源利用率(资源压力）会变高，但是成本低。
• 双机双工模式，就是两台服务器都运行业务①和业务②。这样挂掉一台业务也不会立刻中断。它也是集群的一种。

5).集群技术

◆集群技术就是将多台计算机组织起来进行协同工作，它是提高系统可用性和可靠性的一种技术。在集群系统中，每台计算机均承担部分计算任务和容错任务，当其中一台计算机出现故障时，系统使用集群软件将这台计算机从系统中隔出离去，通过各计算机之间的负载转嫁机制完成新的负载分担，同时向系统管理人员发出警报。集群系统通过功能整合和故障过渡，实现了系统的高可用性和可靠性。

◆特点：可伸缩性、高可用性、可管理性、高性价比、高透明性。

◆分类：高性能计算集群、负载均衡集群、高可用性集群。

6).负载均衡

◆负载均衡是集群系统中的一项重要技术，可以提高集群系统的整体处理能力，也提高了系统的可靠性，最终目的是加快集群系统的响应速度，提高客户端访问的成功概率。集群的最大特征是多个节点的并行和共同工作，如何让所有节点承受的负荷平均，不出现局部过大负载或过轻负载的情况，是负载均衡的重要目的。

◆比较常用的负载均衡实现技术主要有以下几种：

• (1)基于特定软件的负载均衡(应用层)。很多网络协议都支持重定向功能，例如，基于HTTP重定向服务，其主要原理是服务器使用HTTP重定向指令，将一个客户端重新定位到另一个位置。服务器返回一个重定向响应，而不是返回请求的对象。客户端确认新地址然后重发请求，从而达到负载均衡的目的。
• (2)基于DNS的负载均衡属于传输层负载均衡技术，其主要原理是在DNS服务器中为同一个主机名配置多个地址，在应答DNS查询时，DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果，将客户端的访问引导到不同的节点上去，使得不同的客户端访问不同的节点，从而达到负载均衡的目的。
• (3)基于NAT的负载均衡。将一个外部IP地址映射为多个内部IP地址，对每次连接需求动态地转换为一个内部节点的地址，将外部连接请求引到转换得到地址的那个节点，上从而达到负载均衡的目的。
• (4)反向代理负载均衡。将来自Internet上的连接请求以反向代理的方式动态地转发给内部网络上的多个节点进行处理，从而达到负载均衡的目的。
• (5)混合型负载均衡。

恢复块和冗余联系与比较：

恢复块是针对粒度更小的操作，冗余是针对粒度大的子系统、系统等等。

恢复块方法更侧重于在运行时动态地处理和替换故障的代码块，而N版本程序设计则侧重于通过多个独立设计的版本之间的比较和多数表决来确保结果的正确性.

9.4.2检错技术

对无须在线容错的地方或不能采用冗余设计欸对部分，可靠性要求还高的，故障会导致严重后果的一般采用检错技术。

检错技术：发现故障及时报警，提醒维护人员处理。

优点：代价低于容错和冗余技术；缺点：不能自动解决故障，需要人工干预处理。

检错技术要着重考虑的要素：检测对象、检测时延、实现方式、处理方式。

1).检测对象：

检测点应考虑放在容易出错的地方和出错对软系统影响较大的地方；检测内容选取哪些有代表性的、易于判断的指标。

2).检测时延

从发生故障到检测到有一定的时延的，设计时应考虑，不能让时延影响到故障的报警。

3).实现方式

判断返回结果、超长正常范围、计算运行时间、置状态位等等

4).处理方式

大多是：查出故障--停止软件---报警，也有不停止的。

9.4.3降低复杂度设计

软件复杂度：分模块复杂度和结构复杂度。

模块复杂性： 主要包含模块内部数据流向和程序长度两个方面，结构复杂性：用不同模块之间的关联程度来表示。

9.4.4系统配置技术

1)双机热备技术

2)服务器集群技术

前面已经讲了。

9.5软件可靠性测试

 

9.5.1软件可靠性测试概述
9.5.2定义软件运行剖面

建模用马尔可夫链来完成，

用马尔可夫链将输入域编码为一个代表用户观点的软件使用的状态集。弧用来连接状态并表示由各种激励导致的转换，这些激励可能由硬件、人机接口或其他软件等产生。将转换概率分配给每个 弧，用来代表一个典型用户最有可能施加给系统的激励。这种类型的马尔可夫链是一个离散的 有限状态集，这类模型可以用有向图或转换矩阵表示。

定义运行剖面的下一步是开发使用模型，明确需要测试的内容。

9.5.3可靠性测试用例设计

一个典型的测试用例应该包括下列组成部分。

(1)测试用例标识。

(2)被测对象。

(3)测试环境及条件。

(4)测试输入。

(5)操作步骤。

(6)预期输出。

(7)判断输出结果是否符合标准。

(8)测试对象的特殊需求。

9.5.4可靠性测试的实施

在进行应用软件的可靠性测试前有必要检查软件需求与设计文档是否一致，检查软件开发

过程中形成的文档的准确性、完整性以及与程序的一致性，检查所交付程序和数据以及相应的

软件支持环境是否符合要求。

软件可靠性数据是可靠性评价的基础。

用时间定义的软件可靠性数据可以分为4类，这4类数据可以互相转化，具体内容如下。

(1)失效时间数据：记录发生一次失效所累积经历的时间。

(2)失效间隔时间数据：记录本次失效与上一次失效间的间隔时间。

(3)分组时间内的失效数：记录某个时间区内发生了多少次失效。

(4)分组时间的累积失效数：记录到某个区间的累积失效数。

在测试过程中必须真实地进行记录，每个测试记录必须包含如下信息。

(1)测试时间。

(2)含有测试用例的测试说明或标识。

(3)所有与测试有关的测试结果，包括失效数据。

(4)测试人员。

测试活动结束后要编写《软件可靠性测试报告》,对测试用例及测试结果在测试报告中加以

总结归纳。

测试报告应具备如下内容。

(1)软件产品标识。

(2)测试环境配置(硬件和软件)。

(3)测试依据。

(4)测试结果。

(5)测试问题。

(6)测试时间。

把可靠性测试过程进行规范化，有利于获得真实有效的数据，为最终得到客观的可靠性评

价结果奠定基础。

9.6软件可靠性评价

9.6.1软件可靠性评价概述

软件可靠性评价工作是指选用或建立合适的可靠性数学模型，运用统计技术和其他手段，对软件可靠性测试和系统运行期间收集的软件失效数据进行处理，并评估和预测软件可靠性的过程。这个过程包含如下3个方面。

(1)选择可靠性模型。

(2)收集可靠性数据。

(3)可靠性评估和预测。

9.6.2怎样选择可靠性模型

针对可靠性模型的构成以及使用模型来进行可靠性评价的目的，可以从以下几个方面进行

比较和选择。

1.模型假设的适用性

模型假设是可靠性模型的基础，模型假设要符合软件系统的现有状况，或与假设冲突的因素在软件系统中应该是可忽略的。

2.预测的能力与质量

预测的能力与质量是指模型根据现在和历史的可靠性数据，预测将来的可靠性和失效概率

的能力，以及预测结果的准确程度。

在满足其他条件的前提下，应尽量选用比较成熟、应用较广的模型作为分析模型。

3.模型输出值能否满足可靠性评价需求

使用模型进行可靠性评价的最终目的，是想得到软件系统当前的可靠性定量数据，以及预

测一定时间后的可靠性数据，可以根据可靠性测试目的来确定哪些模型的输出值满足可靠性评

价需求。一般来说，最重要的几个需要精确估计的可靠性定量指标包括如下内容。

(1)当前的可靠度。

(2)平均无失效时间。

(3)故障密度。

(4)期望达到规定可靠性目标的日期。

(5)达到规定的可靠性目标的成本要求。

4.模型使用的简便性

模型使用的简便性一般包含如下3层含义。

(1)模型需要的数据在软件系统中应该易于收集，而且收集需要投入的成本不能超过可靠

性计划的预算。

(2)模型应该简单易懂，进行可靠性分析的软件测试人员不会花费太多的时间去研究专业

的数学理论，他们只需要知道哪些假设适用，需要收集哪些数据，能够得到哪些分析结果就可

以了。

(3)模型应该便于使用，最好能用工具实现数据的输入。也就是说，测试人员除了输入可

靠性数据外，不需要深入模型内部进行一些额外的工作。

9.6.3可靠性数据的收集

可靠性数据主要是指软件失效数据，是软件可靠性评价的基础，主要是在软件测试、实施阶段收集的。

数据的收集工作的困难：

1). 可靠性数据的规范不统一，对软件进行度量的定义混乱不清。

2). 数据收集工作的连续性不能保证。

3). 缺乏有效的数据收集手段。

4). 数据的完整性不能保证。

5). 数据质量和准确性不能保证。

为解决困难的办法：

1).及早确定所采用的可靠性模型，以确定需要收集的可靠性数据，并明确定义可靠性数

据规范中的一些术语和记录方法制定标准的可靠性数据记录和统计表格等。

2).制订可实施性较强的可靠性数据收集计划，指定专人负责，抽取部分开发人员、质量保证人员、测试人员、用户业务人员参加，按照统一的规范收集记录可靠性数据。

3).视软件测试特别是可靠性测试产生的测试数据的整理和分析，因为这部分数据是用模拟软件实际运行环境的方法、模拟用户实际操作的测试用例测试软件系统产生的数据，对软件可靠性评价和预测有较高的实用价值。

4).充分利用数据库来完成可靠性数据的存储和统计分析。一方面减少数据管理的混乱，

一方面提高数据处理的效率。

9.6.4软件可靠性的评估和预测

软件可靠性的评估和预测的主要目的，是为了评估软件系统的可靠性状况和预测将来一段时间的可靠性水平。

可靠性评价标准：

(1)判断是否达到了可靠性目标，是否达到了软件付诸使用的条件，是否达到了中止测试

的条件。

(2)如未能达到，要再投入多少时间、人力和资金才能达到可靠性目标或投入使用。

(3)在软件系统投入实际运行一年或若干时间后，经过维护、升级和修改，软件能否达到

交付或部分交付用户使用的可靠性水平。

软件可靠性评价技术和方法主要依据选用的软件可靠性模型，其来源于统计理论。软件可

靠性评估和预测以软件可靠性模型分析为主，但也要在模型之外运用一些统计技术和手段对可

靠性数据进行分析，作为可靠性模型的补充、完善和修正。这些辅助方法如下。

(1)失效数据的图形分析法。运行图形处理软件失效数据，可以直观地帮助人们进行分析，

图形指标如下。

①累积失效个数图形。

②单位时间段内的失效数的图形。

③失效间隔时间图形。

(2)试探性数据分析技术(Exploratory Data Analysis,EDA)。对于失效数据图形进行一定

的数字化分析，能发现和揭示出数据中的异常。对可靠性分析有用的信息如下。

①循环相关。

②短期内失效数的急剧上升。

③失效数集中的时间段。

这种分析方法常可以发现因排错引入新的缺陷、数据收集的质量问题及时间域的错误定义

等问题。