呵呵
量化评估么
给实际最终用户试用让他打分(alpha测试...)

我不否认数据积累的重要性
但是我认为数据积累的目的并不是为了能够自己对自己开发的系统进行评估
而是为了更有效地进行量化管理

我们公司现在也在做这一块的内容。
其中我想的是首先我们要区分，量化的目的是什么？
是同级产品之间做比较，还是单纯分析一个产品的质量好外？
如果是同级产品之间做比较，那必须需要度量软件的规模。
度量软件规模了之后，才可以再量化相应的评估数据出来。

评估软件质量的标准不是绝对的，是相对的。一个软件的质量特性包括：功能，性能，安全性，易用性，可靠性，可维护性，可移植性等，还有一些行业特性。而让这些特性达到什么样的指标，则是根据用户的需求来规定的。软件测试就是要验证软件的这些特性与需求的符合程度，符合程度越高表明质量就越好。

    所以个人认为量化的依据应该包括：
    1.测试用例的密度--用例密度直接影响bug的数量和严重级别
    2.测试用例覆盖率--因为覆盖率很小发现的bug很少时能说明质量很好吗？
    3.bug数量--用户使用过程中出现很多bug，用户一定是不会再认可这个软件了
    4.bug的严重级别--严重的bug会使用户无法使用软件更别说能接受这个产品了

[ 本帖最后由 wuyunga 于 2008-3-13 13:21 编辑 ]

所谓系统应该包括数据、软件和文档，作为评估是不是应该从流程实现和控制上来进行判断，不单只看软件的bug。还应考虑数据和文档的正确性，以及过程执行中的评审的正确性！

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

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

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

学习，学习


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

引用:

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

谢谢纠错，已更改了．

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