ODC(Orthogonal Defect Classification)簡介

Defect分析是軟件開發和測試中一個重要的環節，ODC介紹了一種不同于大家常用的非常有效的defect分類及分析方法。這篇文章簡單的向大家介紹了什么是ODC，以及如何在項目和產品開發中使用ODC來改進開發測試流程從而增強產品質量。希望讀者具有基本的軟件開發和測試經驗，并且了解defect分析的基本方法。

Defect 分類幫助改進產品質量

軟件開發中都包含有控制軟件開發的流程。我們設計模塊、開發代碼、對產品進行測試、然后發布產品。但是，我們怎樣從以前的錯誤中學習，怎樣做得更好呢？一般情況下，我們會拿一些輸出的數據來進行分析，從而知道我們應該怎么樣和進行什么樣的改進（如圖1）。但是如何確定我們做的努力是真正有用的呢？這就是defect classification (defect分類) 能夠幫助我們的地方，如果我們可以正確的使用defect classification，它會對我們有很多的幫助。

回頁首

幾種常見的defect 分類方法

在軟件開發過程中我們會在不同的階段發現數量不等的defect，如圖2所示，對于所發現的defect我們可以逐一的對它們進行分析，例如使用root causal analysis方法，可是這種分析方法占用了大量的時間和資源，顯然我們非常需要有一種方法可以明確地告訴我們應該在哪里改進。

下面我們來看看幾種我們常見的defect 分析方法：

按照defect 嚴重程度分類

我們在測試過程中會根據defect的嚴重程度對defect 進行分類，在這里我們將嚴重度稱為severity, 我們有如下圖所示的一個項目不同測試階段的defect的分布圖：

在這個圖中defects跟據它們的severity屬性進行了分類， severity為1的defect是最嚴重的defect, 它使系統根本不能運轉，需要立即進行改正。那severity為 2的defect 是一般功能性的錯誤，這些錯誤是需求中所要求的，必須改正才能實現系統完整的功能。Severity 為3的defect是一些細小的錯誤，它們不影響功能的實現，但可能引起用戶的誤解或者使用不當。Severity為4 的 的defect是測試人員建議改進的地方，如果時間允許開發人員可以選擇性的改正，或者等到下個版本中再改進。從圖3中我們可以看到第一個圖是在一個項目測試前期的時候，這時候1級的defect很多，整個系統還不能夠運轉，正需要大量的時間和人力進行測試和改正代碼錯誤。第二個圖則顯示項目測試已經到了中期，這時候最嚴重的defect已經很少了，系統已經基本可以運轉，然后測試人員發現了大量的功能性的錯誤和細節上的錯誤需要改正。第三個圖顯示了項目測試已經到了末期，這時的產品需求的功能已經實現，只有部分細節和建議需要改進，產品已經可以發布了。在用severity分類的圖表中，我們可以了解到以下有關項目的幾個方面：

1) 工作的優先級

2) 項目的進展狀態

3) 產品的質量

按照component/module分類

對于不同的component或者module，我們也可以有類似的defect分布圖來說明另外一些問題：

圖4中，對于第一個圖，我們能看出C模塊中發現的defect明顯的比其他模塊的少，那么原因可能是C模塊的開發人員技術非常的好。第二個圖中我們可以看出A和C中發現的defect明顯比其他兩個模塊的多，那么可能這兩個模塊的難度、大小或者是改動的變化比較大，因此而造成了它們中發現的defect比較多。對于第三個圖，C模塊的defect明顯比其他的多，那么可能是C模塊的開發人員太差了，需要管理者的特別關注了。

回頁首

Orthogonal Defect Classification簡介

下面我們來介紹ODC，什么是ODC（Orthogonal Defect Classification）呢？簡單的說，它是另外一種defect分類的方法，它使你能夠快速得到每一個問題的信息來幫助你后面做出正確的決定來解決問題。

開發中應用ODC

作為一個開發人員我發現的問題如果按類型（type）分類可能是由如下幾種可能：(括號中的英文為縮寫圖例)

1) 沒有正確的初始化 （Init）

2) 代碼沒有正確的check-in （Chk）

3) 算法問題 （Alg）

4) 功能性的錯誤，可能是模塊內的功能沒有被正確實現，也可能是模塊與模塊之間相聯系的部分沒有被正確實現。（Fnct Cls）

5) 有可能是有關時間的錯誤 （Time）

6) 界面相關的錯誤 （Intf）

7) 代碼之間相關聯的錯誤，例如錯誤的繼承關系 （Rel'n）

按照type的分類我們有如下的分布圖：

從圖5、圖6中，我們可以了解到開發過程中哪個環節的錯誤比較多，例如圖6中算法錯誤和功能性錯誤是最多的那么應該在單元測試或者code review中著重注意這兩個部分的代碼質量。另外從上圖中我們也可以知道在哪以及如何來改正錯誤代碼。