9. 软件可靠性基础知识

1 软件可靠性基本概念

1.1 软件可靠性定义

  • 软件可靠性:在规定条件下,软件执行规定功能的能力。
  • 特点
    1. 复杂性:软件内部逻辑复杂。
    2. 物理退化:硬件失效影响。
    3. 唯一性:软件唯一,无替代品。
    4. 版本更新较快。给软件可靠性评估带来较大的难度。

1.2 软件可靠性的定量描述

1.2.1 规定时间

  • 定义:自然时间、运行时间、执行时间。
  • 公式:R(t)=1F(t)R(t) = 1 - F(t)

1.2.2 软件失效概率

  • 定义:软件失效的概率。
  • 公式:F(t)=1R(t)F(t) = 1 - R(t)

1.2.3 可靠度

定义:软件在规定时间内不失效的概率。

1.2.4 失效强度

定义:单位时间内软件系统出现失效的概率。

1.2.5 平均失效时间

定义:系统平均失效前的平均工作时间。

1.2.6 平均恢复前时间

定义:平均恢复到修复成功的时间。

1.2.7 平均故障间隔时间

定义:两次故障间的平均时间。

1.3 可靠性目标

  • 定义:软件缺陷对软件运行的影响程度。
  • 影响:成本、修复和恢复成本、现有或潜在的业务机会损失。
  • 划分:按成本影响和对系统能力的影响。

按照成本影响划分失效严重程度类

  1. 成本 > 100 万元:1
  2. 10 万元 < 成本 ≤ 100 万元:2
  3. 1 万元 < 成本 ≤ 10 万元:3
  4. 0.1 万元 < 成本 ≤ 1 万元:4
  5. 成本 < 0.1 万元:5

失效影响系统能力的影响划分失效严重程度类

  1. 部分操作无响应,但可用其他操作方式替代:1
  2. 用户重复操作无响应,可恢复:2
  3. 系统出错停止响应,重要数据可恢复:3
  4. 系统崩溃,重要数据不可恢复:4

1.4 可靠性测试的意义

  1. 软件失效可能造成灾难性的后果。
  2. 软件的失效在整个计算机系统失效中的比例较高
  3. 相比硬件可靠性技术,软件可靠性技术很不成熟,这就加剧了软件可靠性问题的重要性。
  4. 与硬件元器件成本急剧下降形成鲜明对比的是,软件费用呈有增无减的势头,而软件可靠性问题是造成费用增长的主要原因之一。
  5. 软件对生产活动和社会生活的影响越来越大,从而增加了软件可靠性问题在软件工程领域乃至整个计算机工程领域的重要性。

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

广义的软件可靠性测试是指为了最终评价软件系统的可靠性而运用建模、统计、试验、分析和评价等一系列手段对软件系统实施的一种测试。

狭义的软件可靠性测试是指为了获取可靠性数据,按预先确定的测试用例,在软件的预期使用环境中,对软件实施的一种测试。狭义的软件可靠性测试也叫“软件可靠性试验”(Software Reliability Test), 它是面向缺陷的测试。

可靠性测试的目的可归纳为以下 3 个方面。

  1. 发现软件系统在需求、设计、编码、测试和实施等方面的各种缺陷。
  2. 为软件的使用和维护提供可靠性数据。
  3. 确认软件是否达到可靠性的定量要求。

2 软件可靠性建模

2.1 影响软件可靠性的因素

  • 运行剖面(环境):软件可靠性定义是相对运行环境而言的。
  • 软件规模:软件规模越大,可靠性越低。
  • 软件内部结构、结构对软件可靠性的影响:内部结构越复杂,软件可靠性越低。
  • 开发方法和开发环境:开发方法影响软件可靠性。
  • 软件的可靠性投入。

