通过测试度量软件质量,软件质量管理与测试2-度量

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

展开阅读全文