04 软件可靠性度量和测试.ppt_第1页
04 软件可靠性度量和测试.ppt_第2页
04 软件可靠性度量和测试.ppt_第3页
04 软件可靠性度量和测试.ppt_第4页
04 软件可靠性度量和测试.ppt_第5页
已阅读5页,还剩36页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1,第4章软件可靠性度量和测试,2,内容提要,4.1软件可靠性4.1.1软件可靠性发展史4.1.2软件可靠性的定义4.1.3软件可靠性的基本数学关系4.1.4软件可靠性与硬件可靠性的区别4.1.5影响软件可靠性的因素4.1.6软件的差错、故障和失效4.2可靠性模型及其评价标准4.2.1软件可靠性模型4.2.2软件可靠性模型参数4.2.3软件可靠性模型及其应用4.2.4软件可靠性模型评价准则,3,内容提要,4.3软件可靠性测试和评估4.3.1软件可靠性评测4.3.2软件可靠性测试的具体实施过程4.4提高软件可靠性的方法和技术4.4.1建立以可靠性为核心的质量标准4.4.2选择开发方法4.4.3软件重用4.4.4使用开发管理工具4.4.5加强测试4.4.6容错设计4.5软件可靠性研究的主要问题4.6小结,4,4.1软件可靠性,用软件系统规模越做越大越复杂,其可靠性越来越难保证。应用本身对系统运行的可靠性要求越来越高,在一些关键的应用领域,如航空、航天等,其可靠性要求尤为重要,在银行等服务性行业,其软件系统的可靠性也直接关系到自身的声誉和生存发展竞争能力。特别是软件可靠性比硬件可靠性更难保证,会严重影响整个系统的可靠性。在许多项目开发过程中,对可靠性没有提出明确的要求,开发商(部门)也不在可靠性方面花更多的精力,往往只注重速度、结果的正确性和用户界面的友好性等,而忽略了可靠性。在投入使用后才发现大量可靠性问题,增加了维护困难和工作量,严重时只有束之高阁,无法投入实际使用。,5,4.1.1软件可靠性发展史,软件工程的发展大体上可分为下列四个阶段。1950年1958年1959年1967年1968年1978年1978年至今,6,4.1.2软件可靠性的定义,1983年美国IEEE计算机学会对“软件可靠性”一词正式作出了如下的定义:在规定的条件下,在规定的时间内,软件不引起系统失效的概率,该概率是系统输入和系统使用的函数,也是软件中存在的错误的函数;系统输入将确定是否会遇到已存在的错误(如果错误存在的话);在规定的时间周期内,在所述条件下程序执行所要求的功能的能力。,7,定义的说明,1、上述定义是硬件可靠性定义的引申和扩展2、“规定的时间”三种时间(日历时间、时钟时间、CPU时间)效果最好-CPU时间3、“规定的条件”环境条件程序的输入空间:输入向量的集合程序的输出空间:输出向量的集合程序的运行剖面:输入元素选用的概率分布,8,输入空间示意图/离散型运行剖面图/连续型运行剖面图,9,4.1.3软件可靠性的基本数学关系,随机变数e:从程序运行开始到系统失效所经历的时间Fe(t):e的分布函数T:任意的给定时刻Re(t):程序在t时刻的可靠度,10,4.1.4软件可靠性与硬件可靠性的区别,软件和硬件在可靠性特征上的差异,主要有以下几点:最明显的是硬件有老化损耗现象,硬件失效是物理故障,是器件物理变化的必然结果,有浴盆曲线现象;软件不发生变化,没有磨损现象,有陈旧落后的问题,没有浴盆曲线现象。硬件可靠性的决定因素是时间,受设计、生产、运用的所有过程影响,软件可靠性的决定因素是与输入数据有关的软件差错,是输入数据和程序内部状态的函数,更多地决定于人。硬件的纠错维护可通过修复或更换失效的系统重新恢复功能,软件只有通过重设计。对硬件可采用预防性维护技术预防故障,采用断开失效部件的办法诊断故障,而软件则不能采用这些技术。事先估计可靠性测试和可靠性的逐步增长等技术对软件和硬件有不同的意义。为提高硬件可靠性可采用冗余技术,而同一软件的冗余不能提高可靠性。硬件可靠性检验方法已建立,并已标准化且有一整套完整的理论,而软件可靠性验证方法仍未建立,更没有完整的理论体系。硬件可靠性已有成熟的产品市场,而软件产品市场还很新。软件错误是永恒的,可重现的,而一些瞬间的硬件错误可能会被误认为是软件错误。,相对而言,软件的可靠性对设计的依赖程度更大,11,4.1.5影响软件可靠性的因素,软件差错是软件开发各阶段潜入的人为错误:需求分析定义错误。如用户提出的需求不完整,用户需求的变更未及时消化,软件开发者和用户对需求的理解不同等等。设计错误。如处理的结构和算法错误,缺乏对特殊情况和错误处理的考虑等。编码错误。如语法错误,变量初始化错误等。测试错误。如数据准备错误,测试用例错误等。文档错误。如文档不齐全,文档相关内容不一致,文档版本不一致,缺乏完整性等。,错误引入软件的方式:程序代码特性、开发过程特性,提高可靠性:减少错误和提高健壮性,12,4.1.6软件的差错、故障和失效,异常。偏离期望的状态(或期望值)的任何情形都可称为异常。缺陷。不符合使用要求或与技术规格说明不一致的任何状态常称为缺陷。差错。从一般意义上说,差错有下面几个方面不同的含义:计算的、观测的或测量的值与真实的、规定的或理论上正确的值或条件之间的差别。一个不正确的步骤、过程或数据定义。一个不正确的结果。一次产生不正确的结果的人的活动。故障。在一个计算机程序中出现的不正确的步骤、过程或数据定义常称为故障。上述“差错”中的第二项属于故障。失效。一个程序运行的外部结果与软件产品的要求出现不一致时称为失效。软件失效证明了软件中存在着故障。上述“差错”中的第三项属于失效。,常用术语:,13,可以更清楚地说明失效与故障之间的区别,14,软件差错、已纠正差错、故障及失效的关系,15,4.2可靠性模型及其评价标准,4.2.1软件可靠性模型为了对软件可靠性进行评估,除了进行软件测试之外,我们还需要借助软件可靠性模型的帮助。软件可靠性模型(SoftwareReliabilityModel)是指为预计或估算软件的可靠性所建立的可靠性框图和数学模型。建立可靠性模型可以将复杂系统的可靠性逐级分解为简单系统的可靠性,以便于定量预计、分配、估算和评价复杂系统的可靠性。,16,历史背景,软件可靠性建模是围绕着20世纪70年代的先驱工作者Telinski、Moranda、Shooman和Coutinbo等人的工作展开的。其基本方法是用过去的失效数据建立可靠性模型,然后用所建立起来的模型估计现在和预测将来的软件可靠性。该方法使用的先验条件是给定过去某个时期内的软件失效次数或软件的失效时间间隔。因此,根据模型使用的这两种数据我们将模型分成如下两类:给定时间间隔内的失效数模型。两相临失效间的时间间隔模型。,这两类模型并非互不相关,17,好模型的一般标准,建立软件可靠性模型的目的是估计软件可靠性,提供开发状态、测试状态以及计划日程状态的参考定量数据,监视可靠性性能及其变化。一个好的模型必须有适合具体项目开发过程的正确的假设。如果不知道哪个模型最适合当前项目,那么,一个聪明的办法就是在一个项目上执行一个以上的模型并且综合分析所得到的结果。在软件可靠性模型先驱者的工作成果的基础上,经过更多软件可靠性工作者近40年的努力,软件可靠性模型到目前为止已经出现了很多种,最为常见且比较具有代表意义的模型不下20个。下面简单列举其中的几个:Musa模型,包括基本模型和对数模型;Shooman模型;Goel-Okumoto模型;测试成功模型;威布尔模型。,18,模型分类,Musa和Okumoto根据软件可靠性模型的五种特征,对模型进行了下述分类:时间域(TimeDomain):按时钟时间、执行时间(或时间)分类;类别(Category):根据软件在无限的时间内运行时可能经历的故障数是有限的还是无限的进行分类;型式(Type):根据软件在运行时间t时的失效数分布来分类。其中主要考虑泊松分布和二项式分布。种类(Class):根据软件发生故障的故障密度对时间的函数形式分类(仅对有限故障类)。族(Family):根据软件的故障密度对它的期望故障数的函数形式分类(仅对无限故障类)。,19,可靠性度量,常见的软件差错包括非法转移、误转移、死循环、空间溢出、数据执行和无理数据等。在软件可靠性分析和设计中,常常利用故障模型来对不同的故障表现进行抽象。故障模型可以建立在系统的各个级别上。建立的级别越低,进行故障处理的代价就越低,但模型所覆盖的故障也越少。常用的故障模型有基于逻辑级、基于数据结构级和基于系统级的故障模型。,20,模型建立,软件可靠性模型的建立是通过对所选模型关联参数的统计来确定失效情况、可靠性目标和实现这一目标的时间,并利用可靠性模型来制定测试策略,同时确定软件交付的预期可靠性。此外,它对经费估算、资源计划、进度安排和软件维护等也很重要。软件可靠性建模可归结为模型的比较与选择、参数选择及模型应用。模型参数取决于软件性能、过程特性、修改活动和程序变化等。由于软件本身的特性,以及缺乏可靠性数据,因此建立完全满足这些因素的可靠性模型非常困难,且难以验证。,21,模型统一,从现有模型来预计软件可靠性,往往存在偏差。当给定或已知数据的基本分布时,极大似然估计是模型参数估计最基本的方法,它显然有利于对预计的改进。最小二乘法能很好地代替极大似然估计,它通过故障强度拟合来估计模型参数。对中小样本的情况,它具有较小的偏差和较快的收敛性。Bayes分析方法提供了一种把先验知识综合到估计过程中的方法,为把不同数据源综合起来提供了有效的手段,但其分析和计算极为复杂。,22,4.2.2软件可靠性模型参数,正如前面所说,当今存在着由很多软件可靠性工作者开发的很多软件可靠性模型。这些模型使用了由各个软件可靠性工作者定义的各种各样的参数。P85,23,4.2.3软件可靠性模型及其应用,Musa模型基本模型:差错对故障率有同等贡献对数模型:差错对故障率贡献不同Goel-Okumoto模型,24,以上软件可靠性模型的适用条件和阶段,25,4.2.4软件可靠性模型评价准则,模型拟合性模型预计有效性模型偏差模型偏差趋势模型噪声,26,4.3软件可靠性测试和评估,软件可靠性评价是软件可靠性工作的重要组成部分。软件可靠性评测是主要的软件可靠性评价技术,它包括测试与评价两个方面的内容,既适用于软件开发过程,也可针对最终软件产品。在软件开发过程中使用软件可靠性评测技术,除了可以更快速地找出对可靠性影响最大的错误,还可以结合软件可靠性增长模型,估计软件当前的可靠性,以确认是否可以终止测试和发布软件,同时还可以预计软件要达到相应的可靠性水平所需要的时间和测试量,论证在给定日期提交软件可能给可靠性带来的影响。对于最终软件产品,软件可靠性评测是一种可行的评价技术,可以对最终产品进行可靠性验证测试,确认软件的执行与需求的一致性,确定最终软件产品所达到的可靠性水平。,27,4.3.1软件可靠性评测,本章所述的软件可靠性评测是指运用统计技术对软件可靠性测试和系统运行期间采集的软件失效数据进行处理并评估软件可靠性的过程。软件可靠性评测的主要目的是测量和验证软件的可靠性,当然实施软件可靠性评测也是对软件测试过程的一种完善,有助于软件产品本身的可靠性增长。软件测试者可以使用很多方法进行软件测试,如按行为或结构来划分输入域的划分测试,纯粹随机选择输入的随机测试,基于功能、路径、数据流或控制流的覆盖测试,等等。对于给定的软件,每种测试方法都局限于暴露一定数量和一些类别的错误。通过这些测试能够查找、定位、改正和消除某些错误,实现一定意义上的软件可靠性增长。但是,由于它们都是面向错误的测试,测试所得到的结果数据不宜用于软件可靠性评估。,软件可靠性测试是指在软件的预期使用环境中,为进行软件可靠性评估而对软件实施的一种测试。软件可靠性测试应该是面向故障的测试,以用户将要使用的方式来测试软件。软件可靠性评测由可靠性目标的确定、运行剖面的开发、测试的计划与执行、测试结果的分析与反馈4个主要活动组成。,29,4.3.2软件可靠性测试的具体实施过程,软件可靠性测试过程模型,测试目的正确地完成规定的功能满足性能要求不完成没有规定的功能提供运行中的故障数据测试准备和执行规定测试要求包括测试条件和测试环境评审和批准测试计划和程序提供使用环境及操作人员供测试组织进行测试要求独立的测试组织承担测试任务,31,4.4提高软件可靠性的方法和技术,4.4.1建立以可靠性为核心的质量标准在软件项目规划和需求分析阶段就要建立以可靠性为核心的质量标准。这个质量标准包括实现的功能、可靠性、可维护性、可移植性、安全性、吞吐率等等,虽然还没有一个衡量软件质量的完整体系,但还是可以通过一定的指标来指定标准基线。软件质量从构成因素上可分为产品质量和过程质量。还可把质量分为动态质量和静态质量。静态质量是通过审查各开发过程的成果来确认的质量,包括模块化程度、简易程度、完整程度等内容。动态质量是考察运行状况来确认的质量,包括平均故障间隔时间(MeanTimeBetweenFailures,MTBF)、软件故障修复时间(MeanTimeToRepairFault,MTRF)、可用资源的利用率。在许多实际工程中,人们一般比较重视动态质量而忽视静态质量。,32,确定划分的各开发过程的质量度量,需求分析质量度量设计结果质量度量测试结果质量度量验收结果质量度量,33,4.4.2选择开发方法,软件开发方法对软件的可靠性也有重要影响。目前的软件开发方法主要有Parnas方法、Yourdon方法、面向数据结构的Jackson方法和Warnier方法、PSL/PSA方法、原型化方法、面向对象方法、可视化方法、ICASE方法、瑞理开发方法等,其他还有BSP方法、CSF方法等。这里特别要提一下的是Parnas方法。,Parnas方法是最早的软件开发方法。(1972)基本思想:在概要设计时预先估计未来可能发生的变化,提出信息隐藏的原则以提高软件的可靠性和可维护性。可视化方法和ICASE方法只能作为辅助方法,面向数据结构的方法等只适合小型系统开发,面向对象的方法是建议的方法,结合其他方法使用。,35,4.4.3软件重用,软件重用不仅仅是指软件本身,也可以是软件的开发思想方法、文档,甚至环境、数据等,包括三个方面内容的重用:开发过程重用,指开发规范、各种开发方法、工具和标准等。软件构件重用,指文档、程序和数据等。知识重用,如相关领域专业知识的重用。,36,4.4.4使用开发管理工具,开发一个大的软件系统,离不开开发管理工具,作为一个项目管理员,仅仅靠人来管理是不够的,需要有开发管理工具来辅助解决开发过程中遇到的各种各样的问题,以提高开发效率和产品质量。如Intersolv公司的PVCS软件开发管理工具,在美国市场占有率已超过70,使用PVCS可以带来不少好处:规范开发过程,缩短开发周期,减少开发成本,降低项目投资风险;自动创造完整的文档,便于软件维护;管理软件多重版本;管理和追踪开发过程中危及软件质量和影响开发周期的缺陷和变化,便于软件重用,避免数据丢失,也便于开发人员的交流,对提高软件可靠性,保证质量有很大作用。,37,4.4.5加强测试,测试规范包括以下三类文档:测试设计规范:详细描述测试方法,规定该设计及其有关测试所包括的特性。还应规定完成测试所需的测试用例和测试规程,规定特性的通过/失败判定准则。测试用例规范:列出用于输入的具体值及预期输出结果。规定在使用具体测试用例时对测试规程的各种限制。测试规程规范:规定对于运行该系统和执行指定的测试用例来实现有关测试所要求的所有步骤。测试的方法多种多样:走查(Walk-through),即手工执行,由不同的程序员(非该模块设计者)读代码,并进行评论。机器测试,对给定的输入不会产生不合逻辑的输出。程序证明或交替程序表示。模拟测试,模拟硬件、I/O设备等。设计审查,关于设计的所有各方面

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论