采用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）”這些屬性。下面將介紹這些不同的屬性。

圖1：ODC的八個屬性.來源： ODC v5.11, IBM 軟件工程中心, www.research.ibm.com/softeng.

在ODC活動中，這個測試人員就是“ODC提交者”或者“ODC打開者”，我們稱呼開發人員為“ODC回應者”或者“ODC關閉者”。對這八個屬性的分別介紹如下所示：

• 活動就是當缺陷被發現時實際的處理步驟（代碼審查，功能測試等等）。
• 觸發 描述了暴露缺陷時存在的環境或者條件。
• 影響 就是對用戶或者是認識到的，或者是實際的影響。
• 目標 表示被修復實體的高層特性（例如，設計，代碼，ID，等等）。
• 類型 表示所進行的實際修正的種類。
• 限定符 指明了所進行的修復應歸于缺失，錯誤或者還是外來的代碼或者信息。
• 來源 指明了發現的缺陷是出現在內部代碼編寫中，重用自一個程序庫中，從一個平臺轉移到另一個平臺上的，或者是外包一個軟件銷售商的。
• 階段 確定可擁有這個缺陷目標（比如設計，代碼，ID等等）歷史。

現在，ODC是由IBM Rational ClearQuest (RCQ)和Jmystiq支持的。² 我們可以將特殊的ODC屬性合并到RCQ 窗口和制表符中去。圖2顯示了我們將ODC用戶化以后的一個RCQ窗口�！癘DC Submitter”和“ODC Responder”是兩個集成ODC八個屬性信息的標簽。與ODC中獨創的屬性一起，我們同時可以獲得大量需要通過Jmystiq分析的資源，這些資源可以使ODC的分析變得更容易。

圖2：一個在定制ODC后的Rational ClearQuest窗口�！癘DC Submitter”和“ODC Responder”是收集ODC八個屬性信息的兩個頁簽

我們的案例項目的背景

我們的項目是一個典型的基于J2EE portal 技術的Web應用。這個項目屬于中等規模，大約由86,000行Java代碼和14,000行Java Server Pages代碼組成。這個項目使用了典型的迭代開發模式，并在最終版本之前包含多個迭代，如圖3所示。在這個項目上我們已經設置了相當高的質量目標。

圖3：案例項目中使用的迭代模式

這個項目包括十五個開發人員和測試人員，各自分成兩個團隊。在每一個開發階段，主要的角色要承擔的主要的責任也不相同。表1中顯示了這個項目開發的階段和相應的責任人，同時也包括最初在采取ODC方法之前的退出標準。

你如何采用ODC？

ODC有它自己的生命周期，我們可以將它整合到迭代軟件開發的生命周期中去。隨著迭代的進行，我們可以監控每個開發階段的軟件質量狀況。如果在我們的ODC分析結果中發現異常情況，我們可以采取糾正或者預防措施。

如圖4所示，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）�！靶碌摹北硎咀罱�增加的代碼�！盎�礎”表示來自最后一個版本或者最后一次迭代的舊代碼�！爸貙憽北硎疽呀洷粶y試但是修改過的代碼。如果是一個全新的項目，那么所有部分的代碼都是新的。
• 將項目分成組件：為了分析缺陷以及跟蹤到開發階段，我們應該將這個項目劃分成幾個組件。然后我們可以跟蹤缺陷到一些組件而不是整個程序階段。所有的資源包括代碼，文檔和配置文檔都應該劃分成幾個組件。你可以根據功能名稱，物理位置或者邏輯關系來創建這些組件。
• 為ODC的評估決定項目檢查點：在項目整個生命周期中的所有階段中，你應該計劃做兩次或者三次評估。比如，你可以在功能測試之后做評估，或者在UAT（用戶接受測試）后做。你執行ODC評估的檢查點和檢查時間將影響軟件質量的提高和效率。
• 確定你正在使用的開發模式：你當前所使用的開發模式將決定所需要的識別標志的數量。例如，如果你使用的是迭代開發模式，那么識別標志就會被兩種方式其中的一種所控制。一種識別標志代表完整的過程，另一種表示每一次迭代。
• 創建計劃文檔: 一個ODC計劃應該包括記錄資源分配，工作進度以及評估步驟。
• 評審ODC計劃：在你正式開始之前，了解每個步驟資源分配是否平衡是十分重要的。更好的平衡就會得到更好的質量提高。

在我們的案例項目中，我們確定使用30％的階段屬性是基礎代碼，70％的是新代碼。我們將項目按照功能中的邏輯關系劃分為十二個組件，并使用ODC信號模板編輯ODC計劃文檔。對這個文檔進行幾次評審以后，我們準備進入下一個步驟，數據輸入和確認。

步驟3和4：數據輸入和確認

我們可以將這兩個步驟合并成一個步驟。這里的主要目的是提供一套可靠而且準確的缺陷數據記錄。

以下幾點是這兩個步驟中要特別注意的事項：

• 在數據輸入之前，確保所有的開發人員和測試人員都清楚地了解每個屬性的含義。
• 在數據輸入過程中，數據的格式應該由工具來控制。這些程序應該與缺陷狀態的轉換保持一致。
• 數據輸入以后，需要一個完全的確認。這個確認過程可以由人工的方法來實現，也可以由自動操作來完成。過程內的 人工數據的有效性對于輸入數據的正確性十分關鍵。

在我們的案例項目中，我們使用Rational ClearQuest來采集數據輸入，并通過創建一些邏輯關系使用Jmystiq來實現自動確認。另外我們還創建一個特殊的指導方針確保所有的開發人員和測試人員理解這些屬性的意義。

步驟5：評估

這是一個收獲的步驟，收集到如此多優良的數據以后，你可以生成一個結果用來以下幾種方法來分析:

• 選項1：利用Jmystiq生成一個分析序列
• 選項2：生成一個ODC“退出評估報告”，并從它開始分析
• 選項3：為這個項目生成并選擇一些有意義的圖表

在開發生命周期的任何時候都可以進行評估。我們利用Jmystiq為評估產生一些圖表。當在圖表中發現不正常的現象時，我們可以設法從不同的方面來對它作出解釋。下面我將展示一些這種評估工作的例子。