软件质量度量指标v20文档格式.docx

软件质量度量指标v20文档格式.docx

《软件质量度量指标v20文档格式.docx》由会员分享，可在线阅读，更多相关《软件质量度量指标v20文档格式.docx（9页珍藏版）》请在冰豆网上搜索。

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

【数据来源】：

《联通集中集团客户业务支撑系统销售管理用户需求说明书》《联通集中集团客户业务支撑系统销售管理需求跟踪矩阵》

【计算结果】需求覆盖率=113/8=14.13

2.2用例执行覆盖率

【用例执行覆盖率】：

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

∑执行的测试用例个数（个）/∑测试用例个数（个）*100%

《iSMS测试进度跟踪表》

【计算结果】：

用例执行覆盖率=100%

功能模块

测试用例个数

执行的测试用例个数

用例覆盖率

XX模块线索管理

14

100%

XX模块创建

XX模块信息管理

41

XX模块审批

5

Xx模块立项

20

Xx模块信息管理

9

Xx模块管理

8

Xx模块综合查询

2

总计

113

2.3缺陷修复率（截至于**年*月*日）

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

∑修复（关闭）的缺陷数量（个）/∑有效缺陷数量（个）

从公司内部缺陷管理系统中导出数据：

缺陷修复率=206/216*100%=95%

2.4缺陷遗留个数（截至于**年*月*日）

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

待分配+待修改+reopen状态的缺陷

从公司内部缺陷管理系统中导出数据

缺陷遗留个数=10，且为C类以下bug（建议性缺陷）

2.5缺陷分布统计（模块缺陷率）

【模块缺陷率】：

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

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

本模块的缺陷数（个）/∑各模块的缺陷数（个）*100%

QC管理平台

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

模块名

缺陷数

模块缺陷率

模块1

10

10/50*100%=20%

模块2

20/50*100%=40%

模块3

总数

50

2.6缺陷分布统计（严重缺陷率）

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

本模块的严重缺陷数（个）/∑各模块的严重缺陷数（个）*100%

严重缺陷数

严重缺陷率

1

1/5*100%=20%

2

2/5*100%=40%

5

2.7缺陷密度及收敛

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

如果缺陷密度逐渐收敛，说明版本逐渐稳定；

如果趋势起伏不定，需要分析研究原因，查找不稳定的原因；

如果缺陷密度趋势呈波状，一定要重视起来，说明版本及其不稳定，确认发布时要慎重。

本版本的缺陷数（个）/∑已测各模块数（个）

日常跟踪数据、QC管理平台

版本序号

测试版本（日期）

已测模块总数

版本bug数

缺陷比率（bug总数/已测模块总数）

2011.12.5

21

4.2

2011.12.8

22

2.4

3

2011.12.12

18

24

1.3

4

2011.12.14

23

26

1.1

2011.12.17

25

6

2011.12.18

27

1.0

7

2011.12.19

14

0.5

8

2011.12.20

33

0.4

2011.12.21

16

2011.12.22

0.3

11

2011.12.25

0.2

趋于收敛的缺陷密度图：

起伏不定的缺陷密度图：

3测试过程质量指标

3.1缺陷探测率

【缺陷探测率】：

计算内部发现的缺陷数除以内部发现的缺陷数与用户发现的缺陷数之和，主要查看内部发现缺陷的能力。

缺陷探测率越高，即内部发现的bug数越多，发布后客户发现的bug数就越少，质量成本就越低。

内部发现的缺陷数（个）/（内部发现的缺陷数（个）+用户发现的缺陷数（个））*100%

日常跟踪表，QC平台，用户缺陷平台或列表

缺陷探测率=80/（80+5）=94%

3.2有效缺陷率

【有效缺陷率】：

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

无效BUG状态包括：

问题重复、不是问题、不可复现状态。

这项指标用于考察测试人员发现的、被确认为缺陷的缺陷数高低或者百分比，数和比率越高测试质量越高。

注意：

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

测试人员发现的有效缺陷数（个）/测试人员发现的总缺陷数（个）*100%

日常跟踪表，QC平台，用户缺陷平台

【计算结果】

测试人员

有效缺陷数

总缺陷数

有效缺陷率

张苗苗

60

62

60/62*100%=97%

李豆豆

40

42

40/42*100%=95%

总体

100

104

100/104*100%=96%

3.3用例执行效率

【用例执行效率】：

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

此指标的统计需要有一定的前提条件：

用例的执行步骤相对来说分布较均匀，执行时间在一个较长的时间段内

∑测试人员执行的用例数（个）/∑执行用例的时间（小时）

执行用例数

执行时间（单位：

小时）

用例执行效率

30

12

30/12=2.5

20/7=2.8

19

50/19=2.6

3.4缺陷发现率

【缺陷发现率】：

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

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

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

建议慎用。

∑提交缺陷数（个）/∑执行测试的有效时间（小时）

提交缺陷数

执行测试时间（单位：

缺陷发现率

25/30=0.83

10/9=1.1

35

39

35/39=0.9

4交付质量指标

4.1加载回退率

【加载回退率】：

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

上线加载当日无法满足上线条件，导致回退。

（上线需求数（个）-加载当时回退需求数（个））/上线需求数（个）*100%

生产门户需求管控平台，客户需求管理平台等

【计算结果】加载回退率=（15-1）/15*100%=93%

4.2故障回退率

计算计划上线需求个数减去故障回退的需求个数之差除以计划上线需求个数，主要查看新需求上线交付质量。

上线加载次日，用户无法使用，引发投诉，进行故障回退。

（上线需求数（个）-故障回退需求数（个））/上线需求数（个）*100%

生产门户需求管控平台，客户需求管理平台/缺陷管理平台等

【计算结果】故障回退率=（16-2）/16*100%=88%

5版本说明

1.鉴于自己的经验有限，尤其侧重于测试方面，故总结的度量指标多为测试指标。

2.其实软件的质量保证需要多种途径、多个层次、多个阶段有计划有步骤地去实现，测试只是其中一条途径。

休哈特说“产品质量不是检验出来的，而是生产出来的”，可见“测试只能发现问题，并不能解决问题”。

戴明博士说“引起效率低下和不良质量的原因主要在公司的管理系统而不在员工”，但是我们不能因此而放弃对高质量的追求。

3.我正在系统学习质量控制、质量保证、质量改进方面的知识，后续会整理出更为全面的度量指标，和同行及致力于提高软件质量的朋友们分享。