正交缺陷分類（ODC）流程簡介及應用經驗分享

正交缺陷分類（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。這六個選項是由開發人員，也就是該缺陷的解決者來填寫的。由這幾個屬性可以得知，開發人員做了哪方面的修改用以解決問題？改動大不大？是原來的代碼有遺漏？不正確？還是需要被刪除一部分？原來的版本中是否存在這個問題？等等。有了這些屬性的值，就可以很快的知道產生這個缺陷的根源了。

常見問題及建議

缺陷管理工具對 ODC 的支持不完善

有些 ODC 屬性間是有關聯關系的。例如：在 ODC Submitter 選項簽中，如果在 Activity 屬性中選擇了“Function Test”，那么 Trigger 屬性就只能在“Coverage”，“Sequence”，“Variation”和“Interaction”中進行選擇。如果在 Activity 屬性中選擇了“System Test”，那么可選的 Trigger 屬性的值又是截然不同的另外幾種選項，分別為：“Workload”，“Recovery”，“Startup/Restart”，“Hardware config”和“Software config”。在缺陷管理工具中，若對這些屬性間的關聯關系不做限制，選擇每個選項時都會把所有的值列出來供用戶選擇，這樣很容易造成選項間的不匹配。從而導致最后統計 ODC 數據時，結果不合理。

另外，沒有對 ODC 屬性項進行必填操作的校驗，也是缺陷管理工具對 ODC 支持不完善的表現之一。例如：僅填寫了 Activity 屬性，即表明了該缺陷是在何種類型的測試中發現的，但是不填寫 Trigger 屬性，也就是說不指明是在哪種觸發條件下發現的該缺陷，就會造成信息缺失，從而分析出的結果也不會準確。

因此，我們強烈建議在配置缺陷管理工具用以支持 ODC 時，加上對有關聯關系屬性的限制，并對必填的 ODC 屬性進行強制填寫的校驗，強制每個人必須填寫，否則無法提交成功。從而在工具的層面上，保證 ODC 數據輸入的完整性和正確性。

測試或開發人員對各自需要填寫的 ODC 屬性不熟悉

ODC 這種缺陷分析方法并沒有普及到每一個項目中，因此在第一次應用 ODC 的項目中必須在分類階段前，就要在項目內部做好 ODC 知識的系統培訓。不僅僅是簡單的了解，而是需要知道每個屬性所有可選項的含義。這樣就不會在分類階段開始后，一片茫然。另外，由于 ODC 屬性選項眾多，不可能靠之前的幾次培訓就全部記住。建議打印一份類似于 ODC 屬性快速參考手冊的資料。這樣在填寫 ODC 數據時，可一邊參考手邊的文檔一邊填寫。

2. 校驗階段

在第一步中，測試人員和開發人員已經填寫了 ODC 數據。那么接下來就需要 ODC 專家對這些數據進行校驗。因為填寫不正確的 ODC 數據會導致后面的評估和行動兩個流程步驟沒有意義。因此校驗數據的正確性尤為重要。

常見問題及建議

校驗結果如何在缺陷管理工具中體現？

校驗員在校驗完某個缺陷并確認相關人員已經完成修改后，校驗工作還并沒有結束。為了在下一階段，即評估階段中，僅僅對已被校驗過的缺陷進行分析，就需要在缺陷管理工具中有地方進行標識，用以過濾掉未校驗過的缺陷。

可以在 ODC Responder 選項簽中增加一個屬性項，叫做“ODC Validated”。如圖 3 所示。

圖 3. ODC Responder 選項簽中新增加屬性 ODC Validated:

有四個選項可供選擇。

• “空”：默認情況下，該屬性項為空。表示校驗人員還沒有開始進行該缺陷的校驗工作；
• “是”：已被校驗過，并且相關人員已經把錯誤的 ODC 屬性進行了修改；
• “否”：已被校驗過，但是相關人員還沒有進行修改；
• “N/A”：對于無效的缺陷，是不算在最后的統計數據中的。出現無效缺陷的情況可以包括：由于測試人員的問題，開的無效缺陷（User Error）；所發現的問題并不是一個缺陷，而恰恰在產品設計上就是這樣的（As Design）；該缺陷與之前開的另一缺陷重復（duplicate）；

