软件质量度量指标v10.doc

《软件质量度量指标v10.doc》由会员分享，可在线阅读，更多相关《软件质量度量指标v10.doc（14页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、1 软件质量指标度量软件质量指标度量 V 1.0 2012.3 2 目录目录 1 综述综述.3 1.1编写目的.3 1.2阅读指南.3 2 软件质量指标软件质量指标.4 2.1需求功能点覆盖率.4 2.2用例执行覆盖率.4 2.3缺陷修复率（截至于*年*月*日）.5 2.4缺陷遗留个数（截至于*年*月*日）.5 2.5缺陷分布统计（模块缺陷率）.5 2.6缺陷分布统计（严重缺陷率）.6 2.7缺陷密度及收敛.7 3 测试过程质量指标测试过程质量指标.9 3.1缺陷探测率.9 3.2有效缺陷率.9 3.1用例执行效率.10 3.2缺陷发现率.10 4 交付质量指标交付质量指标.12 4.1加载回

2、退率.12 4.2故障回退率.12 5 版本说明版本说明.13 3 1 1 综述综述 1.1编写目的编写目的 本文档主要为测试经理、测试组长/测试人员、技术负责人、项目经 理、开发人员等提供软件质量、测试质量、交付质量等衡量依据。通过 不同指标的目标设定、过程跟踪、结果分析，为当期被测产品的质量提 供可参考的数据，也为后续测试提供数据的基础积累，并作为制定方法 流程的依据。 1.2阅读指南阅读指南 软件测试质量指标主要针对研发项目、商务项目被测产品出具数据 度量。 测试过程质量指标主要为测试经理、测试组长对测试人员的测试执 行质量出具数据度量。 交付质量主要为新需求的交付质量出具数据度量。 三

3、者可单独使用，也可结合使用。 4 2 2 软件质量指标软件质量指标 2.1需求功能点覆盖率需求功能点覆盖率 【需求覆盖率】 ：计算测试用例总数之和除以与之一一对应的功能点数之 和，主要查看是否有功能点遗漏测试的情况。 【公式】：测试用例数（个） / 功能点（个） 说明：用例覆盖需求矩阵，一个需求对应多个功能点。 【数据来源】：联通集中集团客户业务支撑系统销售管理用户需求说明 书联通集中集团客户业务支撑系统销售管理需求跟踪矩阵 【计算结果】需求覆盖率=113/8=14.13 2.2用例执行覆盖率用例执行覆盖率 【用例执行覆盖率】： 计算测试用例执行总数除以与之一一对应的测试数 之和，主要查看是否

4、有测试用例执行遗漏或有效的情况。 【公式】：执行的测试用例个数（个） / 测试用例个数（个）*100% 【数据来源】：iSMS 测试进度跟踪表 【计算结果】：用例执行覆盖率=100% 功能模块测试用例个数执行的测试用例个数用例覆盖率 XX 模块线索管理 14 14 100% XX 模块创建 14 14 100% XX 模块信息管理 41 41 100% XX 模块审批 5 5 100% 5 Xx 模块立项 2020100% Xx 模块信息管理 99100% Xx 模块管理 8 8 100% Xx 模块综合查询 2 2 100% 总计 113113100% 2.3 缺陷修复率（缺陷修复率（截至于

5、*年*月*日） 【缺陷修复率】 计算已修复（关闭）的缺陷总数除以有效缺陷总数，主 要查看是否有测试用例执行遗漏或有效的情况。 【公式】：修复（关闭）的缺陷数量（个） / 有效缺陷数量（个） 【数据来源】：从公司内部缺陷管理系统中导出数据： 【计算结果】：缺陷修复率=206/216*100%=95% 2.4 缺陷遗留个数（截至于*年*月*日） 【缺陷遗留个数缺陷遗留个数】统计待分配、待修改、重新处理的缺陷数量 【公式公式】：待分配+待修改+reopen 状态的缺陷 【数据来源数据来源】：从公司内部缺陷管理系统中导出数据 【计算结果计算结果】：缺陷遗留个数：缺陷遗留个数=10，且为，且为 C 类以

