為什麼要去度量缺陷？我覺得最大的意義是**。且聽我慢慢道來。
專案沒開始前，**：
a；這個專案將會有多少個defect
b；各個階段將發現多少個defect
c；多長時間解決這些defect
d；結果怎麼算是好，發布怎麼樣算是底氣十足
為了以上的**，於是我們開始了度量之旅，
1；我們要基於乙個統一的規模度量，就好比是**白問題，大家統一在乙個環境才有得可比性（咳，最近老是被個山東人說我黑，這個就嚴重不公平，環境不一樣嘛，見諒舉這個例子，因為好委屈，哈哈）。那如何度量規模，**行？沒關係，可以，功能點？沒關係，可以，或者其他。關於規模度量方法，其實我個人覺得每個都是有優缺點的，但是如果在乙個公司規定了並統一了度量方法即可。ok，以下我們採用功能點計算軟體規模；
2；好拉，我們開始翻舊賬，這個可是個痛苦的過程，扯皮吵架多得是，我們把從公司可以統計資料的專案全都翻出來，所以說嘛，qa必須組織支援才行。於是我們將專案分門別類，每個專案各個階段，統計缺陷（注此處指的是bug）；
3；得到資料好了之後，開始資料分析，此處你覺得可以帶個黑框眼鏡以示你博學，因為那些圖會讓別人眼花繚亂。我們要得到的是公司組織級資料。專案經理利用這些組織級資料在專案開始時，便可以**以上的。
a；這個專案將會有多少個defect ==> 可以**，經過了資料分析後，得到了公司組織級缺陷密度指標值 = all detected defects/專案規模，利用這個指標值，乘上個規模即可**；
b；各個階段將發現多少個defect ==> 可以** ，利用 各個階段的缺陷密度，利用這個指標值，即可**；其實，這個還可以做很多，比如，測試人員在何時加大測試力度，開發人員何時調整開發工作量等等，這裡其實包含跟蹤的意思；
c；多長時間解決這些defect ==》有bug管理工具的應該可以輕而易舉得到，這個其實還可以引申維護成本
d；結果怎麼算是好，發布怎麼樣算是底氣十足 ==》 個人覺得其實這個用圖來也可以反映，只是不好表達，還有種，反過來計算，跟公司組織級的交付物質量指標值相比較計算這個要好點。因為是資料嘛！
好吧，以上還沒完，缺陷度量，**只是乙個目標。待續*****=
軟體缺陷分析
alan 缺陷分析本質上是對缺陷中包含的資訊項進行收集，彙總，分類之後使用統計方法 或者分析模型 得出分析結果。缺陷分析得出的結果可以用來度量軟體開發過程中各階段中工作產品的質量，了解缺陷集中的區域，明晰缺陷發展趨向。對於軟體過程的改進，軟體產品的發布來說具有十分重要的參考價值 在我們提交缺陷報告的...
軟體缺陷分析
我在marvell實習了一年多，期間主要做的軟體缺陷分析的工作，比如軟體缺陷的度量，風險分析等，結果一年多的不斷學習，我覺得這件事是非常的有意義，然後，國內很少有公司會選擇在這一塊投入，主要原因是這個過程需要長期的投入才能見成效，其次，風險也比較大。我主要會做一些軟體缺陷的分類統計，和缺陷累積量的 ...
18 軟體缺陷
定義 缺陷就是軟體的問題，最終表現為沒有滿足使用者的需求。軟體測試缺陷 1 軟體未達到規格說明書表明的功能 2 軟體出現了規格說明說中指明不會出現的錯誤。3 軟體功能超出了規格說明書指明的範圍 4 軟體未達到規格說明書雖未指明但應該達到的目標 5 軟體測試人員或使用者覺得不好。示例 1 計算器說明書...