校驗小組成員間如何更有效的溝通？

校驗小組成員通常會從測試和開發人員中分別挑選。在很多大項目中，測試和開發團隊可能并不在一個地區，甚至存在時差。如何增強跨地區小組成員的交流，使得資源共享、溝通及時無誤呢？這就需要有一個信息共享平臺。從我們的實際經驗中來看，wiki 是一個不錯的選擇。wiki 是一種多人協作的寫作工具，每個人都可以在上面發表意見。下面是作者正在參與的一個項目組所采用的 ODC 校驗小組 wiki 上的內容，包括如下方面。

• 目的：明確校驗工作的目的；
• 校驗小組人員名單：包括姓名和聯系方式；
• 校驗流程說明：針對本項目的特點，制定出適合本項目的校驗流程。以作者參與的項目為例，校驗流程可以包括：
  • 每周一，由 ODC 校驗小組負責人分配給每個人這周需要校驗的缺陷（分配的方式，會在下面的“每周工作安排”中提到）；
  • 校驗小組中的每位成員開始逐一校驗分配給自己的缺陷。如果發現該缺陷的 ODC 屬性有填寫不正確的或忘記填的，就需要馬上發郵件給該缺陷的發現者或解決者，予以修改。若缺陷本身的描述信息足以令校驗員分析出正確的選項，那么在郵件中需要寫明校驗員的修改意見及原因。若缺陷的描述信息不清晰以至于校驗員無法作出準確判斷的，也需要在郵件中指明。待測試或開發人員在缺陷中補充了更詳細的信息，校驗員再重新進行校驗。
  • 一旦校驗完成，校驗員需要在缺陷管理工具中對該缺陷進行標識，如前面我們提到的“ODC 是否已被校驗”屬性項，這時把它的值從默認值“否”修改為“是”。以表明該缺陷已被校驗過。校驗組長下次再分配待校驗的缺陷時，就會把已被校驗過的缺陷過濾掉。
  • 校驗員把在校驗過程中發現的問題，例如錯誤分類趨勢等進行反饋；
• 每周工作安排：
  • 可由如下表格進行工作分配和進展跟蹤。其中的前兩列由 ODC 校驗小組負責人在分配工作時填寫。后兩列由 ODC 校驗員在進行校驗工作時填寫。表 1 列出了一些可能出現的情況。

表 1. ODC 校驗工作分配 / 跟蹤表

表中的第三列“是否已被校驗”與缺陷管理工具中的“ODC 是否已被校驗”屬性項相對應，同樣有四個選項可供選擇：不填表示校驗人員還沒有開始對該缺陷進行校驗；“是”表示該缺陷已經被校驗完成，可以作為評估階段的統計數據；“否”表示該缺陷還處在校驗過程中，等待相關人員根據檢驗員指出的修改意見在缺陷管理工具中進行修改。在校驗員發出第一封郵件后的三天之內，若沒有得到相關人員的響應，校驗員需要發送第二封郵件，同時抄送相關人員的直接經理。以此督促相關人員盡快更改 ODC 屬性，以便該缺陷被標識為“已校驗”；“N/A”表示該缺陷為無效缺陷。

• 會議紀要：記錄、傳達每次例會的情況，便于日后查看和跟蹤。下面以作者參與的項目為例，會議紀要內容包括如下方面：
  • 參會人員：參會人員名單。
  • 公告：通常是上次會議待解決事情的進展或結果的說明。也可是重要的通知。
  • 本次會議討論內容：本次會議討論內容詳情。
  • 行動：
    • 根據會議討論的結果，有些是需要在會后付諸于行動的。這樣就需要把每個行動的內容和負責人記錄下來，以便下次會議進行跟蹤確認。下面舉例說明。如果本次會議記錄了如下兩條行動：
      • 某某去聯系缺陷管理工具的管理員，添加一個額外的屬性來記錄缺陷是否已被校驗過；
      • 某某去邀請 ODC 專家 David 來參與我們每周的例會，幫助我們解答校驗過程中遇到的問題。
      在下次會議開始的時候，首先要確認上次會議中這兩條行動是否已經實施。并把進度或結果在本次會議紀要中的公告部分進行說明。
