|
|
| 在现代军事和商用系统中，以软件为核心的产品得到了广泛的应用。随着系统中软件成分的不断增加，使得系统对软件的依赖性越来越强，对软件可靠性的要求也越来越高。目前硬件可靠性测试技术和评估手段日趋成熟，硬件可靠性评估模型经过长期的实践积累，已经得到了业界的认可。但是由于软件和硬件存在着巨大的差异性，硬件的可靠性测试和评估技术，并不能完全应用于对软件的可靠性的测试和评估中。因此软件可靠性技术研究成为当今可靠性工程研究领域中一个新的领域。
|
|
|
| 国外从20世纪60年代后期开始加强对软件可靠性的研究工作，经过20年左右的研究，推出了各种可靠性模型和预测方法，于1990年前后形成了较为系统的软件可靠性工程体系。同时，从20世纪80年代中期开始，西方各主要工业强国均确立了专门的研究计划和课题，如英国的AIVEY（软件可靠性和度量标准）计划、欧洲的ESPRIT（欧洲信息技术研究与发展战略）计划、SPMMS（软件生产和维护管理保障）课题、Eureka（尤里卡）计划等。每年，都有大量的人力物力投入到软件可靠性研究项目中，并取得了一定的成果。
|
|
|
| 国内对于软件可靠性的研究工作起步较晚，在软件可靠性量化理论、度量标准（指标体系）、建模技术、设计方法、测试技术等方面与国外差距较大。
|
|
|
| 目前，软件可靠性管理方面还没有建立起具有权威性的管理体系和规范。比如，如何描述软件可靠性，如何测试、如何评估、如何设计、如何提高等。由于目前国内外对于软件可靠性模型的研究多集中在软件的开发阶段，而很少有涉及测试与评估阶段的可靠性模型，即使现有的模型，也多来源于硬件可靠性评估，与软件可靠性评估存在较大的差距，所以从事软件可靠性测试与评估研究是一个有理论价值和实际意义工作。总的来说，软件可靠性工程研究虽然得到了普遍的重视，但仍然不是很成熟，还处于发展确立阶段。
|
|
|
|
|
| 可靠性（reliability）是指产品在规定的条件下和规定的时间内完成规定功能的能力。
|
|
|
| 按照产品可靠性的形成，可靠性可分为固有可靠性和使用可靠性。固有可靠性是通过设计、制造赋予产品的可靠性；使用可靠性既受设计、制造的影响，又受使用条件的影响。一般使用可靠性总低于固有可靠性。
|
|
|
| 软件与硬件有很多不同点，但从可靠性的角度来看，它们主要有4个不同点：
|
|
|
|
|
| 软件内部逻辑高度复杂，硬件则相对简单，这就在很大程度上决定了设计错误是导致软件失效的主要原因，而导致硬件失效的可能性则很小。
|
|
|
|
|
| 软件不存在物理退化现象，硬件失效则主要由于物理退化所致。这就决定了软件正确性与软件可靠性密切相关，一个正确的软件任何时刻均可靠。然而，一个正确的硬件元器件或系统，则可能在某个时刻失效。
|
|
|
|
|
| 软件是惟一的，软件拷贝不改变软件本身，而任何两个硬件不可能绝对相同。这就是为什么概率方法在硬件可靠性领域取得巨大成功，而在软件可靠性领域不令人满意的原因。
|
|
|
|
|
| 硬件通常更新周期较慢，硬件产品一旦定型一般就不会更改，而软件产品通常受需求的变更，软件缺陷的修复，造成软件版本更新较快，这也给软件可靠性评估带来较大难度。
|
|
|
| 尽管这样，软件仍然是一种具有特殊属性的产品，因此，我们也可以按照上面的产品可靠性定义来框架性地描述软件的可靠性。
|
|
|
| 1983美国IEEE计算机学会对“软件可靠性”做出了更为明确的定义，随后，此定义经美国标准化研究所批准为美国的国家标准。在1989年我国国家标准GB/T-11457也采用了这个定义。这个定义就是：
|
|
|
| . 在规定的条件下，在规定的时间内，软件不引起系统失效的概率，该概率是系统输入和系统使用的函数，也是软件中存在的缺陷的函数；系统输入将确定是否会遇到已存在的缺陷（如果缺陷存在的话）。
|
|
|
| . 在规定的时间周期内，在所述条件下程序执行所要求的功能的能力。
|
|
|
| 显而易见，美国IEEE计算机学会关于“软件可靠性”的定义仍然沿用了“产品可靠性”的定义，但有了更具体的定位和更深入的描述。
|
|
|
|
|
|
|
| 软件可靠性只是体现在其运行阶段，所以将“运行时间”作为“规定的时间”的度量。“运行时间”包括软件系统运行后工作与挂起（开启但空闲）的累计时间。由于软件运行的环境与程序路径选取的随机性，软件的失效为随机事件，所以运行时间属于随机变量。
|
|
|
|
|
| 规定的条件主要指软件的运行环境。它涉及软件系统运行时所需的各种支持要素，如支持硬件平台（服务器、台式机、网络平台等）、操作系统、数据库管理系统、中间件以及其他支持软件、输入数据格式和范围以及操作规程等。不同的环境条件下软件的可靠性是不同的，具体地说，规定的环境条件主要是描述软件系统运行时计算机的配置情况以及对输入数据的要求，并假定其他一切因素都是理想的。有了明确规定的环境条件，还可以有效地判断软件失效的责任在用户方还是开发方。
|
|
|
|
|
| 软件可靠性还与规定的任务和功能有关。由于要完成的任务不同，软件的运行情况会有所区别，则调用的子模块就不同（包括程序选择路径不同），其可靠性也就可能不同。所以要准确度量软件系统的可靠性，必须首先明确它的任务和功能。
|
|
|
|
|
| ①用内在的“缺陷”和外在的“失效”的关系来描述可靠性，更能深刻地体现软件的本质特点。
|
|
|
| ②定义使人们对软件可靠性进行量化评估成为可能。对于软件的可靠性这样一个质量特性，很难用一个明确直观的数值去体现。而依据这个定义，我们有可能通过分析影响可靠性的因素，用函数的形式，按照不同的目的建立各种数学模型去分析软件可靠性。
|
|
|
| ③用概率的方法去描述可靠性是比较科学的。前面讲到，软件失效是随机的外部表现，完全是一个随机事件，而软件缺陷是软件固有的没有损耗的内在特质。定义用规定时间内一定的操作不出现软件失效的概率，也就是输入未碰到软件缺陷的概率，来描述可靠性，这种方法就是用概率来描述纯粹的随机事件，是比较合理的，也是可行的。
|
|
|
|
|
| 前一节从软件可靠性的定义我们可以看到，软件的可靠性可以基于使用条件、规定时间、系统输入、系统使用和软件缺陷等变量构建的数学表达式。下面我们从可靠性的定义中的术语“规定时间”、“失效概率”开始，探讨软件可靠性的定量描述，并相应地引入一些概念。
|
|
|
|
|
| 首先对于“规定时间”我们有三种概念，一种是自然时间，也就是日历时间，指我们日常计时用的年、月、周、日等自然流逝的时间段；一种是运行时间，指软件从启动开始，到运行结束的时间段；最后一种是执行时间，指软件运行过程中，中央处理器（CPU）执行程序指令所用的时间总和。
|
|
|
| 例如某单位有一套供会计人员使用的财务软件，我们来关注一整天的时间，上午9:00上班开机运行，下午5:00下班退出程序。在这里，自然时间是一天，也就是24小时，运行时间是8个小时，而CPU处理程序的执行时间可能不到2小时，这要视会计的业务繁忙状况、使用软件的频度和软件本身的设计而定。
|
|
|
| 很明显，在这三种时间中，我们度量软件的可靠性，使用执行时间最为准确，效果也最好。如果运行的软件系统处于一种相对稳定的工作状态，我们可以根据一定的经验值，按一定的换算比例，对这三种时间进行折算。
|
|
|
|
|
| 我们把软件从运行开始，到某一时刻t为止，出现失效的概率看作关于软件运行时间的一个随机函数，用F（t）表示。根据我们对软件可靠性的分析，函数F（t）有如下特征：
|
|
|
|
|
|
|
| .F（+∞）=1，即失效概率在运行时间不断增长时趋向于1，这也和“任何软件都存在缺陷”的思想相吻合。
|
|
|
| 为了简化分析，我们把F（t）看作关于时间t的一个连续函数，并且可导。
|
|
|
|
|
| 我们用来表示可靠性最为直接的方式就是可靠度，根据可靠性的定义，可靠度就是软件系统在规定的条件下，规定的时间内不发生失效的概率，如果用F（t）来表示到t时刻止，软件不出现失效的概率，则可靠度的公式为
|
|
|
|
|
|
|
|
|
| 失效强度（Failure Intensity）的物理解释就是单位时间软件系统出现失效的概率。在t时刻到t+Δt时刻之间软件系统出现失效的平均概率为（F（t+Δt）-F(t)）/Δt，当Δt趋于很小时，就表现为t时刻的失效强度。用f（t）表示失效强度函数，则
|
|
|
|
|
|
|
| 失效率（Failure Rate）又称风险函数（Hazard Function），也可以称为条件失效强度，物理解释就是在运行至此软件系统未出现失效的情况下，单位时间软件系统出现失效的概率。具体用数学用语来描述，就是当软件在0～t时刻内没有发生失效的条件下，t时刻软件系统的失效强度，用λ（t）表示失效率，则
|
|
|
|
|
| 代入公式（15-1）可得从可靠度到失效率的转换表达式：
|
|
|
|
|
|
|
| 我们知道，在0时刻，可靠度R（0）为1，对公式（15-4）一阶常微分方程求解可得：
|
|
|
|
|
| 假设软件系统的失效率为常数时，由公式15-5可得：
|
|
|
|
|
| 当失效率λ（t）与时间t之积，也就是tλ（t）<0.05时，公式15-6可简化为
|
|
|
|
|
|
|
|
|
|
|
| 当可靠度R（t）大于0.95时，公式15-6可简化为
|
|
|
|
|
|
|
|
|
| 平均无失效时间（MTTF）（Mean Time to Failure）就是软件运行后，到下一次出现失效的平均时间。通常平均无失效时间更能直观地表明一个软件的可靠程度。用θ表示平均无失效时间MTTF，则可得：
|
|
|
|
|
|
|
|
|
|
|
|
|
| 当我们讨论完对软件可靠性的定量描述问题之后，需要对软件可靠度这个直接反映软件可靠性的度量指标作下列补充说明。
|
|
|
| . 描述的软件对象必须明确，即需指明它与其他软件的界限。
|
|
|
|
|
| . 必须假设硬件无故障（失效）和软件有关变量的输入值正确。
|
|
|
| . 运行环境包括硬件环境、软件支持环境和确定的软件输入域。
|
|
|
| . 规定的时间必须指明时间基准，可以是自然时间（日历时间）、运行时间、执行时间（CPU时间），或其他时间基准。
|
|
|
| . 软件无失效运行的机会通常以概率度量，但也可以模糊数学中的可能性加以度量。
|
|
|
| . 上述定义是在时间域上进行的，这时软件可靠度是一种动态度量。也可以是在数据域上将软件可靠度定义为一种表态度量，表示软件成功执行一个回合的概率，软件回合（Run）是指软件在规定环境下的一个基本执行过程，如给定一组输入数据，到软件给定相应的输出数据这一过程。软件回合是软件运行的最小的、不可分的执行单位，软件的运行过程由一系列软件回合组成。
|
|
|
| . 有时将软件运行环境简单地理解为软件运行剖面（operational profile）。欧空局（ESA）标准PSS-01-21（1991）“ESA软件产品保证要求”中，定义“软件运行剖面”为：“对系统使用条件的定义。系统的输入值都用其按时间的分布或按它们在可能输入范围内的出现概率的分布来定义”。简单来说，运行剖面定义了关于软件可靠性描述中的“规定条件”，也就相当于可靠性测试中需要考虑的测试环境、测试数据等一系列问题。
|
|
|
|
|
| 前面我们定量分析软件的可靠性时，使用失效强度来表示软件缺陷对软件运行的影响程度。然而在实际情况中，对软件运行的影响程度不仅取决于软件失效发生的概率，还和软件失效的严重程度有很大关系。这里我们引出另外一个概念，失效严重程度类（failure severity class）。
|
|
|
| 失效严重程度类就是对用户具有相同程度影响的失效集合。
|
|
|
| 对失效严重程度的分级可以按照不同的标准进行，最为常见的是按对成本影响、对系统能力的影响等标准划分软件失效的严重程度类。
|
|
|
| 对成本的影响可能包括失效引起的额外运行成本、修复和恢复成本、现有或潜在的业务机会的损失等。由于失效严重程度类的影响分布很广泛，为了按照一定数量的等级去定义失效严重程度类，我们通常用数量级去划分等级。
|
|
|
| 下表给出了一个按照对成本的影响划分失效严重程度类的例子，这个例子涉及到的软件系统是某电子商务运营系统。
|
|
|
|
|
|
|
| 对系统能力的影响常常表现为关键数据的损失、系统异常退出、系统崩溃、导致用户操作无效等。对于不同性质的软件系统，相同的表现可能造成的失效严重程度是不同的，比如对可用性要求较高的系统，导致长时间停机的失效常常会划分到较高的严重级别中去。
|
|
|
| 下表给出了一个按照对系统能力的影响划分失效严重程度类的例子，这个例子涉及到的软件系统是某电信实时计费系统。
|
|
|
|
|
|
|
| 有了失效严重程度的划分，我们现在可以结合失效强度来定量地表示一个软件系统的可靠性目标了。
|
|
|
| 可靠性目标是指客户对软件性能满意程度的期望。通常用可靠度、故障强度、平均无故障时间（MTTF）等指标来描述，根据不同项目的不同需要而定。建立定量的可靠性指标需要对可靠性、交付时间和成本进行平衡。为了定义系统的可靠性指标，必须确定系统的运行模式，定义故障的严重性等级，确定故障强度目标。
|
|
|
| 例如，对于上表的例子，我们可以根据经验和用户的需求确定软件系统需要达到的可靠程度，按照前面的公式，换算成失效强度和平均无失效时间，如下表所示。
|
|
|
|
|
|
|
|
|
| 软件可靠性问题已被越来越多的软件工程专家所重视，人们已开始投入大量的人力、物力去研究软件可靠性的设计、评估、测试等课题。以下多个方面可以反映出软件可靠性问题对软件工程实践，乃至对生产活动和社会活动产生的深远的影响。
|
|
|
| . 软件失效可能造成灾难性的后果。一个最显著的例子就是由于控制系统Fortran程序中少了个逗点，致使控制系统未能发出正确的指令，最终使美国的一次宇宙飞行失败。而目前由于计算机和软件在各行各业中应用的日益广泛和深入，例如军用作战系统、民航指挥系统、银行支付系统、交通调控系统等，一旦发生严重级别的软件失效，轻则造成经济损失，重则危及人们的生命安全，危害国家安全。
|
|
|
| . 软件的失效在整个计算机系统失效中的比例较高。某研究机构曾经作过统计，在计算机系统的失效中，有80%和软件有关。原因是软件系统的内容结构太复杂了，一个较简单的程序，其所有的路径数就可能是一个天文数字。在软件开发的过程中，很难用全路径覆盖方式的测试去发现软件系统中隐藏的所有缺陷，也就是说，很难完全排除软件缺陷。
|
|
|
| . 相比硬件可靠性技术，软件可靠性技术很不成熟，这就加剧了软件可靠性问题的重要性。例如在硬件可靠性领域，故障树分析（FTA）、失效模式与效应分析（FMEA）技术等比较成熟，容错技术也有广泛应用，但在软件可靠性领域，这些技术似乎尚未定型。
|
|
|
| . 与硬件元器成本急剧下降形成鲜明对比的是，软件费用呈有增无减的势头，而软件可靠性问题是造成这种费用增长的主要原因之一。
|
|
|
| . 计算机技术获得日益广泛的应用，随着计算机应用系统中软件成分的不断增加，使得系统对于软件的依赖性越来越强，软件对生产活动和社会生活的影响越来越大，从而增加了软件可靠性问题在软件工程领域乃至整个计算机工程领域的重要性。
|
|
|
| 软件可靠性问题的重要性也凸显出了，发展以发现软件可靠性缺陷为目的的可靠性测试技术的迫切性。
|
|
|
|
|
| 广义的软件可靠性测试是指为了最终评价软件系统的可靠性而运用建模、统计、试验、分析、评价等一系列手段对软件系统实施的一种测试，一个完整的软件可靠性测试包括如下图所示的过程。
|
|
|
|
|
|
|
| 狭义的软件可靠性测试是指为了获取可靠性数据，按预先确定的测试用例，在软件的预期使用环境中，对软件实施的一种测试。狭义的软件可靠性测试也叫“软件可靠性试验（software reliability test）”，它是面向缺陷的测试，以用户将要使用的方式来测试软件，每一次测试代表用户将要完成的一组操作，使测试成为最终产品使用的预演。这就使得所获得的测试数据与软件的实际运行数据比较接近，可用于软件可靠性评价。
|
|
|
| 其实，软件可靠性测试是软件测试的一种形式，和易用性测试、性能测试、标准符合性测试等前面介绍的测试类型一样，是针对软件的某个重要质量特性，使用一定的测试用例对软件进行测试的过程。
|
|
|
| 可靠性测试是对软件产品的可靠性进行调查、分析和评价的一种手段。它不仅仅是为了用测试数据确定软件产品是否达到可靠性目标，还要对检测出的失效的分布、原因及后果进行分析，并给出纠正建议。总的来说，可靠性测试的目的可归纳为以下三个方面：
|
|
|
| ①发现软件系统在需求、设计、编码、测试、实施等方面的各种缺陷。
|
|
|
|
|
|
|
