质量管理计划-Read课件

,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,6.1软件质量的度量,6.2 软件的确认,6.3 软件的验证,6.4 PMBOK的质量管理过程,第六章,6.1软件质量的度量第六章,1,6.1软件质量的度量,6.1.1 软件的质量要素,6.1.2 软件质量评价的准则,6.1.3 软件质量的度量,6.1.4 软件质量度量的实施,6.1软件质量的度量,2,质量与等级的关系,等级的含义是：对功能用途相同、但技术特性不同的实体的一种分类或排序,例如：高质量无错误、可读性强的用户手册,低等级有限的功能,低质量错误百出、编排混乱的用户手册,高等级大量功能,PMBOK强调质量的核心是产品、服务的适用性,什么是适用性？,质量与等级的关系等级的含义是：对功能用途相同、但技术特性不同,3,6.1.2 IEEE,定义的软件质量度量框架,6.1.2 IEEE定义的软件质量度量框架,4,度量框架,一种用来组织、选择、沟通、评价软件系统要求的质量属性的辅助决策法。它逐层分解为特性、子特性和度量,质量特性,一个与质量有关的面向管理的软件属性,质量子特性,质量特性分解出来的技术组件,直接度量,一种不依赖与任何其他属性测量的度量,预计度量,一种试用于开发阶段的度量，它用来预计软件质量特性的值,软件质量度量,一个函数、它的输入是软件数据，输出是一个单一数值。它可解释为给定的软件属性对其质量的影响程度,过程质量,一种用来测量在软件系统开发、实现和维护过程中使用的方法、技术和工具特性的度量,产品度量,一种用来测量软件开发过程中任何中间或最终产品特性的度量,IEEE,定义的软件质量度量框架,度量框架一种用来组织、选择、沟通、评价软件系统要求的质量属性,5,质量需求,在四层模型的第一层，软件产品质量层，是产品必须满足的质量需求。它是用用户术语描述的，主要有四点：,（1）产品将在用户所在组织当前使用的平台和操作系统上运行。,（2）,产品将是可靠的并能防止数据丢失的机制。,（3）,产品将提供完成某些任务所必需的功能。,（4）,产品将易于使用。,质量特性,在模型的第二层，表示与整个质量需求有关的特殊质量特性，它代表了用户的质量需求。它采用从用户角度考虑的立场，把软件质量分解成四类质量特性，这四个质量特性是软件的基本特征。,IEEE,的四个质量特性是：,可移植性、可靠性、功能性、可使用性。,质量需求 在四层模型的第一层，软件产品质量层，是产品必,6,软件质量的另一种理解,ISO/IEC9126-1产品质量-质量模型的软件质量模型,软件质量的另一种理解,7,内部质量的定义是：,反映软件产品在规定条件下使用时，,满足需求的能力的特性,，是软件开发过程中各阶段（需求开发、软件设计、代码编写等）产生的中间软件产品的质量。,了解软件产品的内部质量，可以预计最终产品的质量。,外部质量的定义是：,反映软件产品在规定条件下使用时，,满足需求的程度。,外部特性反映在预定的系统环境中运行时可达到的质量水平。,质量管理计划-Read课件,8,使用质量的定义是：,反映软件产品在规定的使用环境下，使特定用户在达到规定目标方面的能力。,反映的是从用户角度看到的软件产品在特定系统环境下满足其需求的满足程度。,对内部和外部质量特性的度量描述包括：,功能性、可靠性、易用性、效率、可维护性、可移植性等；,对使用质量特性的度量描述包括：,有效性、生产率、安全性、满意程度等,质量管理计划-Read课件,9,6.1.4 软件质量度量的实施,在确定要对一个软件（系统）进行度量之后，一般，采取以下,5,个步骤，来实施对该软件的度量：,（1）确定软件质量需求；,在用户需求中，除功能需求外，还有非功能需求，包括：质量需求、环境需求、设计约束、开发策略等。质量需求是用户比较关心的内容。,但是，我们已经知道，软件的功能需求的确定，存在一定的难度。而非功能需求的确定，则难度更大。这些困难包括：需求如何获取，需求冲突如何协调、需求的确认和变更的授权等。,过程：,需求获取：首先，你要理解用户的需求，区分哪些是质量需求，把这些需求记录下来，获得用户的确认。,需求分析：拿到用户确认的需求后，你可以开始把用户的质量需求与我们设定的质量特性联系起来，一直区分到子特性。这种联系，就是把用户语言描述的需求，转变为计算机工程师语言的需求。建立了这种关联后，可以根据分类，分级，确定直接度量。,6.1.4 软件质量度量的实施在确定要对一个软件（系统）进行,10,6.1.4 软件质量度量的实施,（2）,确定直接度量,直接度量就是实际的软件质量测量活动，它的输入是软件或软件过程，输出是一个测量值。它通过执行一系列的任务，获得一个质量值。,例如：对一个没有经过培训的用户，让他使用软件系统的某一功能，在界面提示、联机帮助、使用手册的帮助下，他学会掌握该功能所花的时间。而用户需求对此项指标的要求（目标）和现实系统所达到的实际值（比如：,10,个人次测量后统计意义上的）的比较，就是将提交质量评审的质量值。,在进行直接度量前，一般应该有以下准备：,（1）工具：有助于计算度量值的硬件/软件工具，如：缺陷跟踪工具；（2）应用：描述度量结果的希望值、度量值的意义、作用和对度量结果数据的使用方法；（3）数据：获得度量结果所需的数据、程序、过程等度量对象；（4）计算：度量程序、步骤和方法。（5）费用：测试是要花钱（人力、物力、时间等）的。,6.1.4 软件质量度量的实施（2）确定直接度量,11,6.1.4 软件质量度量的实施,（3）分析度量结果,对度量过程进行跟踪和分析，需要时，可能会对度量程序、度量工具、度量方法，甚至原始数据，做出补充和调整。,（4）确认质量度量,在度量过程中，进行度量结果的确认非常重要。首先，要确认度量过程是否与事实相符，脱离现实真实的度量，与目标再相符的结果也是没有意义的。其次，是确认方法的有效性，例如：在度量中，我们用到很多统计学方法，在这些方法中，我们有一些概率分布假设（例如：某些错误的发生，我们假设符合随机概率分布），当这些假设并不成立时，度量的结果是不真实的。,6.1.4 软件质量度量的实施（3）分析度量结果,12,其他度量,分析模型的度量（对分析模型的度量以测试系统的大小）,设计模型的度量（度量体系结构、数据和系统的复杂度）,源代码的度量（度量程序的长度、层次、开发量、时间等）,对测试的度量（度量测试的宽度、深度、错误的级别）,对维护的度量（度量软件的稳定性）,其他度量分析模型的度量（对分析模型的度量以测试系统的大小）,13,6.2 软件确认,6.2.1 测试阶段,6.2.2 测试方法,6.2.3 测试类型,6.2.4 测试计划,6.2 软件确认,14,6.2.1 测试阶段,根据不同的软件生命周期定义，测试的阶段、方法和类型构成一个层次结构，如下图：,6.2.1 测试阶段根据不同的软件生命周期定义，测试的阶段、,15,V,模型中的过程从左到右，描述了基本的开发过程和测试行为。,V,模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。,测试的V模式,V模型中的过程从左到右，描述了基本的开发过程和测试行,16,6.2.2 测试方法,测试所处的阶段不同，方法也不同：,白盒测试,在单元测试阶段，由于测试者对被测对象的内部结构、逻辑思路、接口关系等比较熟悉，一般采取白盒测试的方法，它是根据模块的内部逻辑，进行测试设计的方法。有些集成测试也采用白盒方法，关键看集成阶段的划分。,黑盒测试,在集成测试以至此后的各阶段，测试设计和测试人员，对被测对象的内部结构不了解也不需要了解，他的目的是按需求功能进行确认。因此，黑盒测试是严格按软件需求进行测试设计的方法。,代码走查,6.2.2 测试方法测试所处的阶段不同，方法也不同：,17,6.2.3 测试类型,在不同阶段，测试的类型也不相同，常有的测试类型是：,（1）功能测试：软件实现的功能是否符合需求规格说明书中定义的功能；,（2）性能测试：软件在规定配置下的性能是否符合需求规定；,（3）算法测试：确认实现的算法的正确性；,（4）正向测试：按照用户正常的理解、操作方式、思维和使用习惯使用软件，得到的结果是否与需求一致。,（5）逆向测试：如果不按用户正常的理解、操作发生、思维和使用习惯使用软件，软件是否能正确地进行处理。如：无效操作、错误的数据输入处理、非法进入等。,（6）边界测试：按软件的限制、假设条件的边界输入，进行测试。,（7）配置测试：对软件环境进行配置变化，软件需求实现，特别是性能实现是否能符合需求规定要求。,（8）负载测试：在业务处理量、数据负载量、通讯负载量达到何种情况，系统的性能变化和承载能力情况。,6.2.3 测试类型在不同阶段，测试的类型也不相同，常有的测,18,6.2.4 测试计划,测试估计,在拟定测试计划时，首先需要对以下情况，做出估计：,（1）,完成测试设计所需要的工作量：,（2）,完成测试设计所需要的工作时间：,（3）,完成测试所需要的时间：,根据以上三个部分的结果，我们已经知道了测试的范围、内容、任务分配、时间等，这样，项目经理可以能比较充分地规划资源，制订出一份比较全面和切实的测试工作计划。,测试分配,测试计划确定了测试的范围、内容和估计时间，根据,WBS,方法，测试计划还应说明具体测试任务的分解和测试工作的分配。测试组的成员根据分工，各自完成一部分测试任务。测试组与项目开发组还需要保持一定的同步，使测试与开发、修改在协调的步骤下进行，以节约宝贵的项目总时间。,测试确认,6.2.4 测试计划测试估计,19,测试报告：,收集齐上述的所有测试用例，构成了测试报告的基本要件。,测试报告是对所有测试用例测试过程的总结。,在测试报告中，应反映：,（1）测试中出现问题的统计汇总和分析；,（2）未解决问题的汇总和解决方案建议；,（3）回归测试的统计和分析（度量）；,（4）对测试计划的总结或修改。,关于测试用例的问题讨论：,测试用例由谁设计？,设计测试用例的目的和依据是什么？,测试报告：关于测试用例的问题讨论：,20,6.3 软件的验证,6.3.1 审查准备,6.3.2 审查过程,6.3.3 需求审查,6.3.4 设计审查,6.3.5 代码审查,6.3.6 测试审查,6.3 软件的验证,21,软件审查的概念,验证与确认的区别是，确认是在整个软件系统完成交付前或某模块完成交付前的检查，它的检查点是交付前。而验证贯穿于整个开发过程，是对过程的确认。因此，验证的范围包括了整个开发过程，它是软件质量保证并持续改进的强大工具。,审查是一个正式的、严格的、具有深度的技术评审过程。,因此，评审的目的是：,（1）在软件开发过程中，尽早可能地发现问题，特别是过程性的问题；,（2）确保对需求保持一致的意见；,（3）验证任何修改和变更满足预先定义的准则；,（4）为组织提供产品在质量和过程方面是否有效的实际数据；,（5）使团队成员之间在技术上建立相互的了解；,（6）增加软件确认测试的有效性；,（7）提高优秀软件工程师的水准。,软件审查的概念验证与确认的区别是，确认是在整个软件系统完成交,22,评审内容及要求，见下表：,审查类型,被审查项,需提交的资料,提交审查条件,需求,软件需求规格说明书,软件需求规格说明书及在此之前有关的需求分析文档、需求基线及批准文档,确认的需求、已经被分析和形式化描述，需求基线已经被确定,设计,软件设计说明,软件设计文档,设计完成,编码,源代码模块,源程序代码、设计文档、组织的编码标准与规范,被审查模块已经编译正确并完成独立测试,确认测试,测试记录,测试结果报告、质量和验收标准,系统确认及回归测试已经完成,6.3.1 软件审查的准备,评审内容及要求，见下表：审查类型被审查项需提交的资料提交审,23,在审查开始之前，审查组与被审查项目的有关人员，产品经理、技术经理、质量经理和项目经理们开一个“审查开工会”，主审员向被审查对象的有关人员介绍本次审查的目的、对象、范围和内容，有必要的话，花一