软件质量管理与测试2-度量.ppt

1、软件质量管理与测试,软件质量管理与测试,软件质量度量,软件质量度量,概述 需求分析质量度量 设计质量度量 源代码质量度量 测试质量度量 维护质量度量,软件质量度量,概述 时间：贯穿软件生命周期； 目的：对项目、过程、产品质量持续化定量，并对此预测、评估、控制、改进； 包括：客户满意度、项目、产品、品牌、产权等； 方法：测试、审核、调查； 结果：图表、数字、模型。 度量原则 度量活动 度量实施,度量原则,1、基于该领域正确的理论，并确定度量目标； 2、度量定义应具有一致性、客观性、无二义性； 3、度量方法应简单、可计算； 4、度量范围应根据实际需要而定； 5、选取适当的统计方法； 6、结果应可靠

2、； 7、结果应反馈； 8、要有领导的支持。,度量活动,三类 1、产品度量描述产品的特征，用于产品质量的评估和决策。规模、复杂度、性能、质量水平； 2、项目度量（战术性）描述项目的特征和执行状态，如计划的有效性、资源使用效率、成本效益、（预测）进度等； 3、过程度量（战略性）用于开发、维护过程的优化及改进，如缺陷移除、修复效率；目的形成组织对产品、项目度量的各种模型。,度量活动,具体包括： 1、项目评估 2、系统规模度量，如功能点、代码行 3、缺陷分析，如缺陷密度、潜在缺陷发生率 4、针对特定阶段的活动，如需求稳定指数、测试覆盖率、可靠性分析、客户满意度、系统复杂度等的度量 5、开发进度、成本、

3、效率等的度量,度量实施,实施过程： 1、度量承诺：确定度量目标、选择度量元、侧重点 2、度量计划：确认产品、流程、角色、责任和资源相关问题及属性 3、度量实施：收集、分析度量数据，结果用于控制和改善开发过程 4、度量评估：评估度量标准、流程、方法、对象、效用，发现问题，提出改进方案 5、度量改进：根据改进方案持续改进度量标准、流程,软件质量度量,需求分析质量度量 基于功能度量 规约质量度量 需求稳定性度量,基于功能度量,功能点度量（FP）预测系统大小的方法：,家居安防,传感器,显示,监视及应答 子系统,系统配置数据,用 户,输入密码,区域查询,传感器查询,胁迫报警,开启/关闭,测试,区域设置,

4、信息,传感器状态,开启/关闭,报警,基于功能度量,关键测度，评价指标： 1、用户输入数（3） 2、用户输出数（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 处理复杂 F

5、11 可复用 F12 安装方便的要求 F13 多站点 F14 设施的变更,基于功能度量,FP项总和：,基于功能度量,假如复杂度调整值取中等（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：功能性及非功能性（如性能）需求总数 Nc：确认正确的需求数目

6、Nnc：未被确认的需求数目,需求稳定性度量,需求稳定因子（Requirements Stability Index） RSI = （所有确定的需求数 待定的需求变化请求数）/所有确定的需求数 所有确定的需求数 = 初始需求请求数+接受的需求变化请求数,软件质量度量,设计质量度量 体系结构设计度量 构件级设计度量,体系结构设计度量,连接密度（耦合度）= 控制线数/节点数 本例： 15/12=1.25,节点,控制线,深度（4）,宽度（4）,构件级设计度量,内聚度（Cohesion） 是指模块内部各成分（元素 ）之间的联结强度。内聚度越高，越容易理解、修改和维护。但内聚度本身是主观的、非形式化的概念

7、，程序设计人员很难客观地评估一个模块的内聚度。为此，人们开发出许多度量准则用于量化模块的内聚度。 内聚性度量方法,构件级设计度量,耦合度（Couping） 一个软件结构内不同模块之间互连程度的度量。一个完整的系统，模块与模块之间尽可能的使其独立存在（低耦合），也就是说，让每个模块尽可能的独立完成某个特定的子功能；模块与模块之间的接口，尽量的少而简单；如果某两个模块间的关系比较复杂的话，最好首先考虑进一步的模块划分，这样有利于修改和组合。,构件级设计度量,Dhama耦合度计算公式： C=1-1/(Di+2Ci+Do+2Co+Gd+2Gc+W+R) 其中：Di/ Ci ： 输入数据/控制参数的个数

