我在marvell實習了一年多，期間主要做的軟體缺陷分析的工作，比如軟體缺陷的度量，**，風險分析等，結果一年多的不斷學習，我覺得這件事是非常的有意義，然後，國內很少有公司會選擇在這一塊投入，主要原因是這個過程需要長期的投入才能見成效，其次，風險也比較大。
我主要會做一些軟體缺陷的分類統計，和缺陷累積量的**！
關於分類統計，我自認為基於rootcause的分類統計是很有意義的，可惜公司的缺陷沒有這一方面的資訊
如果我們對rootcause進行分析，研究哪些方面是導致此次開發軟體缺陷過多的原因，從而通過過程的優化和程式設計師自身的提高，避免下次再犯同樣的錯誤，這該是一件多麼有意義的事情。
說到這，我想起了高中時代，那時候班主任會鼓勵大家準備乙個糾錯本，對自己每次在練習或者考試中犯的錯誤摘抄下來，並進行分析，我為什麼會做錯，我在做題的時候哪齣了錯，我下次改怎麼避免犯同樣的錯誤。對我而言，我覺得這是乙個很好的提高方式！
同樣，對於程式設計師，除了學習新技術，對已寫過的code的分析和經驗總結，特別是那些出現缺陷原因的分析也是至關重要的，如果下一次的開發或者是接下來的開發工作能不再犯曾犯過的錯，那將會將軟體產品的質量提公升到乙個更高的層次。比如我們在一次開發中發現，由於android的公升級導致缺陷數的增加，那麼在下一次android的公升級時，我們可以提供一些關於android公升級相關的培訓，討論會，讓開發人員深入了解這次公升級中的一些的改變及需要在開發過程注意的地方。
這種防範於未然所投入的人力和物力財力，肯定會比後期發現缺陷修補省的多。
同時，這對開發人員而言，也可以從中不斷地提高自己，積累更豐富的經驗，寫出更優質的code。
很多時候，開發人員一味地忙碌新code的開發，很少回過頭來統計分析，就公司而言，也不願意給他們分配這段時間，所以，我們可以請更專業的人士來做這件事，將資料分析好後，直接反饋到開發和專案管理者那裡，從而大家一起思考改進的方式方法！
對於做產品的公司，又快又好地開發乙個軟體才能搶占市場先機，而如何又快又好，減少缺陷量顯然是乙個最好的途徑。對於乙個軟體的生命週期而言，缺陷的多少絕對會影響到乙個產品的交付期。如果一開始就能做好準備，寫出優質code，縮短開發周期，那該是一件多麼美好的事情！
軟體缺陷分析
alan 缺陷分析本質上是對缺陷中包含的資訊項進行收集，彙總，分類之後使用統計方法 或者分析模型 得出分析結果。缺陷分析得出的結果可以用來度量軟體開發過程中各階段中工作產品的質量，了解缺陷集中的區域，明晰缺陷發展趨向。對於軟體過程的改進，軟體產品的發布來說具有十分重要的參考價值 在我們提交缺陷報告的...
軟體缺陷分析
缺陷資料與缺陷屬性的函式。如缺陷狀態分布情況，缺陷嚴重性分布情況，缺陷模組分布情況等。還有缺陷產生原因分布情況，缺陷關閉方式分布情況。一般是餅圖，每種情況的百分比以及缺陷數。用處 可以評估開發所做的努力，判斷測試完成標準。按各種狀態將缺陷計數作為時間的函式顯示。趨勢報告可以是累計的，也可以是非累計的...
軟體缺陷分析方法
odc 正交缺陷分類 分析方法最早由ibm的waston中心推出，是將乙個缺陷在生命週期的各環節的屬性組織起來，從單維度 多維度來對缺陷進行分析，從不同角度得到各類缺陷的缺陷密度和缺陷比率，從而積累得到各類缺陷的基線值，用於評估測試活動，指導測試改進和整個研發流程的改進 同時根據各階段缺陷分布得到缺...