基于ODC的軟件缺陷度量研究

摘 要:從正交缺陷分類(orthogonal defect classification，ODC)出發(fā)，介紹在缺陷度量前需要收集的缺陷數(shù)據(jù)信息，闡述了缺陷屬性的具體分類，然后從單維度和多維度兩個角度介紹了如何利用ODC的缺陷屬性進行度量分析，并給出了軟件組織應(yīng)用ODC的流程，最后提供了正交缺陷分類方法的應(yīng)用實例，為缺陷度量的應(yīng)用研究提供了一種思路。

關(guān)鍵詞:軟件度量; 缺陷度量; 正交缺陷分類

中圖分類號:TP311

文獻標(biāo)志碼:A

文章編號:1001-3695(2010)02-0563-03

doi:10.3969/j.issn.1001-3695.2010.02.044

Software defect metric based on orthogonal defect classification

CHEN Ai-zhen， ZENG Fu-ping， LU Min-yan

(Dept. of System Engineering of Engineering Technology， Beihang University， Beijing 100191， China )

Abstract:Firstly， according to the orthogonal defect classification， this paper described the defect data information which should be collected before defect measurement execution. Secondly， it described how to use the orthogonal defect classification for measurement analysis from the views of single dimension and multi-dimensional. Thirdly， presented the application process in the software organization. Finally， elaborated the application example. The study of this paper offered a new thought to the application of defect measurement.

Key words:software metric; defect metric; orthogonal defect classification(ODC)

如何評價軟件產(chǎn)品的質(zhì)量以及更好地對軟件過程進行管理和改進是長期困擾軟件業(yè)界的問題。近年來，軟件界許多專家提出了以軟件缺陷數(shù)據(jù)為核心的觀點[1]。在軟件開發(fā)和測試過程中貫穿著缺陷的引入、發(fā)現(xiàn)、修復(fù)和關(guān)閉的過程，如何充分利用這些缺陷信息進行軟件過程改進和產(chǎn)品質(zhì)量的評估是當(dāng)前研究的熱點。軟件缺陷度量是軟件組織對軟件的質(zhì)量和過程進行評估和預(yù)測的常用手段之一。定量的統(tǒng)計缺陷模型和定性的缺陷根原因分析是兩種傳統(tǒng)的缺陷度量方法。前者用數(shù)學(xué)的方法抽象和統(tǒng)計缺陷的數(shù)量，在開發(fā)過程的后期得到一些相關(guān)的分析報告。后者用自然語言描述單個缺陷的根本原因和表現(xiàn)形式，是對單個缺陷的精確分析。顯然，定量和定性的方法是軟件缺陷度量的兩個極端，它們無法實現(xiàn)對缺陷信息的全面分析，以及將度量的結(jié)果及時反饋給開發(fā)人員。

正交缺陷分類(ODC)技術(shù)是IBM TJ Watson研究中心的Chillarege[2]在1992年提出的概念。該方法是一種介于定性和定量之間的分析方法，它在統(tǒng)計缺陷模型和缺陷根原因分析之間架起了一座橋梁[2]。

目前業(yè)界已有一些關(guān)于ODC的研究，如文獻[3，4]分別介紹了缺陷類型屬性和缺陷觸發(fā)屬性的研究與應(yīng)用;文獻[5]介紹了ODC在電信行業(yè)的應(yīng)用;文獻[6]介紹了缺陷觸發(fā)在測試過程中應(yīng)用的一個案例。上述關(guān)于ODC的研究已有一些成果，但也存在一些不足:對ODC的研究更多地集中在理論上的研究，針對軟件組織如何應(yīng)用ODC進行缺陷度量的研究較少，這樣就導(dǎo)致了軟件組織在掌握ODC的基本知識后不知道如何應(yīng)用于本企業(yè)。因此，本文將從ODC缺陷分類、ODC缺陷度量以及ODC的應(yīng)用流程進行較為系統(tǒng)的分析，從而使軟件組織更容易地應(yīng)用ODC進行缺陷度量。

1 正交缺陷分類方法

1.1 ODC缺陷分類

