软件可靠性(第一讲)
计算机软件可靠性测试概述

计算机软件测试中关于可靠性测试的一些看法一.软件可靠性1.1 软件可靠性定义软件可靠性是软件质量因素中最基本、最重要的因素。
1983年,IEEE计算机学会对“软件可靠性”这一术语作了专门的定义:在规定的条件下,在规定的时间内,软件不引起系统失效的概率,该概率是系统输入和输出的函数,也是软件中存在的缺陷的函数;系统输入将确定是否会遇到已存在的错误(如果错误存在的话):在规定的时间周期内,在规定的条件下程序执行所要求的功能的能力。
根据定义,软件可靠性包含了以下3个要素:规定的时间、规定的条件、所要求的功能。
规定的时间:软件可靠性只是体现在其运行阶段,所以将“运行时间”作为“规定时间"的度量。
“运行时间”包括软件系统运行后工作与挂起(开启但空闲)的累计时间。
由于软件运行的环境与程序路径选取的随机性,软件的失效为随机事件,所以运行时间属于随机变量。
规定的条件:条件指软件的运行环境。
它涉及软件系统运行时所需的各种支持要素,如支持硬件、操作系统、其他支持软件、输入数据格式和范围以及操作规程等。
不同的环境条件下软件的可靠性是不同的。
具体地说,规定的环境条件主要是描述软件系统运行时计算机的配置情况以及对输入数据的要求,并假定其他一切因素都是理想的。
有了明确规定的环境条件,还可以有效判断软件失效的责任在用户方还是研制方。
所要求的功能:软件可靠性还与规定的任务和功能有关。
由于要完成的任务不同,软件的运行剖面会有所区别,则调用的子模块就不同(即程序路径选择不同),其可靠性也就可能不同。
所以要准确度量软件系统的可靠性必须首先明确它的任务和功能。
1.2 软件可靠性度量软件可靠性度量是指对软件产品具有可靠性程度的定量评价。
软件可靠性度量参数是描述软件可靠性的依据,确定其指标要求是评估软件可靠性的必要步骤,一般的软件可靠性参数有:可靠度:是指软件在规定的条件下、规定的时间段内完成预定的功能的概率。
或者说是软件在规定时间内无失效发生的概率。
软件可靠性培训讲稿

软件可靠性评估包括软件可靠性估计。软件可靠 性估计是指应用统计技术处理在系统测试和运行期 间采集、观测到的失效数据,以评估软件的可靠 性。 (5)软件可靠性管理 为确定和满足软件可靠性要求所必须进行的一系 列组织、计划、协调和监督等工作。例如:制定和 监督实施软件可靠性计划,制定必要的设计和编程 准则,进行风险管理,改进费用效益关系,改进开 发过程,对采购或重用的软件进行可靠性管理。
Z (t ) = lim
Δt →0
P (t < ξ < t + Δt | ξ > t ) 1 = ⋅ f (t ) Δt R (t )
中国可靠性:
其中f(t)为失效概率密度函数。
如果在可靠性测试或使用中,对发生的失效 不采取纠正活动,且使用是稳定的,即软件的操 作剖面是不变的,则失效时间服从指数分布,即 失效率为一常数。 失效率适用于要求失效发生频率比较低的系 统,比如操作系统。
中国可靠性:
4 .软件可靠性工程与装备系统可靠性工 程的关系
考虑系统可靠性时必须考虑其中的软件可 靠性,考虑软件可靠性时,要牢记软件是为 系统服务的,注意把软件放在系统之中,切 不可孤立起来单独考虑如何保证软件的可靠 性。
中国可靠性:
wwwkekaoxingcom软件失效的原因内在原因都是在软件开发过程中形成且未被排除的潜在缺陷如有缺陷的遗漏的或多余的指令或指令集这些缺陷的来源可能是软件开发者的失误也可能是恶意逻辑外在原因都是软件外部给软件提供的各种非期望的条件一种是客观存在于软件外部的系统中的环境异常另一种是软件运行过程中人员造成的可能是操作人员的失误也可能是有人恶意的侵袭见图3
整个非容错程序的失效率λ为诸 λ i 是第i个缺陷的失效率。
中国可靠性:
软件可靠性(第一讲)

