楊勛姮，段明璐

（華北計算技術(shù)研究所 軟件測評中心，北京 100083）

0 引言

隨著技術(shù)的不斷發(fā)展和人類文明的不斷進步，以軟件為基礎(chǔ)的產(chǎn)業(yè)發(fā)展迅猛，軟件已經(jīng)由以往的單一結(jié)構(gòu)逐漸向復(fù)雜結(jié)構(gòu)轉(zhuǎn)變，航空航天等領(lǐng)域武器裝備系統(tǒng)的結(jié)構(gòu)復(fù)雜度不斷提高，對系統(tǒng)進行缺陷分析是變得越來越重要的。

從開始進入軟件領(lǐng)域，我們就一直被反復(fù)教導(dǎo)一個由無數(shù)慘痛教訓(xùn)總結(jié)出的道理：缺陷在研發(fā)過程的越早期被發(fā)現(xiàn)，其造成的影響和修復(fù)帶來的成本就會越低[1]。

曾經(jīng)有研究顯示，如果在需求分析階段發(fā)現(xiàn)并修復(fù)一個缺陷的成本為 1，在編碼實現(xiàn)階段發(fā)現(xiàn)并修復(fù)缺陷成本就增長到了15，而到了測試階段一躍而升變?yōu)?5，如果到了最終交付用戶使用后才發(fā)現(xiàn)并修復(fù)，成本甚至可以到75。對于不同階段注入的單位缺陷，修復(fù)成本和發(fā)現(xiàn)階段的關(guān)系如圖1所示：

從圖1可以看出，項目開發(fā)后期修復(fù)缺陷的成本已經(jīng)高到了初期修復(fù)成本的75倍，而且返工次數(shù)也隨著項目進行而大幅提高。如果在交付用戶后發(fā)現(xiàn)了一個缺陷需要修復(fù)，必須要重新修改設(shè)計和編碼，然后再次進行評審和測試。

為了達到這些需求，本文首先會介紹軟件缺陷分析的相關(guān)知識，然后列舉目前主流的軟件缺陷分析方法進行一一進行闡述，最終將六種缺陷分析方法綜合進行比較。

圖1 缺陷的成本與發(fā)現(xiàn)階段的關(guān)系Fig.1 The relation of defect cost and found phase

1 缺陷分析技術(shù)的研究

1.1 軟件缺陷相關(guān)概念

軟件缺陷（software defect）是指在軟件開發(fā)周期中軟件產(chǎn)品產(chǎn)生的缺陷和不足，會導(dǎo)致實際運行結(jié)果與預(yù)期結(jié)果產(chǎn)生偏離。SW-CMM 給出的定義是：“系統(tǒng)中存在使其功能無法按需完成的缺點。執(zhí)行過程中缺陷的產(chǎn)生會導(dǎo)致系統(tǒng)失效”。[2]

軟件缺陷表達的含義非常寬泛，站在軟件用戶的角度來看，系統(tǒng)中一切不能完成用戶需要的功能、不能滿足標準規(guī)范要求、造成使用上的不便等缺點都是軟件缺陷；而站在開發(fā)者的角度，軟件缺陷不僅對用戶的使用有影響，也會造成項目延期和超支。

下面介紹幾個與軟件缺陷相關(guān)的術(shù)語[3]。如軟件錯誤、軟件故障、軟件失效，他們之間存在著緊密的聯(lián)系。

（1）軟件錯誤：Error，是指整個軟件的生存周期中存在于軟件設(shè)計、文檔、程序代碼或數(shù)據(jù)結(jié)構(gòu)等載體中的不正確信息。軟件錯誤是人為引起的，經(jīng)過一定條件的催化，必然會引起軟件故障。

（2）軟件故障：Fault，是指軟件本身沒有按照用戶所期待的正確結(jié)果進行表現(xiàn)，是軟件運行時展現(xiàn)出來的一種不可接受的內(nèi)部狀態(tài)[4]。我們可以把它看做一種能導(dǎo)致軟件錯誤產(chǎn)生的缺陷，這是一種動態(tài)行為。