2.2 软件可靠性的建模方法

  1. 模型假设
  • 代表性假设:软件失效独立发生。
  1. 性能度量。
  • 软件可靠性模型的输出量就是性能度量,如失效强度、残留缺陷数等。在软件可靠性模型中性能度量通常以数学表达式给出。
  1. 参数估计方法
  • 估计参数值。
  1. 数据要求
  • 一个软件可靠性模型要求一定的输入数据,即软件可靠性数据。不同类型的软件可靠性模型可能要求不同类型的软件可靠性数据。

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

  1. 基于可靠的假设。
  2. 简单。
  3. 计算一些有用的量。
  4. 给出未来失效行为的好的映射。
  5. 可广泛应用。

2.3 软件的可靠性模型分类

一个有效的软件可靠性模型应尽可能地将上面所述的因素在软件可靠性建模时加以考虑,尽可能简明地反映出来。

自1972年第一个软件可靠性分析模型发表的30多年来,这些可靠性模型大致可分为如下 10 类。

  • 种子法模型。
  • 失效率类模型。
  • 曲线拟合类模型。
  • 可靠性增长模型。
  • 程序结构分析模型。
  • 输入域分类模型。
  • 执行路径分析方法模型。
  • 非齐次泊松过程模型。
  • 马尔可夫过程模型。
  • 贝叶斯分析模型。

3 软件可靠性管理

  • 定义:软件可靠性管理是软件工程管理的一部分,旨在全面提高和获取软件可靠性,贯穿于软件开发全过程。
  • 内容:包括软件工程各个阶段的可靠性活动的目标、计划、进度、任务和修正措施等。

3.1 需求分析阶段

  • 确定可靠性目标和影响因素。
  • 确定验收标准和管理框架。
  • 制定文档编写规范和活动计划。
  • 确定数据收集规范。

3.2 概要设计阶段

  • 确定可靠性度量和验收方案。
  • 进行可靠性设计。
  • 收集数据和调整计划。
  • 编制详细计划和文档。

3.3 详细设计阶段

  • 进行可靠性设计和预测。
  • 调整计划和收集数据。
  • 明确后续计划和编制文档。

3.4 编码阶段

  • 进行可靠性测试和排错。
  • 调整计划和收集数据。
  • 明确后续计划和编制文档。

3.5 测试阶段

  • 进行可靠性测试和排错。
  • 进行建模、评价和调整计划。
  • 收集数据和编制文档。

3.6 实施阶段

  • 进行测试、排错和数据收集。
  • 调整模型和评价。
  • 编制文档。

挑战:可靠性管理目前难以量化,需要长期研究和改进。

4 软件可靠性设计

  • 定义:软件可靠性设计是软件设计的一部分,必须在软件的总体设计框架中使用,并且不能与其他设计原则相冲突。
  • 目标:在满足质量要求的前提下,以提高和保障软件可靠性为最终目标。
  • 原则:应确定软件的可靠性目标,不能无限扩大,并且排在功能、用户需求和开发费用之后考虑。
  • 技术:软件可靠性设计技术主要有容错设计、检错设计和降复杂度设计等技术。

4.1 容错设计技术

对于软件失效后果特别严重的场合,如飞机的飞行控制系统、空中交通管制系统或反应堆安全控制系统等,可采用容错设计方法。

4.1.1 恢复块设计

  • 定义:程序的执行过程可以看成是由一系列操作构成的,这些操作又可由更小的操作构成。恢复设计就是选择一组操作作为基本单元,从而把普通的程序变成恢复块。被选择用来构成恢复块的程序块可以是模块、过程、子程序和程序段等。
  • 特点:一个恢复块包含有若干个功能相同、设计差异的程序文本,每一时刻有一个文本处于执行状态。一旦该文本出现故障,则用备份文本加以替换,从而构成“动态冗余”。软件容错的恢复执行过程就是软件包含有一系列恢复块。

4.1.2 N 版本程序设计

  • 核心:是通过设计出多个模块或不同版本,对于相同初始条件和相同输入的操作结果,实行多数表决,防止其中某一模块或版本的故障提供错误的服务,以实现软件容错。
  • 注意:使软件的需求说明具有完全性和精确性。这是保证软件设计结果不相关的前提,因为软件的需求说明是不同设计组织和人员的唯一共同的依据。

