是最早的软件可靠性模型之一Read

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,单击此处编辑母版标题样式,*,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,是最早的软件可靠性模型之一Read,软件可靠性问题的提出,20世纪中期是计算机硬件飞速开展的阶段，但软件开发尚处于低级阶段，软件的重要性还不显著。,随着软件的大量使用和软件规模的迅速增长，软件可靠性低的问题日益显著，并作为“软件危机的主要问题之一于1968年被提了出来。,据了解，美国航天飞机上飞行软件有50多万行源代码；而F一22战斗机上的飞行软件的源代码数更是高达150多万行。,另据美国军方的统计，美国军方在武器装备作战使用中遇到的问题，软件问题约占到70左右。,2,由于软件故障造成的重大事故不乏其例,美国空军的范登堡中心在60年代后期发生过屡次导弹试射失败的事故，事后发现几乎都是由软件错误造成的；,F一18战斗机在海湾战争中，飞行控制软件共发生了500屡次故障；,我国某型号飞机首飞前航空电子系统在地面测试中测出的故障共800多个，其中软件故障就达600多个，约占75；,3,由于软件故障造成的重大事故不乏其例,1990年1月15日，美国一,通信中转系统,新投入使用的软件发生了错误，导致主干线远程网,大规模崩溃,；,美国的Therac-25放射性治疗仪由于,软件存在缺陷,导致几个癌症病人受到非常严重的过量放射性治疗，其中,4个人因此死亡,；,2002年11月28日，欧洲的亚里安娜5型火箭因,发动机控制系统软件的错误,而,导致飞行试验失败。,4,软件可靠性的开展,在20世纪50年代末60年代初，计算机硬件从晶体管到集成电路，得到了飞速的开展.而软件开发仍处于很低级的阶段，极大地依赖于开发人员的编程技巧，且主要关注的是软件的功能。1968年在西德召开的国际软件工程会议上提出的“软件危机的主要问题之一，就是软件可靠性低，经常出故障。从那时起，才开场认识到软件可靠性的重要性。据统计，计算机系统中，由于软件错误引起的故障占所有故障的65%。美国贝尔Bell实验室曾对一个AT&T运行支持系统作了统计，发现80%的故障与软件有关。究其原因是软件太复杂了，一个小小的程序，其可能的路径可以是天文数字，以致于在软件开发过程中难以对其作穷尽的测试，或者说难于完全排除软件缺陷。,5,调用路径太多,其中每个结点或圆圈代表一段可能以转移语句完毕的顺序执行语句，每条弧代表两段程序间的控制转移。程序含有一个最少重复20次的循环语句.由于有5条贯穿循环体的路径，即cdefhm；cdefim；cdegjm；cdegkm；cdlm，那么从 点A到点B的所有独立路径数为520 +519 +51，约为1014 或1016亿。,6,1故障机理,硬件产生故障的原因有四个方面：即设计问题、生产过程中的问题、超载及耗损。硬件故障主要是由于耗损物理退化所致的，而软件不存在物理退化现象。这就决定了软件正确性与软件可靠性密切相关，一个正确的软件任何时刻均可靠；然而一个正确的硬件元器件或系统那么可能在某个时刻故障。软件没有耗损问题并不等于没有可靠性问题，因在开发过程中常有一些随机因素，不可防止地会在软件中留下缺陷，因而软件也有可靠性问题。所以硬件的故障机理是耗损，而软件的故障机理就是残留缺陷在一定环境下造成的软件错误。,软件与硬件的不同,7,2复杂性,软件内部逻辑高度复杂，而硬件内部逻辑较为简单，这就在很大程度上决定了设计错误是导致软件故障的主要原因，而导致硬件故障的可能性那么很小。,3唯一性,软件是唯一的，软件拷贝不改变软件本身，而任何两个硬件不可能绝对一样。,8,软件可靠性的核心是“思考问题，软件中不可能象硬件那样分解成元部件，它只有语句。语言本身造成的软件故障较少，且通过静态测试(目测或编译)可加修正。软件错误来源主要是软件设计者的思维错误及软件的复杂性，这是难以控制的。故软件可靠性的提高需从人的思维正确性和减少软件的复杂性两方面着手。这正如我们用汉语写文章，观点有错误不能归咎于语言本身不好，而应归咎于人的思想。,4可靠性的核心,9,由于软件内部逻辑复杂，运行环境动态变化，且不同的软件差异可能很大，因而软件故障机理可能有不同的表现形式。譬如有的故障过程比较简单，易于追踪分析，而有的故障过程可能非常复杂，难于甚至不可能加以详尽描述和分析，尤其是运行于高度复杂实时环境中的大型软件。但总的说来，软件故障机理可描述为：软件缺陷软件错误软件故障。,软件故障,10,1软件缺陷,软件缺陷(Default)：软件开发中残留的内在缺陷称为软件缺陷。这些缺陷可以在软件生存期的各个阶段被引入。在软件开发的各阶段，软件始终离不开人的参与，而人难免会犯错误，这样就必然给软件留下不良的痕迹。例如一段程序进展某些数据处理，假设在处理过程中就产生软件错误，那么说明这段程序存在缺陷或缺少一个程序段。软件缺陷是一个静止的现象，只在一定的输入条件下才能被激活导致软件错误，而且软件错误也不一定导致软件故障，比方容错软件中的错误就可以被检测出来并可纠正或防止，而不导致故障。,11,2软件错误,软件错误(Error)：软件缺陷在一定条件下暴露并导致系统在运行中出现可感知的不正常、不正确、不按标准执行的内部状态，那么认为软件出现“错误，简称出错。所谓不正确的内部状态，是指在此状态下，当正常的算法继续下去时，就会发生软件故障。软件错误是由于软件缺陷造成的。一个错误可能是多个故障源。例如，在求最大值的程序中，设计人员由于疏忽将求得的平均值作为最大值，这就是一个软件错误。,12,3软件故障,软件故障(Failure)：在对错误不作任何纠正和恢复的情况下，导致系统的输出不满足用户提供的正式文件上指明的要求或双方协议的条款，称为软件的一次故障。软件故障是由于软存错误造成的一种外部表现，它是动态的、程序执行过程中出现的行为表现。2中的故障例子，由于没有容错措施，即没有限制和排除软件故障的措施，最终将得到不可承受的结果平均值，产生软件故障。,13,软件故障的特点,14,影响软件可靠性的因素,运行环境(剖面)。同一软件在不同运行剖面下，其可靠性行为可能极不一样。由于软件故障是软件缺陷在一定输入情况下被激活的结果，假设软件输入域划分为两个局部：G和F：运行剖面不包含F中的输入，那么软件不会出现故障，其可靠性恒为l。反之，如果运行剖面不包含G中的输入，那么每一输入情况下均出现故障，如果没有容错措施那么R=0。,软件规模。随着软件规模的增大，软件可靠性问题愈显突出。在我们考虑软件可靠性问题时，软件一般是指中型以上软件(4000-5000条以上语句)，这时可靠性问题难以对付。软件工程实践的一个侧面可以反映这一点，即单元测试一般由编程人员本人进展，而综合测试那么需独立的测试人员。软件可靠性增长模型也主要应用于综合测试阶段。,软件内部构造。软件内部构造一般比较复杂，且动态变化，对可靠性的影响也不甚清楚。但总的说来，构造越复杂，软件复杂度越高，内含缺陷数越大，因而软件可靠度越低。,15,软件可靠性设计技术。关于软件可靠性设计技术的外延并不明确，但一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术。,软件可靠性测试。研究说明，软件测试方法与资源投入对软件可靠性有不可无视的影响。,软件可靠性管理。软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动，使之系统化、标准化、一体化，这样就可以防止许多人为错误，以提高软件可靠性。,软件开发人员能力和经历。显然，软件开发人员(包括测试人员)的能力愈强，经历愈丰富，所犯错误便可能愈少，所得软件产品质量愈高，相应的可靠性也愈高。,软件开发方法。软件工程说明，开发方法对软件可靠性有显著影响。与非构造化方法比较，构造化方法可以明显减少软件缺陷数。,软件开发环境。研究说明，程序语言对软件可靠性有影响。譬如，构造化语言Ada优于Fortran语言，而软件测试工具优劣那么影响测试效果。,16,软件可靠性定义,1沿用硬件可靠性的定义，即软件可靠性是指软件在所规定的环境条件下、规定的时间内，一直能按要求和规格说明正确地完成任务的性质。这一性质的概率(定量)描述也称为可靠度，可用可靠度函数表示。可见这是一种面向时间的定义方法，它没有考虑故障的原因、软件产品故障的特点及软件产品的特殊性。,2软件可靠性定义为：假定输入和硬件都没有错误，对于一组输入数据，软件能正常运行不发生错误的概率。这是一种面向数据的定义方法。,建议推荐,17,软件可靠性技术,软件避错技术,软件容错技术,软件测试技术,软件预计技术,18,软件避错技术,软件设计技术,1 自顶向下设计(TDDTop-Down Design)是把系统功能最抽象描述作为最高层次，并从它出发，把系统分成分级的分系统，称为层(Levels)。,2数据构造设计法。主要注意力集中在信息构造和信息流动上，而不是过于集中在所要完成的功能上。如定义数据构造、标识数据流、定义能使数据流动的操作等。为了防止数据冲突，须引进中间文件，来实现输入数据与输出数据的构造转换处理。,3高级软件(HOSHigher Order Software)方法论。这是一种详细说明和开发可靠软件系统的方法论，是完全面向系统而不是面向传统软件的。高级软件的根本出发点是把一个给定的系统看成一个“软件，并可用数学模型(即函数)来描述。1974年NASA将高级软件首次在宇宙飞船模型软件开发中应用，现已用于开发宇宙飞船的飞行软件中。,19,软件实现技术,1自顶向下 (Top-Down Programming，TDP)和由底向上程序设计(BottomUp Programming，BUP)方法。,2模块程序设计(MPModular Programming)的思想是把整个软件系统分解成为一系列独立的代码段来实现软件的。每段就叫一个模块，它常常是一个小型的、面向功能性的子程序或函数，每个模块用来表示与某个功能有关的一个或多个任务，模块之间的数据通信靠接口来完成。模块之间有一定的独立性，可由不同的程序员编程来加快实现的进程。,3逐步求精程序设计 (SWRPStep Wise Refinement Programming)的根本思想是：对于一个复杂的问题，先解决容易局部(给出较粗的框图)，接着对剩下的问题再作更细的分解，如此反复，直到所有问题都解决为止。,4构造化程序设计(SPStructure Programming)概念是强调从程序构造和风格上来研究程序设计。构造化程序设计严格说不是一种程序设计的方法，而是编程的一个标准或风格。,20,软件避错技术的应用,在“美洲豹(Jaguar)飞机的数字式电传飞行控制系统的飞控软件中,21,软件容错技术,N文本技术,22,N,文本特点,独立设计；,尽量采用不同的算法和数据构造；,不同的语言；,不同的程序员来编写。,每个文本程序中设置一个或多个穿插检测点，每当文本执行到一个穿插检测点时便产生一个比较向量，并将比较向量交给表决程序，自己那么进入等待状态，等待来自表决驱动的指令。,23,比较向量,比较向量，用于比较的目的。,比较状态标志，用来指示在产生比较向量的过程中是否发生了特殊事件，譬如监测到例外条件，遇到文本结尾等。,24,表决程序,激活各文本使之投入运行；,承受来自各文本的比较向量；,实现各文本同步；,比较各文本的比较向量；,处理比较结果。,25,恢复块技术,26,软件容错技术的应用,F8纵向数字飞行控制系统在各余度硬件通道中采用了非相似软件，即“恢复块，也就是F8DFBW驻留备份软件(Resident Backup Software简称REBUS),27,软件测试技术,定义：,软件测试是为了发现错误而执行软件的过程。或者说软件测试是根据软件开发各阶段的说明和程序内部构造，精心设计的测试用例(测试用例) 而执行软件及发现错误的过程。,28,软件测试的原那么,1好的测试用例能使从程序中查出以前未发现的错误的可能性增大。,2能查出先前未发现的错误的测试是成功的测试。,3尽量防止程序员及程序设计机构测试自己的程序，因为软件测试中人的心理状态是重要的问题之一。,29,软件测试的一般步骤,30,软件测试方法,31,1静态测试。不执行程序而只是检查源程序的构造、文法和过程间的接口是否有错的测试称为静态测试。程序编译是静态测试的一种方法，还有许多其它测试工具如审查会等人工测试法。,2动态测试。使程序在某种控制环境中运行，在完成所要求的功能的同时，检查是否存在不必要的功能的测试称为动态测试。动态测试对要求、数据、结果和内部程序工作状态四部份的对应关系进展准确选择和测定。动态测试也称程序测试，是通过测试用例执行程序发现错误的过程。,32,测试策略,“黑盒测试法,黑盒测试又称数据驱动(输入输出驱动)测试方案。在应用这种方案时，测试者把程序看成一个黑盒，即完全不考虑程序内部构造和内部特性，仅按软件说明书来测试程序所有可能的输入情况。如果将所有输入情况都测试一遍这将是一个天文数字。,33,“白盒测试法,白盒测试法又称逻辑驱动测试。它允许人们检查程序的内部构造。使用这一方案时，测试者从检查程序的逻辑着手，按程序构造测试，即测试程序的每一条路径而不考虑软件说明书的要求。显然，独立路径也是一个天文数字。,虽然以上两种极端方案都不可行，但它却给测试提供了考虑问题的方向。即应该把程序外部功能和内部构造结合起来，形成新的测试方案。,34,测试用例设计,1等价划分。把输入域作等价划分，使所设计的测试用例具有代表性，即一个测试用例可以代表与其等价的其它测试用例。,2边值分析。边值分析不是简单地等价类中找一个测试用例，而需经边值分析，并且不仅分析输入的边值还分析输出的边值。,黑盒方法,等价划分，边值分析，因果图，猜测错误,白盒方法,语句覆盖，判定覆盖，条件覆盖，判定/条件覆盖，多重条件覆盖,35,3因果图。因果图是一种用于设计测试用例的图形工具，它对用自然语言书写的需求或设计标准的内容进展分析，找出输入(因)与输出(果)及其间的逻辑关系，并由图的形式表示出来。通过布尔逻辑吸收、合并，删去低效率的测试用例，最后将因果图转换成判定表，将判定表中的每一列转换成高效率的测试用例。IBM公司有几个这样的程序专利。,36,4猜测错误。凭直觉和经历列出可能有的错误和易错情况表，并写出测试用例。,5语句覆盖。选择足够的测试用例使程序中的每条语句至少被执行一次。这是一个必要但不充分的准那么。,6判定覆盖。要求程序中的每一个分支语句至少都通过一次，即每一条判定语句的真值执行一次，假值也执行一次。它较语句覆键的逻辑覆盖好些，但同样是不充分的。,37,7条件覆盖。执行所设计的测试用例，使得判定中的每个条件都获得各种可能的结果。它较判定覆盖准那么要好，但不能替代它。,8判定条件覆盖。要求设计足够的测试用例，使得每个判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能也至少出现一次，同时程序的每个入口点至少要进入一次。,9多重条件覆盖。执行所设计的调试情况，使得每个判定中条件结果的所有可能组合至少出现一次，程序所有入口都至少进入一次，显然这是一种最强的逻辑覆盖准那么。,38,路径覆盖,39,测试方法,模块独立测试,模块独立测试或程序单元测试是指测试程序中的单个子程序或过程的测试(以下简称模块测试)。,模块测试的目的是对模块的功能与模块的性能标准或接口标准进展比较，以提醒模块与标准的矛盾。模块测试主要是采用白盒测试方法。利用一种或多种白盒测试法对模块的逻辑构造进展分析，得到一些测试用例，然后根据模块标准再用黑盒方法对原有的测试用例加以补充。,40,综合测试,综合测试是测试程序模块间接口的过程，以发现模块间相互作用出现的问题。综合测试模块组装方法有自顶向下、自底向上及混合测试等方法。,41,面向对象的软件测试,传统的软件测试以构造化软件开发为主，在理论和方法上已经取得丰硕成果，但自20世纪80 年代中后期以来，面向对象软件开发技术迅速开展.,尽管面向对象技术的根本思想保证了软件有更高的质量，但因为无论采用什么样的编程技术，编程人员的错误都是不可防止的，而由于面向对象技术开发的软件代码重用率高，更需要严格测试，以防止错误的繁衍。,42,面向对象软件语言特征对测试影响,封装性对测试的影响,继承性对测试的影响,多态和动态绑定对测试的影响,UMLUnified Modeling Language已成为面向对象分析与设计的标准建模语言。,43,软件建模的区别,传统软件开发所采用的是从过程的角度即构造化方法来建立模型，它采用了模块分解和功能抽象的手段，开发人员把精力集中在控制流程和算法上。,面向对象软件开发利用对象、属性和操作作为主要的建模成分对问题进展建模。它从需求分析入手，开发人员可以把精力集中在所研究的问题域上,其软件模型的改变,44,软件测试层次,传统软件测试层次,面向对象软件测试层次,单元测试,类测试,集成测试,类簇(交互)测试,系统测试,系统测试,45,类测试与传统的单元测试区别,输入数据,处理,输出数据,传统测试模型,输入数据,处理,输出数据,类的测试模型,初始状态,完毕状态,46,类测试的执行顺序,47,类簇测试,类簇测试又称为类的交互测试，它主要考察一组协同操作的类之间的相互作用。,系统测试是检验系统是否符合要求,系统测试,面向对象软件的系统测试与传统的系统测试没有太大的区别，仅仅是测试用例的形式不同有所而已。,48,实例模型测试-,撞球游戏,在软件开发的前期，我们可以对软件进展建模，这使得我们可以在编写具体代码之前先对软件的模型进展测试。对分析和设计模型进展测试的好处在于：,测试用例可以更早地确定。,漏洞可在开发过程中早期检测出来，从而节省了时间、金钱和精力。,对代码测试有指导意义，使之有的放矢,49,撞球游戏的模型测试,50,模型测试过程,用例建模,类建模,动态和交互分析,51,用例建模,通过UML的用例图use-case diagram和各种情景来进展用例建模。,52,用例模型审查标准,标准,对需求的说明,完整性,使用用例描述了一个合格产品所需的所有功能。,正确性,每个用例都要精确地描述了一个需求,一致性,需求之间没有相互矛盾的地方,53,类建模,用UML类图class diagram进展类建模。,54,Ballxp类是游戏的核心类，游戏中的数据运算、情形判定和图形绘制都是通过它来完成的。,比方为了实现游戏的根本功能，Ballxp类中必须包含有小球、砖块和木棍的状态信息，必须有数据更新、画球、画砖、画木棍的功能。为了响应游戏者的鼠标移动，又要添加承受鼠标信息的接口函数。为了应对小球在不同区域的碰撞，还要对当前的小球位置进展识别。,55,动态和交互分析,UML中可用状态图和顺序图来表述，它可以方便我们分析软件实际运行时的动态过程。,56,撞球游戏的顺序图,57,通过上面的一系列模型和分析，我们可以审查软件在设计上的疏漏。,要尽量在编码开场前对设计充分检查，否那么，在后期修复错误的代价将相当大。这是模型测试的意义所在。,58,软件可靠性预计,软件可靠性预计：由模块可靠性软件系统的可靠性,软件可靠性预计的三个要素：模型、数据和参数估计,软件可靠性预计和可靠性测试的关系：,软件可靠性测试为可靠性预计提供数据,软件可靠性预计给出什么时候停顿测试,59,软件可靠性模型概述,正因为软件可靠性有着举足轻重的影响，在软件开发阶段完毕之前需要估计和预测软件可靠性。,软件可靠性模型是分析和评估软件可靠性的根底。,软件可靠性模型的目的是使用某种随机过程将软件可靠性或其相关量表示成时间和软件产品特性或者开发过程的函数。,软件可靠性建模的根本思路是用过去的失效数据建立可靠性模型，然后用所建立起来的模型估计现在的软件可靠性和预测将来的软件可靠性。,对于软件的模块、子系统、系统都可以应用软件可靠性模型。,60,最早的模型是于1956年提出来的一系列公式，但由于它们过于复杂而对后来的建模几乎没有影响；,最早的建模活动可追溯到1967年Hudson的工作，他当时以随机生灭过程描述软件缺陷的引入和剔除过程；,进入20世纪70年代后，Jelinski、Moranda、Halstead、Littlewood、Verrall、Musa等软件可靠性建模的先驱们从不同的角度基于不同的假设各自发表了大量的模型，并就各自模型的优越性进展了长时间的争论。,61,之后，在先驱者的工作成果根底上，经过更多软件可靠性工作者30余年来的努力，软件可靠性模型到目前为止已经出现上百种；,现有的模型几乎将目前数理统计中常用的随机分布都用到了；,最为常见且比较具有代表意义的模型不下20个，对软件可靠性的度量、评估和预测起到了积极的作用；,与此同时，软件可靠性工作者不断引入各种先进的思想，力图抑制各种假设对模型使用造成的障碍。,62,软件可靠性模型分类,软件可靠性模型主要分为经历模型和解析模型，普遍使用的是解析模型。,根据不同的准那么，可对解析模型再作分类：,1根据建模对象的不同分类，如面向数据、面向错误数和面向时间的模型；,2根据模型假设的不同分类；,3根据模型适用阶段的不同分类，如适用于测试阶段的增长模型和适用于确认阶段确实认模型；,4根据模型使用的数学工具不同分类，分为统计模型和概率模型。,63,模型具体类型,根据作为建模对象的数据或信息是否与时间相关，软件可靠性模型可分为静态模型和动态模型。,静态模型可进一步分为：缺陷播种模型、基于数据域模型和经历模型。,动态模型可进一步分为微观模型和宏观模型，前者考虑软件内部的特征量如语句数，一定程度上视软件为白箱；后者不考虑软件内部构造或特征量，视软件为黑箱。,64,软件可靠性模型,模型,动 态,静 态,宏 观,微观,模型,缺陷播种,模型,数 据 域,模型,经 验,模 型,故障时间,故障计数,Jelinski-Moranda,Schick-Wolverton,Moranda几何,Musa执行时间,Littlewood-Verrall,Goel-Okumoto NHPP,Moranda 几何Possion,Shooman,超几何,Neison,Halstead,表中表示隶属关系,65,JelinskiMorandaJM模型,假设：,1软件最初的错误数N为常值，用表示在第(i-1)个错误被改正后，软件投入运行至第次i故障发生前这个阶段的时间，且故障间隔时间是统计独立的。,2在两个相继故障构成的时间间隔内，软件的故障率为常数，其大小正比于软件中的残存错误数。,3每个软件错误一经发现，立即被修正，且不考虑修改错误的时间，也不产生新的错误。,4每次故障后总有并仅有一个错误被排除，因此系统的故障率是阶梯式下降的。,按上述假设得出的软件系统故障的密度函数为：,66,故障率为：,可靠度为：,参数估计,建立极大似然方程第七章：,运用极大似然方法：,67,可得模型参数的极大似然估计值：,可靠度指标发现个软件错误后，停顿测试。此时，软件的可靠性水平为：,68,例题,Jelinski,和,Moranda,曾在美国海军舰队计算机程序编制中心利用海军战术数据系统 (NTDS)的软件故障数据，对他们的模型作了验证。,验证结果正确,69,阶段,错误数,错误间隔时间（日）,累计时间（日）,JM预计的故障时间,设,计,阶,段,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,9,12,11,4,7,2,5,8,5,7,1,6,1,9,4,1,3,8,6,1,1,33,7,91,2,1,9,21,32,36,43,45,50,58,63,70,71,77,78,87,91,92,95,98,104,105,116,149,156,247,249,250,4.7,4.8,5.9,5.2,5.4,5.6,5.8,6.0,6.3,6.6,6.9,7.2,7.6,8.0,8.5,9.0,9.6,10.3,11.1,12.0,13.0,14.3,15.9,17.8,20.3,23.5,测,试,阶,段,27,28,29,30,31,87,47,12,9,135,337,384,396,405,540,28.1,34.8,45.6,66.4,121.7,使用阶段,32,33,34,798,814,849,=0.00685,总的错误数,故障率系数,70,Littlewood-Verrall模型,L-V模型发表于1973年，是最早的软件可靠性模型之一，也是第一个贝叶斯模型。,类别：动态、宏观、面向故障时间的模型。,模型假设：,1相邻故障时间间隔x1,x2, ,xn构成一列独立随机变量，xi服从参数为i的指数分布；,2 i 构成一列独立随机变量，i服从参数为和(i)的Gamma分布；,3软件运行方式与预计的运行剖面一样；,4所有软件缺陷等级一样。,71,Nelson模型,最早于1973年提出，并于1978年得以完善，是基于数据域软件可靠性模型, 工程应用最多的模型之一。,类别：静态、基于数据域模型。,模型假设：,1软件执行可分解为一系列执行回合，每个回合对应输入空间中的一个输入；,2每次输入的结果可能是运行成功或运行失败；,3测试过程中不剔出错误。,如果输入空间共有N个元素，测试结果有n个元素导致运行失败，那么软件运行一次失败的概率为：p=n/N；,故软件运行一次无故障的概率为R(1)=1-p=1-n/N；,软件运行m次无故障的概率为R(m)=(1-n/N)m 。,72,软件可靠性模型简介,73,软件的验证与确认V&V),软件的生存期,74,软件验证和确认的目的,检验和保证软件的质量和可靠性的途径有两种：被动的和主动的。前者的目的是发现软件中的错误并纠正它，只能说明软件有错误，而不能证明无错。这就是一般意义下的调试(Debug)，它是长期来保证软件质量和可靠性的主要手段。目前已形成科学而有技巧性的软件可靠性测试技术，它的目的是最大限度地证明软件是正确的。具体来说，就是提高软件的正确性、可靠性、内部的完整性和一致性，使产品符合设计目标、要求和标准，这就是软件的验证和确认。显然，要完全到达后一目的是很难的。,75,软件验证定义,软件验证是显示软件在生存期各阶段正确实现和满足要求标准而无设计和构造技术错误的过程。一般认为软件验证是指程序正确性证明，这是人们所期望的、理论上完美的主动检验方法，但尚末实用化。尤其对于复杂程序，要给出正确性证明是极其困难的。一般对软件局部功能或模块尽可能进展验证，力求给出正确性证明，或理解为运行的程序和它的外部说明文件之间的等价性证明。因此，在软件的要求标准文件不完整或模糊其词的情况下，谈论程序的正确性是没有意义的。而要求标准文件又是软件的一局部，同样需加以验证，验证需保证软件错误被检测出来并加以消除。验证是在测试或模拟环境下执行程序发现错误。,76,软件确认的定义,软件确认是显示系统(硬、软件)实现了要求标准所列的各项功能及性能的过程。确认过程必须显示该标准是完整一致的，整个软、硬件系统在所有状态下均是正确反映满足要求的。确认一般在软件综合测试阶段进展，由于验证比较困难，就进展确认，使软件尽可能“正确。确认是在给定实际系统中执行程序来发现错误。,测试可看做是验证程序正确性的一种试验方法，也是确认的有力手段。但由于测试数据的局限性，一个已被确认的系统对测试数据以外的情形可能出错，因此，确认也不是绝对的，即测试只消除了利用工程所用测试方法和测试数据能查获出的大多数过失。,77,数字飞行控制系统软件验证与确认,78,79,谢谢！,80,谢谢观赏,