（3）軟件失效：Failure，是指軟件在運行時產(chǎn)生出的無法被用戶接受的外部行為結(jié)果[5]。例如：功能執(zhí)行能力的喪失；系統(tǒng)失去在限度內(nèi)按要求執(zhí)行功能的能力；程序的實際操作與需求發(fā)生偏離等。

1.2 軟件缺陷屬性及分類

軟件缺陷的屬性有很多種，常見屬性包括：缺陷標識、缺陷嚴重性、缺陷來源、缺陷類別、重現(xiàn)的頻率、產(chǎn)生原因等等[6]。依據(jù)缺陷擁有的不同屬性，可以有多種的分類方法，如通過缺陷標識進行分類、通過缺陷嚴重性進行分類、通過缺陷來源進行分類、通過缺陷類別進行分類、通過缺陷狀態(tài)進行分類等。

首先，介紹一些常見的缺陷分類標準：

（1）缺陷的嚴重性

主要是不同程度的缺陷對系統(tǒng)和用戶造成的影響，如表1所示。

（2）缺陷的起源

主要是指缺陷引發(fā)的系統(tǒng)故障第一次被發(fā)現(xiàn)所處的階段，如表2所示。

（3）缺陷的來源

主要是指缺陷產(chǎn)生的位置，如代碼、文檔等，如表3所示。

（4）缺陷的根源

主要是指導(dǎo)致缺陷產(chǎn)生的根本原因，如表4所示。

（5）缺陷的類別

主要是指依據(jù)缺陷的表現(xiàn)形式和影響對缺陷本身進行的分類，如表5所示。

（6）缺陷的優(yōu)先級

主要是指依據(jù)缺陷造成的影響來判別處理缺陷的優(yōu)先順序，優(yōu)先級最高的缺陷并不一定是最嚴重的問題，而是當前影響最大的問題，因此缺陷的優(yōu)先級與嚴重性并沒有必然聯(lián)系。如表6所示。

表1 軟件缺陷的嚴重性分類Tab.1 The classification of software defect severity

表2 軟件缺陷的起源分類Tab.2 The classification of software defect origin

表3 軟件缺陷的來源分類Tab.3 The classification of software defect source

（7）缺陷重現(xiàn)的頻率

主要是描述缺陷再次出現(xiàn)的可能性。如表7所示。

（8）缺陷狀態(tài)

主要是描述缺陷在整個項目開發(fā)過程中的生命周期，從發(fā)現(xiàn)到被處理而被描述的狀態(tài)。如表8所示。

下面，我們再對幾種典型的缺陷分類方式[7]進行介紹：

（1）國軍標分類：GJB437是我國的國家軍用標準，在標準中依據(jù)在大量軍用軟件中發(fā)現(xiàn)錯誤的來源，將缺陷分為三大類：文檔缺陷、程序缺陷和設(shè)計缺陷[8]。

（2）IEEE（電氣和電子工程師學(xué)會）的異常分類標準：這個標準對軟件生命周期中每個階段發(fā)現(xiàn)缺陷的處理方式進行了描述，使用者還可以通過標準提供的相關(guān)數(shù)據(jù)對缺陷造成的異常進行識別和跟蹤。

（3）IBM 的缺陷預(yù)防分類方案：1990年由R.G.Mays等人提出，這個方案對缺陷引入的消除效果較好。主要使用因果分析法對缺陷進行多次分類，直到找到問題引入的根源，這種分類方法非常簡單。

表4 軟件缺陷的根源分類Tab.4 The classification of software defect root

表5 軟件缺陷的類別分類Tab.5 The classification of software defect category

表6 軟件缺陷的優(yōu)先級分類Tab.6 The classification of software defect priority

表7 軟件缺陷重現(xiàn)的頻率分類Tab.7 The classification of software defect repeat frequency

（4）IBM 的正交缺陷分類[9]：由 IBM 公司提出，該分類法定義了彼此正交的八個屬性對缺陷特征進行描述，八個屬性可對應(yīng)到缺陷的發(fā)現(xiàn)和修復(fù)這兩類活動中，該方法分類細致，并可適用于多種情況。

1.3 軟件缺陷分析方法

在建立缺陷分析模型或者分析缺陷時，可以用到的分析方法[10]主要有根本原因分析法、缺陷分布分析法、缺陷注入-發(fā)現(xiàn)矩陣分析法、DRM（defect removal model analysis）分析法、ODC（orthogonal defect classification）分析法和軟件故障樹分析法。下面對這些方法進行簡單的分析和比較。

