一、综述

1.1 编写目的

本文档主要为研发经理、测试经理、测试组长/测试人员、技术负责人、工程经理、开发人员等提供软件质量、测试质量、交付质量等衡量依据。通过不同指标的目标设定、过程跟踪、结果分析，为当期开发产品的质量提供可参考的数据，也为后续测试提供数据的根底积累，并作为制定方法流程的依据。

1.2 阅读指南

1、软件测试质量指标主要针对研发工程、商务工程被测产品出具数据度量。

2、测试过程质量指标主要为测试经理、测试组长对测试人员的测试执行质量出具数据度量。

3、交付质量主要为新需求的交付质量出具数据度量。

三者可单独使用，也可结合使用。

二、软件质量指标

2.1 需求功能点覆盖率

1、需求覆盖率：计算测试用例总数之和除以与之一一对应的功能点数之和，主要查看是否有功能点遗漏测试的情况。

2、公式：∑测试用例数〔个〕 / ∑功能点〔个〕

说明：用例覆盖需求矩阵，一个需求对应多个功能点。

3、数据来源：?用户需求说明书??需求跟踪矩阵?

4、计算结果：需求覆盖率=113/8=14.13

2.2 用例执行覆盖率

1、用例执行覆盖率： 计算测试用例执行总数除以与之一一对应的测试数之和，主要查看是否有测试用例执行遗漏或有效的情况。

2、公式：∑执行的测试用例个数〔个〕 / ∑测试用例个数〔个〕*100%

3、数据来源：?测试进度跟踪表?

4、计算结果：用例执行覆盖率=100%

2.3 缺陷修复率〔截至于**年*月*日〕

1、缺陷修复率：计算已修复〔关闭〕的缺陷总数除以有效缺陷总数，主要查看是否有测试用例执行遗漏或有效的情况。

2、公式：∑修复〔关闭〕的缺陷数量〔个〕 / ∑有效缺陷数量〔个〕

3、数据来源：从公司部缺陷管理系统中导出数据：

4、计算结果：缺陷修复率=206/216*100%=95%

2.4 缺陷遗留个数〔截至于**年*月*日〕

1、缺陷遗留个数：统计待分配、待修改、重新处理的缺陷数量

2、公式：待分配+待修改+reopen状态的缺陷

3、数据来源：从公司部缺陷管理系统中导出数据

4、计算结果：缺陷遗留个数=10，且为C类以下bug(建议性缺陷)

2.5 缺陷分布统计〔模块缺陷率〕

1、模块缺陷率 ：计算各模块的缺陷数除以总体缺陷之和，主要查看模块的质量的情况。

2、说明：此指标不能单纯看结果，要结合实际情况进展分析，如模块的粒度是否划分均匀，模块的重要性，模块包含的容是否更容易发现bug等。

3、公式：本模块的缺陷数〔个〕 / ∑各模块的缺陷数〔个〕*100%

4、数据来源：QC管理平台

计算结果可通过导出表格、分析图形的方式来度量结果

2.6 缺陷分布统计〔严重缺陷率〕

1、模块缺陷率 ：计算各模块的严重缺陷数除以总体缺陷之和，主要查看模块的质量的情况。

2、说明：此指标不能单纯看结果，要结合实际情况进展分析，如模块的粒度是否划分均匀，模块的重要性，模块包含的容是否更容易发现bug等。

3、公式：本模块的严重缺陷数〔个〕 / ∑各模块的严重缺陷数〔个〕*100%

4、数据来源：QC管理平台

计算结果可通过导出表格、分析图形的方式来度量结果

2.7 缺陷密度及收敛

1、模块缺陷率 ：计算各版本缺陷数除以测试模块，主要查看版本是否趋于稳定情况，通过数据图表等方式来衡量版本交付的风险大小，是衡量版本是否可交付的重要依据之一。

2、说明：如果缺陷密度逐渐收敛，说明版本逐渐稳定；如果趋势起伏不定，需要分析研究原因，查找不稳定的原因；如果缺陷密度趋势呈波状，一定要重视起来，说明版本及其不稳定，确认发布时要慎重。

3、公式：本版本的缺陷数〔个〕 / ∑已测各模块数〔个〕