4.1.3 冗余设计

  • 定义:在主运行的系统之外备用额外的元件或系统,如果出现一个元件故障或系统故障,则立即更换冗余的元件或启动冗余的系统,则该硬件系统仍可以维持运行。
  • 注意:在软件系统中,冗余技术的运用有所区别。如果采用相同的软件系统互为备份,其意义不大,因为在相同的运行环境中,一旦软件出现故障的地方,冗余备份的软件系统互为备份,其意义不大,因为在相同的运行环境中,一旦软件出现故障的地方,冗余备份的软件系统也很有可能出现同样的故障。
  • 优点:软件的冗余设计技术实现的策略是在一套完整的软件系统之外,设计一种不同的路径、不同算法或不同实现方法的模块或系统作为备份,在出现故障时可以使用冗余的部分进行替换,从而维持软件系统的正常运行。
  • 结论:采用冗余技术设计软件所增加的额外费用远远低于重新设计一个版本软件的费用。冗余设计还有可能导致软件运行时所花费的存储空间、内存消耗以及运行时间有增加,这就需要在可靠性要求和额外付出代价之间做出折中。

4.2 检错技术

  • 目的:在软件系统中,对于无法在线容错或不能采用冗余设计技术的部分,采用检错技术以满足高可靠性要求。
  • 实现:通过在软件出现故障后及时发现并报警,提醒维护人员进行处理。
  • 缺点:不能自动解决故障,若不进行人工干预,可能导致软件系统不能正常运行。
  • 考虑因素
    1. 检测对象:包括检测点和检测内容,应放在易出错和影响大的地方,选取有代表性的、易于判断的指标。
    2. 检测延时:从故障发生到被检测出的时间,需考虑检测延时对故障处理的影响。
    3. 实现方式:直接判断返回结果或计算运行时间等,根据实际情况选用。
    4. 处理方式:大多数采用“查出故障—停止软件系统运行—报警”的方式,也有采用不停止或部分停止软件系统运行的情况。
  • 总结:检错技术实现代价低于容错技术和冗余技术,但需人工干预以解决故障。

4.3 降低复杂度设计

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

降低复杂度设计的思想就是在保证实现软件功能的基础上,简化软件结构,缩短程序代码长度,优化软件数据流向,降低软件复杂度,从而提高软件可靠性。

4.4 系统配置技术

通常在系统配置中可以采用相应的容错技术,通过系统的整体来提供相应的可靠性,主要有双机热备技术和服务器集群技术。

双机热备技术是一种软硬件结合的较高容错应用方案。该方案是由两台服务器系统和一个外接共享磁盘阵列柜和相应的双机热备份软件组成。双机热备方案中,根据两台服务器的工作方式可以有3种不同的工作模式,即:双机热备模式、双机互备模式和双机双工模式。

集群内各结点服务器通过内部局域网相互通信,当某结点服务器发生故障时,这台服务器上所运行的应用程序将在另一结点服务器上被自动接管。

5 软件可靠性测试

5.1 软件可靠性测试概述

软件可靠性测试由可靠性目标的确定、运行剖面的开发、测试用例的设计、测试实施、测试结果的分析等主要活动组成。

软件可靠性测试还必须考虑对软件开发进度和成本的影响,最好是在受控的自动测试环境下,由专业测试机构完成。

软件可靠性测试是一种有效的软件测试和软件可靠性评价技术。

软件可靠性测试要在工程上获得广泛应用,还有许多实际问题需要解决。

5.2 定义软件运行剖面

定义运行剖面首先需要为软件的使用行为建模,建模可以采用马尔可夫链来完成。

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

开发使用模型涉及将输入域分层,有两种类型的分层形式:用户级分层和用法级分层。用户级分层考虑各种类型的用户以及他们如何使用系统;用法级分层则要求考虑系统能够提供的所有功能。一旦用户和用法模型被开发出来,弧上的概率将被分配。这些概率估计主要是基于如下几个方面。

  1. 从现有系统收集到的数据。
  2. 与用户的交谈或对用户进行观察获得的信息。
  3. 原型使用与测试分析的结果。
  4. 相关领域专家的意见。

