正交缺陷分類（ODC）簡介

正交缺陷分類法，Orthogonal Defect Classification（以下簡稱 ODC）是一種缺陷分析方法，由 IBM 在 1992 年提出。它通過給每個缺陷添加一些額外的屬性，利用對這些屬性的歸納和分析，來反映出產品的設計、代碼質量、測試水平等各方面的問題。從而得到一些解決辦法來進行改進。例如對于測試團隊，通過 ODC 可以知道測試工作是否變得更加復雜；每一個測試階段，是否利用了足夠多的觸發條件來發現缺陷；退出當前測試階段有什么風險；哪個測試階段做得好，哪個測試階段需要改進等。對于開發團隊，利用 ODC 可以知道產品設計和代碼編寫的質量情況。而給產品用戶帶來的好處就是提高客戶滿意度，減小產品投入市場后的維護花費。

ODC 的工作流程分為四部分：“缺陷分類”，“校驗已被分類的缺陷”，“評估數據”以及“采取行動來改進工作”。下面我們將逐一進行講解。

1. 分類階段

分類，是 ODC 工作流程中的第一步，即需要測試和開發人員分別對每一個缺陷填寫 ODC 屬性。對于團隊成員來說，正確的了解每個屬性的值尤為重要，這樣才能保證他們在分類時盡量選擇正確的選項。

前提條件

有些缺陷管理工具在默認情況下是不支持 ODC 的，這就需要在填寫之前，對缺陷管理工具進行改進，配置額外的屬性。常用的缺陷管理工具包括 Clear Quest(CQ) 和 Configuration Management Version Control(CMVC) 等。需要增加的 9 個 ODC 相關屬性分別是。

1. Activity：表示在做哪種測試時發現的缺陷。比如：UT( 單元測試 )、FVT（功能測試），SVT（系統測試）等；
2. Trigger；表示采取哪種方式觸發的該缺陷，不同的 activity 對應不同的 trigger 類型；
3. Impact：表示該缺陷的發生會對客戶造成的影響；
4. Target：表示開發人員為了修復這個缺陷，需要在哪方面做修改。比如可以修改的方面包括：產品設計、相應的代碼和文檔等；
5. Defect Type：缺陷類型；
6. Qualifier：表示該缺陷是由于丟失相關代碼、還是代碼不正確造成的?；蛘呤怯捎诘谌教峁┑拇a造成的；
7. Source：表示該缺陷的來源是由于內部編寫的代碼引起的問題，還是由外包公司提供的代碼引起的等；
8. Age：表示該缺陷是由新代碼產生的還是由于修改其它缺陷而引發的，或是在上一個發布版本中就已經有的問題等；
9. Content Type: 表示修復文檔的類型。僅對文檔類的缺陷有效。

對于 CMVC，自從 1.7 版本后就自帶了 ODC 屬性，可直接使用。而對于 CQ，需要安裝一個 ODC 包即可。關于該 ODC 包可從附件中下載，解壓后里面有詳細的文檔教讀者如何在 CQ 中安裝該包。

在配置好 ODC 后，CQ 的應用程序窗口中會出現新的選項簽：ODC Submitter 和 ODC Responder，如圖 1 和圖 2 所示。

圖 1. CQ 中的 ODC Submitter 選項簽

圖 2. CQ 中的 ODC Responder 選項簽

在缺陷管理工具支持 ODC 后，就需要測試人員和開發人員分別填寫 ODC 屬性，后面的流程都會用到這些數據。

測試人員進行分類

從圖 1 中我們可以看到，ODC Submitter 選項簽中有三個選項，分別是 Activity、Trigger 和 Impact。這三個選項是由測試人員，也就是該缺陷的發現者來填寫的。由這幾個屬性可以得知，該缺陷是在進行何種類型測試的時候，由怎樣的觸發方法來發現的。同時，對用戶造成的影響是什么。僅靠這三個 ODC 屬性，就可以一目了然。

開發人員進行分類

從圖 2 中我們可以看到，ODC Responder 選項簽中有六個選項，分別是 Target，Defect Type，Qualifier Source，Age 和 ContentType。這六個選項是由開發人員，也就是該缺陷的解決者來填寫的。由這幾個屬性可以得知，開發人員做了哪方面的修改用以解決問題？改動大不大？是原來的代碼有遺漏？不正確？還是需要被刪除一部分？原來的版本中是否存在這個問題？等等。有了這些屬性的值，就可以很快的知道產生這個缺陷的根源了。

原文轉自：http://www.anti-gravitydesign.com