本文内容包括: 軟體開發中典型的品質問題 什麼是ODC？ 我們的案例項目的背景 你如何采用ODC？ ODC分析案例 行動計劃以及ODC各階段的建議 注釋 參考資料
本文來自于 Rational Edge：通過測試人員在軟體開發整個生命周期中揭示的一些缺陷，向測試團隊提供更加詳細的缺陷資訊，看看正交缺陷分類或者ODC是如何提高軟體品質的。 高性能軟體通常是很難産生的，現在的疊代化開發實踐對瀑布式方法有了巨大的改善，然而當通過測試工具分析代碼時，許多相當好的測試方法卻隻産生了一些缺陷記錄。通過這些簡單的記錄，很難确定軟體的适用性、設計文檔的适宜性、代碼的效率以及顧客的滿意度。
在過去的幾年裡，我已經通過在Rational環境中加入一種額外的測試技術改善了這種情況：ODC，其表示“正交缺陷分類”。它是缺陷分析一個革命性的方法，在充實了記錄的内容同時提供了一個系統的分析方法，可以追溯到缺陷的開發階段。ODC能夠提高測試的效率，監控品質狀态，向開發者提供改進的線索，同時有助于評估顧客的滿意程度。
在這篇文章中，我将和大家一起分享我在一個使用Rational開發環境的軟體項目中采用ODC方法的經驗。我們将看到ODC可以給我們帶來的許多好處，同時我将向大家提出一些關于實作ODC的建議。
軟體開發中典型的品質問題 究竟有多少缺陷？我們怎樣才能區分這些缺陷？通常情況下，我們可以收集盡可能多 的缺陷并将它們按照“嚴重程度”和“優先級”進行分類。是以我們可能在相同的嚴重程度和優先級發現幾百個缺陷情況，對于相同的缺陷我們的測試可能産生一百個執行個體。這些過于簡單的缺陷屬性不足于進行高品質的分析，原因有以下幾點： 首先，我們不知道每個缺陷引起的原因。術語“嚴重級别”和“優先級”的描述性并不很強，是以它們對開發團隊的幫助并不是很大。這裡并沒有幫助開發者來了解缺陷原因的方法，他們隻能通過手工搜尋這些缺陷的腳本來給他們定位。 第二，我們無法評估這些員工的工作效率。在一天内發現100多個嚴重程度為1的缺陷的人就是這個團隊最優秀的測試員嗎？即使這些缺陷都代表相同的問題。 第三，一個疊代或者階段的退出标準不完全。也就是說，因為我們不清楚每個缺陷的“類型”每個階段退出标準隻能建立在全面通過率的基礎上。當然 ，如果我們不知道關于這些缺陷更多的屬性，我們可以在适當的時間檢視合适的缺陷。 第四，這裡并沒有描述使用者感情的缺陷，是以開發者根本不知道顧客的滿意水準，一直到釋出以後。 事實上，我們需要更多的屬性來描述缺陷，并且需要一個相應的方法來分析這些額外的屬性。這些屬性與開發者和測試人員相關，與開發階段相關，與顧客的滿意程度也相關。通過分析這些屬性的結果可以提高軟體的品質，這是ODC的承諾。 什麼是ODC？ ODC在高層次上，是幫助擷取缺陷資訊的一個缺陷分類方案。但是它不僅僅是一個分類方案，ODC是一個軟體過程的度量系統，它是建立在包含于缺陷流中的語義資訊基礎上的。它可以幫助我們評估測試的效力和效率，可以進行錯誤跟蹤，通過方案背後的分析機制評估顧客的滿意度。
在這個簡單的術語中，ODC為測試人員的記錄定義了一組缺陷屬性。同時為分析這些缺陷提供了一組經驗性的規則。然後，可以根據這些分析，對提高軟體品質采取正确的措施。
在以下一個或者多個條件下，ODC是十分有用的：
開發生命周期相對來說是一個很漫長的過程，包括後續的改進工作。例如，這個項目包括多個軟體版本或者一個版本有多次疊代。 潛在的缺陷數目是相當大的。缺陷數目越多，客觀的分析結果也越多，對我們了解軟體品質越有好處。 這個項目已經将“高品質”設定為它的主要目标之一。 ODC通過搜集有用的資訊豐富了缺陷的屬性。ODC一共有8個屬性，如圖1所示。當一個測試人員發現并送出一個缺陷時，他可以給這個缺陷配置設定“活動（Activity）”、“觸發（Trigger）”、“影響（Impact）”這三個屬性。當一個開發人員修複或者回應了一個缺陷時，他可以配置設定“階段（Age）”、“來源（Source）”、“限定符（Qualifier）”、“類型（Type）”以及“目标（Target）”這些屬性。下面将介紹這些不同的屬性。 采用ODC改善軟體品質：一個案例研究 圖1：ODC的八個屬性.來源： ODC v5.11, IBM 軟體工程中心, www.research.ibm.com/softeng.
在ODC活動中，這個測試人員就是“ODC送出者”或者“ODC打開者”，我們稱呼開發人員為“ODC回應者”或者“ODC關閉者”。對這八個屬性的分别介紹如下所示：
活動就是當缺陷被發現時實際的處理步驟（代碼審查，功能測試等等）。 觸發 描述了暴露缺陷時存在的環境或者條件。 影響 就是對使用者或者是認識到的，或者是實際的影響。 目标 表示被修複實體的高層特性（例如，設計，代碼，ID，等等）。 類型 表示所進行的實際修正的種類。 限定符 指明了所進行的修複應歸于缺失，錯誤或者還是外來的代碼或者資訊。 來源 指明了發現的缺陷是出現在内部代碼編寫中，重用自一個程式庫中，從一個平台轉移到另一個平台上的，或者是外包一個軟體銷售商的。 階段 确定可擁有這個缺陷目标（比如設計，代碼，ID等等）曆史。 現在，ODC是由IBM Rational ClearQuest (RCQ)和Jmystiq支援的。2 我們可以将特殊的ODC屬性合并到RCQ 視窗和制表符中去。圖2顯示了我們将ODC使用者化以後的一個RCQ視窗。“ODC Submitter”和“ODC Responder”是兩個內建ODC八個屬性資訊的标簽。與ODC中獨創的屬性一起，我們同時可以獲得大量需要通過Jmystiq分析的資源，這些資源可以使ODC的分析變得更容易。 采用ODC改善軟體品質：一個案例研究 我們的案例項目的背景 我們的項目是一個典型的基于J2EE portal 技術的Web應用。這個項目屬于中等規模，大約由86,000行Java代碼和14,000行Java Server Pages代碼組成。這個項目使用了典型的疊代開發模式，并在最終版本之前包含多個疊代，如圖3所示。在這個項目上我們已經設定了相當高的品質目标。 采用ODC改善軟體品質：一個案例研究 圖3：案例項目中使用的疊代模式
這個項目包括十五個開發人員和測試人員，各自分成兩個團隊。在每一個開發階段，主要的角色要承擔的主要的責任也不相同。表1中顯示了這個項目開發的階段和相應的責任人，同時也包括最初在采取ODC方法之前的退出标準。
Table 1: Activities, owners, and exit criteria for stages of an iteration in a typical software development project. 活動 負責人 産生缺陷 退出标準 需求管理 負責人 No 代碼實作 開發者 No 單元測試 開發者 Yes (ClearQuest) 所有單元測試用例都通過。 代碼審查 開發者 Yes （ClearQuest） 所有代碼評審檢查單中的規則都通過。 功能測試 測試者 Yes （ClearQuest） 95% 測試用例通過。沒有嚴重程度級别 1 和 級别 2 未被修複的缺陷存在。 系統測試 測試者 Yes （ClearQuest） 95% 測試用例通過。沒有嚴重程度級别 1 和 級别 2 未被修複的缺陷存在。 使用者驗收測試 使用者 Yes （ClearQuest 和 Notes 資料庫） 沒有嚴重程度級别 1 和 級别 2 未被修複的缺陷存在。
你如何采用ODC？ ODC有它自己的生命周期，我們可以将它整合到疊代軟體開發的生命周期中去。随着疊代的進行，我們可以監控每個開發階段的軟體品質狀況。如果在我們的ODC分析結果中發現異常情況，我們可以采取糾正或者預防措施。
如圖4所示，ODC的生命周期包括六個步驟，由三個可能的角色，三個循環來實施，這将取決于所需的ODC步驟的數量。我将詳細闡述下面的這些概念。
采用ODC改善軟體品質：一個案例研究 圖4：通過三個不同顔色标明的角色實作六個ODC步驟
三個角色
ODC生命周期包括三個不同的角色：
團隊成員：這是ODC中最普通的角色。團隊成員就是開發者，測試人員或者使用者，他們負責輸入資料。 ODC核心：這個角色是一個ODC專家，其熟悉ODC的執行，并且可以幫助項目團隊進行正确的計劃和分析工作。ODC核心人物可以來自項目團隊的外部。 ODC的特殊團體：ODC的特殊團體負責活動計劃的建立、确認以及評估。這個團體是由來自不同團隊的人員組成的團隊。 三個循環
根據ODC所需的步驟的數量，它有三個可能的循環:
大循環：除了預備步驟，這個循環本身含有五個步驟。IDC計劃步驟與ODC的評估是相關聯的，并且它可以使評估更加有效。 中等循環：它包含四個步驟，這幾個步驟是ODC生命周期中的核心組成部分。盡管完整的ODC評估在這個循環中是不能得到的，一些有用的評估是可以被執行的。 小循環：這個循環包含兩個步驟。也就是說隻要找到一定數量的缺陷，随時可能發生确認的活動。 ODC的實作：六個步驟
這篇文章中我将闡述一個完整的大循環。通常循環中的一個步驟被看作是下一個步驟的基礎，上一個步驟的輸出是目前步驟的輸入。除了預備步驟，其他四個步驟形成一個支援疊代軟體開發的循環。
步驟1：預備階段
第一個步驟是十分重要的，對于那些以前沒有采用ODC的團隊來說尤其關鍵。在這個步驟中，我們需要做的事包括：
獲得采取ODC方法操作的準許和支援 采取ODC，要獲得開發團隊和測試團隊的允許 找到一個ODC的中心人物，邀請他/她提供一些ODC教育訓練和指導。 調查項目目前的狀況。比如，目前的開發生命周期是什麼？用什麼工具來進行缺陷跟蹤？如果這不是一個新項目。你應該考慮使用曆史資料的方法 給開發人員和測試人員指派ODC角色。這将有助于決定誰來負責計劃，執行确認，執行評估以及制作活動計劃。注意這些人應該包含ODC特殊團隊的成員。 在一個缺陷跟蹤工具上部署ODC計劃，比如Rational ClearQuest 指導兩輪内部教育訓練：一輪是關于ODC基本概念的教育訓練，另一輪是資料輸入和确認标準的教育訓練。在我們的案例項目中，我被邀請作為ODC的核心人物，同時也是開發團隊的成員。兩個ODC特殊團隊的人，一個來自開發團隊，另一個來自測試團隊。我們請我們Clear Quest團隊來幫我們部署ODC計劃。兩輪内部教育訓練之後，我們的ODC開發就正是開始了。 步驟2：計劃
計劃步驟的主要任務是定義“來源”，它在随後的資料輸入步驟中将會用到。這個步驟中産生的信号對評估退出标準是十分關鍵的。
在這個步驟中我們需要做的事包括以下幾個方面：
确定階段屬性：“階段（Age）”缺陷屬性有三點：新的（New）、基礎（Base）、重寫（Rewritten）。“新的”表示最近增加的代碼。“基礎”表示來自最後一個版本或者最後一次疊代的舊代碼。“重寫”表示已經被測試但是修改過的代碼。如果是一個全新的項目，那麼所有部分的代碼都是新的。 将項目分成元件：為了分析缺陷以及跟蹤到開發階段，我們應該将這個項目劃分成幾個元件。然後我們可以跟蹤缺陷到一些元件而不是整個程式階段。所有的資源包括代碼，文檔和配置文檔都應該劃分成幾個元件。你可以根據功能名稱，實體位置或者邏輯關系來建立這些元件。 為ODC的評估決定項目檢查點：在項目整個生命周期中的所有階段中，你應該計劃做兩次或者三次評估。比如，你可以在功能測試之後做評估，或者在UAT（使用者接受測試）後做。你執行ODC評估的檢查點和檢查時間将影響軟體品質的提高和效率。 确定你正在使用的開發模式：你目前所使用的開發模式将決定所需要的識别标志的數量。例如，如果你使用的是疊代開發模式，那麼識别标志就會被兩種方式其中的一種所控制。一種識别标志代表完整的過程，另一種表示每一次疊代。 建立計劃文檔: 一個ODC計劃應該包括記錄資源配置設定，工作進度以及評估步驟。 評審ODC計劃：在你正式開始之前，了解每個步驟資源配置設定是否平衡是十分重要的。更好的平衡就會得到更好的品質提高。 在我們的案例項目中，我們确定使用30％的階段屬性是基礎代碼，70％的是新代碼。我們将項目按照功能中的邏輯關系劃分為十二個元件，并使用ODC信号模闆編輯ODC計劃文檔。對這個文檔進行幾次評審以後，我們準備進入下一個步驟，資料輸入和确認。
步驟3和4：資料輸入和确認
我們可以将這兩個步驟合并成一個步驟。這裡的主要目的是提供一套可靠而且準确的缺陷資料記錄。
以下幾點是這兩個步驟中要特别注意的事項：
在資料輸入之前，確定所有的開發人員和測試人員都清楚地了解每個屬性的含義。 在資料輸入過程中，資料的格式應該由工具來控制。這些程式應該與缺陷狀态的轉換保持一緻。 資料輸入以後，需要一個完全的确認。這個确認過程可以由人工的方法來實作，也可以由自動操作來完成。過程内的 人工資料的有效性對于輸入資料的正确性十分關鍵。 在我們的案例項目中，我們使用Rational ClearQuest來采集資料輸入，并通過建立一些邏輯關系使用Jmystiq來實作自動确認。另外我們還建立一個特殊的指導方針確定所有的開發人員和測試人員了解這些屬性的意義。
步驟5：評估
這是一個收獲的步驟，收集到如此多優良的資料以後，你可以生成一個結果用來以下幾種方法來分析:
選項1：利用Jmystiq生成一個分析序列 選項2：生成一個ODC“退出評估報告”，并從它開始分析 選項3：為這個項目生成并選擇一些有意義的圖表 在開發生命周期的任何時候都可以進行評估。我們利用Jmystiq為評估産生一些圖表。當在圖表中發現不正常的現象時，我們可以設法從不同的方面來對它作出解釋。下面我将展示一些這種評估工作的例子。
樣例1：Opendate裡的觸發
在我們的案例項目中，當繪制“Opendate内部觸發的總次數”圖表（參見圖5）時，我們可以發現在功能測試階段之後出現了一些覆寫缺陷。造成這種缺陷可能有兩種原因。原因之一是測試效率不夠高，原因之二是重新修複或重寫代碼不夠理想。是以接下來在我們不得不研究“觸發與元件”以及“限定符與元件”的圖表，進而找出真正的原因。
采用ODC改善軟體品質：一個案例研究 圖5：我們可以看到一些覆寫缺陷（灰色标明的）是在功能測試之後發生的
樣例2：階段中的觸發
當我們繪制“階段（Age） 内部觸發的總次數”的圖表(圖6)時，發現基礎缺陷的比例相當大。另外兩張圖表“元件與活動”和“元件與階段”是确定相關原因的。如果我們在同一個元件同時發現了有新代碼的缺陷和有基礎代碼的缺陷，那麼這些缺陷反映的是最近附加代碼。這是造成這種現象最常見的原因。否則，這個問題就可能屬于無效的測試用例。
采用ODC改善軟體品質：一個案例研究 圖6：大量的基本缺陷應當進行進一步的調查研究。
樣例3：活動内部的觸發（Trigger）
當我們檢查“活動内部的觸發完全次數”圖表（圖7）時，發現在功能測試階段，覆寫與變體占主要地位。這可能标明單元測試或者詳細的計劃不夠充分，或者原計劃的綜合測試用例不夠充分，測試人員僅僅關注于基本功能要點
采用ODC改善軟體品質：一個案例研究 圖7：在功能測試階段，覆寫和變體占主導地位。
步驟6：活動
活動是最後一個步驟，這個時候應該設計一個正式的活動計劃，這個計劃能夠幫助我們不斷地提高軟體品質。這個活動計劃包括來自設計文檔的材料，特殊代碼元件，開發步驟或者測試方法。但是最重要的部分是下一次疊代或者下一次釋出所要采取的活動。這些活動的目标必須清楚而且是可度量的。緊記下一個階段中出現的問題往往是先前步驟中的錯誤導緻的。
ODC分析案例 我們的項目有三個品質目标：及時遞交産品，確定釋出之前沒有我們沒有發現的缺陷以及達到顧客的高度滿意。在這個部分我将展示幾個真實的案例，它們可以證明ODC是如何幫助我們實作這些目标并提高軟體品質的。
使用ODC提供更好的退出标準
我們的開發生命周期包含了幾個連續的階段。每個階段有它自己的退出點，它們是根據預先确定的退出标準來評估的。為每個階段設定準确而詳細的退出标準對于管理整個開發進度表是十分重要的。在采用ODC之前，我們每個階段的退出标準僅僅是根據測試用例的通過率來決定的。這雖然合理，但是并沒有更詳細的顆粒度。
有了ODC，我們可以根據不同的情形為每一個階段編制退出标準，它允許我們在适當的時候檢視更詳細的缺陷情況。這樣做，我們可以為以前的階段增加附助的标準，比如，“嚴重級别為1和2 的未确定缺陷是集中的或者是複雜的缺陷，我們就可以退出。”
利用ODC來評估設計和代碼的充分性
當我們遇到一個品質問題，我們需要了解這個問題存在于設計中還是編碼中。ODC在缺陷的記錄中提供了兩個屬性，我們可以根據這個記錄跟蹤原因一直到高水準的設計，低水準設計或者代碼中。
第一個屬性是“缺陷類型（Defect Type）”，它詳細說明了這個問題是否是與設計相關的。在圖8中，它用圖說明了缺陷類型與時間的關系，我們可以看到缺陷的不同類型，比如配置設定、校驗、運算法則以及打包。但是我們看不到任何帶有類型功能的缺陷。從ODC的原則看，這意味着高水準的設計是充分的。我們也可以看到有太多 Algorithm 類型的缺陷，這意味着低水準的設計還需要改進。
采用ODC改善軟體品質：一個案例研究 圖8：太多 Algorithm 類型的缺陷意味着低水準的設計需要改進。
另一個有用屬性是“限定符（Qualifier）”，圖9的圖表詳細标明了“缺陷類型中限定符的總次數”。它表明這個問題是否由代碼造成的。在圖9中我們找到幾個限定符：錯誤的（incorrect）、丢失的（missing）以及外來的（extraneous）。丢失的表明代碼本應在那現在卻不在。錯誤的表明代碼存在，但是編寫得不正确。在這個案例中，由于我們已經找到了很多帶有配置設定類型和運算法則類型的不正确的代碼，我們得知這個代碼編寫得很糟糕。大量帶有類型運算法則的丢失的缺陷反映了對詳細設計的誤解的問題。（我們會在下一個缺陷類型與元件圖表中獲得更多的詳細情況）
采用ODC改善軟體品質：一個案例研究 圖9：大量的帶有配置設定類型和運算法則類型的錯誤代碼表明這個代碼編寫得很糟糕。
用ODC評估測試的效率
測試效率對于確定産品品質是十分重要的。采用ODC之前，我們隻是簡單的依賴執行的測試用例來評估這個測試效率，但是這并不是一個很客觀的度量。ODC提供了觸發和階段兩個屬性來幫助我們跟蹤這個目标一直到開發生命周期不同的測試階段。
每個觸發都歸屬于某個特定的活動。缺少任何觸發意味着在相關活動中的測試不夠充分。在圖10中，我們可以看到在GUI評審活動中丢失了兩個觸發：輸入裝置和Widget/GUI行為。由于我們的項目提供了一個使用者界面，這兩個觸發是必需的。
采用ODC改善軟體品質：一個案例研究 圖10：我們觀察到在GUI 評審活動中丢失了兩個觸發：輸入裝置和Widget/GUI行為
我們重新看一下圖4，由于原計劃是由計劃編制階段的識别标志而産生的。在圖11中，我們可以看到原計劃與實際過程中存在的重大差異。首先，在實際過程中互相作用的比例比原計劃中的要少。這意味着我們在內建測試用例中要花費更多的精力。其次，變展現象在實際過程中占着主要的地位。由于目前階段不正常的現象反映了先前階段缺陷的問題，是以我們要通過單元測試來檢查其過程。最後，我們發現分界線和二者選一的單元測試是不夠充分的，同時我們還發現基本輸入類型的确認不夠完善。
采用ODC改善軟體品質：一個案例研究 圖11：原計劃方案與實際過程中存在着差異
在前面我對基礎（Base）和新的（New）的概念做過解釋。在圖12中我們可以看到基礎缺陷的百分比比新缺陷的高。這種現象可能表明先前的版本的測試不夠充分，我們應該對基礎代碼進行回歸測試。在圖12中我們還看到一些重寫和重新修複的缺陷。這可能表明重寫和重新修複的過程完成地不夠好。
采用ODC改善軟體品質：一個案例研究 圖12：基礎缺陷的百分比比新缺陷的高，這種現象可能表明先前的版本的測試不夠充分，我們應該對基礎代碼進行回歸測試。
用ODC評估缺陷修複的效率
有時候我們發現測試時間表會被延遲。我們可以通過嚴重級别的屬性來找到原因。
嚴重程度較大的缺陷需要配置設定更高的優先權。在圖13中，我們可以看到一些嚴重程度高的缺陷需要花費很多時間來關閉。
采用ODC改善軟體品質：一個案例研究 圖13：通過描繪缺陷“嚴重級别”與關閉“時間”關系的圖表，我們可以看到一些嚴重水準為1 的缺陷已經花時間解決了
ODC可被作為一種控制産品狀态的途徑
在使用ODC之前，我們根據缺陷嚴重水準來評估産品的品質，而且隻能近似估計産品總體品質。使用ODC以後我們可以針對詳細的品質相關特征做出可靠的定量分析，進而推斷我們産品品質的狀況。這些結果是十分客觀的。
圖14圖示是一個典型的“Opendate内的限制符總次數”的圖表。根據經驗我們估計丢失缺陷的比例應該在30％和40％之間，我們看到圖示顯示的丢失缺陷的百分比是35％，恰好在我們預計範圍之内。但是在後來的階段中仍然發現一些丢失的缺陷，是以我們應該找出此原因。
采用ODC改善軟體品質：一個案例研究 圖14：在後來的階段中仍然發現一些丢失的缺陷
使用ODC突出顯示涉衆關注點中的不比對
我們品質的目标是給顧客很高的滿意度。在采用ODC之前我們不能清楚地确定開發者與顧客之間關注點的不比對。ODC的屬性影響力可以幫助我們收集關于使用者滿意度的資訊，并找出顧客真正關注的焦點。
在圖15中，我們可以看到我們顧客關注的焦點是可用性。但是在圖16中，它反映開發生命周期中的狀況，我們發現我們并沒有充分關注可用性的測試。我們還看到大量的請求缺陷。這可能導緻進度的延遲，因為新的請求必須進入測試階段。
采用ODC改善軟體品質：一個案例研究 采用ODC改善軟體品質：一個案例研究 行動計劃以及ODC各階段的建議 從ODC的分析，可以發現我們開發生命周期中的優勢和難點，然後采取活動并改進。
行動計劃
我們的行動計劃有十二個具體的步驟，如下所示：
進行教育訓練來提高JavaServer Faces (JSF)/JSP技巧，因為絕大多數缺陷都位于UI元件。（請看圖8） 為具體的設計做一個模闆，使其具有更多相關可選擇的通道（請看圖8和圖9）。 設計并執行關于的輸入裝置和 Widget/GUI 行為測試用例（請看圖10）。 制定一個輸入确認的清單，它包括對精确數值、浮标、文本、資料等的确認（請看圖11）。 精心處理“單元測試執行”過程來確定單元測試的效率（請看圖12）。 對測試用例進行分類和分析，確定良好觸發的範圍，尤其是內建測試用例（請看圖11）。 通知測試團隊及時改寫代碼（請看圖12）。 精心處理“缺陷修複”過程進而避免重新修複的缺陷（請看圖12）。 對元件進行回歸測試，它是重寫缺陷和基礎缺陷集合而成的（請看圖13）。 更多得關注嚴重級别高的缺陷，無論我們對缺陷進行修複還是核查（請看圖13）。 将功能測試階段延長一周，因為在随後的階段發現的遺失缺陷位于一些重要的功能區域（請看圖14）。 草拟一個提高産品在頁面設計、頁面流程、功能性、重新組織等等方面可用性的計劃（請看圖15和圖16）。 采用ODC的建議
這裡我将對 ODC使用過程的各個階段提一些建議。
計劃編制階段
識别标志正确但是并不精确。我們可以求助一個對每個活動（觸發）都很熟悉的人來幫助完成配置設定的任務。 我們應該清楚地了解該采取哪種活動以及活動的順序是什麼，因為它并不反映報告結果。 資料輸入階段 一個新的需求通常是來自于市場，用以尋求他們認為顧客想要的一個新功能。我們通常不送出可用性的需求。 我們帶着特殊的使命來執行單個的活動。比如，當我們在功能測試階段發現一些UI問題時，我們怎樣來為這個缺陷選擇具體的活動呢？如果要想那個功能測試包含GUI測試，我們依然要對這些活動像功能測試一樣進行分類并。重要的是打開并對這個缺陷進行分類的人需要考慮分是，當他們沒有發現這個缺陷時他們實際上想要執行的是什麼活動。 如果有一個與我們工作相關的活動，我們應該将它與其他活動區分開來。比如，恰巧在功能測試階段發現了GUI活動，我們将會對GUI進行測試。這個在GUI測試中發現的缺陷活動被看作是GUI。 怎樣差別作用範圍和變體？這取決于發現這個缺陷在一個測試用例中還是兩個測試用例中？如果功能點在一個測試用例中是好的，而在另一個測試用例中失敗了，那麼關于這些功能要點的缺陷将被看作變體缺陷而送出。 當一個測試人員送出了一個缺陷，他或她應該輸入清楚的、詳細的而且正确的描述字段。同樣當一個開發人員解決了一個缺陷，他/她應該輸入清楚的、詳細的而且正确的字元字段。是以ODC集中要點，基于輸入的資料做出正确的确認。 當送出一個顧客缺陷時，這個輸入順序可能就域缺陷處理順序不一樣了。觸發屬性将在活動屬性之前輸入。 Web應用的一些輸入提示僅僅是：當Web King發現了缺陷，這個活動就是Code Inspector，觸發是Design Conformance，影響是Standard。如果Home Page Reader這個缺陷，活動是GUI Review，觸發是Design Conformance，影響是Accessibility。如果這個缺陷出現在聯機幫助、錯誤資訊或者螢幕資訊，那麼活動就是Documentation Review。 确認階段 所有關于資料輸入的提示都是合适的。 任何單個屬性值的主導地位都可能引起更深入的研究. 評估階段 評估的主要觀點來自于随後的分析階段發現的任何屬性的主要字段，異常的百分比或數量的趨勢和一些種類的缺陷（比如丢失的、覆寫等等）。 如果這個綜合缺陷的百分比不是這樣高，或許是件好事。我們隻要提前開始采取活動。我們可以比較其它觸發之間的比率來決定這個現象。 我們可以檢視無效的缺陷，它們可以幫助我們确定将來可能發生在教育訓練或者了解中的差距。 覆寫和變體是很簡單的，單個的功能測試；先後順序，互動關系，以及系統測試觸發都是複雜的測試場景。 缺陷的配置設定很大程度上受到順序、範圍和執行活動的精确度的影響。 總結
我一直專注于ODC實作方法來提高軟體品質。除此之外，以上給出的一些指導方針，幾個具體的要點需要關注：
開始階段的教育訓練活動對成功執行ODC是十分重要的。錯誤了解ODC概念将導緻偏差。 ODC的目标不僅僅是收集資料而是找到發展趨勢。 ODC本身是一個疊代過程可以幫助你不斷提高軟體品質。 就我的經驗而論，ODC能夠幫助開發人員和測試人員更好的合作。更重要的是，ODC可以幫助我們提高開發和測試的效率和效力。這些對品質的提高都十分關鍵。
這裡展示的範例是用來論證怎樣将ODC整合到軟體項目中的。無論你的項目是什麼類型，無論你目前面臨的是哪個開發階段，你都可以立即開始使用ODC。我相信隻要你按照這篇文章中的指導方針來制定具體的資料，就可以看到很大的改進。
注釋 1 Ram Chillarege 等人。“正交缺陷分類－－一個過程中測量的概念”，軟體工程的IEEE會報，1992年11月，編号11，第18卷。
2 JMYSTIQ （Java－－管理你的軟體并提高品質）是一個來自軟體開發和服務，用來進行分析缺陷資料的使用者友好的Java工具。它是組織使用ODC（正交缺陷分類）和OPC（正交問題分類）方法所必需的工具，用來擷取缺陷資訊。檢視 https://www.ibm.com/ibm/cas/archives/2004/demos/ 獲得更多的資訊
參考資料 ODC基本概念：http://w3.research.ibm.com/softeng/ODC/DETODC.HTM
Jmystiq的幫助系統。
M. Butcher，H. Munro，T. Kratschmer，“通過ODC改進軟體測試：三個案例研究”。IBM 系統刊物，2002年，編号1，第41卷。
Ram Chillarege 和 Kothanda Ram Prasad，“測試與開發過程的回顧―――使用ODC觸發的個例研究”
Kathryn Bassin，“軟體開發中的監測與評估”。
Ram Chillarege，Inderpal S. Bhandari，Jarir K.Chaar，Michael J. Halliday，Diane S. Moebus，Bonnie K. Ray，Man-Yuen Wong，“正交缺陷分類－－一個過程中度量的概念”軟體工程的IEEE會報，1992年11月，編号11，第18卷。
Ram Chillarege 和 Shriram Biyani，“使用ODC基礎增長模式鑒定風險”
Diane Kelly 和 Terry Shepard，“缺陷分類與審查中的一個案例研究”
![Xcode中建立Target的步驟[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)