• 參考資料的鏈接：
  • 關于 ODC 校驗工作和 ODC 分類說明的參考資料鏈接。

對于校驗小組長來說，如何更有效、更直接的分配校驗任務？

僅僅在 wiki 中列出工作分配表，雖然也可以進行任務分配和進度跟蹤，但由于并沒有跟缺陷管理工具相關聯，所以需要校驗人員根據表 1 中的缺陷編號，逐一在缺陷管理工具中進行查找。顯然這樣很浪費時間，也難免會在查找過程中發生錯誤。因此在缺陷管理工具中直接分配任務是更合適的辦法，同時利用表 1 中所示的 ODC 校驗工作分配 / 跟蹤表進行進度跟蹤。

在作者從事的項目中，我們采用在缺陷管理工具中增加一個名為 ODC Validator 的屬性，如圖 4 中所示。來供校驗小組長在分配任務時進行選擇。這樣校驗人員在登錄缺陷管理工具后，直接查詢 ODC Validator 屬性為自己名字的缺陷列表即可。

圖 4. ODC Responder 選項簽中新增加屬性 ODC Validator:

3. 評估階段

在確保輸入的 ODC 數據正確性的前提下，就可以對這些缺陷進行分析了。根據 ODC 的不同屬性進行分類統計，可得出不同方面的結論。以此來反映測試、開發或產品設計方面的問題，指出潛在的改進的機會。比如：缺陷被發現的如何、產品是否穩定等。下面挑幾個典型的評估方法進行說明。

對測試工作的評估

利用不同的 ODC 屬性的組合，可以從多方面來評估測試工作的完成情況。例如利用測試階段和 activity 屬性來評估是否應在某一測試階段中發現的缺陷卻被在下一測試階段中才發現；利用 activity 和 trigger 屬性來評估是否每個 activity 都使用了足夠多的與之對應的 trigger 來發現缺陷；利用時間和 trigger 屬性來評估是否隨著時間的推移測試變得更加復雜等。下面就利用第一種評估方法來進行舉例。

不同的測試階段有不同的測試重點。例如在功能測試階段，所對應的 activity 就是 Function Test( 功能測試 )。而在系統測試階段，所對應的 activity 就是 System Test（系統測試）。我們可以通過統計在每種測試階段中發現缺陷的 activity 來判斷是否本應在該測試階段中發現的缺陷被遺留到了下一測試階段。以此來評估測試工作的完成情況。如圖 5 所示。

圖 5. 利用測試階段和 activity 屬性得到的評估圖

由上圖我們可以看出，該項目在系統測試階段，有近一半缺陷的 activity 是功能測試。這說明本應該在功能測試階段發現的缺陷，卻被遺留到了系統測試階段才得以發現?？梢姽δ軠y試階段的測試工作做得不夠全面。

經驗和建議

• 這個評估方法常用于衡量是否本應該在功能測試階段發現的缺陷沒有被發現，而是到了系統測試階段才被發現。因此該評估方法最好在系統測試開始后使用，因為在此之前的階段使用沒有太大的幫助；
• 客觀上講，在系統測試階段發現一些功能測試階段的缺陷是正?，F象，這不會影響系統測試的正常運行。反而如果在系統測試階段沒有任何功能測試階段的缺陷，就說明有問題了。很可能是由于測試人員對 activity 屬性理解不正確導致的錯誤輸入引起的；
• 上圖所表現出來的問題是過多的本應在功能測試階段發現的缺陷卻在系統測試階段被發現。針對該問題，我們可以通過增加功能測試階段的測試用例來增加功能測試的覆蓋面?；蚴切薷墓δ軠y試階段的退出標準，例如必須發現多少缺陷才能進入系統測試階段等等。

對產品穩定度的評估

利用 ODC 屬性不僅可以評估測試工作的完成情況，同時還可以評估產品的穩定度。例如：隨著項目的進展，定期統計 qualifier 屬性的變化趨勢，以此來評估產品是否變得更加完善；或者定期統計 impact 屬性的變化趨勢，以此來評估影響產品功能性和可靠性的缺陷是否在減少。下面就以一個實例中的 qualifier 屬性為研究對象，來評估一下該實例是否隨著項目進展的過程而變得更加完善。如圖 6 所示。