表8 軟件缺陷狀態(tài)分類Tab.8 The classification of software defect state

1.3.1 根本原因分析法

Root Cause Analysis，簡稱為RCA。該方法的基礎(chǔ)是魚骨圖和柏拉圖等，通過分析產(chǎn)生缺陷的根本原因來采取相應(yīng)的措施和方法，以提高開發(fā)和測試過程的工作效率。

根本原因分析法主要有以下使用場景：

（1）首先從各類評審和各級測試中收集缺陷，通過分析缺陷在產(chǎn)生的功能模塊上的分布情況，掌握相對質(zhì)量較差的模塊有哪些，在測試時加以關(guān)注重點進行覆蓋。

（2）然后對缺陷進行分類，依據(jù)分類的分布情況挑出其中最重要的缺陷類型，之后對此類缺陷使用魚骨圖[11]、柏拉圖[12]等方式進行分析后找到它產(chǎn)生的根本原因，針對該種原因制定相符合的糾正措施，可以減少該類原因的產(chǎn)生。

（3）對找到的缺陷根本原因生成缺陷分布報告，依據(jù)根本原因的分布情況進行分析，可以提高軟件質(zhì)量。

通過本方法對大量數(shù)據(jù)進行分析后發(fā)現(xiàn)，軟件缺陷產(chǎn)生的根本原因可能包括以下幾種：

（1）需求類文檔問題：需求類文檔存在歧義、不詳細、不一致的情況導(dǎo)致。

（2）系統(tǒng)設(shè)計問題：架構(gòu)設(shè)計或模塊設(shè)計考慮不周全，或與需求不一致導(dǎo)致。

（3）程序編碼問題：編碼人員編碼錯誤。

（4）維護問題：軟件版本變更時修復(fù)缺陷卻引發(fā)了新的問題。

（5）實施問題：安裝部署使實施人員安裝或設(shè)置不當導(dǎo)致產(chǎn)生的問題。

（6）升級問題：軟件版本升級時由于未完全按照操作規(guī)程實施導(dǎo)致軟件升級不正確或不完全引發(fā)的缺陷。

（7）外部問題：軟件運行環(huán)境中的軟硬件導(dǎo)致的缺陷，可能包括硬件、操作系統(tǒng)、數(shù)據(jù)庫、辦公軟件等等。

（8）溝通問題：開發(fā)組成員溝通不明確或理解出現(xiàn)不一致導(dǎo)致。

1.3.2 缺陷分布分析法

缺陷分布分析法就是依據(jù)軟件缺陷的屬性，如缺陷嚴重性、缺陷起源、缺陷來源、缺陷根源、缺陷類別等，對收集到的缺陷數(shù)據(jù)進行分布統(tǒng)計，以便于獲取到缺陷分布反映出的軟件情況，從而為提高軟件質(zhì)量提供依據(jù)。下面舉幾個通過不同屬性分布進行分析的例子：

（1）缺陷按缺陷起源的分布。通過這種方法可以分析出來自于不同起源的缺陷是否有效、注入率等信息，可以用來衡量項目各階段相關(guān)人員的水平及狀態(tài)。缺陷起源一般包括需求、構(gòu)架、設(shè)計、編碼、測試、用戶等。

（2）缺陷按缺陷嚴重性的分布。通過這種方法可以了解到處于各嚴重性等級的缺陷數(shù)量及其比例等信息，針對不同水平的軟件制定相應(yīng)的改進措施。缺陷嚴重性一般包括宕機、嚴重、重要、次要、無關(guān)緊要等級別。

（3）缺陷按缺陷根源的分布。通過這種方法可以了解到產(chǎn)生缺陷的根本原因是什么，并針對這些潛在的問題進行糾正。缺陷根源一般包括測試策略、過程工具和方法、團隊、組織、軟件、硬件等等。

1.3.3 缺陷注入-發(fā)現(xiàn)矩陣分析法

