一、软件失效机理
由于软件内部逻辑复杂，运行环境动态变化，并且不同的软件可能差异很大，因而软件失效机理可能有不同的表现形式。例如，有的失效过程比较简单，易于跟踪分析；有的失效过程可能非常复杂，难于甚至不可能进行详尽地描述和分析。因此，对于软件的失效机理及有关软件失效的基本概念，目前尚无统一的认识和定义。
为了避免在使用术语时造成歧义，首先应明确缺陷（defect）、故障（fault）、隐错或臭虫（bug）、错误（error）、失效（failure）等近义词汇的含义。
1.软件故障和缺陷、隐错或臭虫
软件故障和缺陷、隐错或臭虫是同义词，是存在于软件（包括说明文档、应用数据、程序代码等）之中的那些不期望的或不可接受的偏差。软件故障静态地存在于软件内部，是软件开发过程中人为错误的结果。例如缺少一个逗号、多一条语句等等。其后果是当软件运行于某一特定条件时将导致软件失效。
软件故障具有下列一些特征：
1）软件故障的固有性
软件故障主要源于人的失误和水平、能力的局限性。一旦软件开发结束后交付给用户，如果存在软件故障，那么它将一直潜伏于软件之中直到被发现或被修改。
2）软件故障对环境的敏感性
所谓环境，是指软件的运行环境（包括软硬件平台、软硬件配置和其他支撑软件）和输入环境（如应用对象、用户要求、输入数据等）。在大多数情况下，一个程序的运行，并不一定遍历程序的所有部分。程序中的各个部分可做多种不同的逻辑组合，形成不同的执行路径，从而实现不同的功能。而这些组合取决于输入环境，输入环境的改变决定了程序内部路径的重新组合。如果程序中有故障，并且程序的执行路径经过了故障点，那么必然会引起错误；如果程序的执行路径没有经过故障点，则不会引起错误；而对在一定输入环境下执行出错的程序，当退出该环境后，对于其他环境又可能正常执行，但当再次进入该环境时，程序又会出错。可见，软件故障对输入环境十分敏感。至于软件故障对运行环境的敏感性则更容易理解。一般在某一运行环境下开发和正常执行的程序，改换到另一运行环境下去执行，就会表现出许多的软件错误。
3）软件故障的传染性
软件一旦出错，如果不对软件故障进行纠正，那么其错误结果作为后续逻辑路径的输入必然使得运行结果不是程序本身所期望的合理结果，从而故障可能会一直存在并影响其他位置而发生错误，最终造成系统失效的后果。例如一个子程序的故障，通过子程序的调用可能传染调用者，通过进程间的通信，还可能传染更多其他的进程。
2.软件错误
软件错误是指系统运行时，引起或可能潜在的引起系统失效的软件故障。在大多数情况下，错误可被检测并排除，但是在某些情况下，仍然会有部分错误隐藏于软件内部之中。
软件错误和软件故障具有相同或十分近似的含义，在gb/t11457-89“软件工程术语”中没有刻意对这两个词加以区别。软件故障并非就一定会使软件出错，它只有在特定的条件下才会导致软件错误，在一般的情况下，软件仍然能够正常运行。
3.软件失效
软件失效是泛指程序在运行中丧失了全部或部分功能、出现偏离预期的正常状态的事件。预期的正常状态应以用户的需求为依据。
可见，软件错误是相对于软件而言的，是一种面向开发的概念，而软件失效则是一种面向用户的概念。一个错误在在没有被排除的情况下，可以使软件发生多次失效。相同的失效现象，可能由不同的错误所造成。
综上所述，软件失效机理可以概述为三个不同层次概念的因果关系。软件故障可以导致软件错误并最终造成系统的失效，因而软件故障是一切系统失效的根源。
二、软件失效的软划分
系统处于不同状态时，可能会发生多种不同类型的失效，这些失效对整个系统完成规定功能的影响程度千差万异，因而在研究处理措施时应按轻重缓急区别对待。当具体分析软件发生的某种失效的危害度（criticality，简称为cr）时，须考虑两个重要因素：失效发生的可能性（possibility，简称为po），和失效对系统影响的严重度（severity，简称为se）。不妨定义某种失效的危害度
cr=se×po，
显然，不同失效的危害性千差万别，当需考虑多种失效时，则可针对具体系统建立相应的复杂模型。
软件失效严重程度类是一个失效集合，其中失效发生时对用户产生相同影响。常见的分级标准包括对人员生命、成本和系统能力的影响。这些分级标准又包括很多子标准，不同的子标准对于特定的不同的应用系统来说可能非常重要。例如，成本影响可能包括额外的运行成本、修复和恢复成本、现有或潜在业务机会的损失；系统能力影响可能包括关键数据损失、可恢复性和停机时间等子标准。对于可应用性很重要的系统，导致更长时间停机的失效常常被分配更高的失效严重程度类。还需要注意的是，严重程度可以随失效发生的时间而发生变化。
在定义要使用的失效程度类时，经验表明最好的方法是集体讨论需要考虑的所有可能的导致失效的因素，然后逐步确定最重要的失效因素。有些因素是客观存在的，但是很难度量，例如对公司荣誉的影响，进而对市场份额产生的影响。
一般而言，软件失效严重程度类的影响分布很广泛，因而不可能很准确地估计影响。表1给出了一个根据成本硬性划分的失效严重程度类的例子，然而用户的实际评价在各个失效严重等级之间并不存在“非此即彼”的清晰分界点，相邻等级之间存在着“亦此亦彼”的性质。根据系统能力影响划分失效严重程度类，如表2所示，但该表中定义含混，没有进一步阐明“多项”、“关键”、“重要”、“小错误”等概念。
表1 根据成本划分的失效严重程度类
表2 根据系统能力影响划分失效严重程度类
putnam等将软件失效严重度分为4类：致命的（critical）、严重的（serious）、一般的（moderate）、轻微的（cosmetic）。
李德毅等将系统失效严重度分为5类：①保持系统“全部功能正常”的能力，即系统无任何失效；②保持系统“主要功能正常”的能力，即系统有弱失效；③保持系统“基本功能正常”的能力，即系统有失效，但尚能维持；④保持系统“最低功能”正常的能力，即失效已达到临界，再严重则不能容忍；⑤系统失去最低功能，即系统出现了致命失效。显然，这种划分同样适用于软件失效。
人类思维具有不确定性，我们习惯于且擅长用自然语言对失效的严重度和可能性进行软性划分。一般地，系统发生失效的严重度和可能性都可用自然语言中“很小”、“小”、“一般”、“大”、“很大”等五个定性概念来描述，我们称这五个语言值的集合构成一个软件失效评价概念集。若要从定量的角度分析，我们可以应用云模型有效地实现语言值表示的定性概念与其定量表示之间不确定性转换，从而可对软件失效程度的定量描述实现类似自然语言的软性划分。这些语言值都可适当地选用一些定义在论域[0, 1]上的云模型（通常采用云变换方法根据属性域中数据值的分布情况，自动生成一系列由云模型表示的基本概念，实现对论域的软划分，具体请参见附录）来表示。图1为相应的不确定定性定量表示转换示意图，其中“很小”、“很大”分别用半降云、半升云表示。
图1 软件失效严重度（或可能性）评价概念集的云图表示
三、软件失效数据
软件失效数据是整个软件可靠性分析和估测过程的工作基础，在整个软件可靠性工程的研究中，占据重要的地位。所收集的数据是否真实、准确和有效，是否满足模型要求，都直接影响到软件可靠性评估的准确性和可信性。因此，在研究软件可靠性模型之前，对软件失效数据做一个透彻的了解是非常必要的。
在实际研究工作中，通常将软件失效数据分为完全数据和不完全数据两大类。其定义如下：
定义3.1 数据集合{n（ti）|n（t0）=0,i=1,2, …,n}称为完全数据集合，如果
∃i∈{1,2, …,n}，有n（ti）-n（ti-1）=1，
其中：t0为初始时刻，ti表示累积时刻，n（ti）为时刻ti时的累积失效数。
定义3.2 数据集合{n（ti）|n（t0）=0,i=1,2, …,s}称为不完全数据集合，如果
∃i∈{1,2, …,s}，有n（ti）-n（ti-1）＞1，
其中：t0为初始时刻，ti表示累积时刻，n（ti）为直到时刻ti时的累积失效数。
显而易见，完全数据给出了每个失效发生的时间间隔，而不完全数据给出了在一定的时间间隔（不一定要求是均匀的）内的累积失效数。
由于软件中一个相同的错误可能会导致多次失效，并且若干个错误之间有时存在相关性，从而会降低所收集数据的精确度。因此，收集软件可靠性数据时，首先要制订出详细的计划和标准，诸如人力资源、时间的分配，所收集数据的形式、记录方式、存储方式等等；其次，应对数据作具体的分析处理后方可应用，如数据的提取、合并、相关性分析等，采用的主要技术有em算法、分段拟合技术等；另外，当使用某一具体的软件可靠性模型时，可能会出现需要的是其中的一类失效数据，而收集到的却是另一类，这时需进行失效数据间的转换。目前虽已开发出了一些自动收集软件可靠性数据的支持工具，但局限性很大，因此，如何准确而高效地自动收集各种软件可靠性数据，还是一项有待于进一步研究和实践的课题。
1.软件失效数据的缺乏
要保证全部、精确的数据收集是十分困难的，特别是要保证出现失效时作出完全而精确的报告则更难。其中，最经常也是最严重的问题是失效时间的丢失。目前，软件可靠性研究工作者，普遍感到由于缺乏数据，严重地影响到研究工作的进展。同时，关于数据的收集工作，又存在着许多问题有待解决：
（1）收集到的数据大多总是不完全的，而遗漏的数据确恰恰又是最重要的；
（2）进行数据收集同样需要方便实用的工具，这方面的工作目前还十分缺乏；
（3）由于所使用的数据而产生的可靠性估计误差比由于使用软件可靠性模型而产生的误差要大一个数量级，这说明数据质量改进的重要性。
2.影响软件失效数据收集的因素
软件产业是一门典型的知识密集型产业，存在于软件开发过程中的特殊复杂性问题，大多来源于人类脑力劳动的社会化，对它的管理要复杂、困难得多。由于受到许多潜在因素的影响，要想从一个实际的项目中收集一组软件失效数据是十分困难的。主要因素有：
（1）对软件进行度量的尺度定义混乱不清。如对时间、失效、错误类型、模型结构等的定义，就相当含糊，缺乏统一的标准。这样就使得在进行软件失效数据的收集时，目标不明确。
（2）对软件产品的管理问题。软件产品的随意复制，可使它们在不同的系统上运行；同一产品的不同版本，又可以不受限制地同时被使用。于是，其后果就可能使收集的软件失效数据含混不清。
（3）不完全的排错及诊断，使收集的数据中含有不少的虚假成分，它们不能正确反映软件的真实状况。
（4）收集技术本身需要许多方便、实用的工具，以及结构精良、定义严谨的数据库。但是，目前由于这些工具及数据库的制作、设计及应用并未受到应有的重视，以致严重妨碍了对软件失效数据的收集。特别是在“自动错误数据收集”的问题，因为有关错误信息与自动诊断难以定义，存在着许多有待解决的难题。
（5）心理因素的障碍。在软件开发过程中，自始至终存在着进度压力。争取将软件早日投放市场的激烈竞争，使进度成为首先要考虑的问题。如果缺乏严格而科学的管理，数据收集的任务就会被当作令人厌烦的“额外负担”而得不到应有的重视，从而无法完成。

---