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

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

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

这个问题我理解起来很是费劲，软件评价标准需要考虑的方面很多啊。

坐个沙发，提供一下我在工作中用到的一些评价评估指标吧。

1、根据软件的规模的进行初步划分：大型软件、中型软件、小型软件
2、根据软件的在整个系统中的等级进行初步划分：关键软件、重要软件、一般软件、辅助软件
3、根据对软件影响的程度进行bug等级的划分：关键缺陷、严重缺陷、一般缺陷、建议改进
4、根据软件测试周期和工作结点来划分：提前完成、按时完成、项目滞后、项目中断

评价软件质量的原则就是上面四种划分的组合，从而得到一个相对完整的质量评价。
组合标准是明确软件的类型和软件的重要度，然后对bug的分布进行统计。
如果关键缺陷的概率过高，那么这个软件可以说已经不用进行评价了。
然后是根据这个软件的测试周期进行评价，过多的中断或者长时间的项目滞后也不是优秀的软件产品。

个人经验吧，可能有些文不对题了，仅供参考

[ 本帖最后由 misfit 于 2008-3-8 11:41 编辑 ]

量化评估，最重要的一点是经验。同时科能需要大量统计工作作为铺垫。
下面我主要从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会给这个团队大量的经验积累，
完全可以做到看着统计图估计出一个产品处于什么状态，需要加强哪些方面等等。

我是一个新手,我觉得软件的质量可以从bug的分布,以及bug的收敛两方面考虑.
我们公司对软件质量的看法是从客户的反馈来评定的

在没发布之前先由测试人员和项目经理来评估，还有就是需求制定者
发布之前先让用户测试一下，让用户评估一下
发布之后主要就是让用户来评估了，用过之后才能发现软件的优势和缺点所在，做综合评价

每轮结束进行一个评审，评审案例覆盖度和执行覆盖度。
按模块统计BUG数，找出BUG多的模块，说明这个模块是软件的薄弱的地方或是研发人员比较差。
执行度会统计每轮漏测的地方，与绩效挂钩。
案例分析后进行补充优化，直到测试的BUG有明显收敛。

个人觉得首先得先确认测对象的规模，大小，复杂度吧，工期，等相关信息

然后再详细的定义出对bug的标准，严重，优先级，详细划分功能点，规划测试的整个工期
收集编写测试用例，然后根据以前相似的项目经验，预先得出一个测试用例数，和bug率，做参考
当然我个人觉得需要的是经验，和之前很好的数据收集
然后得出实际的bug率，或是遗漏的测试设计，并且客户的反馈也在收集之内，当然针对模块的复杂度，也应该有不同的标准，或是根据过往的数据，得出一个千行代码的bug数，也可以是参考之内的东西

同意 3# cityyard 按bug的统计进行评估量化，实际工作中，我们也是这样执行的。
另外，我们还从test case的执行情况进行统计，如每一轮测试，会统计其test case的执行率、成功率、失败率等作为参考
软件版本release后，要看客户的反馈情况，为release的版本打patch的数量
从整个项目或产品角度看，还要考核被测试的软件能否及时release.

我认为应该从以下几个方面的量化管理:
一:提交BUG的数量和执行测试用例的数量.
二:测试用例的覆盖率.
三:BUG的严重程度
四:测试的相关文档的编写质量.


不补的地方,请指教噢.

我想说的，楼上已基本提到了
但我要说的是，软件的应用环境和行业
要分析客户注重、关注的是软件哪方面的质量（质量当然包括功能、性能、。。。。）

"预估软件测试结束的时间" ，经常感觉要预估这个时间非常困难，因为经常要依赖于非测试团队的因素。
目前我们项目遇到最多的情况是：
1. 开发团队解决bug的速度。特别是中后期，测试团队经常是在等待状态
2. 开发团队解决bug的质量。经常出现把哑巴治成瘸子，导致多处小范围的重复再重复的测试，象一个无底洞。
从测试的角度来说，完全不知道要怎样预估这个时间。

从我所在的公司的情况看，评估一个被测软件的质量主要是从三个方面来进行。
1：系统的性能。这其中包括了系统的稳定性，运行时的速度，安全性等。即，性能稳定，运行时，不报错，不因数据量过大而造成速度慢，死机之类的原因。
2：后期提交的bug数量及等级。即，在软件开发、测试的后期，提交的bug数量越少，严重程度越低，这个软件的质量就越好。当然，在bug数量和质量上是不可以造假的。呵呵
3：user acceptance testing中返回的bug数量和其他的意见。即，用户在UAT测试过程中发现的bug数量越少，对系统的其他建议越少，这个软件质量就越好。

首先套用一个定义来说明一个软件的质量：
GB/T 16260.1 提供了一个软件质量评价的通用模型，定义了6种软件质量特性：
1、功能性：（子特性）适合性、准确性、互操作性、保密安全性、功能依从性
2、可靠性：成熟性、容错性、易恢复性、可靠依从性
3、易用性：易理解性、易学性、易操作性、吸引性、易用依从性
4、效率：时间特性、资源利用、效率依从性
5、可维护性：易分析性、易改变性、稳定性、易测试性、维护依从性
6、可移植性：适应性、易安装性、共存性、易替换性、可移植依从性