软件可靠性的基本知识
程序在启动运行时,需要给变量赋值,即给程序提 供输入数据,输入的数据可能由外部设备输入,也 可能由早已存储在计算机内等待读取。 程序运行一次所需的输入数据构成程序输入空间 的一个元素,这个元素是一个多维向量。 全部输入向量的集合构成程序的输入空间。 一组输入数据经过程序处理后得到一组输出数据,这 些输出数据构成一个输出向量,全部输出向量的集合 构成程序的输出空间。
软件可靠性的基本知识
二、时间的度量
1. 日历时间 软件的测试和运行以日、周、月、年等为计时单位。 2. 时钟时间 软件从运行开始,到运行结束以时、分、秒为计时单 位。其中包括等待时间和其他辅助 时间,但不包括停机占用时间。
3. 执行时间 计算机在执行程序时,实际占用中心处 理器(CPU)的时间,又称CPU时间。
软件可靠性的基本知识
图中每个结点或圆圈代表一段可能以转移语句结束的 顺序执行语句,每条弧代表两段程序间的控制转移。 假设程序含有一个最少重复20次的循环语句,而在循 环体内,则有一些嵌套的条件语句。 假设程序中所有判断都是相互独立的,由于有5条贯穿 循环体的路径:
即c→d→e→f→h→m; c→d→e→f→i→m; c→d→e→g→j→m; c→d→e→g→k→m; c→d→l→m。
软件可靠性的基本知识
那么从点A到点B的所有独立路径数为: 520+519+…+51,约为1014或1016亿。如果考 虑程序输入数据的变化,那情况就更为复杂 了。
可见,软件可靠性问题在软件工程实 践中极为重要,对软件可靠性问题的研究 在国际上已十分活跃。
软件可靠性的基本知识
软件可靠性的基本概念
关于软件可靠性的确切定义,国际学术界曾经有过长期 的争论。对软件可靠性定义的理解有广义和狭义两种:
软件可靠性安全性分析基本知识

6
软件可靠性安全性设计分析
第一讲:基础知识
7
基础知识-主要内容
一、软件可靠性安全性概念及关系
软件可靠 性安全性 设计分析
软件可靠性安全性设计分析
二、软件可靠性安全性分析概念及关系
三、软件可靠性安全性设计概念及关系
8
软件可靠性安全性设计分析
一、软件可靠性安全性概念及关系
9
基础知识1-软件可靠性概念
《软件可靠性、安全性与质量保证》黄锡滋 编著 电子工业出版社 2002年10月 《软件可靠性工程手册》Michael R.LYU主编, 电子工业出版社 1997年3月 软件安全性相关标准 软件可靠性安全性设计分析方面的论文及期刊 等 软件工程方面的书籍,如《软件工程》张海藩 编著 人民邮电出版社 2003年7月 软件容错方面的书籍及期刊、论文等
基础知识2-软件安全性概念
序号 1 2 来源 学者Nancy G.Leveson 定义描述 软件安全性涉及确保软件在系统环境中运行而不产生不可接 受的风险。
2004年美国航天 软件工程和软件保证的方面,提供了一个系统的方法来标识、 航空局的软件安 分析和跟踪危险和危险功能(例如,数据和指令)的软件缓 全性标准 解和控制,以确保软件在系统中更加安全地运行”。 美国国防部的三 军联合提出的软 件系统安全手册 将系统安全性工程(包括软件系统安全性)定义为“在系统 寿命周期各阶段运用工程和管理原理、准则和技术,以便在 使用效能、时间和费用的约束范围内使安全性最优并且风险 降低”。
②有些状态可能引起软件失效的状态,
导致不能实现功能。
③有些状态上述二者都涉及。
在规定的时间内,如果软件运行的真实 环境与运行前规定的环境相关,则软件 是可靠的就可判断软件是安全的
软件可靠性 软件工程

