软件质量量化指标

软件测试质量评估方法讨论稿

当前我们的软件测试质量评估主要考虑测试设计、测试执行两个方面，在测试过程中加入检查点进行监督，避免项目后期对项目的进展产生影响。

一、测试设计

测试设计主要指测试用例，其衡量方法采用事后追溯法，通过所有的测试发

二、测试执行

●每轮测试缺陷探测效率分析

在软件完成一轮完整测试后、或者在某个版本的测试后发现bug曲线有异常抬高，需要对该轮所发现所有缺陷进行历史版本追溯分析，主要有以下几情况分

说明：

1.对于1、2需要进行相关文档补充和更新，保证后续测试的全面性；

2.对于3则属于个人问题，保证后续测试中避免该问题的发生；

3.对于4则属于正常现像；

4.对于5，则看实际导致的问题的数量，及后续bug曲线的收敛程度来确认开

发人员所提交测试版本的质量。

●A/B角互测验证

1.其本质也是确认缺陷探测效率，但通过B角去实现。在项目的某个测试阶段

加入B角进行一轮全面或局部测试，通过其发现的问题来确定当前软件的测试质量。由于项目真正测试过程中的测试思路和测试用例需要不断更新，这样才能保证测试的全面性，如果发现统计数据异常能及时调整；

2.在测试计划中添加A/B角的定义及B角参与的阶段；并在该阶段的测试报告

中体现；

3.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会给这个团队大量的经验积累，完全可以做到看着统计图估计出一个产品处于什么状态，需要加强哪些方面等等。

上这些度量项，对于测试管理者来说应该都不陌生，全部整理到一起，真的还是蛮齐全的了。测试品质保证的乐趣，其实很多就在这些关键度量元素间。其一，这样的分析显然是颇具科学意义的，统计学嘛；其二，真正能通过管理这些度量项达到提高质量的效果，那是一件很美妙的事情。我个人而言，比较有实用感触的是1，2，3，5，15这几项。

1---客户反馈缺陷，即漏测。其实这是一个很直观的质量保证结果，本人非常崇尚用这个指标衡量测试人员的结果绩效。虽然漏测的原因不单单在于测试的疏忽，但终究能在很大程度上体现测试的质量。且通过对这个指标的线性观察，发现一些潜在的可能在未来会反馈回来的问题，我们还能亡羊补牢，出补丁提前堵漏。

2---模块缺陷密度。往往找到缺陷最多的地方也是潜在缺陷最多的地方。这个规律几乎是千真万确。就跟越是担心会出问题的时候一般都是会出问题的，类似。这个在测试过程中或者发布之后拿来分析都很有意义。

3---遗留缺陷。仅仅看一个绝对的数字并无太大意义，它的意义在于与之前拟定的交付标准做比对，假若在标准之内就放行，不在标准之内那就卡住。另外，被允许的遗留缺陷一般也是下一阶段启动任务之时开发任务的首要任务之一。

5---趋势分析。这是一个质量活动如期完成的强力证明工具，当然要真正看到收敛才对。

15--测试用例有效率。这个指标更大意义的是规范测试活动，其次才是提高测试用例的质量。想要统计出有效率，有个前提就是测试集驱动测试，即你开展每一轮测试之前，根据测试需求建立好测试集，并且集里面的测试用例也都已经确定好，之后照着逐一测试。很多测试人员说测试用例只不过是我用来熟悉需求的产物，等我拿到被测对象，我根本就不看测试用例就刷刷的往下测。殊不知，人的记忆往往是有漏洞的，当你脱离测试用例来测试，你就是在走向随机测试，大家想想随机的活动有没有可把握性？

简单评论之后，我再加一个度量项，尤其是在这提倡测试先行的年代。---需求review阶段发现的需求issue 数/整个测试过程中发现的需求Issue的总数，这个指标体现测试人员在需求熟悉阶段对需求透析程度，透析度越深往往对促进需求精致化的贡献度越大，对测试用例的有效性的贡献也越大。我们毕竟不希望到了测试执行阶段才来不停的质疑需求这里有问题那里有问题。