软件质量度量指标体系设计方案.docx
《软件质量度量指标体系设计方案.docx》由会员分享，可在线阅读，更多相关《软件质量度量指标体系设计方案.docx（12页珍藏版）》请在冰豆网上搜索。
软件质量度量指标体系设计方案
软件质量度量指标
1综述
1.1编写目的
本文档主要为测试人员、开发人员等提供软件质量、测试质量等衡量依据。
通过不同指标的目标设定、过程跟踪、结果分析，为当期被测产品的质量提供可参考的数据，也为后续测试提供数据的基础积累，并作为制定方法流程的依据。
1.2阅读指南
软件测试质量指标主要针对研发项目被测产品出具数据度量。
测试过程质量指标主要针对被测产品测试执行质量出具数据度量。
2软件测试质量指标
2.1缺陷分布统计（模块缺陷率）
计算各模块的缺陷数除以总体缺陷之和，主要查看模块的质量的情况。
2.1.1使用背景
适用于系统测试，此指标不能单纯看结果，要结合实际情况进行分析，如模块的粒度是否划分均匀，模块的重要性，模块包含的内容是否更容易发现缺陷等。
2.1.2计算方式
模块缺陷率=∑本模块的缺陷个数/∑各模块的缺陷个数*100%
2.1.3数据来源
测试管理工具
1.2.1计算结果
可通过导出表格、分析图形的方式来度量结果
序号
模块
缺陷数量
模块缺陷率
累计占比
1
大会意见汇总
23
14.84%
14.84%
2
分组设置
20
12.90%
27.74%
3
科技奖申报
19
12.26%
40.00%
4
网评结果
14
9.03%
49.03%
5
科技奖汇总
14
9.03%
58.06%
6
网评分组
12
7.74%
65.81%
7
小组意见
10
6.45%
72.26%
8
专家意见
9
5.81%
78.06%
9
网评评审
7
4.52%
82.58%
10
会评分组
7
4.52%
87.10%
11
会评结果
7
4.52%
91.61%
12
其它
6
3.87%
95.48%
13
投票结果
5
3.23%
98.71%
14
大会意见
2
1.29%
100.00%
15
总共
155
100.00%
2.2缺陷分布统计（严重缺陷率）
计算各模块的严重缺陷数除以总体缺陷之和，主要查看模块的质量的情况。
2.2.1使用背景
适用于所有测试情况，此指标不能单纯看结果，要结合实际情况进行分析，如模块的粒度是否划分均匀，模块的重要性，模块包含的内容是否更容易发现缺陷等。
2.2.2计算方式
严重缺陷率=∑本模块的严重缺陷个数/∑各模块的严重缺陷个数*100%
2.2.3数据来源
测试管理工具
2.2.4计算结果
可通过导出表格、分析图形的方式来度量结果
序号
模块
严重缺陷数量
严重缺陷率
累计占比
1
大会意见汇总
10
30.30%
30.30%
2
分组设置
4
12.12%
42.42%
3
网评结果
4
12.12%
54.55%
4
科技奖汇总
3
9.09%
63.64%
5
会评结果
3
9.09%
72.73%
6
科技奖申报
2
6.06%
78.79%
7
小组意见
2
6.06%
84.85%
8
网评分组
1
3.03%
87.88%
9
会评分组
1
3.03%
90.91%
10
其它
1
3.03%
93.94%
11
投票结果
1
3.03%
96.97%
12
大会意见
1
3.03%
100.00%
13
专家意见
0
0.00%
14
网评评审
0
0.00%
15
总共
33
100.00%
2.3缺陷密度及收敛
计算各版本缺陷总权值除以测试功能总权值，主要查看版本是否趋于稳定情况，通过数据图表等方式来衡量版本交付的风险大小，是衡量版本是否可交付的重要依据之一。
另一种算法：
缺陷密度=缺陷数量/代码行
2.3.1使用背景
适用于系统测试或者测试周期超过两星期以上，如果缺陷密度逐渐收敛，说明版本逐渐稳定；如果趋势起伏不定，需要分析研究原因，查找不稳定的原因；如果缺陷密度趋势呈波状，一定要重视起来，说明版本及其不稳定，确认发布时要慎重。
2.3.2计算方式
缺陷密度=∑缺陷总权值/∑功能总权值
缺陷总权值计算方法=Sum（缺陷数*该缺陷等级的权值）
等级
权值
阻塞-阻塞开发或者测试工作进度，或影响系统无法正常运行
10
致命-系统崩溃，丢失数据或内存溢出等严重错误
5
严重-主要功能或业务无效
3
一般-系统功能部分无效
1
普通-拼写错误，文本未对齐，数据长度格式校验等
0.5
功能权值计算方法跟缺陷权值计算方法类似，项目经理根据各个功能模块的复杂度拟出每一个模块权值，为了对不同项目缺陷密度的可比性，不同项目的功能权值要求要基本大致相同。
2.3.3数据来源
测试管理工具
2.3.4计算结果
可通过导出表格、分析图形的方式来度量结果
版本序号
测试版本（日期）
缺陷总权值
功能总权值
缺陷比率（缺陷总权值/功能总权值
1
2020.12.5
5
21
4.2
2
2020.12.8
9
22
2.4
3
2020.12.12
18
24
1.3
4
2020.12.14
23
26
1.1
5
2020.12.17
23
25
1.1
6
2020.12.18
27
27
1.0
7
2020.12.19
27
14
0.5
8
2020.12.20
33
14
0.4
9
2020.12.21
33
16
0.5
10
2020.12.22
33
9
0.3
11
2020.12.25
33
8
0.2
趋于收敛的缺陷密度图：
起伏不定的缺陷密度图：
2.4最近提交缺陷指标分析
2.4.1使用背景
适用于系统测试中各测试阶段缺陷情况查看及分析。
2.4.2参考指标
Ø缺陷创建数量
Ø缺陷解决数量
Ø缺陷关闭数量
2.4.3数据来源
测试管理工具
分析：
Ø5月26日左右大范围更新了修正版本后继续测试，缺陷出现增长趋势，说明期间版本仍不稳定。
Ø缺陷累计较多，导致测试人员回归工作量加大，于5月30日突击完成缺陷回归。
2.5累计创建缺陷与累计解决缺陷指标分析
2.5.1使用背景：
适用于系统测试，或测试周期超过两星期测试项目的缺陷情况查看及分析。
2.5.2参考指标
Ø缺陷创建累计数量
Ø缺陷解决累计数量
2.5.3数据来源
测试管理工具
Ø情况一：
缺陷累计数随日期的增加还在持续的快速增长，并且红色曲线斜率多处区域大于45°，说明产品仍存在较多缺陷，质量并没有稳定下来。
两条曲线斜率多处区域均大于45°，说明测试和开发的效率都还是不错，反之说明效率比较低。
因为质量还没有稳定，所以项目测试暂时不能被关闭。
Ø情况二：
两条曲线之间的间距越来越小，且红色曲线的斜率趋于平缓，说明质量越来越稳定，且可以预见两条曲线有交织的可能性，可以考虑关闭项目测试。
Ø情况三：
两条曲线之间的间距越来越大，且红色曲线斜率并没有放缓趋势。
说明产品质量比较差，需要及时做出修改和调整，使产品质量相对稳定下来。
Ø情况三：
两条曲线之间间距稳定，但是曲线斜率趋于平缓。
说明开发遇到了技术挑战，效率开始降低。
由于模块不能及时发布，同时也影响了测试效率。
3测试过程质量指标
3.1需求覆盖率
计算测试用例总数之和除以与之对应的测试需求点数之和，主要查看是否有功能点遗漏测试的情况。
3.1.1使用背景
需求覆盖的程度，在测试粒度较细的模式下，有可能实现100%的覆盖指标，这并不意味着系统被完全测试。
因为对每个需求的测试用例设计可能不是完全覆盖的，或者需求的信息不全面。
该指标是在测试粒度较粗的模式下，查看是否有需求遗漏情况
3.1.2计算方式
需求覆盖率=∑有效测试用例个数/∑有效测试需求个数（只计算到100%）
有效测试用例数=∑测试用例总数-∑无效用例总数
无效用例总数包含：
需求功能点关闭、用例编写错误、未完成需求的用例数？
有效测试需求个数：
《项目-需求矩阵文档》统计的数据
需要讨论：
未完成需求的用例数是否计算到无效用例数中？
3.1.3数据来源
《系统-需求分析报告》、《项目-需求跟踪文档》、《项目-需求矩阵文档》、《项目-测试用例》
3.2用例执行覆盖率※
计算测试用例执行总数除以与之对应的测试数之和，主要查看测试用例执行情况，是否有遗漏。
3.2.1使用背景
系统测试或者测试周期超过两星期以上，测试执行覆盖率达到100%。
冒烟测试，BVTs（BuildVerificationTests）级别测试用例执行覆盖率达到100%。
回归测试、小版本发布测试被测试模块用例执行覆盖率达到100%或者高级别测试用例执行覆盖率达到100%？
。
3.2.2计算方式
用例执行覆盖率=∑执行的测试用例个数/∑有效测试用例个数*100%
3.2.3数据来源
测试管理工具、《项目-测试用例》
3.3测试用例的有效性※
评价测试用例的有效性，判断是否需要提高测试用例的设计要求
3.3.1使用背景
适用于任何测试类型
3.3.2计算方式
测试用例的有效性=∑用例发现缺陷数/∑总缺陷数
3.3.3数据来源
测试管理工具、《项目-测试用例》
3.4缺陷探测率
计算内部发现的缺陷数除以内部发现的缺陷数与用户发现的缺陷数之和，主要查看内部发现缺陷的能力。
3.4.1使用背景
适用于完整的系统测试
缺陷探测率越高，即内部发现的bug数越多，发布后客户发现的bug数就越少，质量成本就越低。
客户问题收集办法：
运维、实施、需求、项目经理收到客户反馈后，整理汇总《XX项目-客户意见及问题反馈清单》，邮件发送该项目测试负责人，测试负责人整理分析，重点分析客户注重哪些方面问题。
3.4.2计算方式
缺陷探测率=∑内部发现的缺陷个数/∑内部发现的缺陷个数+∑用户发现的缺陷个数*100%
3.4.3数据来源
测试管理工具，《项目-客户意见及问题反馈清单》
3.5有效缺陷率
计算被开发人员确认的BUG数总和除以本人上报BUG的总和，可用于查看查看整个测试组的测试质量。
3.5.1使用背景
该指标用于考察测试人员发现的、被确认为缺陷的缺陷数高低或者百分比数，比率越高测试质量越高。
特殊情况下的有效bug：
Ø系统平台的错误；
Ø初始化参数设置错误；
Ø错误数据、错误环境引起；
Ø开发人员无法修正；
Ø不修改程序，通过改变环境或者重新导入数据，再次发布而解决的错误。
3.5.2计算方式
有效缺陷率=∑测试人员发现的有效缺陷个数/∑测试人员发现的总缺陷个数*100%
3.5.3数据来源
测试管理工具。
升级会员 