《软件质量管理与测试2-度量.ppt》由会员分享,可在线阅读,更多相关《软件质量管理与测试2-度量.ppt(51页珍藏版)》请在淘文阁 - 分享文档赚钱的网站上搜索。
1、软件质量管理与测试软件质量管理与测试软件质量度量软件质量度量o 概述o 需求分析质量度量o 设计质量度量o 源代码质量度量o 测试质量度量o 维护质量度量软件质量度量o 概述时间:贯穿软件生命周期;目的:对项目、过程、产品质量持续化定量,并对此预测、评估、控制、改进;包括:客户满意度、项目、产品、品牌、产权等;方法:测试、审核、调查;结果:图表、数字、模型。n 度量原则n 度量活动n 度量实施度量原则1、基于该领域正确的理论,并确定度量目标;2、度量定义应具有一致性、客观性、无二义性;3、度量方法应简单、可计算;4、度量范围应根据实际需要而定;5、选取适当的统计方法;6、结果应可靠;7、结果应
2、反馈;8、要有领导的支持。度量活动三类1、产品度量描述产品的特征,用于产品质量的评估和决策。规模、复杂度、性能、质量水平;2、项目度量(战术性)描述项目的特征和执行状态,如计划的有效性、资源使用效率、成本效益、(预测)进度等;3、过程度量(战略性)用于开发、维护过程的优化及改进,如缺陷移除、修复效率;目的形成组织对产品、项目度量的各种模型。度量活动具体包括:1、项目评估2、系统规模度量,如功能点、代码行3、缺陷分析,如缺陷密度、潜在缺陷发生率4、针对特定阶段的活动,如需求稳定指数、测试覆盖率、可靠性分析、客户满意度、系统复杂度等的度量5、开发进度、成本、效率等的度量度量实施实施过程:1、度量承
3、诺:确定度量目标、选择度量元、侧重点2、度量计划:确认产品、流程、角色、责任和资源相关问题及属性3、度量实施:收集、分析度量数据,结果用于控制和改善开发过程4、度量评估:评估度量标准、流程、方法、对象、效用,发现问题,提出改进方案5、度量改进:根据改进方案持续改进度量标准、流程软件质量度量o 需求分析质量度量n 基于功能度量n 规约质量度量n 需求稳定性度量基于功能度量功能点度量(FP)预测系统大小的方法:家居安防传感器显示监视及应答子系统系统配置数据用户输入密码区域查询传感器查询胁迫报警开启/关闭测试区域设置信息传感器状态开启/关闭报警基于功能度量关键测度,评价指标:1、用户输入数(3)2、
4、用户输出数(2)3、用户查询数(2)4、文件数(1)5、外部接口数(4)基于功能度量计算功能点:FP=FP项总和(0.65+0.01 Fi)其中 Fi(i=1-14):复杂度调整值 F i:技术复杂因子(0-5)。0表示与该因子无关;5表示与该因子有实质关系。基于功能度量F1 要求可靠性支持与恢复F2 涉及数据通信F3 有分布式功能F4 性能要求F5 经常性的配置管理 F6 联机数据输入 F7 操作方便的要求 F8 联机更新 F9 复杂界面 F10 处理复杂 F11 可复用 F12 安装方便的要求 F13 多站点 F14 设施的变更 基于功能度量FP项总和:度量参数加权因子(复杂性)计算值简单
5、 中等 复杂用户输入数 3 3 4 6 9用户输出数 2 4 5 7 8用户查询数 2 3 4 6 6文件数 1 7 10 15 7外部接口数 4 5 7 10 20FP项总和 50基于功能度量假如复杂度调整值取中等(46),则FP=50(0.65+0.01 46)=56再如:60行源代码/FP 12个FP/人月 3个Bug/需求、设计 4个Bug/单元、集成测试则可确定项目计划,评估评审和测试的完全性规约质量度量Davis提出每个质量特征用一或多个度量表示需求一致性度量:Q1=Nui/Nr需求完全性度量:Q2=Nc/(Nc+Nnc)其中Nui:所有评审者有相同解释的需求数目Nr:功能性及非功
6、能性(如性能)需求总数Nc:确认正确的需求数目Nnc:未被确认的需求数目需求稳定性度量需求稳定因子(Requirements Stability Index)RSI=(所有确定的需求数 待定的需求变化请求数)/所有确定的需求数所有确定的需求数=初始需求请求数+接受的需求变化请求数软件质量度量o 设计质量度量n 体系结构设计度量n 构件级设计度量体系结构设计度量连接密度(耦合度)=控制线数/节点数本例:15/12=1.25节点控制线深度(4)宽度(4)构件级设计度量o 内聚度(Cohesion)是指模块内部各成分(元素)之间的联结强度。内聚度越高,越容易理解、修改和维护。但内聚度本身是主观的、非
7、形式化的概念,程序设计人员很难客观地评估一个模块的内聚度。为此,人们开发出许多度量准则用于量化模块的内聚度。内聚性度量方法构件级设计度量o 耦合度(Couping)一个软件结构内不同模块之间互连程度的度量。一个完整的系统,模块与模块之间尽可能的使其独立存在(低耦合),也就是说,让每个模块尽可能的独立完成某个特定的子功能;模块与模块之间的接口,尽量的少而简单;如果某两个模块间的关系比较复杂的话,最好首先考虑进一步的模块划分,这样有利于修改和组合。构件级设计度量Dhama耦合度计算公式:C=1-1/(Di+2Ci+Do+2Co+Gd+2Gc+W+R)其中:Di/Ci:输入数据/控制参数的个数 Do
8、/Co:输出数据/控制参数的个数 Gd/Gc:用做数据/控制的全局变量的个数 W:此模块调用其它模块的个数(扇出)R:调用此模块的其它模块数(扇入)构件级设计度量o 复杂度(Complexity)在硬件的可靠性设计中,有一条基本原则:简单就是可靠。这个原则同样也适合软件,与功能的增多或增强相伴的是不断升级与补丁。现在已经有若干种软件复杂性的度量方法可供参考,其中 McCabe 是比较出色和实用的方法,它能够计算出多种软件复杂度,由此可对软件进行检查、分析和查明那些可能导致错误的代码。构件级设计度量McCabeCyclomatic Complexity(圈复杂度)V(G)=m-n+2其中:m:连
9、接不同节点有向弧(程序流)的个数 n:程序中代码的最小单元(节点数)说明:V(G)最大10 圈复杂度可加构件级设计度量V(G)=m-n+2=10-9+2=3开始结束软件质量度量o 源代码质量度量1、源代码行数小程序:1.3-1.8个错误/100行代码大程序:2.7-3.3个错误/100行代码2、McCabe度量法(同构件复杂度度量)软件质量度量o 测试质量度量n 测试质量度量n 测试过程质量度量测试质量度量o 测试质量度量 1.测试广度指所有需求中有多少需求在某一时刻已测试,从而度量测试计划执行、测试进度等状态。2.测试深度是指被测试覆盖的独立基本路径占程序中基本路径的总数的比值。3.过程中收
10、集的缺陷数度量,发现的、修正的和关闭的缺陷数量在过程中的差异、发展趋势等,为过程质量、资源额外投入、软件发布预测提供重要依据。测试过程度量o 缺陷密度o 缺陷注入率和缺陷消除率o 测试用例的深度、质量和有效性 o 测试执行的效率和质量 o 缺陷报告的质量 o 基于需求的测试覆盖评估 o 基于代码的测试覆盖评估 测试过程度量o 缺陷密度 软件缺陷分为两种:通过评审或测试等方法发现的已知缺陷、尚未发现的潜在缺陷。缺陷密度=已知缺陷的数量/产品规模 式中,产品规模的度量单位可以是文档页、代码行、功能点。可用于设定产品质量目标、支持软件可靠性模型预测潜伏的软件缺陷进而对软件质量进行跟踪和管理。测试过程
11、度量o 缺陷注入率和缺陷消除率1、缺陷泄漏矩阵 2、缺陷注入率3、缺陷消除率缺陷泄漏矩阵N11N21 N22*NK1 NK2*NKK缺陷起源 j=1 j=2 j=K 行合计i=1i=2i=K发现处列合计 O1 O2 Ok TF1F2Fk缺陷泄漏矩阵 缺陷泄漏矩阵是一个下三角矩阵,矩阵的行是缺陷的发现处(发现阶段),列是缺陷的起源阶段,其元素Nij满足下列条件:(1)只有当ij的元素Nij才有数据;(2)对角线(元素Nij,当i=j)上包含阶段注入并在同一个阶段被发现和清除的缺陷数量;(3)对角线以下(元素Nij,当ij)的元素包含来自早期阶段而后来才被发现和清除的缺陷数量;(4)对角线以上(元
12、素Nij,当ij)的元素是空的,因为早期阶段不可能发现后来阶段注入的缺陷。缺陷泄漏矩阵Fi:表示第i阶段发现和清除的缺陷总数量。iFi=Nij,i=1,2,K j=1Oj:表示第j阶段注入的已知缺陷总数量。KOj=Nij,j=1,2,K i=jT:表示迄今为止经历的软件生存周期的各个阶段所发现和清除的缺陷总数量。K kT=Fi 或 T=Oj i=1 j=1缺陷注入率(Defect Injection Rate)缺陷注入率表示迄今为止经历的软件生存周期的各个阶段中每个阶段注入缺陷的比率。DIRj=Oj/T,j=1,2,K缺陷消除率(Defect Removal Rate)表示在迄今为止经历的软件
13、生存周期的各个阶段中每个阶段消除缺陷的比率。有两种计算公式1、各个阶段如何有效地发现和清除本阶段注入的缺陷数量 DRR1i=Nij/Oi,i=1,2,K 2、各个阶段如何有效地发现和清除迄今为止软件存在的所有缺陷,包括阶段注入的缺陷和以往阶段遗留下来的缺陷 i i-1 DRR2i=Fi/(Oj-Fj),i=2,3,K j=1 j=1 测试过程度量o 测试用例的深度、质量和有效性 测试用例是测试执行的基础,其质量的好坏直接关系到测试的质量,也就影响着软件质量的保证过程。测试用例的度量将包含测试用例的深度、质量和有效性,而且包含自动化程度的度量,即多少比例的测试用例已被自动化。测试用例的深度(Test Case Depth)度量可以表示为每KLOC的测试用例数或每个功能点/对象点的测试用例数。测试过程度量o 测试用例的深度、质量和有效性 测试用例的效率可以用每100或1000个测试用例所发现的缺陷数来衡量,不同的测试阶段是不一样,应该对同一阶段的不同版本进行比较,而不宜对同一版本的不同阶段进行比较。测试用例的质量(Test Case Quality)可以用由测试用例发现的缺陷数量来度量,即 TCQ=测试用例发现的缺陷数量/总的缺陷数量
限制150内