缺陷注入-發(fā)現(xiàn)矩陣分析法主要是依據(jù)缺陷屬性中的“注入階段”和“發(fā)現(xiàn)階段”，通過繪制“缺陷注入-發(fā)現(xiàn)矩陣”對開發(fā)項目過程中的各環(huán)節(jié)質(zhì)量進行分析，查明哪些環(huán)節(jié)是最需要進行改進的。

缺陷注入-分析矩陣表（表9）中行表示缺陷按照起源分類后在各個階段進行統(tǒng)計得出的缺陷數(shù)，矩陣的列表示該階段注入的缺陷遺留到后續(xù)各階段的缺陷數(shù)。

表9 缺陷注入-發(fā)現(xiàn)矩陣Tab.9 Software defect matrix

本階段缺陷清除率的含義是本階段通過各種措施對軟件質(zhì)量進行控制后實施成效的反映。本階段缺陷清除率用 表示，本階段發(fā)現(xiàn)的缺陷數(shù)用 表示，本階段注入的缺陷總數(shù)用 表示，計算公式為：

在需求階段，總計注入200個缺陷，但在需求評審時只發(fā)現(xiàn)其中的35個，可以得出：需求分析階段的缺陷清除率 為：

而且通過對表9的矩陣深入研究，可以發(fā)現(xiàn)編碼實現(xiàn)階段產(chǎn)生的缺陷大部分是在系統(tǒng)測試階段才發(fā)現(xiàn)并進行修復(fù)的，這也就說明，系統(tǒng)測試之前的單元測試和集成測試活動必然進行的不夠充分，從而使缺陷遺留到了后續(xù)階段。

需求分析階段注入的缺陷大部分是在設(shè)計評審時在被發(fā)現(xiàn)，分析結(jié)果表明這可能是由于需求本身穩(wěn)定性和清晰度存在問題造成的，因此在設(shè)計評審時不能只是單純評審設(shè)計，也需要同時軟件需求規(guī)格說明與設(shè)計對照，互相進行驗證，甚至可利用需求追溯查找到上級需求文檔的中可能存在的問題。

1.3.4 DRM分析法

DRM（defect removal model analysis）分析法主要是通過對缺陷排除數(shù)據(jù)進行有效性分析，來驗證各個階段的測試情況是否充分。該方法是通過歷史項目的數(shù)據(jù)，得出軟件研發(fā)過程中各階段對軟件缺陷注入和排除的模型。

首先介紹一下缺陷率的通用概念，即缺陷數(shù)與錯誤概率在一定時間段內(nèi)的比值，但這又與產(chǎn)品類型和發(fā)布前后不同時段均有關(guān)系。比如應(yīng)用軟件在發(fā)布后兩年內(nèi)可以發(fā)現(xiàn)90%以上的缺陷，而操作系統(tǒng)卻至少要在產(chǎn)品發(fā)布后4年才能發(fā)現(xiàn)90%以上的缺陷。

（1）整體缺陷清除率

整體缺陷清除率是用來對整體缺陷排除能力進行分析的工具之一。

首先假設(shè)F為軟件全部的功能點，D為發(fā)現(xiàn)的總?cè)毕輸?shù)， D = D1 + D 2，其中， D 1為在整個軟件研制過程中發(fā)現(xiàn)的全部缺陷數(shù)，D 2為軟件發(fā)布后用戶使用中發(fā)現(xiàn)的缺陷數(shù)。如果A系統(tǒng)規(guī)模為200個功能點，在研制過程中發(fā)現(xiàn)130個缺陷，發(fā)布后用戶反饋了 24個錯缺陷，則： D 1= 1 30， D 2 = 2 4，

據(jù)不完全統(tǒng)計，美國平均的整體缺陷清除率已經(jīng)可以達到85%以上，其中一些具備良好管理體系的著名軟件公司生產(chǎn)的主流軟件產(chǎn)品的確信清除率甚至超過了98%。

（2）基于階段的缺陷排除分析

基于階段的缺陷排除分析又被稱之為 DRM 模型，共涵蓋了3種度量關(guān)系，包括缺陷注入、缺陷排除和有效性。該模型通過輸入一組階段有效性和一組錯誤注入率為DRM建模。

通過表 10的注入-發(fā)現(xiàn)矩陣，我們介紹一下DRM模型。

