IT数码

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