如何量化评估被测试软件的质量？（08-03-07）（获奖名单已公布）

51testing

在测试过程中，我们需要根据各种度量数据从不同角度来对被测软件的质量进行分析评估，找出软件的质量薄弱点、评价软件发布的风险、预估软件测试结束的时间等等，这些分析评估涉及到各种角度、不同指标，也有一些从工程中总结的分析模型，欢迎大家踊跃讨论，分享各自在工作中所使用的评估方法，共同进步。

非常感谢各位会员积极参与，截止至3月14日１７：３０分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在下周内送出。

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	charles	当当购物卡50元	31#
二等奖	cityyard	300论坛积分	3#
三等奖	lzz	100论坛积分	8#

houzeal

受益匪浅

godn_1981

大家说的非常好~~~~~~~真的学到不少东西

lovemiya

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

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

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

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

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

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



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

冷ヅ漠然

  测试结束标准定位的高低就是对软件质量的量化评估哇？

51testing

原帖由 lucky_snow 于 2008-3-31 13:56 发表
获奖名单有错误：charles     32#
charles  是  31#
sense    是 32#

谢谢纠错，已更改了．

lucky_snow

获奖名单有错误：charles     32#
charles  是  31#
sense    是 32#

wudamyw

从产品本身，以技术来说那就复杂了。其实很简单，能满足客户需要就是好质量的软件，无论是否存在多少bug。比如播放软件的play功能，如果说连续快速点击playbutton，程序会挂掉。这问题从技术来说很严重，同时他属于极限压力测试，一般用户是不会发现的。

54111

同意楼上说的，确实像 测试结束标准

huior

本周的题目不是“量化评估”“软件质量”吗？
怎么看获奖答案都象是在回答“测试的结束标准”，呵呵

DU_anjel

不知道软件测试是否已建立了质量标准体系??类似国际标准ISO

感谢前辈们,新手的我学习了...
.

naotang

首先是需求需要量化：
   a、有功能的规格列表以及每个功能的重要级别,市场定位等。
   b、给出性能指标。
根据以上信息,定义产品的完成标准及质量,首先在客户层定义好质量标准.

下面就是根据测试情况定义,更多的是测试人员自己的理解与定义：
1、产品所运用技术的可扩展性、可移植性、安全性，当然这个跟产品的定位有关。
2、重要功能是否全部实现，就算存在问题，是否有规避措施。次要功能在要求上可以低些。
3、性能是否达到预期结果，就算没达到，是否能满足当前的市场。
当然上面的结果取决于你测试列表的覆盖度及深度。

[ 本帖最后由 naotang 于 2008-3-14 17:43 编辑 ]

sense

评估被测软件质量可分为从内部、外部看两方面，内部评价软件质量时多用功能、可靠性、可用性、可维护性、可移植性、性能等多个衡量指标，但不同的软件衡量质量的指标权重是不一样。WEB应该更看重功能、安全、性能，应用程序偏重于功能、可用性、可维护性等方面。
功能性看程序对用户需求的覆盖率，但超出用户需求的部分不一定是好的，从BUG定义的角度来看，也是一种缺陷。
可靠性看程序能无故障运行时间、容错、可恢复、安全性等，与需求初始定义去比较。
可用性看程序的设计是否符合用户场景中的使用习惯，是否方便用户的操作，是否是用户操作的最快捷步骤。
可维护性是指工程实施时是否方便，维护基础数据方便，能快速解决用户维护方面的问题。
可移植性是指能否支持多个平台的使用，各平台、版本之间是否有快速切换的解决方案。
性能是否满足客户需求，能否满足不断增长的数据量和用户量，而程序的性能不下降。
从外部看，一般从用户验收测试、使用过程中的BUG反馈来评价质量。
用户验收是从用户的角度去看程序是否实现既定的需求，是否满足他们工作场景中的使用习惯，操作是否方便等多方面，可以设计问卷，调查结果的分值可以体现用户对软件质量的评价。
使用过程中的BUG反馈，是指用户购买软件后，在使用的过程中发现的BUG量，可以与公司内部发现的BUG进行对比，这个比值可以来衡量软件的质量，同时也可以衡量软件测试的质量。具体的衡量值可以根据不同的软件项目、产品经验来设定。

charles

1、软件需求规格说明书的功能点尽可能的量化；
2、测试用例设计要通过评审，要求需求覆盖率达100％；
3、查看缺陷分别按时间的趋势图、按模块的饼状分布图，按时间的趋势图是否是下降的趋势，按模块的分布图可以发现缺陷集中的相关模块；
4、完成系统的性能、安全、易用性等其他隐式需求的测试；
5、测试用例的执行覆盖率要达到100％；
6、程序代码语句覆盖率不低于80％；
7、缺陷修复率情况：
      1)  致命、严重的缺陷修复率要达到100％以上；
      2) 一般不太严重的缺陷修复率要达到80％以上；
      3) 易用性不影响系统应用的缺陷修复率达到60％以上；
8、系统通过需求人员的确认测试，系统满足需求规格说明书的说明。

huior

好像本周回答问题的朋友比较少哦！不过这个问题的确不太好回答，问题比较发散！
我的回答
http://www.51testing.com/?10851/ ... e_itemid_76932.html

lichao_lc4

各种软件的衡量指标不同，偏重点不同，我认为软件只要达到各自的标准就可以了。

guansnow

量化主要有两个目的：1.确定问题以便解决问题。
                    2.与可替换的产品进行比较，或对照需求比较产品质量。
如果，标度分两类是满意/不满意；
      标度分为四类是：超出要求，目标范围，可接受的最低限度，不可接受。

tdj602

学习，学习


评估软件质量：
1.最大限度满足了用户的需求
2.符合软件质量模型项
3.能应变不断的需求变更

[ 本帖最后由 tdj602 于 2008-3-13 19:02 编辑 ]

87950461

软件质量的量化评估就是所有数据的整合,经过对数据的加工得到的数据便是软件的质量级数。
具体数据包含以下几个：1.功能实现率，2.性能达标率，3.测试覆盖率（功能，性能，压力等等），4.BUG质量，5.BUG的CLOSE质量，6.客户试用满意度，7.员工工作效率，等几个方面的数据。各项数据按其在项目中的重要级别对数据进行+-*/运算，最后得到的数据便是软件的质量级数。
楼上几位前辈写的很好，吸收ING

[ 本帖最后由 87950461 于 2008-3-14 09:20 编辑 ]

hehekouke

大家说的都好棒哦！
吸收ing……