這個項目中由于特殊原因沒有進行正式需求評審，因此矩陣中沒有需求評審相關(guān)數(shù)據(jù)，但這并不意味著需求階段注入缺陷的可能性會變小。接下來我們通過計算將矩陣進行簡化，得到表11。

其中，階段出口處缺陷數(shù)＝前一階段的遺留缺陷數(shù)＋本階段注入缺陷數(shù)－本階段排除的缺陷數(shù)。

由此可見，通過 DRM 模型可以直接地對階段缺陷排除能力進行有效的分析。

1.3.5 ODC分析法

ODC分析法（orthogonal defect classification）按不同維度對每個缺陷進行分類，目前共包括有 8個維度[13]，共114類，具體參見表12。

表10 缺陷矩陣分析表Tab.10 Software defect matrix analysis

表11 缺陷排除有效性結(jié)果Tab.11 The result of defect elimination effectiveness

ODC中的各維度關(guān)系如圖2所示。

正交缺陷分類實際上就是對缺陷進行分類，基于這些分類實施過程改進。ODC分類法與其他分析方法相比，分類更為詳盡。其特點如下：

（1）正交缺陷分類定義的八個屬性彼此正交，每個屬性的所有取值都是彼此正交的，也就是說分類之后信息不會重疊且統(tǒng)計結(jié)果也相對是可以獨立的，這樣就可以對缺陷進行定量的全面描述。

（2）正交缺陷分類適用于所有缺陷類型，經(jīng)過正交分類的缺陷幾乎覆蓋了各個方面，因此可以為過程改進分析提供更多角度進行考慮。與RCA這種定性的分析相比，ODC更能完整的把握缺陷的全部信息，從而更全面的分析出缺陷產(chǎn)生的根本原因，更好的做到缺陷預(yù)防。

（3）由于正交缺陷分類法是貫穿軟件開發(fā)過程的各個階段的，對每一階段的缺陷信息都會使用統(tǒng)一屬性進行分類定義，因此缺陷的type屬性可以適用于任何階段，甚至可以反映出某個階段展現(xiàn)出的特定特性，為開發(fā)過程的改進提供服務(wù)；通過缺陷的trigger屬性和各階段情況，可以表現(xiàn)出缺陷觸發(fā)后的修復(fù)情況，為確認過程的改進提供服務(wù)。

（4）正交缺陷分類法不依賴于產(chǎn)品的特性、產(chǎn)品開發(fā)的工程模型或過程方法。它不依賴于某個產(chǎn)品的特性，不依賴于軟件開發(fā)的工程模型。對于不同的軟件產(chǎn)品，如果都是用ODC分類，那么他們的分析標準是統(tǒng)一的，這樣就保證了產(chǎn)品之間的比較是公平的，是站在同一起跑線上的。

1.3.6 軟件故障樹分析法

20世紀80年代，軟件故障樹分析法（Software Fault Tree Analysis，簡稱SFTA）由硬件移植到軟件領(lǐng)域，其主要功效是用來分析系統(tǒng)的安全和可靠性，是一種由上向下的分析方法，通過這種方法，可以將導(dǎo)致缺陷產(chǎn)生的各種基本事件逐一分析出，并確定這些基本事件對缺陷影響的大小，還可以依據(jù)各基本事件發(fā)生的概率計算出缺陷發(fā)生的概率，從而確定缺陷集中的模塊或是可能產(chǎn)生嚴重問題的模塊。軟件故障樹分析法就是將需要分析缺陷的故障模式作為分析目標，也就是故障樹的頂事件，然后查明導(dǎo)致這一故障產(chǎn)生的全部直接因素，再繼續(xù)找出造成這些直接因素的下一級直接因素，直到找到再繼續(xù)分解的因素為止。

表12 正交缺陷分類Tab.12 Orthogonal defect classification

圖2 ODC中的維度關(guān)系Fig.2 The relation of ODC dimension

故障樹分析法的優(yōu)點是因果關(guān)系清晰，通過故障樹可以直觀全面的看到導(dǎo)致故障產(chǎn)生的各種因素和其邏輯關(guān)系，從而可以指定相應(yīng)的改進措施。依據(jù)建立出的故障樹，可以進行定性分析、定量分析和系統(tǒng)評價。通過定性分析，可以找到?jīng)Q定頂事件發(fā)生的各因素，并了解到解決他們的優(yōu)先順序，從而為制定對應(yīng)解決方案提供依據(jù)。通過定量分析，可以依據(jù)各因素的發(fā)生概率計算出頂事件的發(fā)生概率，為軟件的整體質(zhì)量評估做一個量化評價。