8、 Do/ Co ：输出数据/控制参数的个数 Gd/ Gc ：用做数据/控制的全局变量的个数 W：此模块调用其它模块的个数（扇出） R：调用此模块的其它模块数（扇入）,构件级设计度量,复杂度（Complexity） 在硬件的可靠性设计中，有一条基本原则：简单就是可靠。这个原则同样也适合软件，与功能的增多或增强相伴的是不断升级与补丁。现在已经有若干种软件复杂性的度量方法可供参考，其中 McCabe 是比较出色和实用的方法，它能够计算出多种软件复杂度，由此可对软件进行检查、分析和查明那些可能导致错误的代码。,构件级设计度量,McCabeCyclomatic Complexity (圈复杂度) V(G

9、)=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. 测试深度是指被测试覆盖

10、的独立基本路径占程序中基本路径的总数的比值。 3. 过程中收集的缺陷数度量，发现的、修正的和关闭的缺陷数量在过程中的差异、发展趋势等，为过程质量、资源额外投入、软件发布预测提供重要依据。,测试过程度量,缺陷密度 缺陷注入率和缺陷消除率 测试用例的深度、质量和有效性 测试执行的效率和质量 缺陷报告的质量 基于需求的测试覆盖评估 基于代码的测试覆盖评估,测试过程度量,缺陷密度 软件缺陷分为两种：通过评审或测试等方法发现的已知缺陷、尚未发现的潜在缺陷。 缺陷密度=已知缺陷的数量/产品规模 式中，产品规模的度量单位可以是文档页、代码行、功能点。 可用于设定产品质量目标、支持软件可靠性模型预测潜伏的软件

11、缺陷进而对软件质量进行跟踪和管理。,测试过程度量,缺陷注入率和缺陷消除率 1、缺陷泄漏矩阵 2、缺陷注入率 3、缺陷消除率,缺陷泄漏矩阵,缺陷起源,j=1 j=2 j=K 行合计,i=1 i=2 i=K,发 现 处,列合计 O1 O2 Ok T,F1 F2 Fk,缺陷泄漏矩阵,缺陷泄漏矩阵是一个下三角矩阵，矩阵的行是缺 陷的发现处(发现阶段)，列是缺陷的起源阶段，其元 素Nij满足下列条件： (1)只有当ij的元素Nij才有数据； (2)对角线(元素Nij，当i=j)上包含阶段注入并在同一个阶段被发现和清除的缺陷数量； (3)对角线以下(元素Nij，当ij)的元素包含来自早期阶段而后来才被发现

12、和清除的缺陷数量； (4)对角线以上(元素Nij，当ij)的元素是空的，因为早期阶段不可能发现后来阶段注入的缺陷。,缺陷泄漏矩阵,Fi：表示第i阶段发现和清除的缺陷总数量。 i Fi= Nij， i=1，2，K j=1 Oj：表示第j阶段注入的已知缺陷总数量。 K Oj= Nij， j=1，2，K i=j T：表示迄今为止经历的软件生存周期的各个阶段所发现和清除的缺陷总数量。 K k T= Fi 或 T= Oj i=1 j=1,缺陷注入率(Defect Injection Rate),缺陷注入率表示迄今为止经历的软件生存周 期的各个阶段中每个阶段注入缺陷的比率。 DIRj= Oj/T ，j=1

13、，2，K,缺陷消除率(Defect Removal Rate),表示在迄今为止经历的软件生存周期的各个阶段中每个 阶段消除缺陷的比率。 有两种计算公式 1、各个阶段如何有效地发现和清除本阶段注入的缺陷数量 DRR1i=Nij/Oi，i=1,2,K 2、各个阶段如何有效地发现和清除迄今为止软件存在的所 有缺陷，包括阶段注入的缺陷和以往阶段遗留下来的缺陷 i i-1 DRR2i=Fi/(Oj-Fj)，i=2,3,K j=1 j=1,测试过程度量,测试用例的深度、质量和有效性 测试用例是测试执行的基础，其质量的好坏直 接关系到测试的质量，也就影响着软件质量的保证 过程。测试用例的度量将包含测试用例的

