Ch05软件可靠性度量.pptVIP

2019/9/15,,1,第5章 软件可靠性度量,2019/9/15,,2,5.1 引言,5.1.1 软件可靠性工程及软件可靠性 软件可靠性工程 应用统计技术，处理在软件开发过程中或（和）运行期间所采集的失效数据，以便详细说明并预计、估计和评价软件的可靠性 研究内容包括软件可靠性的基本概念和定义、软件可靠性指标体系、可靠性建模、可靠性设计技术、测试技术和管理技术等,2019/9/15,,3,软件可靠性工程处理以下问题： 确定某过程能否提供满足可靠性要求的代码 为过程改进提供度量 预测软件维护阶段的失效率，确定软件维护工作量 帮助进行安全性认证 确定交付软件产品的时间或停止测试的时机 估计下次故障的可能时间 为软件更新或升级，标识需要重新设计的主要部件 测定软件的可靠性,2019/9/15,,4,软件可靠性 可靠性是软件的13个质量因素中最关键、最重要的 软件可靠性是指在规定时间和条件下软件无故障运行的概率，是系统功能或软件产品中存在的缺陷的函数 软件故障产生的原因是软件缺陷，但缺陷并不一定导致故障的产生，高缺陷率的软件的可靠性不一定就差 软件失效意味着软件运行中断或者无法完成所规定的任务,2019/9/15,,5,几个值得关注的问题： 软件的运行环境：软件可靠性与运行环境密切相关 软件运行的时间间隔：商业软件需要较高的运行时间间隔（较长的运行寿命），而任务关键软件则需要在短时间内高效运行 软件失效的时机是随机的，与硬件失效类似 不同于软件的正确性，对于持续运行的软件其可靠性最终将归于零（以失效结束）；但正确性是软件的特定的某次运行结果，要么为1，要么为0,2019/9/15,,6,5.1.2 软件的缺陷、故障和失效 缺陷（Error，错误）：设计和构造进产品 总数是不可预知的，只能估计 缺陷分为已知和未知（新发现）的 缺陷分为已发现的和未发现的 已发现的缺陷包括已纠正的和未纠正的 故障（Fault）：运行结果错误 故障是缺陷的表现形式，是由存在的缺陷产生的 但缺陷并不一定导致故障，或者条件不具备，或者不会产生故障 失效（Failure）：系统不能完成所需要的功能而失败 失效是故障在软件运行时所产生的后果,2019/9/15,,7,软件质量度量与软件过程有什么关系？,2019/9/15,,8,失效与故障的区别,2019/9/15,,9,5.1.3 软件失效 软件失效是随机发生的 描述失效的方法有三个： 累计失效函数：即与某时间点相关的平均累计失效数 失效率函数：用累计失效函数的变化率表示 平均失效时间MTTF函数：对于一个时间段，表示若干相邻失效时间间隔的平均值；对某个时间点，表示到下次失效的期望时间,2019/9/15,,10,软件失效率 如果没有缺陷，软件失效率为0 如果发现的缺陷能被及时、完全修复，失效率会趋向0 实际上，发现的缺陷数会递增，而纠正一个缺陷会引入更多的缺陷，因而失效率会增加,时间,失效率,硬件,软件（实际）,软件（理想）,2019/9/15,,11,5.2 软件可靠性度量和建模,5.2.1 基本概念 软件可靠性建模过程是根据软件过去的故障行为建立软件可靠性数学模型的过程 建模的目的是为了预计软件将来的故障行为 建模过程包括以下步骤： 通过度量获得历史数据 对故障数据进行分析，拟合成概率分布函数 对拟合函数进行参数分析 确定所期望的可靠性度量值并预测可能的故障行为,2019/9/15,,12,5.2.2 软件可靠性度量参数 软件可靠性R(t)可定义为：在给定条件下，在时间0,t内，软件无故障运行的概率 若用T表示软件无故障运行的时间间隔，F(t)为T的累积分布函数，则软件可靠性可表示为： R(t)=1-F(t) t0 故障率函数(t)为： 其中，f(t)为F(t)的函数密度，即：,2019/9/15,,13,(t)t是在时间0，t内软件正常运行，在t,t+t内发生故障的条件概率，可得： 密度函数f(t)、累积分布函数F(t)、可靠性函数R(t)和故障率函数(t)紧密相关，一般可由任一个惟一地确定另外三个，例如若(t)给定，则： 根据f(t)或R(t)可计算平均失效时间函数MTTF，从而预测故障时间,2019/9/15,,14,5.2.3 软件可靠性度量模型 指数分布 密度函数为 分布函数为 故障率函数为 （常数） 具有指数寿命分布的软件产品（故障率为常数）没有老化现象，符合不需要维护的软件的运行情况,2019/9/15,,15,Weibull分布 Weibull是更常用的分布，在许多工程领域的可靠性分析中都广泛应用，如轴承磨损、河流泛滥等 Weibull分布有两个参数、（为1时变为指数函数） 函数密度为： 分布函数为： 故障率函数为：,2019/9/15,,16,=1时变为指数分布 =2时为Rayleigh分布,研究表明，软件项目的生命周期模式、项目的缺陷移除模式等都很好地符合Rayleigh模型,2019/9/15,,17,数据收集和分析是度量软件可靠性的最重要的先决条件，任何可靠性度量的有效性都与数据收集的有效性直接相关，数据收集过程必须有计划、有组织地进行 与软件可靠性相关的数据包括： 缺陷数据 过程数据 产品数据：如规模、功能、性能等,5.3 软件可靠性数据收集过程,2019/9/15,,18,5.3.1 缺陷数据的收集,缺陷数据的收集常采用问答、报告形式，即发放问题报告表格要求有关人员填写，收集并分析问题报告表格形成统计数据,2019/9/15,,19,5.3.2 过程数据的收集,缺陷数据必须与过程融合才有价值，因而过程数据也需要收集。通常会将项目的持续时间作为主要关心的过程数据，但实际需要更细分 与软件可靠性测试过程相关的数据包括： CPU时间：具有与人无关性，但易忽略人的工作（如评审等） 日历时间：优点是易于收集，但没有考虑阶段特征，如某些技术在某阶段更有效 运行时间：是为测试而运行软件的总时间，也未考虑阶段特征 其他数据：包括平均修复时间、完成每个过程活动的人数、软件生命期各阶段所用时间百分比、各阶段所消耗的资源数量、各阶段的开始、截止日期、各阶段修复一个缺陷所需的工作量、各功能模块的缺陷数，等等,2019/9/15,,20,5.4 软件的运行剖面,软件可靠性建模需要具备三个条件： 软件运行时间基准（日历时间、运行时间、CPU时间） 软件运行过程收集的数据，是建模基础 软件功能和运行环境 软件运行剖面用于定量描述软件的用户运行环境，即软件的功能和各功能的使用概率,2019/9/15,,21,5.4.1 软件新系统的运行剖面,不同的运行模式下各功能的使用概率不同 不同运行模式的出现模式也不同,2019/9/15,,22,运行剖面对软件可靠性工程极具价值： 可为开发过程的资源分配提供参考，有利于提高生产率、可靠性和加快开发速度 有利于测试，可确保常用功能获得更多测试 有利于设计测试用例，以发现影响可靠性最大的故障 根据功能的使用频度可确定开发的优先级 使功能描述更清晰，便于交流 有助于用户培训,2019/9/15,,23,5.4.2 软件运行剖面与可靠性的关系 软件可靠性度量、评估和预测与软件的某个特定的运行剖面密切相关 软件测试期间，为节省时间和成本，通常每个运行剖面只测试一次，因而不能反映每个剖面的出现概率，由此获得的可靠性数据也不能反映实际情况 要将测试期间获得的可靠性值变换为实际值，可用以下公式： 其中，u是实际的用户环境下的故障密度，T是测试值，C为测试压缩系数,2019/9/15,,24,C的含义是：在覆盖全部输入空间条件下，使用期间所要求的执行时间与测试阶段所要求的执行时间之比 C的计算公式为： 其中， k为输入状态k运行时的执行时间 Pk为输入状态k在运行期间的发生概率 QI为输入状态总数 Pmin为最少发生的输入状态的概率,2019/9/15,,25,5.4.3 软件运行剖面的建立,运行剖面是关于系统如何运行的定量描述，建立步骤为： 建立客户剖面：分类描述要获取该系统的客户的使用模式 建立用户剖面：分类描述要使用该系统的用户的使用模式 定义系统模式剖面：根据执行过程描述系统运行模式 确定功能剖面：划分功能并确定各功能的发生概率 确定运行剖面：确定系统各运行模式的发生概率,2019/9/15,,26,5.5 软件可靠性模型及应用,软件可靠性建模是软件可靠性工程的研究重点 5.5.1 与软件可靠性模型有关的问题 历史背景 20世纪70年代，Telinski、Moranda、Shooman等人提出了软件可靠性建模的问题，并使用建立的模型估计软件现在和未来的可靠性 经近40年的发展，软件可靠性模型已有很多种,2019/9/15,,27,软件可靠性模型的分类 Musa、Okumoto根据模型的5个特征进行分类： 时间域（time domain）：日历时间、执行时间或CPU时间 类别（Category）：软件在无限的时间内可能经历的故障数是有限的还是无限的 型（Type）：软件在运行时间t时的失效数分布分类 种类（Class）：故障密度对时间的函数分布（仅对有限故障类） 族（Family）：故障密度对它的期望故障数的函数分布（仅对无限故障类）,2019/9/15,,29,5.5.2 软件可靠性模型参数,与软件可靠性模型相关的参数有： ETF：软件中固有缺陷数，是固定的 ETV：同上，是变化的，在开发、维护过程中随时添加 EC(t)：某时刻已纠正的缺陷数 ED(t)：某时刻已发现的缺陷数 P：在修正缺陷过程中测试的循环次数，常假定 P=ED(t)=EC(t) EC(p)：直到第p次测试才修正的缺陷数 0：起始故障率 p：当前故障率 ：故障率的变化 ：累计执行时间 ：增长率 N：测试用例运行总数 S：成功的测试用例运行总数,2019/9/15,,30,6.5.3 软件可靠性模型,Musa模型 基本模型 假设：每个缺陷对故障率的贡献是相同的；每修正一个缺陷故障率均匀地减少，即故障率对时间的导数是常数；软件固有的故障总数是有限的，但不固定，即修正缺陷时可能产生新缺陷 Musa模型：,2019/9/15,,31,利用基本模型可估计要达到某可靠性目标还必须要发现（检测出）的缺陷数和需要的时间，有助于计划人力和时间 设要达到的可靠性目标为f，则需发现的故障数Nf为： 为达到这一目标所需时间Tf为：,2019/9/15,,32,对数模型 假设： 每个缺陷对故障率的贡献不同；常用的功能的缺陷可及早被检出，故障率的变化随时间减少；软件固有的故障总数是无限的 Musa模型： Nf和Tf为：,2019/9/15,,33,Goel-Okumoto模型 假设：缺陷对时间的分布是非时对齐的，即发现的缺陷不一定会立即消除（适用于开发早期） 基本模型： 其中，ab为常数，与单位时间内发生的缺陷有关 可得： 修正模型： 故障密度函数为Weibull分布,2019/9/15,,34,5.5.4 软件可靠性模型的适用条件,2019/9/15,,35,5.6 软件可靠性测试,5.6.1 软件测试的类型 与软件可靠性相关的测试主要是动态测试 单元测试：对汇编单元进行测试 集成测试：对汇编单元接口的测试 验收测试：验收并确认实现了所有需求 回归测试：对与修正的缺陷的软件部件的再测试,2019/9/15,,36,5.6.2 软件可靠性测试方法,利用在其他测试中的数据收集来检验软件可靠性的测试 基本步骤是： 仔细研究开发过程和软件问题报告 确定使用那些或那个模型来度量软件可靠性 执行一种有效的方法来收集问题报告缺陷数据、过程数据和产品数据，收集集成测试期间及以后的数据 按照模型规定的原理和方法，将数据输入选定的模型，直接估计软件可靠性或间接地估计与其有关的参数 根据估计结果进行决策： 软件能否被释放（发布）？ 是否需要增加测试时间以达到可靠性目标？如果需要，还需要多少时间？,2019/9/15,,37,Beta测试 可以直接反映可靠性水平 系统软件证明测试 在要求时间内、在实际的使用环境中运行系统，不对系统进行维护，收集发现的故障数，以决定整个系统能否通过可靠性测试 基于测试时间的软件证明测试 在相对较长时间内对软件的运行进行软件证明测试 基于测试输入的软件证明测试 只针对特定的测试用力进行软件证明测试,2019/9/15,,38,软件证明测试方法,测试前，先由测试者和用户共同确定以下三个参数： 用户风险因子：是由用户承担的软件可靠性未达目标而通过测试的风险 生产者风险因子：是由开发者承担的可靠性已达目标而未被接受的风险 鉴别因子：是最大可接受的失效密度和失效密度目标的比值,2019/9/15,,39,确定可靠性测试判定标准 根据已确定的三个参数绘制软件可靠性证明测试判定图 确定拒绝线 和接受线 规格化是指将测试时间或测试用例数乘以故障率目标值,2019/9/15,,40,测试开始后，失效发生时，将对应的累计故障数和测试时间或测试用例数在图中标出 判定测试结果：通过或失败都表示测试结束，若测试未完成，则继续测试 注：基于测试用例的证明测试具有随机性，不同测试可能得到不同结果，为此可采用模块化方法选择测试用例，以保证测试的客观性,2019/9/15,,41,5.6.3 软件可靠性测试的实施过程,1、概述 软件可靠性测试有两类： 开发测试：包括性能测试、加载测试、回归测试，目的是发现和修正单元及其集成的缺陷 确认测试：一般只进行加载测试，目的是为了确定软件部件或系统是否被接受 对于软件可靠性建模，开发测试收集的是分组数据，是不完整的，而确认测试获得的是完全数据,2019/9/15,,42,软件可靠性测试过程模型 开发业务剖面是软件可靠性测试的重要环节，因为可靠性目标与业务剖面关系密切,2019/9/15,,43,3、测试的目的 通过在规定的业务剖面下运行软件系统，确认是否能够完成于业务剖面相关的任务： 正确地完成规定的功能 满足性能要求 不完成没有规定的功能 提供运行中的故障数据 4、用户责任 用户要参与软件测试： 规定测试要求，如测试条件和环境 评审和批准测试程序 评审和批准每一需求的认证方法和技术 提供测试环境和人员 要球组织独立的测试组织,2019/9/15,,44,5、测试的准备和执行 测试准备：准备测试用例、测试程序并决定要使用的自动化测试工具 测试用例设计须考虑可靠性定量要求和成本及效率，测试用例的数量和类型选择要与业务剖面及发生概率一致，且考虑到随机性 测试程序与特定的业务剖面相关，要考虑发生概率 测试执行：从性能测试开始进行加载测试，要考虑业务剖面和运行模式已分配执行时间和测试用例 测试执行过程需进行故障识别，记录故障发生时间和严重性 对于发现的故障，需要填写故障报告： 引发故障的缺陷什么时候、在那里出现？原因是什么？如何定位？什么时候该定位被确认？ 要进行的修改有哪些？,2019/9/15,,45,6、测试结果的应用 用户根据测试结果评估可靠性并进行决策 开发者由此产生软件更新需求，或者改进过程和设计 7、需要注意的问题 测试人员独立于开发者的程度将影响测试结果 测试时间计划不周会导致在开发过程后期发现缺陷的风险增加 测试等级及相应的测试时间分配选择不得将不能保证在不牺牲质量的前提下降低成本 测试工具的选择将影响测试效率和完整性,2019/9/15,,46,5.7 软件故障数据的趋向性分析,5.7.1 趋向性分析的含义及作用 软件可靠性建模的基础是测试数据，但由于不同的可靠性模型基于的假设不同，导致可靠性分析方法的离散性，原因主要是： 软件的自然特征及相应的失效数据是离散的 所采用的开发方法和确认方法不同 数据收集的组织有差别 分析的目的、要求各种各样 软件可靠性模型的有限假设和故障数据的离散性是矛盾的，K. Kanoun于1997年提出的趋向性分析方法用于揭示软件可靠性随时间的演化趋势，实践证明具有很高的实用性,2019/9/15,,47,5.7.2 软件故障数据工程模型,2019/9/15,,48,数据收集 收集的故障数据包括： 表征产品本身、开发过程及使用环境的数据，如软件规模、语言、功能、确认和验证方法、使用工具、加载等 与故障及其修正相关的数据，如故障发生时间、故障特征、故障影响结果、缺陷类型、缺陷位置等 数据过滤 对收集的数据进行分析和过滤，需滤出的数据有： 与软件无关的外在数据 错误的或虚假的问题报告 重复数据,2019/9/15,,49,数据分割 根据需求将收集到的数据进行分割，可使分析更具体 分割方法包括： 根据故障的严重性等级分割 根据生命期阶段分割 根据缺陷所在的软件部件分割 数据工程分析 根据工程应用不同，对分割的数据进行不同的分析： 描述性分析：基于统计原理，用图、表进行综合，以识别最有用的现象，如故障的发生条件与严重性的关系等，与可靠性评估没有直接关系，有利于设计和开发 趋向性分析：分析可靠性随时间的变化趋势，有助于评估可靠性模型的有效性 模型应用：选择趋向性