ODC在高層次上，是幫助獲取缺陷信息的一種缺陷分類方法，它所定義的缺陷屬性是IBM公司在總結(jié)了大量的項目經(jīng)驗后抽象得到的。ODC的特征屬性[7，8]包括發(fā)現(xiàn)缺陷的活動、缺陷的影響、缺陷觸發(fā)、缺陷的修復(fù)對象、缺陷類型、缺陷限定詞、缺陷來源、缺陷歷史。在應(yīng)用ODC進行缺陷數(shù)據(jù)收集時，分為發(fā)現(xiàn)缺陷和修復(fù)缺陷兩個階段進行，如圖 1所示。

a)當(dāng)測試人員或用戶發(fā)現(xiàn)一個缺陷時需要定義以下三個屬性:

(a)活動屬性，指發(fā)現(xiàn)缺陷的活動，即發(fā)現(xiàn)缺陷的測試類型，如設(shè)計檢查、代碼審查、單元測試、功能測試和系統(tǒng)測試等。

(b)觸發(fā)屬性，指促使缺陷被發(fā)現(xiàn)的環(huán)境或條件。通常，測試人員在發(fā)現(xiàn)缺陷時，需要描述缺陷發(fā)現(xiàn)的條件和環(huán)境，以利于缺陷的復(fù)現(xiàn)。Trigger屬性正是用來描述促使?jié)撛谌毕蒿@露出來成為一個可見的故障所必須具備的環(huán)境或條件。例如，在軟件代碼審查中發(fā)現(xiàn)C語言中的相等判斷符號“= =”，被誤寫成了賦值符號“=”，那么該缺陷的trigger屬性應(yīng)取值為language dependency。其含義是在進行與編程語言相關(guān)的檢查時發(fā)現(xiàn)缺陷。由于不同的測試活動發(fā)現(xiàn)軟件缺陷的方法或手段是不相同的，可以建立活動屬性和觸發(fā)屬性之間的映射關(guān)系，如表 1所示。

表1 Trigger與activity的映射關(guān)系

活動設(shè)計檢查和代碼審查單元測試功能測試系統(tǒng)測試

觸發(fā)設(shè)計一致性邏輯/流程向后兼容橫向兼容并發(fā)性內(nèi)部文檔語言依賴性邊效應(yīng)極少出現(xiàn)的情況簡單路徑復(fù)雜路徑覆蓋率變更時序交互作用工作量壓力恢復(fù)例外啟動重啟硬件配置軟件配置

(c)影響屬性，指假定或者實際的對用戶的影響。如果缺陷是測試人員在測試過程中發(fā)現(xiàn)的，則由測試人員假定或推測判斷該缺陷如果未被發(fā)現(xiàn)而逃逸到用戶使用現(xiàn)場將對用戶造成的影響;如果缺陷是用戶在實際使用中發(fā)現(xiàn)的，則由用戶定義缺陷對用戶實際產(chǎn)生的影響。該屬性可劃分為13個子屬性，包括安裝性、完整性/安全性、文檔、需求、服務(wù)性、標(biāo)準(zhǔn)、移植性、可靠性、性能、維護性、可用性、能力、易用性。

b)當(dāng)開發(fā)人員接到一個缺陷，并且開始修復(fù)缺陷時，需要定義以下屬性:

(a)修復(fù)對象屬性，指修復(fù)缺陷的最高層的描述，即為了修改這個缺陷，需要追溯到哪個軟件階段、哪些軟件產(chǎn)品。例如，缺陷描述為:數(shù)據(jù)庫記錄的數(shù)據(jù)太多將會影響到軟件的性能。通過分析為了修復(fù)該缺陷需要更改設(shè)計，則該缺陷的Target屬性為設(shè)計。target屬性可以劃分為六個子屬性，分別為需求、設(shè)計、代碼、構(gòu)造/打包、開發(fā)信息、國際語言支持。

(b)缺陷類型屬性，指需要采取什么解決方案修復(fù)缺陷。例如，缺陷是由于沒有對變量初始化而造成的，那么缺陷類型屬性就應(yīng)定義為初始化。由于缺陷修復(fù)的目標(biāo)不同，其修改的方案也是不一樣的。針對修復(fù)對象為設(shè)計和代碼時，缺陷類型的劃分包括七個子屬性，分別為賦值/初始化、檢查、算法/方法、功能/類/對象、時間/序列、接口/面向?qū)ο笙⒑完P(guān)系。

