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

i=1 j=1
缺陷注入率(Defect Injection Rate)
缺陷注入率表示迄今为止经历的软件生存周 期的各个阶段中每个阶段注入缺陷的比率。 DIRj= Oj/T ，j=1，2，…，K
缺陷消除率(Defect Removal Rate)
表示在迄今为止经历的软件生存周期的各个阶段中每个 阶段消除缺陷的比率。 有两种计算公式 1、各个阶段如何有效地发现和清除本阶段注入的缺陷数量 DRR1i=Nij/Oi，i=1,2,…,K 2、各个阶段如何有效地发现和清除迄今为止软件存在的所 有缺陷，包括阶段注入的缺陷和以往阶段遗留下来的缺陷
度量原则 度量活动 度量实施
度量原则
1、基于该领域正确的理论，并确定度量目标； 2、度量定义应具有一致性、客观性、无二义性； 3、度量方法应简单、可计算； 4、度量范围应根据实际需要而定； 5、选取适当的统计方法； 6、结果应可靠； 7、结果应反馈； 8、要有领导的支持。
度量活动
三类 1、产品度量描述产品的特征，用于产品质量的评估和 决策。规模、复杂度、性能、质量水平； 2、项目度量（战术性）描述项目的特征和执行状态， 如计划的有效性、资源使用效率、成本效益、 （预测）进度等； 3、过程度量（战略性）用于开发、维护过程的优化及 改进，如缺陷移除、修复效率；目的形成组织对 产品、项目度量的各种模型。
构件级设计度量
McCabe Cyclomatic Complexity (圈复杂度)
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. 过程中收集的缺陷数度量，发现的、修正的和关 闭的缺陷数量在过程中的差异、发展趋势等，为 过程质量、资源额外投入、软件发布预测提供重 要依据。
缺陷泄漏矩阵
Fi：表示第i阶段发现和清除的缺陷总数量。
Fi= ΣNij， i=1，2，…，K
Oj：表示第j阶段注入的已知缺陷总数量。
j=1 K
i
Oj= ΣNij， j=1，2，…，K
i=j T：表示迄今为止经历的软件生存周期的各个阶段所发现和清除的缺陷总数量。 K k
T= ΣFi 或 T= ΣOj
缺陷泄漏矩阵是一个下三角矩阵，矩阵的行是缺 陷的发现处(发现阶段)，列是缺陷的起源阶段，其元 素Nij满足下列条件： (1)只有当i≥j的元素Nij才有数据； (2)对角线(元素Nij，当i=j)上包含阶段注入并在同一 个阶段被发现和清除的缺陷数量； (3)对角线以下(元素Nij，当i>j)的元素包含来自早期 阶段而后来才被发现和清除的缺陷数量； (4)对角线以上(元素Nij，当i<j)的元素是空的，因为 早期阶段不可能发现后来阶段注入的缺陷。
测试过程度量
测试用例的深度、质量和有效性 测试用例的效率可以用每100或1000个测试 用例所发现的缺陷数来衡量，不同的测试阶段是不 一样，应该对同一阶段的不同版本进行比较，而不 宜对同一版本的不同阶段进行比较。 测试用例的质量（Test Case Quality）可以 用由测试用例发现的缺陷数量来度量， 即 TCQ = 测试用例发现的缺陷数量/总的缺陷数量
构件级设计度量
复杂度（Complexity） 在硬件的可靠性设计中，有一条基本原 则：简单就是可靠。这个原则同样也适合软 件，与功能的增多或增强相伴的是不断升级 与补丁。现在已经有若干种软件复杂性的度 量方法可供参考，其中 McCabe 是比较出 色和实用的方法，它能够计算出多种软件复 杂度，由此可对软件进行检查、分析和查明 那些可能导致错误的代码。
╳
46）= 56
则可确定项目计划，评估评审和测试的完全性
规约质量度量
Davis提出每个质量特征用一或多个度量表示 需求一致性度量：Q1=Nui/Nr 需求完全性度量：Q2=Nc/(Nc+Nnc)
其中 Nui：所有评审者有相同解释的需求数目 Nr：功能性及非功能性（如性能）需求总数 Nc：确认正确的需求数目 Nnc：未被确认的需求数目
度量活动
具体包括： 1、项目评估 2、系统规模度量，如功能点、代码行 3、缺陷分析，如缺陷密度、潜在缺陷发生率 4、针对特定阶段的活动，如需求稳定指数、 测试覆盖率、可靠性分析、客户满意度、系 统复杂度等的度量 5、开发进度、成本、效率等的度量
度量实施
实施过程： 1、度量承诺：确定度量目标、选择度量元、侧重点 2、度量计划：确认产品、流程、角色、责任和资源相 关问题及属性 3、度量实施：收集、分析度量数据，结果用于控制和 改善开发过程 4、度量评估：评估度量标准、流程、方法、对象、效 用，发现问题，提出改进方案 5、度量改进：根据改进方案持续改进度量标准、流程
测试过程度量
基于需求的测试覆盖评估 是依赖于对已执行/运行的测试用例的核实和分 析，所以基于需求的测试覆盖评测转化为评估测试 用例覆盖率：测试的目标是确保100% 的测试用 例全部成功地执行。一般在测试计划中定义了测试 工作量、用例数和用例覆盖率（98%-100%）， 我们根据事先确定的测试日程安排，可以将测试计 划值做成曲线，然后根据实际执行结果，定期画实 际值曲线，从而可以进行测试全过程监控和预测。
软件质量管理与测试
软件质量管理与测试
软件质量度量
软件质量度量
概述 需求分析质量度量 设计质量度量 源代码质量度量 测试质量度量 维护质量度量
软件质量度量
概述
时间：贯穿软件生命周期； 目的：对项目、过程、产品质量持续化定量，并对 此 预测、评估、控制、改进； 包括：客户满意度、项目、产品、品牌、产权等； 方法：测试、审核、调查； 结果：图表、数字、模型。
加权因子（复杂性） 度量参数 用户输入数 用户输出数 用户查询数 文件数 外部接口数 FP项总和 3 2 2 1 4 简单 3 4 3 7 5 中等 4 5 4 10 7 复杂 6 7 6 15 10 计算值 9 8 6 7 20 50
基于功能度量
假如复杂度调整值取中等（46），则
FP = 50 ╳ （0.65+0.01 再如：60行源代码/FP 12个FP/人月 3个Bug/需求、设计 4个Bug/单元、集成测试
测试过程度量
测试执行的效率和质量 测试执行的质量一般可以用软件发布后所遗留 的软件缺陷和总缺陷数的比值来衡量，一般要求低 于0.5%。 测试执行效率可以用下列几种方法来综合度量： * 每个人日所执行的测试用例数 * 每个人日所发现的缺陷数 * 每修改KLOC所运行的测试用例数
测试过程度量
缺陷报告的质量 有效性：修正/关闭的（等级高的）缺陷和测试人 员所报的所有（等级高的）缺陷的比值，这个值越接 近1， 有效性就越高，如果考察等级高的缺陷，其正 常值大约在0.92 – 0.96。 质量：可以用“需要补充信息”、“不是缺陷”的 缺陷数量来衡量，一般占总缺陷数的3%-5%为正常，高 于或低于这个值都可能不正常，高于 5%可能说明缺陷 报告质量低；低于 3%可能说明测试人员缺少怀疑精神。
关键测度，评价指标： 1、用户输入数（3） 2、用户输出数（2） 3、用户查询数（2） 4、文件数（1） 5、 FP = FP项总和
╳
（0.65+0.01
╳
∑Fi）
其中
∑Fi（i=1-14)：复杂度调整值 F i：技术复杂因子（0-5）。
0表示与该因子无关； 5表示与该因子有实质关系。
测试过程度量
基于需求的测试覆盖评估
在执行测试活动中，可用两类测试用例覆盖率估算： 1、确定已经执行的测试用例覆盖率，即在所有测试用例 中有多少测试用例已被执行。 假定Tx已执行的测试过程数 或测试用例数，Rft是测试需求的总数： 已执行的测试覆盖 ＝ Tx／Rft 2、确定成功的测试覆盖，即执行时未出现失败的测试， 如没有出现缺陷或意外结果的测试，假定Ts是已执行的完 全成功、 没有缺陷的测试过程数或测试用例数。 成功的测试覆盖 ＝ Ts／Rft
需求稳定性度量
需求稳定因子（Requirements Stability Index） RSI = （所有确定的需求数 – 待定的需求 变化请求数）/所有确定的需求数 所有确定的需求数 = 初始需求请求数+接 受的需求变化请求数
软件质量度量
设计质量度量 体系结构设计度量 构件级设计度量
体系结构设计度量
连接密度（耦合度）= 控制线数/节点数 本例： 15/12=1.25
节点 控制线 深度（4）
宽度（4）
构件级设计度量
内聚度（Cohesion） 是指模块内部各成分（元素 ）之间的 联结强度。内聚度越高，越容易理解、修改 和维护。但内聚度本身是主观的、非形式化 的概念，程序设计人员很难客观地评估一个 模块的内聚度。为此，人们开发出许多度量 准则用于量化模块的内聚度。 内聚性度量方法
构件级设计度量
Dhama耦合度计算公式：
C=1-1/(Di+2Ci+Do+2Co+Gd+2Gc+W+R)
其中：Di/ Ci ： 输入数据/控制参数的个数 Do/ Co ：输出数据/控制参数的个数 Gd/ Gc ：用做数据/控制的全局变量的个数 W：此模块调用其它模块的个数（扇出） R：调用此模块的其它模块数（扇入）