4、数据来源：日常跟踪数据、QC管理平台

计算结果可通过导出表格、分析图形的方式来度量结果

趋于收敛的缺陷密度图：

起伏不定的缺陷密度图：

三、测试过程质量指标

3.1 缺陷探测率

1、缺陷探测率 ：计算部发现的缺陷数除以部发现的缺陷数与用户发现的缺陷数之和，主要查看部发现缺陷的能力。

2、说明：缺陷探测率越高，即部发现的bug数越多，发布后客户发现的bug数就越少，质量本钱就越低。

3、公式：部发现的缺陷数〔个〕 / 〔部发现的缺陷数〔个〕+用户发现的缺陷数〔个〕〕*100%

4、数据来源：日常跟踪表，QC平台，用户缺陷平台或列表

5、计算结果：缺陷探测率=80/(80+5)=94%

3.2 有效缺陷率

1、有效缺陷率 ：计算被开发人员确认的BUG数总和除于本人上报BUG的总和，可用于查看测试人员的个人测试质量，也可用于查看整个测试组的测试质量。

2、无效BUG状态包括：问题重复、不是问题、不可复现状态。这项指标用于考察测试人员发现的、被确认为缺陷的缺陷数上下或者百分比，数和比率越高测试质量越高。

3、注意：由于系统框架根本性的、初始化参数设置错误引发的、错误数据、错误环境等而开发人员因无法修正、可以通过改变环境而无需修改程序、重新导入数据、再次发布而解决的BUG为有效BUG

4、公式：测试人员发现的有效缺陷数〔个〕 /测试人员发现的总缺陷数〔个〕*100%

5、数据来源：日常跟踪表，QC平台，用户缺陷平台

6、计算结果：

3.3 用例执行效率

1、用例执行效率 ：计算测试人员执行的用例数除以执行测试的时间，主要查看测试人员执行测试的效率。

2、说明：此指标的统计需要有一定的前提条件：用例的执行步骤相对来说分布较均匀，执行时间在一个较长的时间段

3、公式：∑测试人员执行的用例数〔个〕 / ∑执行用例的时间〔小时〕

4、数据来源：日常跟踪表，QC平台，用户缺陷平台或列表

5、计算结果：

3.4 缺陷发现率

1、缺陷发现率 ：计算测试人员各自发现的缺陷数总和除于各自所花费的测试时间总和。

由于执行效率不能足够代表测试人员是否认真工作，那么，每小时发现的缺陷数就是重要的考核指标，测试的工作可以通过这项指标得到反应。

注意：此项指标的统计可作为测试质量的一个依据，但实际工作中如果用此指标作为考核测试人员的唯一依据会带来很多问题，比方，缺陷数可通过减小缺陷粒度、增加微小缺陷、增加不能确定bug数来提高分子数，这样会增加缺陷流转处理本钱，会带来更多的问题。建议慎用。

2、公式：∑提交缺陷数〔个〕 / ∑执行测试的有效时间〔小时〕

3、数据来源：日常跟踪表，QC平台，用户缺陷平台或列表

4、计算结果：

四、交付质量指标

4.1 加载回退率

1、加载回退率 ：计算方案上线需求个数减去加载回退的需求个数之差除以方案上线需求个数，主要查看新需求上线交付质量。

2、说明：上线加载当日无法满足上线条件，导致回退。

3、公式：〔上线需求数〔个〕-加载当时回退需求数〔个〕〕/上线需求数〔个〕*100%

4、数据来源：需求管控平台，需求管理平台等

5、计算结果：加载回退率=〔15-1〕/15*100%=93%

4.2 故障回退率

1、加载回退率 ：计算方案上线需求个数减去故障回退的需求个数之差除以方案上线需求个数，主要查看新需求上线交付质量。

2、说明：上线加载次日，用户无法使用，引发投诉，进展故障回退。

3、公式：〔上线需求数〔个〕-故障回退需求数〔个〕〕/上线需求数〔个〕*100%

4、数据来源：需求管控平台，需求管理平台/缺陷管理平台等

5、计算结果：故障回退率=〔16-2〕/16*100%=88%

• 上一篇：华为ipd 项目指导层 组织架构
• 下一篇：研发部管理制度研发部日常管理