(c)限定詞屬性，指缺陷的性質(zhì)，是遺漏的、錯誤的還是不相關(guān)的。該屬性是對缺陷類型的補充說明。在度量應(yīng)用中可利用該屬性來判斷軟件產(chǎn)品代碼是否完整。

(d)來源屬性，指缺陷引入的最根本的來源，即缺陷是通過什么途徑引入的。可能的引入來源包括內(nèi)部開發(fā)、重用庫、外購和移植。

(e)歷史屬性，指缺陷的歷史，即該缺陷是以前版本中存在的新代碼、修復(fù)缺陷時引入的，還是重寫代碼時引入的。

1.2 ODC缺陷度量

缺陷分類的目的不僅是為了對缺陷進行更好的管理，更重要的在于可以利用缺陷信息進行缺陷度量分析。缺陷度量是為了定量地對缺陷進行分析，提供有關(guān)軟件過程的反饋信息[9，10]。因此，“只收集數(shù)據(jù)，不進行分析”是錯誤的做法，收集數(shù)據(jù)并不是最終的目的，只有通過對缺陷數(shù)據(jù)進行度量分析，才能夠掌握軟件產(chǎn)品的質(zhì)量情況，及早發(fā)現(xiàn)開發(fā)過程中存在的問題，以及度量測試的有效性等。

ODC不僅僅是一個缺陷分類方法，它還是建立在其定義的缺陷語義信息基礎(chǔ)上的度量方法。文獻[11]對ODC在度量方面的應(yīng)用進行了研究，并給出了ODC度量的一些常見模式，如表 2所示，可以為企業(yè)在進行缺陷度量時提供參考。

表2 正交缺陷分析的一些常見模式

度量目標(biāo)ODC屬性非ODC屬性

評估產(chǎn)品的穩(wěn)定性缺陷類型，影響，限定詞，來源，缺陷歷史發(fā)現(xiàn)缺陷時間，嚴重等級，修復(fù)缺陷時間，模塊

度量測試的有效性活動，觸發(fā)，限定詞發(fā)現(xiàn)缺陷時間，嚴重等級，模塊，階段

鑒別設(shè)計和代碼中的強處和不足缺陷類型，限定詞模塊

度量客戶的使用方法影響，觸發(fā)，缺陷類型，限定詞發(fā)現(xiàn)缺陷時間，嚴重等級，模塊

度量進度活動，觸發(fā)嚴重等級，模塊，階段

2 ODC缺陷度量方法研究

本文將在充分理解ODC缺陷分類方法的基礎(chǔ)上，從單維度和多維度兩個角度對ODC缺陷度量方法進行研究。

1)單維度分析 即單獨對一個缺陷屬性進行度量分析。由于ODC定義了八大屬性，可以分別對八大屬性進行單維度分析。應(yīng)用ODC進行單維度分析的步驟如下:

a)軟件組織可以根據(jù)以往軟件項目的歷史數(shù)據(jù)確定軟件過程中發(fā)現(xiàn)的缺陷屬性分布情況，從而確定八大缺陷屬性的期望分布。

b)針對每個缺陷屬性進行分析時，把當(dāng)前項目發(fā)現(xiàn)的缺陷屬性分布情況與期望分布的缺陷特征分布進行比較，觀察是否存在異常分布趨勢或異常特征點。

c)針對每個缺陷屬性存在的異常情況，分析該異常產(chǎn)生的原因，確定軟件產(chǎn)品或軟件過程存在的問題，并采取具體的改進措施。

2)多維度分析 即結(jié)合兩個或兩個以上的缺陷屬性進行分析。例如，在評估產(chǎn)品的穩(wěn)定性時，可以結(jié)合缺陷類型和限定詞進行分析，如圖 2所示。

在發(fā)現(xiàn)某一缺陷類型出現(xiàn)異常時，可以同時得到該缺陷類型的限定詞信息，即是遺漏的、錯誤的還是不相關(guān)的缺陷占的比重較大。因此，可以提供更豐富的信息以確定軟件產(chǎn)品和軟件過程的問題。

