软件测试质量度量指标

软件测试质量度量指标

度量模块	度量指标	统计方法	度量说明
产品完成度	1.需求通过率	（已通过需求/已计划需求）	体现需求的完成度。也常可以统计为（测试用例通过数/计划的测试用例总数），即默认用例覆盖是完全的。
	2.功能点通过率	（已通过功能点/已测试功能点）	同上，当需求规模比较大时，功能点统计会更有价值。难点在于，需求功能点需要有额外的过程进行确认，一般在测试分析阶段统计拆分功能点。
	3.风险规避情况	（已规避风险/已预估风险）	产品已知风险的应对情况，需要风险分析过程的支持
产品质量	4.测试通过率	（已执行测试数/已计划测试数）	比较直观的数据，通过测试的通过率来衡量产品质量
	5.缺陷密度	（缺陷总数/千行代码数）	缺陷密度对于产品质量而言是非常直观有价值的。但由于千行代码数这一度量并不多用，对测试而言也可能获取存在难度，所以经常可以转化为（缺陷总数/功能点数）*100%；或者（缺陷总数/对应模块）（缺陷分布率）。
	6.缺陷严重级别分布	（对应严重级别缺陷数/缺陷总数）	缺陷的数量并不能总是体现出产品实际质量，比如最严重级缺陷过多显然是一个问题。所以缺陷统计应该体现数量和严重级别的二维分布。
	7.缺陷类型分布	（对应类型缺陷数/缺陷总数）	通过对应缺陷类型分布比例来衡量软件某一方面的质量。
	8.缺陷模块分布	（对应模块缺陷数/缺陷总数）	通过对应缺陷模块分布比例来衡量软件个模块的质量。
	9.缺陷修复率	（已修复缺陷数/缺陷总数）	缺陷已被修复的比例统计。
测试完成度：	10.用例覆盖率	（已设计用例数/计划设计用例数）	用于监控测试设计的进度情况。计划设计用例数这一数字比较模糊可能来自估算。可以采用自下而上的方式收集：即让模块测试负责人进行局部数据收集，再汇总统计。
	11.测试执行率	（已执行的测试数/计划执行的测试数）	测试已被执行的情况，用于测试进度跟踪。执行率并不关注测试失败情况。进一步细化可以展开统计测试通过、失败、阻塞和未执行的比率。
	12.测试通过率	（已通过测试数/计划执行的测试数）	测试通过比率。
研发过程质量：	13.缺陷生存周期	（缺陷生存总时长/缺陷数）	通过统计缺陷从打开到关闭的平均时长，衡量研发团队的缺陷修复能力。
	14.测试用例命中率	（缺陷数量/用例数量）	通过用例发现的缺陷数量统计，衡量测试设计的有效性。
	15.二次故障率	（缺陷二次重开数量/缺陷总数量）	缺陷多次重开会造成缺陷修复周期拉长，说明1.开发修复缺陷能力存疑2.测试团队缺陷质量存疑3.开发测试之间沟通效率存疑。需要具体分析。
	16.缺陷有效率	（有效缺陷数量/缺陷总数量）	测试团队提交的缺陷有多少比重是有效缺陷。应该就具体缺陷失效原因进行分析。
	17.缺陷探测率	（某测试级别发现缺陷数/（总体缺陷数+交付后新增缺陷数））	用于衡量某一测试级别的有效性。比如单元测试有效性。
	18.缺陷移除率	（缺陷当阶段移除数量/当阶段引入缺陷数量）	用于统计研发某阶段的缺陷数量和在当阶段被解决的比例，实际是测试尽早介入的体现。比如需求中的缺陷需要在当阶段通过需求评审等手段探测并解决。此数据统计起来有一定难度。
	19.测试依据稳定性	（由需求变更引发的新增、修改测试用例数/总用例数）	体现测试依据，需求文档的稳定度和质量。需求不稳定，则会对测试工作产生比较大的冲击。
计划偏离度量	20.工作量偏离	（（实际工作量-计划工作量）/计划工作量）	用于衡量计划的合理度，是否有大量计划外工作未被纳入估算当中。
	21.工作进度偏离	（已超出计划进度的时间）	通过统计工作进度的偏离来揭示项目时间风险。
	22.预算使用比例	（已花费测试预算（人/天）/计划总测试预算）	用于计算测试预算的花费情况。
	23.问题等待时间	（具体问题等待解决时间）	等待时间通常难以被计划，通过计算等待时间可以帮助衡量项目瓶颈所在，并为后续项目组织提供思路。可细化为需求等待时间，测试阻塞时间等。
产品质量趋势	24.缺陷到达率	（缺陷数量/时间周期）	周期性的缺陷报出数量，比如月缺陷到达率，周缺陷到达率。通过持续时间的到达率监控，可以体现项目产品的趋势。
	25.缺陷收敛度	（缺陷遗留数量/时间周期）	通过统计遗留缺陷随时间推移的趋势，判断后续产品质量的走向。理想情况下，单迭代周期内缺陷数量经过集中爆发后，应呈持续走低态势。
	26.缺陷引入率	（新增缺陷数量/新增千行代码数）	用以衡量产品的增量和修改对于质量的影响，也为后续产品的更新迭代提供参考指标。