《第一部分软件质量与质量保障的》由会员分享，可在线阅读，更多相关《第一部分软件质量与质量保障的（55页珍藏版）》请在金锄头文库上搜索。
1、第一部分软件质量与质量保障,本章内容： 1 对软件测试和软件质量的思考 一、当今社会对软件质量的高要求 二、软件质量问题提出的严重挑战 三、解决软件质量为题的途径 2 软件质量与可靠性概念 一、软件质量 二、软件可靠性 三、软件可靠性模型介绍 3 软件质量度量 一、软件质量度量框架 二、IEEE软件度量方法学步骤简介 4 软件质量保障体系介绍,1 对软件测试和软件质量的思考,一、当今社会对软件质量的高要求 1、计算机已无处不在，从生产到生活，从工厂到家庭，从工作到娱乐 制造业、农业 交通、通信、金融、保险、消防 商业、服务业、供电、供水、医疗卫生 行政管理、政务、公检法 航天、航空、科学研究、
2、军事 教育、文化 2、在一些领域，软件逐步替代了硬件 典型例子：通信领域（20世纪90年代以来） 通信企业都是软件企业 IC制造； 数字模拟代替了物理实验；,替代优势:准确、快速、高效、成本低 替代趋势：极为迅猛,用户使用低质量的软件，在运行过程中会产生各种各样的问题，可能带来不同程度的严重后果，轻者影响系统的正常工作，重者造成事故，损失生命财产。,软件:软件（software）是计算机中与硬件相结合的一部分，包括程序（program）和文档（document）,1 对软件测试和软件质量的思考,3、对软件质量提出了全方位的要求 功能：愈来愈多、范围广 性能：愈来愈高，速度、响应、适应性 可靠性
3、：稳定可靠 安全性：安全运行 4、关键软件（Critical software）： 关键软件：人员和公众的生命和安全 环境质量 数据和信息安全 关于 设备、设施、系统的正常运行 社会的正常秩序 关键软件的特点：规模庞大 大部分为实时、嵌入式 高可靠性 涉及国家政务、军事国防,1 对软件测试和软件质量的思考,二、严重的挑战软件质量问题 1、软件工程技术的发展长期落后于硬件 2、软件常常不能满足应用系统提出的需求 3、由于软件质量造成的事故屡见不鲜 用于F-16的导航软件中的错误使其在飞越赤道时引起飞机翻转； 1981年，对航天飞机定时软件的极小改变引起发射失败；,1 对软件测试和软件质量的思考,
4、4、用户对购买的软件质量不满,用户对软件质量满意度统计,1 对软件测试和软件质量的思考,5、解决软件质量问题的实际困难 开发过程和产品不可见 复杂 多变易变 难以量化控制 需求不明 人为因素 测试技术不理想,软件:是当前最复杂的脑力劳动，以个人劳动为基础的产品，合文化、心理、集体性有极大关系。,1 对软件测试和软件质量的思考,三、解决软件产品质量问题的途径从软件测试的角度 1、增强软件产品开发的质量意识，重视测试工作的组织 2、加强测试人员队伍的建设 软件质量和测试人员资格制度 加强培训：技术、管理 3、软件开发组织中建立独立的测试机构，体现独立测试原则 4、对整个软件开发过程实施规范化管理
5、产品质量取决于生产产品所采用过程的过程控制 ISO9000，CMM（软件过程成熟度）等 5、CMM对软件测试提出的要求 （1）选取适用的测试支持工具 （2）对软件工程技术人员进行软件测试及其它验证技术的培训 （3）对完成的代码实时同行评审和单元测试 （4）按项目定义的软件过程进行软件测试 （5）按软件过程计划和执行集成测试、系统测试、验收测试 （6）收集和分析测试中发现的缺陷数据 改正 6、CMM中软件质量保证、验证 评审和审核提出了更多的要求,制定和评审测试标准 选用有效的测试方法 做到测试的充分性 建立和使用测试准备就绪准则 实施回归测试 对测试计划、测试规程、测试用例进行评审 对测试计划
6、、测试规程、测试用例进行管理 对测试计划、测试规程、测试用例进行控制,软件测试是保证软件质量的最重要的手段,2 软件质量、软件可靠性概念,内容： 1、软件质量 2、软件可靠性概念 3、软件可靠性模型介绍,2 软件质量与可靠性概念,一、软件质量： 是贯穿软件生存期的一个极为重要的问题，使软件开发过程中所使用的各种开发技术和验证方法的最终体现。 软件质量的定义： ANSI/IEEE std 729-1983定义软件质量为： 与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体 可从三方面来理解： 软件需求是衡量软件质量的基础，不符合需求的软件就不具备质量。 规定了的标准是软件开发必须遵循的
7、准则。 如果已开发的软件已经满足了那些明文规定的需求，却没有满足那些隐含的需求，那么软件产品的质量仍然是有问题的。,2 软件质量与可靠性概念,二、软件可靠性 软件质量的一项重要指标 是指“在规定的条件下和规定的时间内，计算机程序完成规定功能（无故障运行）的概率”。 什么是Bug:在英语中是“小虫子”的意思，现在泛指计算机中软件或硬件错误。 Bug和Debug的由来：,Bug之多：微软Windows 98操作系统改正了windows 95 里面5000多个Bug,计算机中含有这么多Bug有一个技术原因： 软件愈来愈庞大复杂 在任何复杂的大系统中，错误是难免的，大型软件尤其难以按期完成 国外统计：
8、17万个项目（总投资2500亿美元） 6%按期按预算完成； 31%中途取消； 61%最终完成，但都超出了预算和进度（一大半项目的实际花费超出预算达189%）,Bug的确切定义：软件的Bug指的是软件中（程序和文档）不符合用户需求的问题,常见的软件Bug分成3中类型： （1）完全没有实现的功能 （2）基本实现了用户需要的功能，但在运行时会出现一些功能和性能上的问题； （3）实现了用户不需要的功能，即多余功能。,2 软件质量与可靠性概念,衡量软件可靠性的简单指标：平均失败间隔时间MTBF 指两次此相邻失效时间间隔的平均。 MTBF=MTTF（平均无故障时间）+MTTR（平均修复时间） MTTF（平
9、均无故障时间）：指当前时间（有效）到下一次失败的时间平均 MTTR（平均修复时间）：指从一次故障产生到故障恢复的时间平均 MTTF（平均故障时间） MTTR（平均修复时间 平均失败间隔时间MTBF,2 软件质量与可靠性概念,R可靠度：在规定时间内无失效发生的概率。 设规定时间为t0 ，软件发生失效的时间是，R(t0)=P( t0). MTTF即为在时间0-无穷内对R(t0)的积分。,2 软件质量与可靠性概念,由来： 通过拥有一个软件可靠性如何随着时间的变化而变化的健壮的模型，使得管理部门能够通过收集软件确认测试中的数据，制订一个可靠性目标，并跟踪目标实现的过程。 目的： 能够用平均故障时间（M
10、TTF）测量和预测软件可靠性 确定最佳停止测试和发布软件的时间 为权衡测试时间、可靠性、费用和性能指标提供数据 定义符合实际的软件可靠性指标,三、软件可靠性模型介绍,2 软件质量与可靠性概念,软件可靠性模型目前有40多种（常用10多种） 可靠性建模是可靠性估计过程的基础，它确定产品是否达到了可靠性指标，是否可以发行。 目前比较流行的有： Jelinski-Moranda的故障分离模型 Goel-Okumoto的NHPP模型非齐次泊松过程模型 黑盒测试： Musa的基本执行时间模型 增强的NHPP模型（广义泊松模型） Littlewood-Verrall的贝叶斯判定模型 Krishna-murt
11、hy和Mathur的基于路径的模型 白盒测试 Gokhala et al.的基于状态的模型,3 软件质量度量,有许多因素影响软件质量 可直接度量的因素 把影响软件质量 的因素分为两类 只能间接度量的因素 不管哪一类，必须能够度量，构成了软件质量度量体系。 IEEE有关软件质量度量方法学的标准1061-1998,一、软件质量度量框架,软件质量度量框架：一组用来组织、选择、沟通、评价软件系统要求的质量属性的辅助决策法，他逐层分解为特性、子特性和度量。 质量特性：一个与质量有关的面向管理的软件属性； 质量子特性：质量特性分解出来的技术组件 直接度量：一种不依赖于其他属性测量的度量； 预计度量：一种适
12、用于开发阶段的度量，它用来预计软件质量特性的值； 软件质量度量：一个函数，它的输入是软件数据，输出是一个单一数值，它可解释为给定的软件属性对其质量的影响程度； 过程度量：一种用来测量在软件系统开发、实现和维护过程中使用的方法、技术和工具特性的度量 产品度量：一种用来测量软件开发过程中任何中间或最终产品特性的度量。,软件质量度量框架,与质量需求相关联的质量特性,与质量特性相关联的质量子特性,直接度量例子,二、IEEE软件度量方法学步骤,确定软件质量需求 确定软件质量度量 实施软件质量度量 分析软件质量度量 确认软件质量度量,直接度量文档,分析软件质量度量结果,在数据收集过程中，要根据工程总的软件
13、质量需求对度量结果进行分析。要识别出哪些与目标值不一致的度量以便做进一步的分析。 根据分析结果，有些可能需要重新设计或者记录，有些可能需要对文档进行补充，有些可能需要做一些补充测试。在某些情况下，若度量值只稍微超出目标值，并且认为是非关键度量，也可不做改动。,Grady和Caswell在HP公司实施软件度量程序的10个步骤,定义软件度量程序的目标 明确责任 开展调查 定义要收集的初始度量 推荐这些度量的初始样本 获取用于自动数据收集和分析的工具 进行软件度量培训 宣传成功事例 建立度量数据库 以有序方式建立一个改进此过程的方法,三、 验证度量,复杂度度量 缺陷度量 产品度量 过程度量,度量-复
14、杂度,复杂度 是与质量子特性正确性和质量特性可维护性相关联的一个直接项测量,通过对本组织编制的源程序代码做大范围的复杂度抽样测试，就可以建立一个复杂度基线，可以用来确定： 代码审查的候选模块 对哪一部分进行重新设计可能是恰当的？ 需要附加文档的部分 可能附加测试的部分,度量-复杂度-方法,McCabe圈(环)复杂度度量 使用程序控制流程结构作为其复杂度相对的测量 圈复杂度E-N+2P E=边的个数（或控制转移次数） P转入程序中的控制路径个数 N=节点个数（顺序语句组只包含一个控制转移）,度量-复杂度-方法,Halstead的软件科学 基于程序大小测量程序复杂度的算法 1=程序中不同操作符的个
15、数 2=程序中不同操作数的个数 3=程序中操作符出现的总数 4=程序中操作数出现的总数 程序词汇量： = 1+ 2,度量-缺陷度量,缺陷度量是通过收集审查总结报告而得到。根据缺陷类型（即逻辑、接口、数据定义、文档）、缺陷改进起因和缺陷严重性对这些度量进行分类，将能够确定软件开发过程中需要改进的地方。 通过对模块进行缺陷跟踪，缺陷度量有助于软件验证和确认活动，它能够发现需要重新设计或者做附加测试的候选模块，也能够潜在识别哪些需要在软件工程实践方面需要进一步培训的软件工程师。,度量-产品度量,产品度量是测量，这些测量代表了组织已开发出的产品的情况。 例子： 在需求、设计、编码和测试审查阶段发现的缺
16、陷的类型和数量； 交付的文档页数 新增代码的行数 修改的代码行数 交付的代码总行数 交付的所有模块的平均复杂度 模块的平均大小 模块的总数 单元测试发现的缺陷总数 集成测试发现的缺陷总数 确认测试发现的缺陷总数,度量过程度量,过程度量反映过程的效率。 例子： 平均查找修改时间 每一次审查花费的人/小时数 每KLOC花费的人/小时数 每一次审查发现的平均缺陷数 在审查期间发现的每一类缺陷的个数 平均修改次数 被审查模块的平均数,制定度量计划,测量应是健全的； 测量应建议一个基准 测量应涉及特定的产品和过程属性； 测量应建议一个改进策略 测量应是软件开发过程固有的结果 测量应简单 测量应可预测和可跟踪 测量不应该用来作为评价个人实绩的一部分。,四、确认度量,时间测量 测试覆盖测量 质量度量,时间测量,查错修改周期测量 累积测试时间,测试覆盖度量,代码覆盖 段覆盖 调用对 需求覆盖,质量度量,