测试覆盖率Cv 测试覆盖率Cv 表明在整个测试期间发现软件内潜 在故障的可能性有多大。 在故障的可能性有多大。 可通过被测试对象软件内潜在的原 有故障的捕捉率来测定的。 有故障的捕捉率来测定的。
测试过程中已发现原有故障总数为 n0(实测值),经过相当长时间测试 实测值) 后可能发现的原有故障总数为N 后可能发现的原有故障总数为N0, 采用平均值函数m NHPP模型 采用平均值函数m(t)的NHPP模型 描述测试发现原有故障的过程 m(t)的收敛值m(∞)=Nc 的收敛值m 测试覆盖率Cv的推测值 测试覆盖率Cv的推测值:
整理得
Ec ( t ) ET λ = IT IT K
若对程序进行若干次不同的功能 测试, 测试,可得到一系列实验数据
Ec ( ti ), λ ( ti ), i = 1, 2, …, n 令
1 ET = a, = b, K IT EC ( t i ) = ε i , λ ( ti ) = λ i IT
设Ns 是在测试前人为地向程序中 植入的故障数, 植入的故障数,ns 是经过一段时 间测试后发现的播种故障数目, 间测试后发现的播种故障数目, n 是在测试中又发现的程序原有 故障数。 故障数。设测试用例发现植入故 障和原有故障的能力相同, 障和原有故障的能力相同,则程 =E 序中原有故障总数 N ( =ET )估算 Ns 值为 N = 线模型
估算软件中故障总数E 估算软件中故障总数ET 的方法
利用Shooman模型估算程序中 利用Shooman模型估算程序中 原来错误总量E 原来错误总量ET —瞬间估算
ET EC ( t1 ) EC ( t1 ) 1 = = K t1 IT MTTF1 IT
ET EC ( t2 ) EC ( t2 ) 1 = = K t2 IT MTTF2 IT
软件可靠性安全性分析基本知识

THANK YOU
汇报人:
可靠性设计原则
容错设计:通过冗余设计、故障检 测和恢复等技术提高软件的容错能 力。
模块化设计:将软件划分为独立的 模块,降低软件的复杂性和耦合度, 提高可维护性和可靠性。
添加标题
添加标题
添加标题
添加标题
健壮性设计:软件应能处理异常情 况,如输入数据不合法或系统资源 不足等。
自动化测试:通过自动化测试工具 对软件进行测试,确保软件在各种 情况下都能正常工作。
可靠性测试与评估
可靠性测试的目 的:验证软件在 规定条件下能否 正常工作
可靠性测试的方 法:包括功能测 试、性能测试、 压力测试等
可靠性评估的标 准:如MTBF (平均故障间隔 时间)、故障率 等
可靠性评估的流 程:包括测试数 据收集、分析、 评估和改进等步 骤
软件安全性分析
安全需求与风险评估
工具名称:Checkmarx
工具名称:PVS-Studio
工具名称:SonarQube
动态分析工具
概述:动态分析工具用于在软件运行时检测和评估其可靠性安全性 常见工具:Valgrind、Purify、Insure++等 工作原理:通过插桩技术、内存管理等方式监控程序的运行状态 优点:可以实时发现潜在的错误和漏洞,提高软件质量
软件可靠性安全性分析基本知 识
汇报人:
软件可靠性安全性分析概述 软件可靠性分析 软件安全性分析 软件可靠性安全性分析工具 软件可靠性安全性管理 软件可靠性安全性案例分析
软件可靠性安全性分析概述
定义与目的
软件可靠性安 全性分析的定
义
软件可靠性安 全性分析的目
的
软件可靠性安 全性分析的基
软件可靠性

7.7 软件可靠性7.7.1 基本概念 1. 软件可靠性的定义定义 1 软件可靠性(software reliability )是指软件在规定的运行环境中和规定的时间内无失效运行的概率[ANSI91]。
所以它是时间t 的函数,我们用)(t R 来表示。
定义 2 软件故障率(failure rate )是指在单位时间内软件发生故障的概率。
它和软件可靠性的关系如下:)()()(t R dt t dR t -=λ 或者是:))(exp()( 0 ⎰-=tdt t t R λ定义3 软件平均无故障时间(MTTF)。
指软件从开始运行到出现一个故障的期望时间,根据可靠性的定义有:⎰∞=)(dt t R MTTF和软件中错误相关的定义定义4 软件错误(Software Error )。
指在软件生存期内的不希望或不可接受的人为错误。
软件错误是一种人为的行为,相对于软件本身是一种外部行为。
定义 5 软件缺陷(Software Defect )。
指存在于软件(文档、数据、程序)之中的那些不希望或不可接受的偏差。
其结果是软件在某一特定条件时出现运行故障。
当软件指程序时,软件缺陷即程序污点(Bug )。
定义 6 软件故障(Software Fault )。
指软件运行过程中出现的一种不希望或不可接受的内部状态。
软件故障是一种动态行为。
定义 7 软件失败(Software Failure )。
指软件运行时产生的一种不希望或不可接受的外部行为结果。
2. 软件的可用性定义程序在给定的时间点,按照SRS 的规定,成功地运行的概率。
可靠性与可用性的区别:可靠性指在0到t 这段时间间隔内系统没有失效;可用性仅仅意味着在时刻t ,系统是正常运行的。
在时刻t 系统是可用的,意味着两种可能:1)在0到t 这段时间间隔内系统一直没有失败;2)在0到t 这段时间间隔内,系统失效了若干次,但都被修复好了。
如果一端时间内,软件系统故障停机时间分别为t d1 , t d2 ,⋯⋯,正常运行时间分别为t u1 , t u2 ,⋯⋯。
8_10 软件可靠性