6、下 bug(建议性缺陷) 2.5 缺陷分布统计（缺陷分布统计（模块缺陷率） 【模块缺陷率模块缺陷率】 ：计算各模块的缺陷数除以总体缺陷之和，主要查看模块 的质量的情况。 6 说明：此指标不能单纯看结果，要结合实际情况进行分析，如模块的粒度 是否划分均匀，模块的重要性，模块包含的内容是否更容易发现 bug 等。 【公式】：本模块的缺陷数（个） / 各模块的缺陷数（个）*100% 【数据来源】：QC 管理平台 【计算结果】可通过导出表格、分析图形的方式来度量结果 模块名模块名缺陷数缺陷数模块缺陷率模块缺陷率 模块 11010/50*100%=20% 模块 22020/50*100%=40% 模块

7、32020/50*100%=40% 总数50 2.6 缺陷分布统计（缺陷分布统计（严重缺陷率） 【模块缺陷率模块缺陷率】 ：计算各模块的严重缺陷数除以总体缺陷之和，主要查看 模块的质量的情况。 说明：此指标不能单纯看结果，要结合实际情况进行分析，如模块的粒度 是否划分均匀，模块的重要性，模块包含的内容是否更容易发现 bug 等。 【公式】：本模块的严重缺陷数（个） / 各模块的严重缺陷数（个） *100% 【数据来源】：QC 管理平台 【计算结果】可通过导出表格、分析图形的方式来度量结果 模块名模块名严重缺陷数严重缺陷数严重缺陷率严重缺陷率 模块 111/5*100%=20% 模块 222/5

8、*100%=40% 模块 322/5*100%=40% 总数5 7 2.7 缺陷密度及收敛缺陷密度及收敛 【模块缺陷率模块缺陷率】 ：计算各版本缺陷数除以测试模块，主要查看版本是否趋 于稳定情况，通过数据图表等方式来衡量版本交付的风险大小，是衡量版本是 否可交付的重要依据之一。 说明：如果缺陷密度逐渐收敛，说明版本逐渐稳定；如果趋势起伏不定， 需要分析研究原因，查找不稳定的原因；如果缺陷密度趋势呈波状，一定要重 视起来，说明版本及其不稳定，确认发布时要慎重。 【公式】：本版本的缺陷数（个） / 已测各模块数（个） 【数据来源】：日常跟踪数据、QC 管理平台 【计算结果】可通过导出表格、分析图形

9、的方式来度量结果 版本序号测试版本（日期） 已测模 块总数 版本 bug 数 缺陷比率（bug 总数/已测模块 总数) 12011.12.55214.2 22011.12.89222.4 32011.12.1218241.3 42011.12.1423261.1 52011.12.1723251.1 62011.12.1827271.0 72011.12.1927140.5 8 82011.12.2033140.4 92011.12.2133160.5 102011.12.223390.3 112011.12.253380.2 趋于收敛的缺陷密度图： 起伏不定的缺陷密度图： 9 10 3 3

10、测试过程质量指标测试过程质量指标 3.1 缺陷探测率缺陷探测率 【缺陷探测率】 ：计算内部发现的缺陷数除以内部发现的缺陷数与用户发 现的缺陷数之和，主要查看内部发现缺陷的能力。 说明：缺陷探测率越高，即内部发现的 bug 数越多，发布后客户发现的 bug 数就越少，质量成本就越低。 【公式】：内部发现的缺陷数（个） / （内部发现的缺陷数（个）+用户 发现的缺陷数（个）*100% 【数据来源】：日常跟踪表，QC 平台，用户缺陷平台或列表 【计算结果】：缺陷探测率=80/(80+5)=94% 3.2有效缺陷率 【有效缺陷率】 ：计算被开发人员确认的 BUG 数总和除于本人上报 BUG 的 总和，

11、可用于查看测试人员的个人测试质量，也可用于查看整个测试组的测试 质量。 无效 BUG 状态包括：问题重复、不是问题、不可复现状态。这项指标用于 考察测试人员发现的、被确认为缺陷的缺陷数高低或者百分比，数和比率越高 测试质量越高。 注意：由于系统框架根本性的、初始化参数设置错误引发的、错误数据、 错误环境等而开发人员因无法修正、可以通过改变环境而无需修改程序、重新 导入数据、再次发布而解决的 BUG 为有效 BUG 【公式】：测试人员发现的有效缺陷数（个） /测试人员发现的总缺陷数 （个）*100% 11 【数据来源】：日常跟踪表，QC 平台，用户缺陷平台 【计算结果】 测试人员测试人员有效缺陷