14、深度、质 量和有效性，而且包含自动化程度的度量，即多少 比例的测试用例已被自动化。 测试用例的深度（Test Case Depth）度量可 以表示为每KLOC的测试用例数或每个功能点/对 象点的测试用例数。,测试过程度量,测试用例的深度、质量和有效性 测试用例的效率可以用每100或1000个测试 用例所发现的缺陷数来衡量，不同的测试阶段是不 一样，应该对同一阶段的不同版本进行比较，而不 宜对同一版本的不同阶段进行比较。 测试用例的质量（Test Case Quality）可以 用由测试用例发现的缺陷数量来度量， 即 TCQ = 测试用例发现的缺陷数量/总的缺陷数量,测试过程度量,测试执行的效率

15、和质量 测试执行的质量一般可以用软件发布后所遗留 的软件缺陷和总缺陷数的比值来衡量，一般要求低 于0.5%。 测试执行效率可以用下列几种方法来综合度量： * 每个人日所执行的测试用例数 * 每个人日所发现的缺陷数 * 每修改KLOC所运行的测试用例数,测试过程度量,缺陷报告的质量 有效性：修正/关闭的（等级高的）缺陷和测试人 员所报的所有（等级高的）缺陷的比值，这个值越接 近1， 有效性就越高，如果考察等级高的缺陷，其正 常值大约在0.92 0.96。 质量：可以用“需要补充信息”、“不是缺陷”的 缺陷数量来衡量，一般占总缺陷数的3%-5%为正常，高 于或低于这个值都可能不正常，高于 5%可能

16、说明缺陷 报告质量低；低于 3%可能说明测试人员缺少怀疑精神。,测试过程度量,基于需求的测试覆盖评估 是依赖于对已执行/运行的测试用例的核实和分 析，所以基于需求的测试覆盖评测转化为评估测试 用例覆盖率：测试的目标是确保100% 的测试用 例全部成功地执行。一般在测试计划中定义了测试 工作量、用例数和用例覆盖率（98%-100%）， 我们根据事先确定的测试日程安排，可以将测试计 划值做成曲线，然后根据实际执行结果，定期画实 际值曲线，从而可以进行测试全过程监控和预测。,测试过程度量,基于需求的测试覆盖评估 在执行测试活动中，可用两类测试用例覆盖率估算： 1、确定已经执行的测试用例覆盖率，即在所

17、有测试用例 中有多少测试用例已被执行。 假定Tx已执行的测试过程数 或测试用例数，Rft是测试需求的总数： 已执行的测试覆盖 TxRft 2、确定成功的测试覆盖，即执行时未出现失败的测试， 如没有出现缺陷或意外结果的测试，假定Ts是已执行的完 全成功、 没有缺陷的测试过程数或测试用例数。 成功的测试覆盖 TsRft,测试过程度量,基于代码的测试覆盖评估 基于代码的测试覆盖评测是对被测试的程序代码语句、 路径或条件的覆盖率分析，是根据测试已经执行的源代码 的多少来表示的。这种测试覆盖策略类型对于安全至上的 系统来说非常重要。 评估代码覆盖率，需要断定测试目标期望的、总的测 试代码行数，在测试中真

18、正执行的代码行数及其百分比， 将此结果记录在测试评估报告中。测试过程中已经执行的 代码的多少，与之相对的是要执行的剩余代码的多少。,测试过程度量,代码覆盖可以建立在控制流（语句、分支或路 径）或数据流的基础上。控制流覆盖的目的是测试 代码行、分支条件、代码中的路径或软件控制流的 其他元素。数据流覆盖的目的是通过软件操作测试 数据状态是否有效。 已执行的测试覆盖 TcTnc 其中：Tc是用代码语句、条件分支、代码路径、 数据状态判定点或数据元素名表示的已执行项目数，Tnc是代码中的项目总数。,软件质量度量,维护质量度量 维护度量 维护过程度量,维护度量,缩写 WYF：一年维护期内系统失效的加权数 NYF：一年维护期内系统失效数 KLMC：为维护软件产生的代码千行数 NMFP：被维护软件规定的功能点数 NYSH：系统在一年维护期内服务的小时数 NYFH：一年内至少有一个功能不可用的小时数 NYVFH：一年内至少有一个关键功能不可用的小时数 NYTFH：一年内全部功能不可用的小时数 RYF：系统失效问题的用户重