一般而言，缺陷發(fā)現(xiàn)的活動可以與其他屬性結(jié)合在一起分析，以掌握不同活動發(fā)現(xiàn)的缺陷其他屬性分布情況。但是，其他的缺陷屬性之間并不是都可以隨便組合的，應(yīng)該以企業(yè)自身度量的目的為驅(qū)動，有針對性地選取兩個或兩個以上的缺陷屬性進行分析，這樣得到的結(jié)果才會更有指導(dǎo)意義。如果軟件組織不知道如何選取缺陷屬性進行組合，那么可以參考表 2。

3 ODC缺陷度量流程

雖然IBM公司已經(jīng)給出一套完備的缺陷分類屬性，包括八大關(guān)鍵屬性和164個子屬性，但是不同的軟件組織的缺陷有著不同的特征。軟件組織在應(yīng)用ODC時，需要根據(jù)軟件組織的實際情況借鑒其相似的缺陷屬性，而對于差異較大的缺陷屬性需要根據(jù)實際情況在深刻理解ODC八大屬性的基礎(chǔ)上對其進行改造。在缺陷度量時，可以結(jié)合軟件組織的度量目的，參考表 2和軟件組織實際情況綜合分析選擇缺陷屬性數(shù)據(jù)。基于ODC的缺陷度量應(yīng)用流程(圖3)可以歸納為下面的幾個步驟:

a)準(zhǔn)備條件:深刻理解ODC的八大屬性，了解軟件組織的缺陷特征及缺陷分類;

b)ODC改造:基于對ODC八大屬性的深刻理解，依據(jù)軟件組織自身的缺陷特點對ODC的子屬性進行改造;

c)收集缺陷數(shù)據(jù):在度量目的的指導(dǎo)下，選擇適當(dāng)?shù)亩攘浚瑧?yīng)用改造后的ODC進行缺陷數(shù)據(jù)的收集;

d)實施缺陷度量:應(yīng)用改造后的ODC模型，根據(jù)度量的目的選擇度量，并收集缺陷數(shù)據(jù)，進行缺陷度量。

e)分析數(shù)據(jù):對度量中的異常數(shù)據(jù)進行分析。

f)制定改進措施:根據(jù)異常數(shù)據(jù)分析的結(jié)果結(jié)合具體的實際情況制定改進措施。

4 ODC缺陷度量應(yīng)用

4.1 ODC改造

上面介紹的ODC缺陷度量應(yīng)用流程，為軟件組織應(yīng)用ODC進行缺陷度量提供了一種思路。本文將ODC應(yīng)用于某軟件測試組織收集的缺陷數(shù)據(jù)，并根據(jù)軟件測試組織的自身特點對ODC進行改造，得到的改造結(jié)果如表 3所示。

表3 某軟件組織改造ODC結(jié)果

ODC屬性O(shè)DC子屬性

活動文檔審查代碼審查單元測試系統(tǒng)測試

觸發(fā)種類、標(biāo)志、內(nèi)容、格式邏輯、數(shù)據(jù)、接口、注釋、文檔、可追溯性、例外情況處理、內(nèi)存復(fù)雜路徑、簡單路徑功能、性能、接口、邊界、強度、余量、安全性、恢復(fù)性、人機交互界面、可靠性、安裝性、容量、互操作性、敏感性、數(shù)據(jù)處理

影響功能、安裝性、可移植性、效率、可維護性、可靠性

類型需求、設(shè)計、代碼、其他

限定詞多余、錯誤、遺漏

修復(fù)對象文檔、代碼

來源開發(fā)、測試

歷史基礎(chǔ)、修復(fù)

4.2 缺陷度量

本節(jié)將在上述缺陷分類的基礎(chǔ)上，從單維度和多維度兩方面對缺陷信息進行度量分析。通過收集六個軟件項目的缺陷數(shù)據(jù)來確定其缺陷屬性的期望分布。

1)單維度分析 通過對六個軟件項目在不同測試活動中發(fā)現(xiàn)的缺陷數(shù)進行統(tǒng)計分析，可得到如圖 4所示的期望分布情況。