12、数有效缺陷数总缺陷数总缺陷数有效缺陷率有效缺陷率 张苗苗606260/62*100%=97% 李豆豆404240/42*100%=95% 总体100104100/104*100%=96% 3.1 用例执行效率用例执行效率 【用例执行效率】 ：计算测试人员执行的用例数除以执行测试的时间，主 要查看测试人员执行测试的效率。 说明：此指标的统计需要有一定的前提条件：用例的执行步骤相对来说分 布较均匀，执行时间在一个较长的时间段内 【公式】：测试人员执行的用例数（个） / 执行用例的时间（小时） 【数据来源】：日常跟踪表，QC 平台，用户缺陷平台或列表 【计算结果】： 测试人员执行用例数执行时间（单位

13、： 小时） 用例执行效率 张苗苗301230/12=2.5 李豆豆20720/7=2.8 总体501950/19=2.6 3.2 缺陷发现率缺陷发现率 【缺陷发现率】 ：计算测试人员各自发现的缺陷数总和除于各自所花费的 12 测试时间总和。 由于执行效率不能足够代表测试人员是否认真工作，那么，每小时发现的 缺陷数就是重要的考核指标，测试的工作可以通过这项指标得到反馈。 注意：此项指标的统计可作为测试质量的一个依据，但实际工作中如果用 此指标作为考核测试人员的唯一依据会带来很多问题，比如，缺陷数可通过减 小缺陷粒度、增加微小缺陷、增加不能确定 bug 数来提高分子数，这样会增加 缺陷流转处理成本

14、，会带来更多的问题。建议慎用。 【公式】：提交缺陷数（个） / 执行测试的有效时间（小时） 【数据来源】：日常跟踪表，QC 平台，用户缺陷平台或列表 【计算结果】： 测试人员测试人员提交缺陷数提交缺陷数执行测试时间执行测试时间 （单位：小时）（单位：小时） 缺陷发现率缺陷发现率 张苗苗253025/30=0.83 李豆豆10910/9=1.1 总体353935/39=0.9 13 4 4 交付质量指标交付质量指标 4.1 加载回退率加载回退率 【加载回退率】 ：计算计划上线需求个数减去加载回退的需求个数之差除 以计划上线需求个数，主要查看新需求上线交付质量。 说明：上线加载当日无法满足上线条件

15、，导致回退。 【公式】：（上线需求数（个）-加载当时回退需求数（个）/上线需求 数（个）*100% 【数据来源】：生产门户需求管控平台，客户需求管理平台等 【计算结果】加载回退率=（15-1）/15*100%=93% 4.2 故障回退率故障回退率 【加载回退率】 ：计算计划上线需求个数减去故障回退的需求个数之差除 以计划上线需求个数，主要查看新需求上线交付质量。 说明：上线加载次日，用户无法使用，引发投诉，进行故障回退。 【公式】：（上线需求数（个）-故障回退需求数（个）/上线需求数 （个）*100% 【数据来源】：生产门户需求管控平台，客户需求管理平台/缺陷管理平台 等 【计算结果】故障回退

16、率=（16-2）/16*100%=88% 14 5 5 版本说明版本说明 1. 鉴于自己的经验有限，尤其侧重于测试方面，故总结的度量指标多为测试 指标。 2. 其实软件的质量保证需要多种途径、多个层次、多个阶段有计划有步骤地 去实现，测试只是其中一条途径。休哈特说“产品质量不是检验出来的， 而是生产出来的”，可见“测试只能发现问题，并不能解决问题”。戴明 博士说“引起效率低下和不良质量的原因主要在公司的管理系统而不在员 工”，但是我们不能因此而放弃对高质量的追求。 3. 我正在系统学习质量控制、质量保证、质量改进方面的知识，后续会整理 出更为全面的度量指标，和同行及致力于提高软件质量的朋友们分享。