软件质量度量指标体系设计方案.docx

1、软件质量度量指标体系设计方案软件质量度量指标1综述1.1编写目的 本文档主要为测试人员、开发人员等提供软件质量、测试质量等衡量依据。通过不同指标的目标设定、过程跟踪、结果分析，为当期被测产品的质量提供可参考的数据，也为后续测试提供数据的基础积累，并作为制定方法流程的依据。1.2阅读指南软件测试质量指标主要针对研发项目被测产品出具数据度量。测试过程质量指标主要针对被测产品测试执行质量出具数据度量。2软件测试质量指标2.1缺陷分布统计（模块缺陷率）计算各模块的缺陷数除以总体缺陷之和，主要查看模块的质量的情况。2.1.1使用背景适用于系统测试，此指标不能单纯看结果，要结合实际情况进行分析，如模块的粒

2、度是否划分均匀，模块的重要性，模块包含的内容是否更容易发现缺陷等。2.1.2计算方式模块缺陷率=本模块的缺陷个数/各模块的缺陷个数*100%2.1.3数据来源测试管理工具1.2.1计算结果可通过导出表格、分析图形的方式来度量结果序号模块缺陷数量模块缺陷率累计占比1大会意见汇总2314.84%14.84%2分组设置2012.90%27.74%3科技奖申报1912.26%40.00%4网评结果149.03%49.03%5科技奖汇总149.03%58.06%6网评分组127.74%65.81%7小组意见106.45%72.26%8专家意见95.81%78.06%9网评评审74.52%82.58%10

3、会评分组74.52%87.10%11会评结果74.52%91.61%12其它63.87%95.48%13投票结果53.23%98.71%14大会意见21.29%100.00%15总共155100.00%2.2缺陷分布统计（严重缺陷率）计算各模块的严重缺陷数除以总体缺陷之和，主要查看模块的质量的情况。2.2.1使用背景适用于所有测试情况，此指标不能单纯看结果，要结合实际情况进行分析，如模块的粒度是否划分均匀，模块的重要性，模块包含的内容是否更容易发现缺陷等。2.2.2计算方式严重缺陷率=本模块的严重缺陷个数/各模块的严重缺陷个数*100%2.2.3数据来源测试管理工具2.2.4计算结果可通过导出

4、表格、分析图形的方式来度量结果序号模块严重缺陷数量严重缺陷率累计占比1大会意见汇总1030.30%30.30%2分组设置412.12%42.42%3网评结果412.12%54.55%4科技奖汇总39.09%63.64%5会评结果39.09%72.73%6科技奖申报26.06%78.79%7小组意见26.06%84.85%8网评分组13.03%87.88%9会评分组13.03%90.91%10其它13.03%93.94%11投票结果13.03%96.97%12大会意见13.03%100.00%13专家意见00.00%14网评评审00.00%15总共33100.00%2.3缺陷密度及收敛计算各版本

5、缺陷总权值除以测试功能总权值，主要查看版本是否趋于稳定情况，通过数据图表等方式来衡量版本交付的风险大小，是衡量版本是否可交付的重要依据之一。另一种算法：缺陷密度=缺陷数量/代码行2.3.1使用背景适用于系统测试或者测试周期超过两星期以上，如果缺陷密度逐渐收敛，说明版本逐渐稳定；如果趋势起伏不定，需要分析研究原因，查找不稳定的原因；如果缺陷密度趋势呈波状，一定要重视起来，说明版本及其不稳定，确认发布时要慎重。2.3.2计算方式缺陷密度=缺陷总权值/功能总权值缺陷总权值计算方法 = Sum（缺陷数*该缺陷等级的权值）等级权值阻塞-阻塞开发或者测试工作进度，或影响系统无法正常运行10致命-系统崩溃，

6、丢失数据或内存溢出等严重错误5严重-主要功能或业务无效3一般-系统功能部分无效1普通-拼写错误，文本未对齐，数据长度格式校验等0.5功能权值计算方法跟缺陷权值计算方法类似，项目经理根据各个功能模块的复杂度拟出每一个模块权值，为了对不同项目缺陷密度的可比性，不同项目的功能权值要求要基本大致相同。2.3.3数据来源测试管理工具2.3.4计算结果可通过导出表格、分析图形的方式来度量结果版本序号测试版本（日期）缺陷总权值功能总权值缺陷比率（缺陷总权值/功能总权值12020.12.55214.2 22020.12.89222.4 32020.12.1218241.3 42020.12.1423261.1

