odc分析法
odc（正交缺陷分類）分析方法最早由ibm的waston中心推出，是將乙個缺陷在生命週期的各環節的屬性組織起來，從單維度、多維度來對缺陷進行分析，從不同角度得到各類缺陷的缺陷密度和缺陷比率，從而積累得到各類缺陷的基線值，用於評估測試活動，指導測試改進和整個研發流程的改進；同時根據各階段缺陷分布得到缺陷去除過程特徵模型，用於對測試活動進行評估和**。
無論測試人員還是開發人員在建立和處理乙個缺陷時首先都要新增一些字段內容用於後面的odc分析。
建立缺陷人員需要填寫的字段內容主要有：發現缺陷活動、功能模組、結果影響、嚴重程度和缺陷型別等。處理缺陷人員需要填寫的字段內容主要有：開發處理決定、缺陷注入階段等。（字段可以根據分析需要進行擴充、刪減）
基於這些字段內容便可以對累計的缺陷資料，根據不同需要單獨或兩兩作出不同維度的資料分析。主要通過資料圖表的形式來顯示分析結果，常用的圖表為餅圖（單維度）、直方圖（多維度）。通過結果評估測試活動，指導測試改進和研發流程改進。
單維度分析主要採用餅圖反映所選屬性中各類缺陷數量所佔比例。如對「功能模組」屬性進行單維度分析，目的在於通過各個功能模組的缺陷密度，了解各個功能模組的質量狀況。生成的餅圖如下：
多維度分析採用直方圖的方式，結合兩個或者多個屬性對缺陷進行分析。如使用「功能模組」屬性結合「嚴重程度」屬性進行二維度分析。目的在於通過各個模組所產生的缺陷的嚴重級別了解各個模組的開發質量狀況。生成的直方圖如下：
gompertz分析法
軟體測試是為了發現軟體產品中存在的缺陷，是軟體質量保證的重要階段。質量、進度和成本是軟體專案關注的三大要素，它們互相依賴、互相制約。測試的總目標是充分利用有限的人力、物力，高效率、高質量的完成測試。gompertz分析方法是在利用已有測試資料的基礎上，對測試過程進行定量分析和**，對軟體產品質量進行定量評估，對是否結束測試任務給出判斷依據。
我們在日常的軟體測試過程中會發現，在測試的初始階段，測試人員對測試環境不很熟悉，因此日均發現的軟體缺陷數比較少，發現軟體缺陷數的增長較為緩慢；隨著測試人員逐漸進入狀態並熟練掌握測試環境後，日均發現軟體缺陷數增多，發現軟體缺陷數的增長速度迅速加快；但隨著測試的進行，軟體缺陷的隱藏加深，測試難度加大，需要執行較多的測試用例才能發現乙個缺陷，儘管缺陷數還在增加，但增長速度會減緩，同時軟體中隱藏的缺陷是有限的，因而限制了發現缺陷數的無限增長。這種發現軟體缺陷的變化趨勢及增長速度是一種典型的『s』曲線，滿足gompertz增長模型的應用條件。模型表示式為：
y=a*b^(c^t)
其中y表示隨時間t發現的軟體缺陷總數，a是當t→∞時的可能發現的軟體缺陷總數，即軟體中所含的缺陷總數。a*b是當t→0時發現的軟體缺陷數，c表示發現缺陷的增長速度。我們需要依據現有測試過程中發現的軟體缺陷數量來估算出三個引數a，b，c的值，從而得到擬合曲線函式。
對於三個引數a，b，c的估算需要大量複雜的數學計算過程，下面通過乙個例項來做簡單說明：
某測試專案，已經執行測試21周，測試資料如下表所示：
通過對以上測試資料進行數學計算並採用「非線性回歸最小二乘法」，最終估算出a，b，c三個引數分別為448.685，0.078和0.874。則得到的gompertz增長模型擬合曲線函式為：
y=a*b^(c^t)=448.685*0.078^(0.874^t)
生成的曲線圖如下：
從得到的擬合曲線函式可以看出，該軟體產品的總缺陷數估計共有448.685個（極限缺陷數=449）。執行測試21週後，共計發現缺陷數374個，發現缺陷率為83.3%，測試是不充分的。以目前的測試能力來看，若要想將發現缺陷率達到95%，在考慮進一定標準偏差和相關係數前提下，需要發現缺陷數至少達到419.93個。則有：
419.93= a*b^(c^t)= 448.685*0.078^(0.874^t)
解得t=28，即要測到第28周，還需要再測7周時間可將發現缺陷率提高到95%。之後產品經理就可以根據產品的質量等級、產品成本以及產品進度決定是繼續測試還是退出測試。
需要說明的是，這個方法使用前提是產品的整個測試活動中測試能力保持相對穩定，同時對測試過程中發現的缺陷只做數量上的處理，不做等級上的劃分，這是這個方法的不足之處。
dre/drm分析法
dre/drm分析法是通過已有專案歷史資料，得到軟體生命週期各階段缺陷注入和排除的模型，用於設定各階段質量目標，評估測試活動。
缺陷排除效果分析dre矩陣：
dre主要針對歷史資料，矩陣的每一列代表缺陷在何時（什麼階段）引入（產生），每一行代表發現缺陷時開展的工作。矩陣中的數值代表已經發現的缺陷數量。例如：在做**審查工作時發現1095條缺陷，其中12條是在需求階段就已經產生，941條是在編碼階段產生。而經過各項測試工作後，發現的缺陷中有1537條是在編碼階段引入。
本矩陣的目標是要分別計算出各個階段的缺陷移除率為後面所用。缺陷移除率的定義為當前階段工作實際發現的缺陷數量佔當前階段應該發現的缺陷數量的比值。例如：做單元測試時實際發現332條缺陷，在單元測試及之前階段應該已經發現122+859+939+1537+2=3459條缺陷，而在做單元測試工作之前已經發現730+729+1095=2554條缺陷。就是說單元測試工作本該可以發現到3459-2554=905條缺陷，實際卻發現332條缺陷，缺陷移除率為332/905=36.7%。其他階段的缺陷移除率依此演算法都可得到。
下面就可以用drm缺陷排除模型進行專案質量策劃。
其中「前一階段洩露的缺陷」等於上一階段「階段出口缺陷數」。每個階段的「注入缺陷」一般來自於歷史資料的平均值（經驗值）。「缺陷排除有效率」同樣來自於對歷史資料的計算（前面已經提到）。「排除缺陷數」為我們最終想要的結果，它等於每個階段還未排除的缺陷數（小計部分）與此階段的缺陷排除有效率的乘積。從這個結果我們能估算出如果按之前的經驗我們在每個階段應該能發現的缺陷數。如果想降低最終「現場」階段發現的缺陷，在每個階段注入缺陷一定的情況下需要提高缺陷排除有效率來達到目的，它的提高意味著每個階段排除缺陷數量的提高，也是質量目標的提高。
軟體缺陷分析方法
odc 正交缺陷分類 分析方法最早由ibm的waston中心推出，是將乙個缺陷在生命週期的各環節的屬性組織起來，從單維度 多維度來對缺陷進行分析，從不同角度得到各類缺陷的缺陷密度和缺陷比率，從而積累得到各類缺陷的基線值，用於評估測試活動，指導測試改進和整個研發流程的改進 同時根據各階段缺陷分布得到缺...
軟體測試 缺陷報告
缺陷報告是描述軟體缺陷現象和重現步驟地集合。軟體缺陷報告software bug report sbr 或軟體問題報告software problem report spr 作用 缺陷報告是軟體測試人員的工作成果之一，體現軟體測試的價值缺陷報告可以把軟體存在的缺陷準確的描述出來，當測試人員發現乙個缺...
軟體測試 缺陷報告
缺陷報告是描述軟體缺陷現象和重現步驟地集合。軟體缺陷報告software bug report sbr 或軟體問題報告software problem report spr 作用 缺陷報告是軟體測試人員的工作成果之一，體現軟體測試的價值缺陷報告可以把軟體存在的缺陷準確的描述出來，當測試人員發現乙個缺...