所以对一个软件的质量评定，可以以以上各个方面去进行衡量。当然，各个方面都能够符合，这不大实际，但是主要看这软件的侧重点，以及客户的需求。从而检测在这一方面的质量是否过关，是否令人满意。而这满意度主要还是需要从最终用户的角度出发进行评测。

以上是小弟的一些愚见，也是从黑盒测试方面进行评论。大家讨论讨论而已。

这个问题非常好,感谢.下面谈谈我对这的理解:
我认为主要从两方面来衡量：
1、需求方面：
1）、肯定得保证测试用例100%覆盖用户需求。
2）、用例通过率：全部用例通过率95%以上。基本用例通过率100%。
3）、通过BUG曲线，分析BUG已经降低到了正常状态。
4）、没有致命问题。按我们的定义，P0--P2级别的BUG必须全部修理。
2、代码方面：有代码覆盖率工具来检查测试用例代码覆盖率。按我的理解，这个如果能做到覆盖70%，应该很不错了。

说明一下：上面我说的用例，包含前面大家讨论的功能、性能等方面。

我们公司软件质量的评估，首先要看测试出来的问题等级和数量，另外重要的是客户的使用情况，不过我想公司现状和软件的现状无法制定出一个更好的评估标准。下面谈一下我个人的想法：
首先，需求的覆盖率是软件质量的根基，这就要求我们对需求的管理非常规范
其次，在软件各个阶段出现的bug情况（单元、集成、系统），是软件质量的表现
最后，客户验收测试的满意程度，这个不应该用BUG的数量来衡量，应该以客户的实际反应状况为标准，因为客户提出的不一定是软件的质量有问题，而是从客户的使用情况来说明软件是不是适合客户使用

[ 本帖最后由 xuwh 于 2008-3-12 15:17 编辑 ]

量化是个很复杂的工程，实现是很困难的。
量化包含的方面很多
比如
各项度量指标的量化（ 用例覆盖率要达到多少，残留缺陷密度的指标，并发访问量的指标，点击率的指标、   还有有很多）
工作量的量化 （需要统计人员的工作效率，在做计划时预计总的工作任务，分解工作任务，  这些都需要有很多的度量数据的积累作为参考）
工作时间的量化（根据工作量来计划工作时间）
工作任务的量化（根据每个人的情况来分配工作任务）
总之呢，牵扯的方面很多
目前在初步学习之中，现在只了解了皮毛

不同的软件应该有不同的评定标准，行业不同要求也不一样，看针对哪个领域。
不过不管哪个领域的软件，我认为首先要考虑软件的安全性，数据安全很重要，客户用你的软件数据丢失或者什么的，你想会有什么后果，还有就是好不容易开发个软件一下就被破解了.......

其次看软件的稳定性与响应速率，如果一个软件运行就死或者打开要等几分钟才出来，相信没有人用
再次就看正确性了或者叫准确性，对小数点的精确程度，如果一个财务软件经常算错，或者航天的软件。。。。。。
再看界面与操作的友好程度，因为这些是直接与用户接触的，长期对着一个界面极不美观，操作极不方便的软件可想会有好心情么？
。。。。。。
只是业余的人发表的看法哈，呵呵，理论的东西书上多的是，就不知道了。。。。。。。

软件不外乎是为了实现某个功能而实现的一段代码，所以我认为衡量软件的质量，最关键的是测试case覆盖率。case的覆盖当然需要是多个方面的，最基本的是：性能、功能、安全、易用性，由于软件需要不断升级和维护，同时很重要的还包含：可移植性、可维护性。以上每个方面的case都有覆盖到，且case都能通过的话，就说明这个软件具有很高质量了。
    当然case的覆盖，需从两方面出发，一方面是：客户的需求；另一方面是：系统开发的结构。这样的case才能尽可能的保证覆盖的完整。所以现在很多测试管理软件，类似：TD,TM等...都有把case跟需求关联起来，统计覆盖率，不过我认为这还是不够的，这个只是能统计到case覆盖需求的覆盖率，但是实际还有一部分case，跟需求没有直接关系，是系统结构设计引起的，这部分如果也能纳入关联管理，就很好了！
    另外谈一下对bug的是否能够衡量软件质量的看法把，我个人觉得这个可以做个参考，但是不能作为重要依据。因为bug的来源跟开发人员、测试人员、架构设计人员、需求调研人员有很大的，而且直接的关系，作为评价质量的量化依据不太客观。

    以上是我的看法，供参考...

引用:

原帖由 cityyard 于 2008-3-9 10:47 发表
量化评估，最重要的一点是经验。同时科能需要大量统计工作作为铺垫。
下面我主要从bug统计来说一下我的经验。

1。测试项目数和摘出bug数预测
    一般来说我们可以根据软件代码行数来粗略估计一个产品可能包含的 ...

我觉得这个说的很好