7、 52020.12.1723251.1 62020.12.1827271.0 72020.12.1927140.5 82020.12.2033140.4 92020.12.2133160.5 102020.12.223390.3 112020.12.253380.2 趋于收敛的缺陷密度图：起伏不定的缺陷密度图：2.4最近提交缺陷指标分析2.4.1使用背景适用于系统测试中各测试阶段缺陷情况查看及分析。2.4.2参考指标缺陷创建数量缺陷解决数量缺陷关闭数量2.4.3数据来源测试管理工具分析：5月26日左右大范围更新了修正版本后继续测试，缺陷出现增长趋势，说明期间版本仍不稳定。缺陷累计较多，导致测试

8、人员回归工作量加大，于5月30日突击完成缺陷回归。2.5累计创建缺陷与累计解决缺陷指标分析2.5.1使用背景：适用于系统测试，或测试周期超过两星期测试项目的缺陷情况查看及分析。2.5.2参考指标缺陷创建累计数量缺陷解决累计数量2.5.3数据来源测试管理工具情况一：缺陷累计数随日期的增加还在持续的快速增长，并且红色曲线斜率多处区域大于45，说明产品仍存在较多缺陷，质量并没有稳定下来。两条曲线斜率多处区域均大于45，说明测试和开发的效率都还是不错，反之说明效率比较低。因为质量还没有稳定，所以项目测试暂时不能被关闭。情况二：两条曲线之间的间距越来越小，且红色曲线的斜率趋于平缓，说明质量越来越稳定，且

9、可以预见两条曲线有交织的可能性，可以考虑关闭项目测试。情况三：两条曲线之间的间距越来越大，且红色曲线斜率并没有放缓趋势。说明产品质量比较差，需要及时做出修改和调整，使产品质量相对稳定下来。情况三：两条曲线之间间距稳定，但是曲线斜率趋于平缓。说明开发遇到了技术挑战，效率开始降低。由于模块不能及时发布，同时也影响了测试效率。3测试过程质量指标3.1需求覆盖率计算测试用例总数之和除以与之对应的测试需求点数之和，主要查看是否有功能点遗漏测试的情况。3.1.1使用背景需求覆盖的程度，在测试粒度较细的模式下，有可能实现100%的覆盖指标，这并不意味着系统被完全测试。因为对每个需求的测试用例设计可能不是完全

10、覆盖的，或者需求的信息不全面。该指标是在测试粒度较粗的模式下，查看是否有需求遗漏情况3.1.2计算方式需求覆盖率=有效测试用例个数/有效测试需求个数（只计算到100%）有效测试用例数=测试用例总数-无效用例总数无效用例总数包含：需求功能点关闭、用例编写错误、未完成需求的用例数？有效测试需求个数：项目-需求矩阵文档统计的数据需要讨论：未完成需求的用例数是否计算到无效用例数中？3.1.3数据来源系统-需求分析报告、项目-需求跟踪文档、项目-需求矩阵文档、项目-测试用例3.2用例执行覆盖率计算测试用例执行总数除以与之对应的测试数之和，主要查看测试用例执行情况，是否有遗漏。3.2.1使用背景系统测试或

11、者测试周期超过两星期以上，测试执行覆盖率达到100%。冒烟测试，BVTs（Build Verification Tests）级别测试用例执行覆盖率达到100%。回归测试、小版本发布测试被测试模块用例执行覆盖率达到100%或者高级别测试用例执行覆盖率达到100%？。3.2.2计算方式用例执行覆盖率=执行的测试用例个数/有效测试用例个数*100%3.2.3数据来源测试管理工具、项目-测试用例3.3测试用例的有效性评价测试用例的有效性，判断是否需要提高测试用例的设计要求3.3.1使用背景适用于任何测试类型3.3.2计算方式测试用例的有效性=用例发现缺陷数/总缺陷数3.3.3数据来源测试管理工具、项目

12、-测试用例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数据来源测试管理工具。