1、1软件质量指标度量V 1.02012.32目录1 综述 .31.1 编写目的 .31.2 阅读指南 .32 软件质量指标 .42.1 需求功能点覆盖率 .42.2 用例执行覆盖率 .42.3 缺陷修复率（截至于*年*月*日） .52.4 缺陷遗留个数（截至于*年*月*日） .52.5 缺陷分布统计（模块缺陷率） .52.6 缺陷分布统计（严重缺陷率） .62.7 缺陷密度及收敛 .73 测试过程质量指标 .93.1 缺陷探测率 .93.2 有效缺陷率 .93.1 用例执行效率 .103.2 缺陷发现率 .104 交付质量指标 .124.1 加载回退率 .124.2 故障回退率 .125 版本说
2、明 .1331 综述1.1 编写目的 本文档主要为测试经理、测试组长/测试人员、技术负责人、项目经理、开发人员等提供软件质量、测试质量、交付质量等衡量依据。通过不同指标的目标设定、过程跟踪、结果分析，为当期被测产品的质量提供可参考的数据，也为后续测试提供数据的基础积累，并作为制定方法流程的依据。1.2 阅读指南 软件测试质量指标主要针对研发项目、商务项目被测产品出具数据度量。 测试过程质量指标主要为测试经理、测试组长对测试人员的测试执行质量出具数据度量。 交付质量主要为新需求的交付质量出具数据度量。三者可单独使用，也可结合使用。42 软件质量指标2.1 需求功能点覆盖率 【需求覆盖率】 ：计算
3、测试用例总数之和除以与之一一对应的功能点数之和，主要查看是否有功能点遗漏测试的情况。【公式】：测试用例数（个） / 功能点（个）说明：用例覆盖需求矩阵，一个需求对应多个功能点。【数据来源】：联通集中集团客户业务支撑系统销售管理用户需求说明书联通集中集团客户业务支撑系统销售管理需求跟踪矩阵【计算结果】需求覆盖率=113/8=14.132.2 用例执行覆盖率【用例执行覆盖率】： 计算测试用例执行总数除以与之一一对应的测试数之和，主要查看是否有测试用例执行遗漏或有效的情况。【公式】：执行的测试用例个数（个） / 测试用例个数（个） *100%【数据来源】：iSMS 测试进度跟踪表 【计算结果】：用例
4、执行覆盖率=100%功能模块 测试用例个数 执行的测试用例个数 用例覆盖率XX 模块线索管理 14 14 100%XX 模块创建 14 14 100%XX 模块信息管理 41 41 100%XX 模块审批 5 5 100%5Xx 模块立项 20 20 100%Xx 模块信息管理 9 9 100%Xx 模块管理 8 8 100%Xx 模块综合查询 2 2 100%总计 113 113 100%2.3 缺陷修复率（截至于*年*月* 日） 【缺陷修复率】 计算已修复（关闭）的缺陷总数除以有效缺陷总数，主要查看是否有测试用例执行遗漏或有效的情况。【公式】：修复（关闭）的缺陷数量（个） / 有效缺陷数量
5、（个）【数据来源】：从公司内部缺陷管理系统中导出数据：【计算结果】：缺陷修复率=206/216*100%=95%2.4 缺陷遗留个数（截至于*年*月* 日）【缺陷遗留个数】统计待分配、待修改、重新处理的缺陷数量【公式】：待分配+待修改+reopen 状态的缺陷 【数据来源】：从公司内部缺陷管理系统中导出数据【计算结果】：缺陷遗留个数=10，且为 C 类以下 bug(建议性缺陷) 2.5 缺陷分布统计（模块缺陷率）【模块缺陷率】 ：计算各模块的缺陷数除以总体缺陷之和，主要查看模块的质量的情况。6说明：此指标不能单纯看结果，要结合实际情况进行分析，如模块的粒度是否划分均匀，模块的重要性，模块包含的
6、内容是否更容易发现 bug 等。【公式】：本模块的缺陷数（个） / 各模块的缺陷数（个） *100%【数据来源】：QC 管理平台 【计算结果】可通过导出表格、分析图形的方式来度量结果模块名 缺陷数 模块缺陷率模块 1 10 10/50*100%=20%模块 2 20 20/50*100%=40%模块 3 20 20/50*100%=40%总数 502.6 缺陷分布统计（严重缺陷率）【模块缺陷率】 ：计算各模块的严重缺陷数除以总体缺陷之和，主要查看模块的质量的情况。说明：此指标不能单纯看结果，要结合实际情况进行分析，如模块的粒度是否划分均匀，模块的重要性，模块包含的内容是否更容易发现 bug 等
7、。【公式】：本模块的严重缺陷数（个） / 各模块的严重缺陷数（个）*100%【数据来源】：QC 管理平台 【计算结果】可通过导出表格、分析图形的方式来度量结果模块名 严重缺陷数 严重缺陷率模块 1 1 1/5*100%=20%模块 2 2 2/5*100%=40%模块 3 2 2/5*100%=40%总数 572.7 缺陷密度及收敛【模块缺陷率】 ：计算各版本缺陷数除以测试模块，主要查看版本是否趋于稳定情况，通过数据图表等方式来衡量版本交付的风险大小，是衡量版本是否可交付的重要依据之一。说明：如果缺陷密度逐渐收敛，说明版本逐渐稳定；如果趋势起伏不定，需要分析研究原因，查找不稳定的原因；如果缺陷
8、密度趋势呈波状，一定要重视起来，说明版本及其不稳定，确认发布时要慎重。【公式】：本版本的缺陷数（个） / 已测各模块数（个）【数据来源】：日常跟踪数据、QC 管理平台 【计算结果】可通过导出表格、分析图形的方式来度量结果版本序号 测试版本（日期）已测模块总数版本 bug数缺陷比率（bug总数/已测模块总数)1 2011.12.5 5 21 4.2 2 2011.12.8 9 22 2.4 3 2011.12.12 18 24 1.3 4 2011.12.14 23 26 1.1 5 2011.12.17 23 25 1.1 6 2011.12.18 27 27 1.0 7 2011.12.19
9、 27 14 0.5 88 2011.12.20 33 14 0.4 9 2011.12.21 33 16 0.5 10 2011.12.22 33 9 0.3 11 2011.12.25 33 8 0.2 趋于收敛的缺陷密度图：起伏不定的缺陷密度图：9103 测试过程质量指标3.1 缺陷探测率【缺陷探测率】 ：计算内部发现的缺陷数除以内部发现的缺陷数与用户发现的缺陷数之和，主要查看内部发现缺陷的能力。说明：缺陷探测率越高，即内部发现的 bug 数越多，发布后客户发现的bug 数就越少，质量成本就越低。【公式】：内部发现的缺陷数（个） / （内部发现的缺陷数（个） +用户发现的缺陷数（个）*1
10、00%【数据来源】：日常跟踪表，QC 平台，用户缺陷平台或列表 【计算结果】：缺陷探测率=80/(80+5)=94%3.2有效缺陷率【有效缺陷率】 ：计算被开发人员确认的 BUG 数总和除于本人上报 BUG 的总和，可用于查看测试人员的个人测试质量，也可用于查看整个测试组的测试质量。无效 BUG 状态包括：问题重复、不是问题、不可复现状态。这项指标用于考察测试人员发现的、被确认为缺陷的缺陷数高低或者百分比，数和比率越高测试质量越高。注意：由于系统框架根本性的、初始化参数设置错误引发的、错误数据、错误环境等而开发人员因无法修正、可以通过改变环境而无需修改程序、重新导入数据、再次发布而解决的 BUG 为有效 BUG【公式】：测试人员发现的有效缺陷数（个） /测试人员发现的总缺陷数（个）*100%