圖 6. Qualifier 屬性趨勢圖

圖 6 顯示了 missing 和 incorrect 的百分比隨項目進展而發生的變化趨勢。對于一個逐漸趨向于穩定的產品來說，Qualifier 為 missing 的缺陷應該逐漸減少。因為任何未經測試過的新代碼的加入，都會增加潛在的風險。

但是從圖 6 中我們可以看到這個實例的穩定度并不樂觀。Qualifier 為 missing 的缺陷并沒有隨著項目的發展而有減少的趨勢。

經驗和建議

• 這個趨勢圖可以按周或月來定期查看趨勢變化；
• 看這個圖時，不能只籠統的看表面所反映的數據，missing 所占的百分比是多少，incorrect 占多少。還應該看到更深層的內容，比如那些 missing 的缺陷到底屬于哪個 defect type? 又是發生在哪些 component? 這樣才能夠發現真正的風險在哪里，以此判斷產品是否穩定。而不僅僅只是看到有多少百分比的缺陷的 Qualifier 是 missing；
• 上圖中的縱坐標是百分比。如果某個時間段里僅發現了很少的缺陷時，這種表現方式會造成誤解。因此看這種類型的評估圖時，既要看用百分比來展現的視圖，也要看用缺陷數作為縱坐標來展現的視圖。

對產品設計和代碼的評估

供開發人員填寫的 ODC 屬性中有一個屬性叫做 target。它表示開發人員為了修復這個缺陷，需要在哪方面做修改。比如可以修改的方面包括：design/code、build、information、language 等。為了評估產品在設計和代碼方面的完成情況，我們可以分析 target 是 design/code 的缺陷，利用其對應的 defect type 和 qualifier 屬性來發現產品在需求、設計和代碼階段的不足，以及在哪個薄弱環節更容易引入缺陷。下面以一個案例來說明如何利用 defect type 和 qualifier 屬性來評估。如圖 7 所示。

圖 7. 利用 Defect type 和 Qualifier 得到的評估圖

從圖 7 中我們可以看到 defect type 為 algorithm/method 的缺陷，qualifier 是 missing 和 incorrect 的比例及缺陷數量都很高。這說明產品的低層次的細節設計描述不完整，同時沒有被開發人員很好的理解；其次是 defect type 為 assignment-initialization 和 checking 的缺陷，它們的 incorrect 比例相對來說比較高，這反映了代碼編寫上還存在欠缺；最后我們看到 defect type 為 interface/O-O messages、relationship 和 timing/serialization 等的缺陷，其 qualifier 為 incorrect 和 missing 的數量都比較少，這說明產品在高層次的設計上和需求分析、理解上都還做得不錯。

經驗和建議

• 根據產品不同的 component，做出圖 7 這樣的評估圖，這樣比籠統的統計整個產品的 qualifier 和 defect type 屬性關系更有意義。因為這樣可以清楚的看到每個 component 的問題，然后針對每個 component 提出改進的解決辦法，以減少缺陷的注入。

4. 行動階段

僅僅發現了問題，是不夠的，還需要解決問題。根據評估過程中反映出的不同問題，有針對性的提出解決方案并讓相關人員采取行動。這一階段也是最能給產品帶來價值的。

經驗和建議

• 測試和開發團隊應該參與到這個過程中，因為他們才是最終行動的實施者；
• 所識別的行動應該是合理的，有可行性的；
• 所識別的行動越具體越好。不要籠統的指出對產品有什么改進行動，最好是能針對某個組件或是模塊，采取行動；
• 利用在評估階段生成的各種評估圖一起分析、衡量出改進的行動方案，不要單憑某一個評估圖來做決定；
• 要采取的行動應該是可以衡量的，這樣可以看出是否該行動對產品有積極的影響。

總結

正交缺陷分類（ODC）是一種缺陷分析方法，合理的把它運用在項目中，可以幫助測試、開發團隊改進工作，從而提高產品質量。明確 ODC 的流程及各階段的工作重點，并借鑒本文中提到的經驗建議，會讓讀者在運用 ODC 時更加得心應手。

原文轉自：https://www.ibm.com/developerworks/cn/rational/r-cn-odcprocessintroduction/