软件测试质量评估方法讨论稿
当前我们的软件测试质量评估主要考虑测试设计、测试执行两个方面，在测试过程中加入检查点进行监督，避免项目后期对项目的进展产生影响。 一、
测试设计
测试设计主要指测试用例，其衡量方法采用事后追溯法，通过所有的测试发现的缺陷来评估测试设计质量。测试用例效率度量表如下： No 测试用例总数 缺陷 40 有测试用例对 35 无测试用例对测试用例缺陷覆应的缺陷数 5 盖度 35/40=87.5% 总数 应的缺陷数 备注 1 104 二、
测试执行
? 每轮测试缺陷探测效率分析
在软件完成一轮完整测试后、或者在某个版本的测试后发现bug曲线有异常抬高，需要对该轮所发现所有缺陷进行历史版本追溯分析，主要有以下几情况分类： No 1 2 3 4 5 说明：
1. 对于1、2需要进行相关文档补充和更新，保证后续测试的全面性； 2. 对于3则属于个人问题，保证后续测试中避免该问题的发生； 3. 对于4则属于正常现像；
4. 对于5，则看实际导致的问题的数量，及后续bug曲线的收敛程度来确认开发人员所提交测试版本的质量。 ? A/B角互测验证
1. 其本质也是确认缺陷探测效率，但通过B角去实现。在项目的某个测试阶段加入B角进行一轮全面或局部测试，通过其发现的问题来确定当前软件的测试质量。由于项目真正测试过程中的测试思路和测试用例需要不断更新，这样才能保证测试的全面性，如果发现统计数据异常能及时调整；
2. 在测试计划中添加A/B角的定义及B角参与的阶段；并在该阶段的测试报告中体现；
3. Alpha测试用户为自然B角，对Alpha测试过程中所发现的问题均要进行分析。 不存在 历史版本是否存在该缺陷 存在 原因分析 测试方案未包含 测试用例未包含 测试未执行 新问题 修复缺陷导致的新问题 改进措施 更新方案 补充测试用例 加强测试 新功能或功能升级产生的 精选文库
已完成需求用例测试覆盖率达100%本阶段是否完成一轮全面测试当前项目千行bug率是否符合历史经验数据bug曲线的收敛状态遗留bug数量及类别符合通过标准测试阶段性软件质量软件质量量化待发布软件
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)是最简单的路线，这个周期越短，说明项目进展越顺利反之则意味着项目进度目前有很大的阻碍。
需求用例测试覆盖率达100%系统测试是否完成一轮完整测试项目千行bug率是否符合历史经验数据bug曲线在最后系统测试阶段完全收敛Alpha用户测试发现问题的严重度( 精选文库 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的总数，这个指标体现测试人员在需求熟悉阶段对需求透析程度，透析度越深往往对促进需求精致化的贡献度越大，对测试用例的有效性的贡献也越大。我们毕竟不希望到了测试执行阶段才来不停的质疑需求这里有问题那里有问题。 -- 3 精选文库 评估软件质量的标准不是绝对的，是相对的。一个软件的质量特性包括：功能，性能，安全性，易用性，可靠性，可维护性，可移植性等，还有一些行业特性。而让这些特性达到什么样的指标，则是根据用户的需求来规定的。软件测试就是要验证软件的这些特性与需求的符合程度，符合程度越高表明质量就越好。 所以个人认为量化的依据应该包括： 1.测试用例的密度--用例密度直接影响bug的数量和严重级别 2.测试用例覆盖率--因为覆盖率很小发现的bug很少时能说明质量很好吗？ 3.bug数量--用户使用过程中出现很多bug，用户一定是不会再认可这个软件了 4.bug的严重级别--严重的bug会使用户无法使用软件更别说能接受这个产品了 软件质量的量化评估就是所有数据的整合,经过对数据的加工得到的数据便是软件的质量级数。 具体数据包含以下几个：1.功能实现率，2.性能达标率，3.测试覆盖率（功能，性能，压力等等），4.BUG质量，5.BUG的CLOSE质量，6.客户试用满意度，7.员工工作效率，等几个方面的数据。各项数据按其在项目中的重要级别对数据进行+-*/运算，最后得到的数据便是软件的质量级数。 楼上几位前辈写的很好，吸收ING 1、软件需求规格说明书的功能点尽可能的量化； 2、测试用例设计要通过评审，要求需求覆盖率达100％； 3、查看缺陷分别按时间的趋势图、按模块的饼状分布图，按时间的趋势图是否是下降的趋势，按模块的分 布图可以发现缺陷集中的相关模块； 4、完成系统的性能、安全、易用性等其他隐式需求的测试； 5、测试用例的执行覆盖率要达到100％； 6、程序代码语句覆盖率不低于80％； 7、缺陷修复率情况： 1) 致命、严重的缺陷修复率要达到100％以上； 2) 一般不太严重的缺陷修复率要达到80％以上； 3) 易用性不影响系统应用的缺陷修复率达到60％以上； 8、系统通过需求人员的确认测试，系统满足需求规格说明书的说明。 同意 3# cityyard 按bug的统计进行评估量化，实际工作中，我们也是这样执行的。 另外，我们还从test case的执行情况进行统计，如每一轮测试，会统计其test case的执行率、成功率、 失败率等作为参考 软件版本release后，要看客户的反馈情况，为release的版本打patch的数量 从整个项目或产品角度看，还要考核被测试的软件能否及时release. 从我所在的公司的情况看，评估一个被测软件的质量主要是从三个方面来进行。 1：系统的性能。这其中包括了系统的稳定性，运行时的速度，安全性等。即，性能稳定，运行时，不报错，不因数据量过大而造成速度慢，死机之类的原因。 2：后期提交的bug数量及等级。即，在软件开发、测试的后期，提交的bug数量越少，严重程度越低，这 -- 4 精选文库 个软件的质量就越好。当然，在bug数量和质量上是不可以造假的。呵呵 3：user acceptance testing中返回的bug数量和其他的意见。即，用户在UAT测试过程中发现的bug数量越少，对系统的其他建议越少，这个软件质量就越好。 软件质量如何评估？ 我们公司软件质量的评估，首先要看测试出来的问题等级和数量，另外重要的是客户的使用情况，不过我想公司现状和软件的现状无法制定出一个更好的评估标准。下面谈一下我个人的想法： 首先，需求的覆盖率是软件质量的根基，这就要求我们对需求的管理非常规范 其次，在软件各个阶段出现的bug情况（单元、集成、系统），是软件质量的表现 最后，客户验收测试的满意程度，这个不应该用BUG的数量来衡量，应该以客户的实际反应状况为标准，因为客户提出的不一定是软件的质量有问题，而是从客户的使用情况来说明软件是不是适合客户使用 软件不外乎是为了实现某个功能而实现的一段代码，所以我认为衡量软件的质量，最关键的是测试case覆盖率。case的覆盖当然需要是多个方面的，最基本的是：性能、功能、安全、易用性，由于软件需要不断升级和维护，同时很重要的还包含：可移植性、可维护性。以上每个方面的case都有覆盖到，且case都能通过的话，就说明这个软件具有很高质量了。 当然case的覆盖，需从两方面出发，一方面是：客户的需求；另一方面是：系统开发的结构。这样的case才能尽可能的保证覆盖的完整。所以现在很多测试管理软件，类似：TD,TM等...都有把case跟需求关联起来，统计覆盖率，不过我认为这还是不够的，这个只是能统计到case覆盖需求的覆盖率，但是实际还有一部分case，跟需求没有直接关系，是系统结构设计引起的，这部分如果也能纳入关联管理，就很好了！ 另外谈一下对bug的是否能够衡量软件质量的看法把，我个人觉得这个可以做个参考，但是不能作为重要依据。因为bug的来源跟开发人员、测试人员、架构设计人员、需求调研人员有很大的，而且直接的关系，作为评价质量的量化依据不太客观。 以上是我的看法，供参考... 我们公司现在也在做这一块的内容。 其中我想的是首先我们要区分，量化的目的是什么？ 是同级产品之间做比较，还是单纯分析一个产品的质量好外？ 如果是同级产品之间做比较，那必须需要度量软件的规模。 度量软件规模了之后，才可以再量化相应的评估数据出来。 评估软件质量的标准不是绝对的，是相对的。一个软件的质量特性包括：功能，性能，安全性，易用性，可靠性，可维护性，可移植性等，还有一些行业特性。而让这些特性达到什么样的指标，则是根据用户的需求来规定的。软件测试就是要验证软件的这些特性与需求的符合程度，符合程度越高表明质量就越好。 所以个人认为量化的依据应该包括： -- 5
软件质量量化指标