依據(jù)期望分布情況，對某直升機的晝夜觀瞄裝置管理軟件進行度量分析。通過采集其不同測試活動發(fā)現(xiàn)的缺陷數(shù)，并將其與該期望分布情況進行比較，如圖 5所示。

由圖 5可以看出，該軟件項目在代碼審查和系統(tǒng)測試活動中發(fā)現(xiàn)的缺陷數(shù)較多，即該軟件在代碼審查和系統(tǒng)測試活動的測試較為充分。文檔審查活動發(fā)現(xiàn)的缺陷較少的原因可能是軟件組織的文檔化管理比較完善。通過了解軟件組織的情況，發(fā)現(xiàn)該軟件組織的文檔都已經(jīng)按照標(biāo)準(zhǔn)制定了各種文檔的模板，包括文檔需要介紹的內(nèi)容、格式等都進行了明確的規(guī)定。

2)多維度分析 在進行多維度分析時，可以同時考慮兩個及兩個以上的缺陷屬性。本文結(jié)合測試活動和缺陷觸發(fā)兩個屬性進行分析，以期了解某一測試活動的缺陷觸發(fā)分布情況。如圖 6所示，給出了某一測試項目文檔審查階段的缺陷觸發(fā)與期望分布的比較情況。

由圖 6可以看出，該軟件項目在文檔審查階段，格式觸發(fā)發(fā)現(xiàn)的缺陷比期望分布多，因此，需要與開發(fā)人員確認軟件的文檔是否按照軟件工程化的格式要求進行編寫，并及時提醒開發(fā)人員應(yīng)注意文檔的格式，以提高文檔的可讀性和可維護性。同樣，該軟件項目中內(nèi)容觸發(fā)發(fā)現(xiàn)的缺陷比期望分布少，因此，需要了解測試過程中對文檔內(nèi)容的審查是否充分。在資源允許的情況下，測試人員可以對該軟件項目的內(nèi)容進行更全面的審查。

5 結(jié)束語

軟件缺陷度量的目的在于充分利用軟件開發(fā)和測試過程中發(fā)現(xiàn)的缺陷數(shù)據(jù)，挖掘其有用的信息，為評價軟件產(chǎn)品質(zhì)量，以及制定測試和開發(fā)過程的改進決策提供數(shù)據(jù)基礎(chǔ)。本文闡述了基于ODC進行缺陷度量的應(yīng)用。但是，如何利用缺陷度量的結(jié)果制定更為合理的改進措施，將作為以后研究工作的重點。

參考文獻:

[1]陳莉. 正交缺陷分類方法在軟件缺陷管理及分析中的應(yīng)用[D].長沙:湖南大學(xué)，2005.

[2]CHILLAREGE R. Orthogonal defect classification:a concept for in-process measurements [J]. IEEE Trans on Software Engineering， 1992，18(11):943-956.

[3]袁東林. 基于正交缺陷分類的軟件過程測量方法[J]. 計算機應(yīng)用與軟件， 2007，24(3):65-38，73.

[4]袁東林. 利用正交缺陷分類技術(shù)測量軟件驗證過程的有效性[J]. 計算機應(yīng)用研究， 2006，23(4):81-84.

[5]潘鐵軍， 鄭蕾娜. 基于正交分類的軟件缺陷跟蹤系統(tǒng)[J]. 計算機工程與應(yīng)用， 2007， 43(13):76-79，101.

[6]CHILAREGE R. Test and development process retrospective:a case study using ODC triggers[C]//Proc of the International Conference on Dependable Systems and Networks. 2002.

[7]CHILLAREGE R. ODC for process measurement， analysis and control[C]//Proc of the 4th International Conference on Software Quality. 1994:10-15.

[8]ODC official website[EB/OL]. (2002). http://www.research.ibm.com/softeng/ODC/ODC.HTM.

[9]United Kingdom Software Metrics Association. Quality standards defect measurement manual [S].2000

[10]胡冠林，汪厚祥.軟件缺陷分類及其度量技術(shù)研究[J]. 艦船電子工程， 2005，25(3):55-58.

[11]BUTCHER M， MUNRO H， KRATSCHMER T. Improving software testing via ODC:three case studies[J]. IBM Systems Journal， 2002，41(1):31.