文档介绍：软件质量量化指标
软件测试质量评估方法讨论稿
当前我们的软件测试质量评估主要考虑测试设计、测试执行两个方面，在测试过程中加入检查点进行监督，避免项目后期对项目的进展产生影响。
测试设计
测试设计主要指测试用例，其衡量方法采用事后追溯法，通过所有的测试发现的缺陷来评估测试设计质量。测试用例效率度量表如下：
No
测试用例总数
缺陷总数
有测试用例对应的缺陷数
无测试用例对应的缺陷数
测试用例缺陷覆盖度
备注
1
104
40
35
5
35/40=%
测试执行
每轮测试缺陷探测效率分析
在软件完成一轮完整测试后、或者在某个版本的测试后发现bug曲线有异常抬高，需要对该轮所发现所有缺陷进行历史版本追溯分析，主要有以下几情况分类：
No
历史版本是否存在该缺陷
原因分析
改进措施
1
存在
测试方案未包含
更新方案
2
测试用例未包含
补充测试用例
3
测试未执行
加强测试
4
不存在
新功能或功能升级产生的新问题
5
修复缺陷导致的新问题
说明：
对于1、2需要进行相关文档补充和更新，保证后续测试的全面性；
对于3则属于个人问题，保证后续测试中避免该问题的发生；
对于4则属于正常现像；
对于5，则看实际导致的问题的数量，及后续bug曲线的收敛程度来确认开发人员所提交测试版本的质量。
A/B角互测验证
其本质也是确认缺陷探测效率，但通过B角去实现。在项目的某个测试阶段加入B角进行一轮全面或局部测试，通过其发现的问题来确定当前软件的测试质量。由于项目真正测试过程中的测试思路和测试用例需要不断更新，这样才能保证测试的全面性，如果发现统计数据异常能及时调整；
在测试计划中添加A/B角的定义及B角参与的阶段；并在该阶段的测试报告中体现；
Alpha测试用户为自然B角，对Alpha测试过程中所发现的问题均要进行分
    一个bug的生命历程是一个完整的轮回，从他出生(open)开始，到调查(Accept)到修复(Fix)，再到确认(Verify)是最简单的路线，这个周期越短，说明项目进展越顺利反之则意味着项目进度目前有很大的阻碍。
    6 降级bug数
    降级bug的多少对于软件质量评估也是一个重要参考标准，降级bug也就是由于修正一个bug又作了一个新bug，降级bug数目过多意味着现在的产品在越修越坏。一个新的QA团队，在2，3，4，5，6步骤可能会有所迷惑，不知道阈值应该怎样选但如果每次都坚持这样做，很多次之后2，3，4，5，6会给这个团队大量的经验积累，完全可以做到看着统计图估计出一个产品处于什么状态，需要加强哪些方面等等。
上这些度量项，对于测试管理者来说应该都不陌生，全部整理到一起，真的还是蛮齐全的了。测试品质保证的乐趣，其实很多就在这些关键度量元素间。其一，这样的分析显然是颇具科学意义的，统计学嘛；其二，真正能通过管理这些度量项达到提高质量的效果，那是一件很美妙的事情。我个人而言，比较有实用感触的是1，2，3，5，15这几项。
1---客户反馈缺陷，即漏测。其实这是一个很直观的质量保证结果，本人非常崇尚用这个指标衡量测试人员的结果绩效。虽然漏测的