测试和软件质量分析报告-STMT

,Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,软件测试方法和技术,- Ch.16,测试和软件质量分析报告,Zhu.Kerry,gmail,.com,Zhu.Kerry,朱少民,Kerry Zhu,第十六章 测试和软件质量分析报告,Zhu.Kerry,16.1,软件产品的质量度量,16.2,评估系统测试的覆盖程度,16.3,软件缺陷分析方法,16.4,基于缺陷分析的产品质量评估,16.5,测试报告及其模板,16.1,软件产品的质量度量,Zhu.Kerry,16.1.1,软件度量的内容和分类,16.1.2,软件度量的分工和过程,16.1.3,软件质量模型,16.1.4,软件质量的度量,16.1.5,质量度量的统计方法,软件度量,软件度量就是对软件所包含的各种属性的量化表示。,软件度量可以提供对软件过程和软件产品的深入了解的衡量指标，使组织能够更好地做出决策以达成目标，软件度量具有如下作用：,用数据指标表明验收标准；,监控项目进度和预见风险；,分配资源时进行量化均衡；,预计和控制产品的过程、成本和质量。,Zhu.Kerry,软件度量的分类,Zhu.Kerry,测量（,Measurement,）,、,度量,（,Metric,） 和,指标,(Indicator),软件度量的分类,软件过程度量,软件项目度量,产品质量度量,软件度量的内容,Zhu.Kerry,规模度量：,代码行数，功能点和对象点等,复杂度度量：,软件结构复杂度指标。,缺陷度量：,帮助确定产品缺陷变化的状态，并指示修复缺陷活动所需的工作量，分析产品缺陷分布的情况,工作量度量,进度度量,生产率度量：,代码行数人,月，测试用例数,/,人,日；,风险度量：,“风险发生的概率”和“风险发生后所带来的损失”,软件度量的分工,Zhu.Kerry,度量工作小组,由专职的度量研究人员和项目协调人员组成，度量研究人员的主要职责是定义度量过程和指导进行度量活动，并对数据进行分析、反馈；项目协调人员的职责是为定义度量过程提供详细的需求信息，并负责度量过程在项目组的推行。,数据提供者,一般是项目中的研发人员，有时还会包括用户服务人员和最终用户。,IT,支持者,确定数据提供的格式与数据存储方式，提供数据收集工具与数据存储设备,软件度量的过程,Zhu.Kerry,识别目标。,分析出度量的工作目标和列表，并由管理者审核确认,定义度量过程。,定义其收集要素、收集过程、分析、反馈过程、,IT,支持体系，为具体的收集活动、分析、反馈活动和,IT,设备、工具开发提供指导。,搜集数据。,应用,IT,支持工具进行数据收集工作，并按指定的方式审查和存储。,数据分析与反馈。,根据数据收集结果，按照已定义的分析方法进行数据分析，完成规定格式的图表，进行反馈。,过程改进。,根据度量的分析报告，管理者基于度量数据做出决策。,软件质量模型,Zhu.Kerry,Boehm,软件质量度量模型,McCall,三层次的度量模型,（图,2-1,）,ISO 9126,软件质量模型,Boehm,软件质量度量模型,Zhu.Kerry,ISO 9126,软件质量模型,Zhu.Kerry,软件质量的度量,Zhu.Kerry,软件可靠性度量、复杂度度量、缺陷度量和规模度量,Mi,c1f1,c2f2,cnfn,Mi,是一个软件质量因素,(,如,SQRC,层各项待计算值,),，,fn,是影响质量因素的度量值（如,SQDC,层各项估计值），,cn,是加权因子。,质量度量的统计方法,Zhu.Kerry,说明不完整或说明错误,(IES),与客户交流不够所产生的误解,(MCC),故意与说明偏离,(IDS),违反编程标准,(VPS),数据表示有错,(EDR),模块接口不一致,(IMI),设计逻辑有错,(EDL),不完整或错误的测试,(IET),不准确或不完整的文档,(IID),将设计翻译成程序设计语言中的错误,(PLT),不清晰或不一致的人机界面,(HCI),杂项,(MIS),质量度量的统计方法,（,2,）,Zhu.Kerry,总计,(,E,i,),严重,(S,i,),一般,(M,i,),微小,(T,i,),错误,数量,百分比,数量,百分比,数量,百分比,数量,百分比,IES,296,22.3%,55,28.2%,95,18.6%,146,23.4%,MCC,204,15.3%,18,9.2%,87,17.0%,99,15.9%,IDS,64,4.8%,2,1.0%,31,6.1%,31,5.0%,VPS,34,2.6%,1,0.5%,19,3.7%,14,2.2%,EDR,182,13.7%,38,19.5%,90,17.6%,54,8.7%,IMI,82,6.2%,14,7.2%,21,4.1%,47,7.5%,EDL,64,4.8%,20,10.3%,17,3.3%,27,4.3%,IET,140,10.5%,17,8.7%,51,10.0%,72,11.6%,IID,54,4.1%,3,1.5%,28,5.5%,23,3.7%,PLT,87,6.5%,22,11.3%,26,5.1%,39,6.3%,HCI,42,3.2%,4,2.1%,27,5.3%,11,1.8%,MIS,81,6.1%,1,0.5%,20,3.9%,60,9.6%,总计,1330,100%,195,100%,512,100%,623,100%,16.2,评估系统测试的覆盖程度,Zhu.Kerry,16.2.1,对软件需求的估算,16.2.2,基于需求的测试覆盖评估,16.2.3,基于代码的测试覆盖评估,测试的评估,Zhu.Kerry,软件测试评估主要有两个的目的,量化测试进程，判断测试进行的状态和进度,为测试或质量分析报告生成所需的量化数据，如缺陷清除率、测试覆盖率等。,例子：,测试覆盖项,测试覆盖率指标测试描述,测试结果,界面覆盖,符合需求（界面图标、信息区、状态区）,静态功能覆盖,功能满足需求,动态功能覆盖,所有功能的转换功能正确,正常测试覆盖,所有硬件软件正常时处理,异常测试覆盖,硬件或软件异常时处理（不允许的操作）,测试结束判断,对软件需求的估算,Zhu.Kerry,假设有,R,个需求，功能需求的数目为,F,非功能需求数为,N,则：,R= F + N.,Q1,M/R,其中,Q1,表示需求的确定性，,M,是所有复审者都有相同解释的需求数目。,功能需求的完整性,Q2,：,Q2,Fu/(,NiNs,),其中,Fu,是唯一功能需求的数目，,Ni,是由规格设计说明书定义的输入个数，,Ns,是被表示的状态的个数。,考虑非功能需求,:,Q3,Fc/(Fc,Fnv,),其中,Fc,是已经确认为正确的需求的个数，,Fnv,是尚未被确认的需求的个数,基于需求的测试覆盖评估,Zhu.Kerry,假定,Tx,已执行的测试过程数或测试用例数，,Rft,是测试需求的总数：,已执行的测试覆盖 ,Tx,Rft,假定,Ts,是已执行的完全成功、没有缺陷的测试过程数或测试用例数。,成功的测试覆盖 ,Ts,Rft,基于代码的测试覆盖评估,Zhu.Kerry,基于代码的测试覆盖评测是对被测试的程序代码语句、路径或条件的覆盖率分析。这种测试覆盖策略对于安全至上的系统来说非常重要。,基于代码的测试覆盖通过以下公式计算：,已执行的测试覆盖 ,Tc,Tnc,其中,Tc,是用代码语句、条件分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数，,Tnc,（,Total number of items in the code,）是代码中的项目总数。,16.3,软件缺陷分析方法,Zhu.Kerry,16.3.1,缺陷分布报告,16.3.2,缺陷趋势报告,缺陷报告,Zhu.Kerry,缺陷分布报告，,允许将缺陷计数作为一个或多个缺陷参数的函数来显示，生成缺陷数量与缺陷属性的函数。如测试需求和缺陷状态、严重性的分布情况等。,缺陷趋势报告，,按各种状态将缺陷计数作为时间的函数显示。趋势报告可以是累计的，也可以是非累计的；,缺陷年龄报告，,显示缺陷处于活动状态的时间，展示一个缺陷处于某种状态的时间长短，从而了解处理这些缺陷的进度情况。,测试结果进度报告，,展示测试过程在被测应用的几个版本中的执行结果以及测试周期,缺陷分布报告,Zhu.Kerry,缺陷趋势报告,(,到达模式,),Zhu.Kerry,缺陷趋势报告（,累积模式）,Zhu.Kerry,缺陷趋势报告,（,MS,例子）,Zhu.Kerry,16.4,基于缺陷分析的产品质量评估,Zhu.Kerry,16.4.1,经典的种子公式,16.4.2,基于缺陷清除率的估算方法,16.4.3,软件产品性能评估,16.4.4,借助工具的方法,已测试出的种子,Bug (s),已测试出的非种子,Bug (n),所有的种子,Bug (S),全部的非种子,Bug (N),则可以推出程序的总,Bug,数为：,N = S * n /s,其中,n,是所进行实际测试时发现的,Bug,总数。如果,n = N,说明所有的,Bug,已找出来，说明做的测试足够充分。,这种测试是否充分，可以用一个信心指数来表示，即用一个百分比表示，值越大，说明对产品质量的信心越高，最大值为,1,。,= 1 if nN,C,= S/(S-N+1), if n=N,经典的种子公式,Zhu.Kerry,=,基于缺陷清除率的估算方法,Zhu.Kerry,F,为描述软件规模用的功能点；,D1,为在软件开发过程中发现的所有缺陷数；,D2,为软件发布后发现的缺陷数；,D,为发现的总缺陷数。因此，,D=D1+D2,。,质量,=D2/F,；,缺陷注入率,=D/F,；,整体缺陷清除率,=D1/D,；,缺陷源,潜在缺陷,清除效率,(%),被交付的缺陷,需求报告,1.00,77,0.23,设计,1.25,85,0.19,编码,1.75,95,0.09,文档,0.60,80,0.12,错误修改,0.40,70,0.12,合计,5.00,85,0.75,软件产品性能评估,Zhu.Kerry,软件产品性能评估其技术性相对比较强，方法的基础是获取与性能表现相关的数据。性能评测一般和测试的执行结合起来做，或者是在执行测试时记录、保存各种数据，然后在评估测试活动中进行计算结果。,主要的性能评测包括：,动态监测,响应时间吞吐量,百分比报告,比较报告,追踪报告,16.5,测试报告及其模板,Zhu.Kerry,在国家标准,GB/T 17544,1998,（附录,C,）对测试报告有了具体要求，对测试纪录、测试结果如实汇总分析，报告出来。测试报告应具有如下结构：,产品标识；,用于测试的计算机系统,使用的文档及其标识,产品描述、用户文档、程序和数据的测试结果；,与要求不符的清单；,针对建议的要求不符的清单，产品未作符合性测试的说明；,测试结束日期。,作业,Zhu.Kerry,第十六章,3,、,5,、,6,Q & A,Zhu.Kerry,