《软件可靠性》PPT课件.pptVIP

第三单元软件可靠性 2007年8月12日 软件可靠性问题的提出 20世纪中期是计算机硬件飞速发展的阶段 但软件开发尚处于低级阶段 软件的重要性还不显著 随着软件的大量使用和软件规模的迅速增长 软件可靠性低的问题日益显著 并作为 软件危机 的主要问题之一于1968年被提了出来 据了解 美国航天飞机上飞行软件有50多万行源代码 而F一22战斗机上的飞行软件的源代码数更是高达150多万行 另据美国军方的统计 美国军方在武器装备作战使用中遇到的问题 软件问题约占到70 左右 由于软件故障造成的重大事故不乏其例 美国空军的范登堡中心在60年代后期发生过多次导弹试射失败的事故 事后发现几乎都是由软件错误造成的 F一18战斗机在海湾战争中 飞行控制软件共发生了500多次故障 我国某型号飞机首飞前航空电子系统在地面测试中测出的故障共800多个 其中软件故障就达600多个 约占75 由于软件故障造成的重大事故不乏其例 1990年1月15日 美国一通信中转系统新投入使用的软件发生了错误 导致主干线远程网大规模崩溃 美国的Therac 25放射性治疗仪由于软件存在缺陷导致几个癌症病人受到非常严重的过量放射性治疗 其中4个人因此死亡 2002年11月28日 欧洲的亚里安娜5型火箭因发动机控制系统软件的错误而导致飞行试验失败 软件可靠性的发展 在20世纪50年代末60年代初 计算机硬件从晶体管到集成电路 得到了飞速的发展 而软件开发仍处于很低级的阶段 极大地依赖于开发人员的编程技巧 且主要关注的是软件的功能 1968年在西德召开的国际软件工程会议上提出的 软件危机 的主要问题之一 就是软件可靠性低 经常出故障 从那时起 才开始认识到软件可靠性的重要性 据统计 计算机系统中 由于软件错误引起的故障占所有故障的65 美国贝尔 Bell 实验室曾对一个AT T运行支持系统作了统计 发现80 的故障与软件有关 究其原因是软件太复杂了 一个小小的程序 其可能的路径可以是天文数字 以致于在软件开发过程中难以对其作穷尽的测试 或者说难于完全排除软件缺陷 调用路径太多 其中每个结点或圆圈代表一段可能以转移语句结束的顺序执行语句 每条弧代表两段程序间的控制转移 程序含有一个最少重复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亿 1 故障机理硬件产生故障的原因有四个方面 即设计问题 生产过程中的问题 超载及耗损 硬件故障主要是由于耗损 物理退化 所致的 而软件不存在物理退化现象 这就决定了软件正确性与软件可靠性密切相关 一个正确的软件任何时刻均可靠 然而一个正确的硬件元器件或系统则可能在某个时刻故障 软件没有耗损问题并不等于没有可靠性问题 因在开发过程中常有一些随机因素 不可避免地会在软件中留下缺陷 因而软件也有可靠性问题 所以硬件的故障机理是耗损 而软件的故障机理就是残留缺陷在一定环境下造成的软件错误 软件与硬件的不同 2 复杂性 软件内部逻辑高度复杂 而硬件内部逻辑较为简单 这就在很大程度上决定了设计错误是导致软件故障的主要原因 而导致硬件故障的可能性则很小 3 唯一性软件是唯一的 软件拷贝不改变软件本身 而任何两个硬件不可能绝对相同 软件可靠性的核心是 思考 问题 软件中不可能象硬件那样分解成元部件 它只有语句 语言本身造成的软件故障较少 且通过静态测试 目测或编译 可加修正 软件错误来源主要是软件设计者的思维错误及软件的复杂性 这是难以控制的 故软件可靠性的提高需从人的思维正确性和减少软件的复杂性两方面着手 这正如我们用汉语写文章 观点有错误不能归咎于语言本身不好 而应归咎于人的思想 4 可靠性的核心 由于软件内部逻辑复杂 运行环境动态变化 且不同的软件差异可能很大 因而软件故障机理可能有不同的表现形式 譬如有的故障过程比较简单 易于追踪分析 而有的故障过程可能非常复杂 难于甚至不可能加以详尽描述和分析 尤其是运行于高度复杂实时环境中的大型软件 但总的说来 软件故障机理可描述为 软件缺陷 软件错误 软件故障 软件故障 1 软件缺陷 软件缺陷 Default 软件开发中残留的内在缺陷称为软件缺陷 这些缺陷可以在软件生存期的各个阶段被引入 在软件开发的各阶段 软件始终离不开人的参与 而人难免会犯错误 这样就必然给软件留下不良的痕迹 例如一段程序进行某些数据处理 若在处理过程中就产生软件错误 则说明这段程序存在缺陷或缺少一个程序段 软件缺陷是一个静止的现象 只在一定的输入条件下才能被激活导致软件错误 而且软件错误也不一定导致软件故障 比如容错软件中的错误就可以被检测出来并可纠正或避免 而不导致故障 2 软件错误 软件错误 Error 软件缺陷在一定条件下暴露并导致系统在运行中出现可感知的不正常 不正确 不按规范执行的内部状态 则认为软件出现 错误 简称出错 所谓不正确的内部状态 是指在此状态下 当正常的算法继续下去时 就会发生软件故障 软件错误是由于软件缺陷造成的 一个错误可能是多个故障源 例如 在求最大值的程序中 设计人员由于疏忽将求得的平均值作为最大值 这就是一个软件错误 3 软件故障 软件故障 Failure 在对错误不作任何纠正和恢复的情况下 导致系统的输出不满足用户提供的正式文件上指明的要求或双方协议的条款 称为软件的一次故障 软件故障是由于软存错误造成的一种外部表现 它是动态的 程序执行过程中出现的行为表现 2 中的故障例子 由于没有容错措施 即没有限制和排除软件故障的措施 最终将得到不可接受的结果 平均值 产生软件故障 软件故障的特点 影响软件可靠性的因素 运行环境 剖面 同一软件在不同运行剖面下 其可靠性行为可能极不相同 由于软件故障是软件缺陷在一定输入情况下被激活的结果 假设软件输入域划分为两个部分 G和F 运行剖面不包含F中的输入 则软件不会出现故障 其可靠性恒为l 反之 如果运行剖面不包含G中的输入 则每一输入情况下均出现故障 如果没有容错措施则R 0 软件规模 随着软件规模的增大 软件可靠性问题愈显突出 在我们考虑软件可靠性问题时 软件一般是指中型以上软件 4000 5000条以上语句 这时可靠性问题难以对付 软件工程实践的一个侧面可以反映这一点 即单元测试一般由编程人员本人进行 而综合测试则需独立的测试人员 软件可靠性增长模型也主要应用于综合测试阶段 软件内部结构 软件内部结构一般比较复杂 且动态变化 对可靠性的影响也不甚清楚 但总的说来 结构越复杂 软件复杂度越高 内含缺陷数越大 因而软件可靠度越低 软件可靠性设计技术 关于软件可靠性设计技术的外延并不明确 但一般是指软件设计阶段中采用的用以保证和提高软件可靠性为主要目标的软件技术 软件可靠性测试 研究表明 软件测试方法与资源投入对软件可靠性有不可忽视的影响 软件可靠性管理 软件可靠性管理旨在系统管理软件生存期各阶段的可靠性活动 使之系统化 规范化 一体化 这样就可以避免许多人为错误 以提高软件可靠性 软件开发人员能力和经验 显然 软件开发人员 包括测试人员 的能力愈强 经验愈丰富 所犯错误便可能愈少 所得软件产品质量愈高 相应的可靠性也愈高 软件开发方法 软件工程表明 开发方法对软件可靠性有显著影响 与非结构化方法比较 结构化方法可以明显减少软件缺陷数 软件开发环境 研究表明 程序语言对软件可靠性有影响 譬如 结构化语言Ada优于Fortran语言 而软件测试工具优劣则影响测试效果 软件可靠性定义 1 沿用硬件可靠性的定义 即软件可靠性是指软件在所规定的环境条件下 规定的时间内 一直能按要求和规格说明正确地完成任务的性质 这一性质的概率 定量 描述也称为可靠度 可用可靠度函数表示 可见这是一种面向时间的定义方法 它没有考虑故障的原因 软件产品故障的特点及软件产品的特殊性 2 软件可靠性定义为 假定输入和硬件都没有错误 对于一组输入数据 软件能正常运行不发生错误的概率 这是一种面向数据的定义方法 建议推荐 软件可靠性技术 软件避错技术软件容错技术软件测试技术软件预计技术 软件避错技术 软件设计技术 1 自顶向下设计 TDD Top DownDesign 是把系统功能最抽象描述作为最高层次 并从它出发 把系统分成分级的分系统 称为层 Levels 2 数据结构设计法 主要注意力集中在信息结构和信息流动上 而不是过于集中在所要完成的功能上 如定义数据结构 标识数据流 定义能使数据流动的操作等 为了防止数据冲突 须引进中间文件 来实现输入数据与输出数据的结构转换处理 3 高级软件 HOS HigherOrderSoftware 方法论 这是一种详细说明和开发可靠软件系统的方法论 是完全面向系统而不是面向传统软件的 高级软件的基本出发点是把一个给定的系统看成一个 软件 并可用数学模型 即函数 来描述 1974年NASA将高级软件首次在宇宙飞船模型软件开发中应用 现已用于开发宇宙飞船的飞行软件中 软件实现技术 1 自顶向下 Top DownProgramming TDP 和由底向上程序设计 Bottom UpProgramming BUP 方法 2 模块程序设计 MP ModularProgramming 的思想是把整个软件系统分解成为一系列独立的代码段来实现软件的 每段就叫一个模块 它常常是一个小型的 面向功能性的子程序或函数 每个模块用来表示与某个功能有关的一个或多个任务 模块之间的数据通信靠接口来完成 模块之间有一定的独立性 可由不同的程序员编程来加快实现的进程 3 逐步求精程序设计 SWRP StepWiseRefinementProgramming 的基本思想是 对于一个复杂的问题 先解决容易部分 给出较粗的框图 接着对剩下的问题再作更细的分解 如此反复 直到所有问题都解决为止 4 结构化程序设计 SP StructureProgramming 概念是强调从程序结构和风格上来研究程序设计 结构化程序设计严格说不是一种程序设计的方法 而是编程的一个标准或风格 软件避错技术的应用 在 美洲豹 Jaguar 飞机的数字式电传飞行控制系统的飞控软件中 软件容错技术 N文本技术 N文本特点 独立设计 尽量采用不同的算法和数据结构 不同的语言 不同的程序员来编写 每个文本程序中设置一个或多个交叉检测点 每当文本执行到一个交叉检测点时便产生一个比较向量 并将比较向量交给表决程序 自己则进入等待状态 等待来自表决驱动的指令 比较向量 比较向量 用于比较的目的 比较状态标志 用来指示在产生比较向量的过程中是否发生了特殊事件 譬如监测到例外条件 遇到文本结尾等 表决程序 激活各文本使之投入运行 接受来自各文本的比较向量 实现各文本同步 比较各文本的比较向量 处理比较结果 恢复块技术 软件容错技术的应用 F 8纵向数字飞行控制系统在各余度硬件通道中采用了非相似软件 即 恢复块 也就是F 8DFBW驻留备份软件 ResidentBackupSoftware简称REBUS 软件测试技术 定义 软件测试是为了发现错误而执行软件的过程 或者说软件测试是根据软件开发各阶段的说明和程序内部结构 精心设计的测试用例 测试用例 而执行软件及发现错误的过程 软件测试的原则 1 好的测试用例能使从程序中查出以前未发现的错误的可能性增大 2 能查出先前未发现的错误的测试是成功的测试 3 尽量避免程序员及程序设计机构测试自己的程序 因为软件测试中人的心理状态是重要的问题之一 软件测试的一般步骤 软件测试方法 1 静态测试 不执行程序而只是检查源程序的结构 文法和过程间的接口是否有错的测试称为静态测试 程序编译是静态测试的一种方法 还有许多其它测试工具如审查会等人工测试法 2 动态测试 使程序在某种控制环境中运行 在完成所要求的功能的同时 检查是否存在不必要的功能的测试称为动态测试 动态测试对要求 数据 结果和内部程序工作状态四部份的对应关系进行准确选择和测定 动态测试也称程序测试 是通过测试用例执行程序发现错误的过程 测试策略 黑盒 测试法黑盒测试又称数据驱动 输入 输出驱动 测试方案 在应用这种方案时 测试者把程序看成一个黑盒 即完全不考虑程序内部结构和内部特性 仅按软件说明书来测试程序所有可能的输入情况 如果将所有输入情况都测试一遍这将是一个天文数字 白盒 测试法白盒测试法又称逻辑驱动测试 它允许人们检查程序的内部结构 使用这一方案时 测试者从检查程序的逻辑着手 按程序结构测试 即测试程序的每一条路径而不考虑软件说明书的要求 显然 独立路径也是一个天文数字 虽然以上两种极端方案都不可行 但它却给测试提供了考虑问题的方向 即应该把程序外部功能和内部结构结合起来 形成新的测试方案 测试用例设计 1 等价划分 把输入域作等价划分 使所设计的测试用例具有代表性 即一个测试用例可以代表与其等价的其它测试用例 2 边值分析 边值分析不是简单地等价类中找一个测试用例 而需经边值分析 并且不仅分析输入的边值还分析输出的边值 3 因果图 因果图是一种用于设计测试用例的图形工具 它对用自然语言书写的需求或设计规范的内容进行分析 找出输入 因 与输出 果 及其间的逻辑关系 并由图的形式表示出来 通过布尔逻辑吸收 合并 删去低效率的测试用例 最后将因果图转换成判定表 将判定表中的每一列转换成高效率的测试用例 IBM公司有几个这样的程序专利 4 猜测错误 凭直觉和经验列出可能有的错误和易错情况表 并写出测试用例 5 语句覆盖 选择足够的测试用例使程序中的每条语句至少被执行一次 这是一个必要但不充分的准则 6 判定覆盖 要求程序中的每一个分支语句至少都通过一次 即每一条判定语句的真值执行一次 假值也执行一次 它较语句覆键的逻辑覆盖好些 但同样是不充分的 7 条件覆盖 执行所设计的测试用例 使得判定中的每个条件都获得各种可能的结果 它较判定覆盖准则要好 但不能替代它 8 判定条件覆盖 要求设计足够的测试用例 使得每个判定中每个条件的所有可能结果至少出现一次 每个判定本身所有可能也至少出现一次 同时程序的每个入口点至少要进入一次 9 多重条件覆盖 执行所设计的调试情况 使得每个判定中条件结果的所有可能组合至少出现一次 程序所有入口都至少进入一次 显然这是一种最强的逻辑覆盖准则 路径覆盖 测试方法 模块独立测试模块独立测试或程序单元测试是指测试程序中的单个子程序或过程的测试 以下简称模块测试 模块测试的目的是对模块的功能与模块的性能规范或接口规范进行比较 以揭示模块与规范的矛盾 模块测试主要是采用白盒测试方法 利用一种或多种白盒测试法对模块的逻辑结构进行分析 得到一些测试用例 然后根据模块规范再用黑盒方法对原有的测试用例加以补充 综合测试 综合测试是测试程序模块间接口的过程 以发现模块间相互作用出现的问题 综合测试模块组装方法有自顶向下 自底向上及混合测试等方法 面向对象的软件测试 传统的软件测试以结构化软件开发为主 在理论和方法上已经取得丰硕成果 但自20世纪80年代中后期以来 面向对象软件开发技术迅速发展 尽管面向对象技术的基本思想保证了软件有更高的质量 但因为无论采用什么样的编程技术 编程人员的错误都是不可避免的 而由于面向对象技术开发的软件代码重用率高 更需要严格测试 以避免错误的繁衍 面向对象软件语言特征对测试影响 封装性对测试的影响继承性对测试的影响多态和动态绑定对测试的影响 UML UnifiedModelingLanguage 已成为面向对象分析与设计的标准建模语言 软件建模的区别 传统软件开发所采用的是从过程的角度即结构化方法来建立模型 它采用了模块分解和功能抽象的手段 开发人员把精力集中在控制流程和算法上 面向对象软件开发利用对象 属性和操作作为主要的建模成分对问题进行建模 它从需求分析入手 开发人员可以把精力集中在所研究的问题域上 其软件模型的改变 软件测试层次 类测试与传统的单元测试区别 输入数据 处理 输出数据 传统测试模型 输入数据 处理 输出数据 类的测试模型 初始状态 结束状态 类测试的执行顺序 类簇测试 类簇测试又称为类的交互测试 它主要考察一组协同操作的类之间的相互作用 系统测试是检验系统是否符合要求 系统测试 面向对象软件的系统测试与传统的系统测试没有太大的区别 仅仅是测试用例的形式不同有所而已 实例模型测试 撞球游戏 在软件开发的前期 我们可以对软件进行建模 这使得我们可以在编写具体代码之前先对软件的模型进行测试 对分析和设计模型进行测试的好处在于 测试用例可以更早地确定 漏洞可在开发过程中早期检测出来 从而节省了时间 金钱和精力 对代码测试有指导意义 使之有的放矢 撞球游戏的模型测试 模型测试过程 用例建模类建模动态和交互分析 用例建模 通过UML的用例图 use casediagram 和各种情景来进行用例建模 用例模型审查标准 类建模 用UML类图 classdiagram 进行类建模 Ballxp类是游戏的核心类 游戏中的数据运算 情形判定和图形绘制都是通过它来完成的 比如为了实现游戏的基本功能 Ballxp类中必须包含有小球 砖块和木棍的状态信息 必须有数据更新 画球 画砖 画木棍的功能 为了响应游戏者的鼠标移动 又要添加接受鼠标信息的接口函数 为了应对小球在不同区域的碰撞 还要对当前的小球位置进行识别 动态和交互分析 UML中可用状态图和顺序图来表述 它可以方便我们分析软件实际运行时的动态过程 撞球游戏的顺序图 通过上面的一系列模型和分析 我们可以审查软件在设计上的疏漏 要尽量在编码开始前对设计充分检查 否则 在后期修复错误的代价将相当大 这是模型测试的意义所在 软件可靠性预计 软件可靠性预计 由模块可靠性 软件系统的可靠性软件可靠性预计的三个要素 模型 数据和参数估计软件可靠性预计和可靠性测试的关系 软件可靠性测试为可靠性预计提供数据软件可靠性预计给出什么时候停止测试 软件可靠性模型概述 正因为软件可靠性有着举足轻重的影响 在软件开发阶段结束之前需要估计和预测软件可靠性 软件可靠性模型是分析和评估软件可靠性的基础 软件可靠性模型的目的是使用某种随机过程将软件可靠性或其相关量表示成时间和软件产品特性或者开发过程的函数 软件可靠性建模的基本思路是用过去的失效数据建立可靠性模型 然后用所建立起来的模型估计现在的软件可靠性和预测将来的软件可靠性 对于软件的模块 子系统 系统都可以应用软件可靠性模型 最早的模型是H K Weiss于1956年提出来的一系列公式 但由于它们过于复杂而对后来的建模几乎没有影响 最早的建模活动可追溯到1967年Hudson的工作 他当时以随机生灭过程描述软件缺陷的引入和剔除过程 进入20世纪70年代后 Jelinski Moranda Halstead Littlewood Verrall Musa等软件可靠性建模的先驱们从不同的角度基于不同的假设各自发表了大量的模型 并就各自模型的优越性进行了长时间的争论 之后 在先驱者的工作成果基础上 经过更多软件可靠性工作者30余年来的努力 软件可靠性模型到目前为止已经出现上百种 现有的模型几乎将目前数理统计中常用的随机分布都用到了 最为常见且比较具有代表意义的模型不下20个 对软件可靠性的度量 评估和预测起到了积极的作用 与此同时 软件可靠性工作者不断引入各种先进的思想 力图克服各种假设对模型使用造成的障碍 软件可靠性模型分类 软件可靠性模型主要分为经验模型和解析模型 普遍使用的是解析模型 根据不同的准则 可对解析模型再作分类 1 根据建模对象的不同分类 如面向数据 面向错误数和面向时间的模型 2 根据模型假设的不同分类 3 根据模型适用阶段的不同分类 如适用于测试阶段的增长模型和适用于确认阶段的确认模型 4 根据模型使用的数学工具不同分类 分为统计模型和概率模型 模型具体类型 根据作为建模对象的数据或信息是否与时间相关 软件可靠性模型可分为静态模型和动态模型 静态模型可进一步分为 缺陷播种模型 基于数据域模型和经验模型 动态模型可进一步分为微观模型和宏观模型 前者考虑软件内部的特征量如语句数 一定程度上视软件为白箱 后者不考虑软件内部结构或特征量 视软件为黑箱 软件可靠性模型 表中 表示隶属关系 Jelinski Moranda J M 模型 假设 1 软件最初的错误数N为常值 用表示在第 i 1 个错误被改正后 软件投入运行至第次i故障发生前这个阶段的时间 且故障间隔时间是统计独立的 2 在两个相继故障构成的时间间隔内 软件的故障率为常数 其大小正比于软件中的残存错误数 3 每个软件错误一经发现 立即被修正 且不考虑修改错误的时间 也不产生新的错误 4 每次故障后总有并仅有一个错误被排除 因此系统的故障率是阶梯式下降的 按上述假设得出的软件系统故障的密度函数为 故障率为 可靠度为 参数估计建立极大似然方程 第七章 运用极大似然方法 可得模型参数的极大似然估计值 可靠度指标 发现 个软件错误后 停止测试 此时 软件的可靠性水平为 例题 Jelinski和Moranda曾在美国海军舰队计算机程序编制中心利用海军战术数据系统 NTDS 的软件故障数据 对他们的模型作了验证 验证结果正确 总的错误数 31 2故障率系数 Littlewood Verrall模型 L V模型发表于1973年 是最早的软件可靠性模型之一 也是第一个贝叶斯模型 类别 动态 宏观 面向故障时间的模型 模型假设 1 相邻故障时间间隔x1 x2 xn构成一列独立随机变量 xi服从参数为 i的指数分布 2 i 构成一列独立随机变量 i服从参数为 和 i 的Gamma分布 3 软件运行方式与预计的运行剖面相同 4 所有软件缺陷等级相同 Nelson模型 最早于1973年提出 并于1978年得以完善 是基于数据域软件可靠性模型 工程应用最多的模型之一 类别 静态