故障樹分析法的缺點是進行發(fā)生概率推測的能力較弱，且只能對針對單個缺陷本身進行分析，而不能對整個過程和系統(tǒng)進行全面分析，在分析的過程中很多步驟需要依賴于分析人員的主觀判斷，這也就導(dǎo)致不同分析人員的分析結(jié)果可能不盡相同，統(tǒng)一性較差，對于復(fù)雜的缺陷故障，建立故障樹的過程會非常復(fù)雜，消耗資源較多，計算和分析比較困難。

2 軟件缺陷分析方法的比較

沒有完美的分析方法，每一種分析方法都有自己的優(yōu)點和缺點，如何能選取合適的方法在恰當?shù)沫h(huán)境中使用是我們研究的重心，如果進一步可以將方法們組合使用，做到物盡其用，將會大大提高我們的分析效率和準確度。表13從方法復(fù)雜度、分析深度、分析廣度和主觀性四個方面對上述常見的缺陷分析方法進行了比較。

分析表13可見：

表13 軟件缺陷分析方法的比較Tab.13 The comparison of software defect analysis methods

（1）方法復(fù)雜度方面，根本原因分析和軟件故障樹分析這兩種方法的復(fù)雜度相比其他方法更復(fù)雜一些，其他四種方法相對簡單。

（2）分析深度方面，根本原因分析法和軟件故障樹分析法由于可以深入查找到缺陷發(fā)生的根本原因，因此分析的深度比較大，其中故障樹分析法的分析結(jié)果更直觀、簡潔和明確。

（3）分析廣度方面，正交缺陷分類法遠遠高于其他五種方案，分類后提供了大量的信息為分析工作提供支持。

（4）在主觀性方面，根本原因分析法和軟件故障樹分析法由于更需要依賴于分析人員的主觀判斷，相對最差，ODC也存在一定的主觀性依賴，其他三種方法則主要依靠的是數(shù)據(jù)進行分析，因此較好。

由此可見，這些方法中，根本原因分析法最適合對大量數(shù)據(jù)分析產(chǎn)生的原因，故障樹分析法是深入分析單類缺陷的最好方法，而ODC正交分解法則是覆蓋最廣、適用最全面、提供信息最豐富的方法。如果可以通過 ODC法結(jié)合根本原因分析法提供大量分析數(shù)據(jù)，并基于這些數(shù)據(jù)簡化建立故障樹的過程，然后對其中分析要求最高的缺陷進行故障樹分析，就可以真正做到各司其職、物盡其用，避免重復(fù)工作，極大的提高效率。

3 結(jié)論

本文針對目前國內(nèi)軟件企業(yè)對提升軟件質(zhì)量的需要，介紹軟件缺陷分析的相關(guān)知識，研究了缺陷分析的各類主流技術(shù)，并綜合比較其優(yōu)點和不足，以便能夠采取針對性的改進措施，減少軟件缺陷的產(chǎn)生，越早發(fā)現(xiàn)缺陷中存在的缺陷，就越是能夠降低耗費在修復(fù)缺陷上的開發(fā)費用，同時提升軟件的質(zhì)量。

[1] Chang Ching-Pao, Chu Pchih-Ping. Defect Prevention in Software Processes: An Action-Based Approach[J]. Journal of Systems and Software, 2007.

[2] 張少中. 基于貝葉斯網(wǎng)絡(luò)的知識發(fā)現(xiàn)與決策應(yīng)用研究[D].大連: 大連理工大學(xué), 2003.ZHANG S Z. Research of knowledge discovery and decision application based on bayesian network[D]. Dalian:Dalian University of Technology, 2003. (in Chinese)

[3] 梁成才, 章代雨, 林海靜. 軟件缺陷的綜合硏究[J]. 計算機工程, 2006, 32(19): 88-90.LIANG C C, ZHANG D Y. The comprehensive research of Software defect[J]. Computer Engineering. 2006, 32(19):88-90. (in Chinese)

