软件质量量化指标.docVIP

软件测试质量评估方法讨论稿 当前我们的软件测试质量评估主要考虑测试设计、测试执行两个方面，在测试过程中加入检查点进行监督，避免项目后期对项目的进展产生影响。 测试设计 测试设计主要指测试用例，其衡量方法采用事后追溯法，通过所有的测试发现的缺陷来评估测试设计质量。测试用例效率度量表如下： No 测试用例总数 缺陷总数 有测试用例对应的缺陷数 无测试用例对应的缺陷数 测试用例缺陷覆盖度 备注 1 　104 　40 　35 　5 35/40=87.5% 　 测试执行 每轮测试缺陷探测效率分析 在软件完成一轮完整测试后、或者在某个版本的测试后发现bug曲线有异常抬高，需要对该轮所发现所有缺陷进行历史版本追溯分析，主要有以下几情况分类： No 历史版本是否存在该缺陷 原因分析 改进措施 1 存在 测试方案未包含 更新方案 2 测试用例未包含 补充测试用例 3 测试未执行 加强测试 4 不存在 新功能或功能升级产生的新问题 5 修复缺陷导致的新问题 说明： 对于1、2需要进行相关文档补充和更新，保证后续测试的全面性； 对于3则属于个人问题，保证后续测试中避免该问题的发生； 对于4则属于正常现像； 对于5，则看实际导致的问题的数量，及后续bug曲线的收敛程度来确认开发人员所提交测试版本的质量。 A/B角互测验证 其本质也是确认缺陷探测效率，但通过B角去实现。在项目的某个测试阶段加入B角进行一轮全面或局部测试，通过其发现的问题来确定当前软件的测试质量。由于项目真正测试过程中的测试思路和测试用例需要不断更新，这样才能保证测试的全面性，如果发现统计数据异常能及时调整； 在测试计划中添加A/B角的定义及B角参与的阶段；并在该阶段的测试报告中体现； Alpha测试用户为自然B角，对Alpha测试过程中所发现的问题均要进行分析。 IT168 分析评论】 ??? 软件质量的量化评估，最重要的一点是经验。同时科能需要大量统计工作作为铺垫。 ??? 下面我主要从bug统计来说一下我的经验。 ??? 1 测试项目数和摘出bug数预测 ??? 一般来说我们可以根据软件代码行数来粗略估计一个产品可能包含的bug数目和需要的测试项目。现在有些公司流行每千行bug数的标准来制定测试计划，这个标准是通过以往测试经验总结出来的， ??? 一般来说，同类的产品，尤其是同一个开发流程的产品，这些数值不应该相差太多，如果相差一个数量级以上，我们几乎可以说，要么是QA出问题了，要么是开发出问题了。 ??? 2 测试bug分级 ??? 使用bugzilla或者Jira之类的缺陷管理系统何以很容易的实现bug分级，一般至少有Fatal, Major, Minor, cosmatic这几种，还有一种特殊的叫做blocker，意思是这个bug会影响测试进度。产品发布前，可以根据实际情况，定一个界限级别，比如要求新出Major为0，并且所有已有的Major全部close。 ??? 3 测试bug收敛 ??? 量化评估必不可少的是bug收敛，这个要通过统计每日新出bug并跟踪已有bug制作收敛曲线来实现。收敛曲线的形状发散表明目前产品极其不稳定，收敛曲线开始收敛表示目前产品趋于稳定，完全收敛之后可以认为是发布的时机。 ??? 4 测试bug分布 ??? bug分布是决定下面测试重点的一个重要的参考数据。首先还是需要统计，找出所有已有的不同级别的bug在各个模块的分布，假如ABC三个模块，A模块占了bug的60%，C模块占了bug的8%那么，我们可以得出这样的结论，软件的不稳定瓶颈在于A模块，是一个薄弱点，需要开发人员集中力量对应。但是C模块也是一个可疑模块，因为出现bug率太低，如果不是开发的太好就是测试方法不当。 ??? 5 测试bug的周期 ??? 一个bug的生命历程是一个完整的轮回，从他出生(open)开始，到调查(Accept)到修复(Fix)，再到确认(Verify)是最简单的路线，这个周期越短，说明项目进展越顺利反之则意味着项目进度目前有很大的阻碍。 ??? 6 降级bug数 ??? 降级bug的多少对于软件质量评估也是一个重要参考标准，降级bug也就是由于修正一个bug又作了一个新bug，降级bug数目过多意味着现在的产品在越修越坏。一个新的QA团队，在2，3，4，5，6步骤可能会有所迷惑，不知道阈值应该怎样选但如果每次都坚持这样做，很多次之后2，3，4，5，6会给这个团队大量的经验积累，完全可以做到看着统计图估计出一个产品处于什么状态，需要加强哪些方面等等。 上这些度量项，对于测试管理者来说应该都不陌生，全部整理到一起，真的还是蛮齐全的了。测试品质保证的乐趣，其实很多就在这些关键度量元素间。其一，这样的分析显然是颇具科学意义的，统计学嘛；其二，真正能通过管理这些度量项达到