一个产品有可能需要开发多个运行剖面,这取决于它所包含的运行模式和关键操作,通常需要为关键操作单独定义运行剖面。

5.3 可靠性测试用例设计

为了对软件可靠性进行良好的预计,必须在软件的运行域上对其进行测试。首先定义一个相应的剖面来镜像运行域,然后使用这个剖面驱动测试,这样可以使测试真实地反映软件的使用情况。

由于可能的输入几乎是无限的,测试必须从中选择出一些样本,即测试用例。测试用例要能够反映实际的使用情况,反映系统的运行剖面。

设计测试用例就是针对特定功能或组合功能设计测试方案,并编写成文档。一个典型的测试用例应该包括下列组成部分

  1. 测试用例标识。
  2. 被测对象。
  3. 测试环境及条件。
  4. 测试输入。
  5. 操作步骤。
  6. 预期输出。
  7. 判断输出结果是否符合标准。
  8. 测试对象的特殊需求。

可靠性测试的主要目的是评估软件系统的可靠性。但除了常规的测试用例集仍然适用外,还要着重考虑和可靠性密切相关的一些特殊情况。在测试中,可以考虑进行“强化输入”,即比正常输入更恶劣(合理程度的恶劣)的输入。

5.4 可靠性测试的实施

可靠性测试前有必要检查软件需求与设计文档是否一致,检查软件开发过程中形成的文档的准确性、完整性以及与程序的一致性,检查所交付程序和数据以及相应的
软件支持环境是否符合要求。

如果非统计测试在可靠性测试之前完成,由统计测试产生的统计数据仍然有效。但是在可靠性测试之后执行非统计测试,可能会影响软件可靠性评估的准确性。

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

  1. 测试时间。
  2. 含有测试用例的测试说明或标识。
  3. 所有与测试有关的测试结果,包括失效数据。
  4. 测试人员。

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

把可靠性测试过程进行规范化,有利于获得真实有效的数据,为最终得到客观的可靠性评价结果奠定基础。

6 软件可靠性评价

6.1 软件可靠性评估概述

软件可靠性评估是软件可靠性活动的重要组成部分,既适用于软件开发过程,也可针对最终软件系统。

对软件可靠性测试和系统运行期间收集的软件失效数据进行处理,并评估和预测软件可靠性的过程。这个过程包含如下 3 个方面:

  1. 选择可靠性模型。
  2. 收集可靠性数据。
  3. 可靠性评估和预测。

### 6.2 怎样选择可靠性模型

选择可靠性模型时,应考虑以下几个方面:

1. 模型假设的适用性
   - 模型假设应符合软件系统的现有状况,忽略冲突因素。
2. 预测的能力与质量
   - 模型应能准确预测软件系统的可靠性和失效概率。
3. 模型输出值能否满足可靠性评价需求
   - 模型应能提供当前可靠度、平均失效时间、故障密度等关键指标。
4. 模型使用的简便性
   - 模型应易于使用,数据收集成本不应超过预算,且易于分析和理解。

### 6.3 可靠性数据的收集

可靠性数据的收集是软件可靠性评估的重要基础,主要来源于软件测试和实施阶段。收集时需注意:

1. 数据收集的规范性
   - 明确数据收集方法,如时间、失效严重程度等。
2. 数据收集工作的连续性
   - 确保数据收集的持续性,避免间断。
3. 数据收集的有效性
   - 使用有效的数据收集工具,确保数据完整性。
4. 数据质量的可靠性
   - 确保数据质量,避免虚假和不准确的数据。
5. 数据收集的简便性
   - 简化数据收集流程,提高效率。

### 6.4 软件可靠性的评估和预测

评估和预测软件可靠性的主要目的是:

1. 判断是否达到可靠性目标
   - 确定软件是否满足预定的可靠性要求。
2. 如未达到,需再投入多少时间、人力和资金
   - 评估达到目标所需的额外资源。
3. 在软件系统投入实际运行一年或若干时间后
   - 评估软件的可靠性水平。

常用的评估和预测方法包括统计分析和模型分析,需结合软件的测试数据和失效数据进行。