[4] 尹相樂, 馬力, 關(guān)昕. 軟件缺陷分類的研究[J]. 計算機工程與設(shè)計, 2008, 29(19): 4910-4912.YIN X L, MA L, GUAN X. The research of software defect classification[J]. Computer Engineering and Design, 2008,29(19): 4910-4912. (in Chinese)

[5] 陳春秀. 軟件可靠性模型的研究及基于可靠性模型的測試[D]. 北京: 華北計算技術(shù)研究所, 2011.CHEN C X. The research of Software Reliability Modeling and testing based on Reliability Modeling[D]. Beijing: North China Institute of Computing Technology, 2011. (in Chinese)

[6] NIAZI M, BABARC M A, VERNERD J M. Software Process Improvement barriers: A cross-cultural comparison[J]. Information and Software Technology, 2010, 52(11): 1204-1216.

[7] 聶林波, 劉孟仁. 軟件缺陷分類研究[J]. 計算機應(yīng)用研究,2004(6): 84-86.NIE L B, LIU M R. The research of software defect classification[J]. Application Research of Computers, 2004(6): 84-86. (in Chinese)

[8] 王青, 伍書劍, 李明樹. 軟件缺陷預(yù)測技術(shù)研究[J]. 軟件學(xué)報, 2008, 19(7): 1565-1581.WANG Q, WU S J, LI M S. The research of software defect Prediction[J]. Journal of Software, 2008, 19(7): 1565-1581.(in Chinese)

[9] WALT C, BARNARD E. Data characteristics that determine classifier performance[J]. SAIEE Africa Research Journal,2007.

[10] 陳愛真, 曾福萍, 陸民燕. 基于ODC的軟件缺陷度量研究[J]. 計算機應(yīng)用研究, 2010, 2(27): 563-565.CHEN A Z, ZENG F P, LU M Y. The research of software defect measurement based on ODC[J]. Application Research of Computers, 2010, 2(27): 563-565. (in Chinese)

[11] 朱永春, 徐紅. 一種基于歷史數(shù)據(jù)的軟件缺陷預(yù)測方法改進[J]. 北京航空航天大學(xué)學(xué)報, 2003, 10: 947-950.ZHU Y C, XU H. The improvement of software defect prediction method based on historical data[J]. Journal of Beijing University of Aeronautics and Astronautics, 2003, 10: 947-950. (in Chinese)

[12] 羅宜美, 黃勝延, 曹式有. 改進魚骨圖在生產(chǎn)管理中的應(yīng)用[J]. 工業(yè)工程, 2007, 10(2): 138-141.LUO Y M, HUANG S Y, CAO S Y. The application of improvement fishbone diagram in production management[J].Industrial Engineering, 2007, 10(2): 138-141. (in Chinese)

[13] 周豐, 馬力. 基于AODE和再抽樣的軟件缺陷預(yù)測模型[J].計算機工程與設(shè)計, 2011, 32(1): 210-212.ZHOU F, MA L. Software defect prediction model based on AODE and resampling[J]. Computer Engineering and Design,2011, 32(1): 210-212. (in Chinese)

[14] 朱少民. 軟件質(zhì)量保證和管理[M]. 北京: 清華大學(xué)出版社, 2007.ZHU S M. Software Quality Assurance and Management[M].Beijing: Tsinghua University Press, 2007. (in Chinese)

[15] LEE S F, BAI X Y, CHEN Y N. Automatic Mutation Testing and Simulation on OWL-S Specified Web Services[R]. 41st Annual Simulation Symposium (ANSS-41), IEEE Computer Society, 2008.

[16] 王雅文. 基于缺陷模式的軟件測試技術(shù)研究[D]. 北京: 北京郵電大學(xué), 2009.WANG Y W. The research of software testing technology based on defect pattern[D]. Beijing: Beijing University of Posts and Telecommunications, 2009. (in Chinese)

[17] 李新軍, 劉曉明, 黃松. 基于軟件過程度量的正交缺陷分類技術(shù)[J]. 計算機工程, 2009, 35(23): 30-34.LI X J, LIU X M, HUANG S. Orthogonal defect classification technology based on software process measurement[J].Computer Engineering, 2009, 35(23): 30-34.