13 /75
2. 基本假定
根据经验数据, 根据经验数据,可以作出下述假定 (1)在类似的程序中,单位长度里的错误数 T/IT近似为常 )在类似的程序中,单位长度里的错误数E 数。 美国的一些统计数字表明,通常 × 美国的一些统计数字表明,通常0.5×10-2≤ET/IT≤2×10-2, × , 也就是说,在测试之前每1000条指令中大约有 ~20个错 条指令中大约有5~ 个错 也就是说,在测试之前每 条指令中大约有 误。
16 /75
单位长度程序中剩余的错误数为:
ET − EC (τ ) ε r (τ ) = IT
17 /75
3. 估算平均无故障时间
经验表明,平均无故障时间与单位长度程序中剩余的 错误数成反比,即
MTTF =
1 kε r
其中, 为常数 它的值应该根据经验选取。 为常数, 其中,k为常数,它的值应该根据经验选取。美国的一 些统计数字表明, 的典型值是 的典型值是200。 些统计数字表明,K的典型值是 。
Ass =
Tup Tup + Tdown
7 /75
如果引入 系统平均无故障时间MTTF( Mean Time To ( 系统平均无故障时间 Failure,平均失效等待时间) ,平均失效等待时间) 平均维修时间MTTR(Mean Time To Repair,失效 ( 平均维修时间 , 平均修复时间) 平均修复时间) 上式式可以变成: 上式式可以变成:
10 /75
有助于理解MTTF、MTTR,还有 的含义。 图8.17 有助于理解 、 ,还有MTBF的含义。 的含义 MTTF=T1 MTTR=T2+T3 MTBF=T1+T2+T3
11 /75
8.10.2 估算平均无故障时间的方法
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
软件可靠性的基本知识
3. 软件内部结构
软件内部结构一般比较复杂,且动态变 化,对可靠性的影响也不甚清楚。
但总的说来,结构越复杂,软件复杂度越 高,内含缺陷数越多,因而软件可靠度越低。
软件可靠性的基本知识
软件可靠性的基本知识
软件可靠性的基本概念
关于软件可靠性的确切定义,国际学术界曾经有过长期 的争论。对软件可靠性定义的理解有广义和狭义两种:
广义的可靠性:
是指一切旨在避免、减少、处理、度量软件故障 (错误、缺陷、失效)的分析、设计、测试方法、 技术和实践活动。
软件可靠性的基本知识
与之相关的内容有软件可靠性度量、软件可靠性设 计、软件可靠性建模、软件可靠性测试和软件可靠 性管理等。
3.软件故障
在对错误不作任何纠正和恢复的情况下,导致系统的 输出不满足用户提供的正式文件上指明的要求,或双 方协议的条款,称为软件的一次故障。
软件故障是由于软存错误造成的一种外部表现,它 是动态的、程序执行过程中出现的行为表现。
软件可靠性的基本知识
综上所述,软件缺陷是人为错误。
当一个软件缺陷被激活时,便产生一 个或多个软件错误;
软件操作剖面:通常是指软件运行的输入空间及 其概率分布。
软件的输入空间是指软件所有可能的输入值构 成的空间。按照欧空局标准的定义,软件的操作 剖面是指“对系统使用条件的定义。即系统的输 入值用其按时间的分布或按它们在可能输入范围 内的出现概率的分布来定义”。
软件可靠性的基本知识
二、时间的度量
1. 日历时间 软件的测试和运行以日、周、月、年等为计时单位。
至少满足下列5个规则之一才称发生了一个软件缺陷 (software bug)
1)软件未实现产品说明书要求的功能; 2)软件出现了产品说明书指明不应该出现的错误; 3)软件实现了产品说明书未提到的功能; 4)软件未实现产品说明书未提及但应实现的功能; 5)软件难以理解、不易使用、运行缓慢,用户评价不好。
2. 时钟时间 软件从运行开始,到运行结束以时、分、秒为计时单 位。其中包括等待时间和其他辅助 时间,但不包括停机占用时间。
3. 执行时间 计算机在执行程序时,实际占用中心处 理器(CPU)的时间,又称CPU时间。
软件可靠性的基本知识
三、软件的故障
软件可靠性工程的主要目标是保证提高软件可靠性。 为达到这一目标,显然首先要弄清软件为什么会出现 故障。只有这样,才有可能在软件开发过程中减少导 致软件故障的隐患,且一旦出现什么故障,有可能采 取有效措施加以清除。
IEEE将软件可靠性定义为:系统在特定环境下,在给定的时间内无 故障运行的概率。
软件可靠性是对软件在设计、开发以及所预定的环境下具有能力的置 信度的一个度量,是衡量软件质量的主要参数之一。而软件测试则是 保证软件质量、提高软件可靠性的最重要手段。
软件缺陷与故障
1、软件缺陷和软件故障案例
案例1 美国迪斯尼公司的狮子王游戏软件bug 兼容性问题
弄清软件故障机理是软件可靠性分析的根本目标。由 于软件内部逻辑复杂,运行环境动态变化,且不同的 软件差异可能很大,因而软件故障机理可能有不同的 表现形式。
软件可靠性的基本知识
1.软件缺陷 软件开发中残留的内在缺陷称为软件缺陷。这些 缺陷可以在软件生存期的各个阶段被引入。
软件可靠性的基本知识
在软件开发的各阶段,软件始终离不开人的参与,而人 难免会犯错误,这样就必然给软件留下不良的痕迹。
4. 软件可靠性设计技术。
一般是指软件设计阶段中采用的用以 保证和提高软什可靠性为主要目标的软件技术。
如故障模式与影响分析(FMECA)、故障 树分析(FTA)等。显然采用或不采用软件可靠 性设计技术对软件可靠性必有影响。
软件可靠性的基本知识
5. 软件可靠性测试 研究表明,软件测试方法与资源投入对软件可靠 性有不可忽视的影响。
程序运行一次所需的输入数据构成程序输入空间 的一个元素,这个元素是一个多维向量。 全部输入向量的集合构成程序的输入空间。
一组输入数据经过程序处理后得到一组输出数据,这 些输出数据构成一个输出向量,全部输出向量的集合 构成程序的输出空间。
软件可靠性的基本知识
程序输入空间的元素数量非常庞大,程序运行中 每个元素被选用的概率各不相同,形成一定的概 率分布,我们称此为程序运行剖面,程序的不同 的运行状态,对应于不同的运行剖面。
例如一段程序进行某些数据处理,若在处理过程中就产 生软件错误,则说明这段程序存在缺陷或缺少一个程序 段。
软件缺陷是一个静止的现象,只在一定的输入条件下才 能被激活导致软件错误,而且软件错误也不一定导致软 件故障。
比如容错软件中的错误就可以被检测出来并可纠正或避 免,而不导致故障。
软件可靠性的基本知识
G 中的输入不会激活软件的缺陷,F 中的输入 恒激活软件缺陷。如果运行剖面不包含F中的 输入,则软件不会出现故障,其可靠性恒为1。
反之,如果运行剖面不包含G中的输入, 则每一输入情况下均出现故障。如果没有容错 措施,则导致软件故障,软件可靠性恒为0。
软件可靠性的基本知识
2.软件规模
如果软件只含一条指令,那么谈论软件可靠性问 题便失去意义。随着软件规模的增大,软件可靠 性问题愈显突出。
举例:计算器内的嵌入式软件
软件缺陷的特征
“看不到” ——软件的特殊性决定了缺陷不易看到
“看到但是抓不到” ——发现了缺陷,但不易找到问题发生的原因所在
软件可靠性的基本知识
Contents: 软件可靠性的基本概念 软件可靠性的基本特征量 软件可靠性设计
软件可靠性的基本知识
软件可靠性的基本概念
狭义的可靠性:
是指软件无失效运行的定量度量。
与之相关的内容有软件可靠性度、软件 失效强度和软件平均失效时间等。
软件可靠性的基本知识
软件可靠性的基本概念
一、软件的环境条件 二、时间的度量
三、软件的故障
四、影响软件可靠性因素
软件可靠性的基本知识
一、软件的环境条件
环境条件包括与程序存储有关的计算机及其操作系 统。
软件可靠性
提要:
➢软件可靠性的发展 ➢软件可靠性概念 ➢软件失效的内涵
软件可靠性发展至今可分为下列三个阶段:
第一阶段:(1950-1967年)
软件可靠性学科萌芽时期。
第二阶段:(1968-1987年)
软件可靠性学科的形成时期。
第三阶段:(1988年至今)
软件可靠性向工程应用过渡的时期。
对软件可靠性的要求
软件可靠性的基本知识
为了说明软件的复杂性,让我们考虑一个由10至 20条高级语言构成的程序,其控制流程图如图所 示。
软件可靠性的基本知识
图中每个结点或圆圈代表一段可能以转移语句结束的 顺序执行语句,每条弧代表两段程序间的控制转移。 假设程序含有一个最少重复20次的循环语句,而在循 环体内,则有一些嵌套的条件语句。 假设程序中所有判断都是相互独立的,由于有5条贯穿 循环体的路径:
一、软件的环境条件 二、时间的度量
三、软件的故障
四、影响软件可靠性因素
软件可靠性的基本特征(可靠性参数)
1. 系统不工作次数 2. 系统平均不工作间隔时间(MTBD)
3. 有效性( A )
4. 平均修复时间(MTTR)
5. 平均不工作时间(MDT) 6. 初期故障率
7. 偶然故障率
8. 使用方误用率
软件可靠性的基本知识
但从技术角度来看,影响软件可靠性的 因素主要包括:
1. 运行环境(剖面)
软件可靠性定义相对于运行环境而言,同 一软件在不同运行剖面下,其可靠性行为可能 极不相同。
软件可靠性的基本知识
我们知道,软件故障是软件缺陷在一定 输入情况下被激活的结果。于是可以将软件 输入域划分为两个部分(G和F) :
9. 用户提出补充要求数 10. 处理能力
软件可靠性的基本知识
随着计算机软件的飞速发展,软件可靠性已变得 越来越重要。据统计,计算机系统中,由于软件 错误引起的故障占所有故障的65%。
究其原因是软件太复杂了,一个小小的程序,其 可能的路径可以是天文数字,以致于在软件开发 过程中难以对其作穷尽的测试,或者说难于完全 排除软件缺陷。
例如计算机型号、字长、内存容量、外存介质的数 量及容量、输入和输出设备的数量、通信网络、操作系 统和数据管理系统、编译程序及其他支持软件等。
这些因素对程序的运行有很大的影响,但在使用中 一般没有变化。
环境条件还包括软件的输入分布。 软件的输入有外部和内部输入:
软件可靠性的基本知识
程序在启动运行时,需要给变量赋值,即给程序提 供输入数据,输入的数据可能由外部设备输入,也 可能由早已存储在计算机内等待读取。
6. 软件可靠性管理 软件可靠性管理旨在系统管理软件生存期各阶段 的可靠性活动。 使之系统化、规范化、一体化,这样就可以避免 许多人为错误,以提高软件可靠性.
7. 软件开发人员能力和经验
8. 软件开发方法
软件工程表明,开发方法对软件可靠性有显著 影响。与非结构化方法比较,结构化方法可以 明显减少软件缺陷数。
当软件错误不加以纠正时,便不可避 免地产生软件故障。
同一个软件缺件可靠性因素
软件可靠性因素:软件生存期内影响软件可 靠性的因素。
显然,有许许多多因素可以影响软件可靠性, 包括技术的、社会的、经济的、甚至文化的, 因为在软件生存期的各个阶段均有人的干预, 而人的行为受到各方面因素的影响。
大部分的软件不是很可靠。
软件不可靠性的因素
不完善的需求定义; 客户与开发人员缺乏沟通; 偏离软件需求; 逻辑设计错误; 编码错误; 编码与文档不一致; 缺少测试过程;
软件可靠性问题