软件缺陷度量之旅

*转载请注明出处。

 

为什么要去度量缺陷？我觉得最大的意义是预测。且听我慢慢道来。

项目没开始前，预测：

A；这个项目将会有多少个defect

B；各个阶段将发现多少个defect

C；多长时间解决这些defect

D；结果怎么算是好，发布怎么样算是底气十足

 

==================================

为了以上的预测，于是我们开始了度量之旅，

1；我们要基于一个统一的规模度量，就好比是皮肤白问题，大家统一在一个环境才有得可比性（咳，最近老是被个山东人说我黑，这个就严重不公平，环境不一样嘛，见谅举这个例子，因为好委屈，哈哈）。那如何度量规模，代码行？没关系，可以，功能点？没关系，可以，或者其他。关于规模度量方法，其实我个人觉得每个都是有优缺点的，但是如果在一个公司规定了并统一了度量方法即可。OK，以下我们采用功能点计算软件规模；

2；好拉，我们开始翻旧账，这个可是个痛苦的过程，扯皮吵架多得是，我们把从公司可以统计数据的项目全都翻出来，所以说嘛，QA必须组织支持才行。于是我们将项目分门别类，每个项目各个阶段，统计缺陷（注此处指的是BUG）；

3；得到数据好了之后，开始数据分析，此处你觉得可以带个黑框眼镜以示你博学，因为那些图会让别人眼花缭乱。我们要得到的是公司组织级数据。项目经理利用这些组织级数据在项目开始时，便可以预测以上的。

 

A；这个项目将会有多少个defect   ==> 可以预测，经过了数据分析后，得到了公司组织级缺陷密度指标值  = All detected defects/项目规模，利用这个指标值，乘上个规模即可预测；

B；各个阶段将发现多少个defect ==> 可以预测 ，利用 各个阶段的缺陷密度，利用这个指标值，即可预测；其实，这个还可以做很多，比如，测试人员在何时加大测试力度，开发人员何时调整开发工作量等等，这里其实包含跟踪的意思；

C；多长时间解决这些defect  ==》有BUG管理工具的应该可以轻而易举得到，这个其实还可以引申维护成本

D；结果怎么算是好，发布怎么样算是底气十足  ==》 个人觉得其实这个用图来也可以反映，只是不好表达，还有种，反过来计算，跟公司组织级的交付物质量指标值相比较计算这个要好点。因为是数据嘛！

 

 

===========================

好吧，以上还没完，缺陷度量，预测只是一个目标。待续======