基于缺陷分類和缺陷預測的軟件缺陷預防

雷 挺

（中國電子科技集團公司第十五研究所，北京100083）

0 引 言

近年來，由于大量的缺陷給軟件企業帶來了大量維護費用，軟件測試技術越來越受到重視，不少企業相繼對研發資質進行了提升，引入能力成熟度模型集成（capability maturity model integration，CMMI），研發缺陷管理和跟蹤系統，將缺陷分析和預測的功能逐步融入到缺陷管理系統中，缺陷預防也開始受到關注，現有的缺陷預防方法有FMEA（故障模式和效果分析）、FTA（故障樹分析）、防御性編程、軟件易測試性設計等，但是目前還沒有一個能夠綜合缺陷分析和缺陷預測的成熟技術，針對不同的生命周期進行有效的分析和提前預防，為了解決以上問題，本文將缺陷預測技術與改進的正交缺陷分類方法相結合，提出了一套缺陷預防流程，并用實際項目進行對比實驗，驗證該流程的有效性。

1 缺陷預防的概念及意義

缺陷預防（defect prevention）是在軟件缺陷沒有出現時，就采取積極有效的預防措施，把缺陷消滅在萌芽狀態的一種技術［1］。

美國質量保證研究所對軟件測試的研究結果表明，在開發過程后期發現問題的成本是非常高的。補救成本會隨著開發周期的進展而大幅上升，這是因為需要修改設計與編碼，需要重新進行測試以及考慮對其他相關模塊的影響［2］。行業研究已經表明，如果在設計時修正一個缺陷的成本是1x，那么在軟件發布之后進行修正的成本將是100x［3］。

為了避免質量低下所帶來的巨大成本，最佳選擇是在缺陷預防方面進行投入。如果開發團隊能夠在上游階段預防缺陷，而不是在后期發現和修正缺陷，那么設計人員、開發人員和其他相關人員等都將從中受益［4］。

2 常用的缺陷預測方法

缺陷預測是預防的基礎，準確預測才能集中有限的資源對缺陷進行針對性預防。按照預測技術的不同，缺陷預測方法可以分為類比法、Delphi估算法、數學預測模型法三大類方法，但是因為前兩種方法有著無法克服的局限性，目前軟件缺陷預測領域的研究工作大部分是集中在數學預測模型法方面。

常見數學預測模型方法有：線性判別分析（linear discriminant analysis，LDA），布爾判別函數（boolean discriminant function，BDF），貝葉斯網絡（bayesian network，BN），分 類 回 歸 樹（classification and regression tree，CART），優化集精簡（optimized set reduce，OSR），聚類分析（clustering analysis，CA），支持向量機（support vector machine，SVM），人工神經網絡（artificial neural network，ANN），平均單一相關評估器（average one－dependence estimators，AODE）［5］等。各種預測方法有著不同的適應面，可以解決不同的問題，也有各自的局限［6］。它們的詳細比較結果見表1。

表1 缺陷預測方法的比較

迄今為止，國內外有100多種缺陷預測模型發表在各種專業刊物和學術會議上，但大多數模型并沒有得到充分的項目數據的支撐和驗證，其有效性和準確性得不到有力地證明，因而未能廣泛應用。

3 缺陷預測模型的優化

作者所在的組織多年來致力于缺陷預測的研究，積累了大量缺陷數據，在此基礎上建立了multi－AODE缺陷預測模型。

假設F（Xi）表示包含屬性Xj的樣本數，屬性Xj、Y均依賴于屬性Xi，m表示m－估計量，AODE方法的原理可用下列公式表達［7］

通過一對多方法可以實現multi－AODE分類器，即組合多個AODE二值分類器來實現多值分類。使用multi－AODE預測模型進行缺陷預測的過程如圖1所示。

向該模型輸入軟件生命周期中的各個階段的度量數據，應用離散化、再抽樣等數據預處理技術，并通過multi－AODE分類器進行預測運算，輸出各階段注入和遺留缺陷密度等級的預測值。如果預測出的注入和遺留缺陷密度值較小，則意味著質量的前景是樂觀的；反之，則意味著需要改進過程，增加對質量控制的關注。

按照覆蓋域盡可能廣的原則，從歷史項目中挑選了83個軟件項目（其中包括36個大型項目，47個中小型項目），使用不同模型進行缺陷預測，結果見表2。

圖1 使用multi－AODE預測模型進行缺陷預測的過程

表2 不同缺陷預測模型的預測結果比較

從表2不難看出，同其他預測模型相比，multi－AODE預測模型有著更好的預測結果，但仍有較大的提升空間，為進一步提高其預測的準確性，作者根據多年項目經驗，對該模型做了如下優化。

（1）增加度量元個數：遵循度量元可理解、易估計、與缺陷相關度高的原則，將原預測模型的度量元個數從21個增加至28個（去掉其中的10個并新增17個），同時細化度量標準，將度量元取值從3至6級擴展至9級，以提高預測的準確性。約定度量元分級如下：A、B、C、D、E分別取1、3、5、7、9級，介于A、B、C、D、E的中間值分別取2、4、6、8級。需要說明的是：

1）提取所有相關度量元并不能提高預測的準確性，甚至會適得其反。應從度量目標出發，確定適當的度量元。

2）“開發過程的度量元”是指在生命周期的每個階段都會影響軟件質量的度量元，由于每個階段都可能采取預防措施，所以下一個階段數據采集時應當更新 “開發過程的度量元”的取值，并且其權重高于另外3個階段的度量元。

（2）控制度量數據的采集：將軟件生命周期中的各個階段的度量數據采集環節集成到了本組織的Gems項目管理工具中，該工具根據項目進度及時提醒相關人員及時填寫各個階段度量數據，若忘記填寫，工具將給出提示信息，這一設計保證數據采集的及時性和有效性，避免了 “垃圾進，垃圾出”的度量。

（3）調整1類／2類錯誤率：1類錯誤是指將低風險模塊錯誤地預測為高風險模塊。2類錯誤是指將高風險模塊錯誤地預測為低風險模塊。毋庸置疑，這兩類錯誤會帶來不同的損失，通過調整度量元的數目、權重、度量標準和取值范圍，實現對可能帶來風險的度量值的放大，犧牲1類錯誤率來保證較低的2類錯誤率，以滿足軍工及科研領域的特殊需要［8］。

使用優化后的預測模型對相同的83個歷史項目進行預測，實驗結果見表3。

表3 模型改進前后的預測結果比較

分析表3可知，盡管優化后的訓練時間略有增加，但是預測值的準確性（平均、最好、最壞）和一致性（Kappa statistic統計值）都有了較大的提高。以每個項目預測值的準確率作為數據樣本，計算方差和熵，更小的方差和熵意味著優化后的預測模型有著更好的穩定性和更小的不確定性，此外，優化后的預測模型在1類／2類錯誤率的調整上也具有更大的靈活性。

盡管優化后的預測模型在預測效果上有顯著的提升，但其預測結果仍不足以具體指導組織或項目進行缺陷預防，為解決這一問題，引入正交缺陷分類（orthogonal defect classification，ODC）方法，并結合組織的實際情況對該方法進行了改進，使用改進的ODC方法對缺陷進行分類，同時分析缺陷原因，通過對大量缺陷數據的分析，找出導致軟件缺陷的共性原因，有針對性地進行預防。

4 改進的ODC：基于缺陷分類的定量分析方法

表4比較了兩類缺陷原因分析方法，顯然，基于缺陷分類的定量分析方法在缺陷預防上有著巨大的優勢。

表4 基于RCA的定性分析方法和基于缺陷分類的定量分析方法

正交缺陷分類（orthogonal defect classification，ODC）是IBM公司提出的缺陷分類方法［9］。該分類方法定義了缺陷特征的8個屬性，用來描述缺陷特征，這些屬性對應著缺陷的發現和修復兩類特定活動。當一個測試人員發現并提交一個缺陷時，給這個缺陷分配 “Activity（測試活動）”、 “Trigger（缺陷觸發）”、 “Impact（缺陷影響）”屬性，稱為Opener（發現者屬性）。當一個開發人員修復或者回應了一個缺陷時，可以分配 “Age（歷史版本）”、“Source（缺陷來源）”、 “Type（缺陷類型）”、 “Qualifier（類型進一步限定）”以及 “Target（缺陷載體）”，這些屬性被稱為解決者屬性（Closer）。

在打開和關閉軟件缺陷時運用ODC方法記錄缺陷的相應屬性值，分析這些信息可以確定缺陷原因，進行錯誤跟蹤，追溯到缺陷的引入階段，反映出軟件的設計、代碼質量等各方面的問題，提供改進線索。此外，還可以從缺陷記錄中獲取大量有價值的語義信息，作為量化評估依據，并為缺陷預防提供數據支持。

結合缺陷預防的要求，對ODC方法的改進如下：在已有的8個屬性的基礎上，擴展 “Target”、 “Type”屬性的取值，仍保持其正交性，同時增加 “Defect Cause（缺陷原因）”和 “Measure（預防措施）”兩個屬性。改進的ODC方法如圖2所示。

使用改進的ODC方法對歷史數據進行缺陷原因分析的流程如下。

（1）發現并提交一個缺陷時，在正交化分類的缺陷數據集（defect data set，以下簡稱缺陷數據集）中記錄 “Activity”、“Trigger”、“Impact”這3個屬性值；

圖2 改進的ODC方法

（2）修復或者回應一個缺陷時，在缺陷數據集中記錄“Age”、 “Source”、 “Qualifier”、 “Type”以及 “Target”5個屬性值，同時記錄修復缺陷所采取的糾正措施、修復效果；

（3）結合（1）、（2）進行缺陷跟蹤，追溯到缺陷的引入階段，分析并確定可能的缺陷原因，并結合修復措施和修復效果以及專家經驗（如果有相關記錄的話）進行缺陷預防的措施分析，同時記錄 “Defect Cause”和 “Measure”屬性；

（4）對大量缺陷數據重復上述步驟，得到一個相對全面的缺陷數據集，它記錄了大量缺陷的可能原因及相應預防措施，從中找出導致軟件缺陷的共性原因和相應的預防措施，按需求、設計、編碼3個階段進行分類。將該數據集應用于新的項目中，可以在項目的需求、設計、編碼階段輔助進行缺陷原因分析（Assist DCA）并指導缺陷預防（Guide DP）。

仍以前述83個歷史項目為分析對象，用改進的ODC方法隊83個項目中的缺陷逐個進行缺陷原因分析，得到一個相對完備的缺陷數據集，下文簡稱 《缺陷屬性數據集》。實踐證明，該數據集能夠為未來新項目提供有力的數據支持。

5 基于缺陷分類和缺陷預測的缺陷預防流程

將缺陷預測與改進的正交缺陷分類方法結合起來，形成了一套完整的軟件缺陷預防流程。

（1）通過改進后的multi－AODE預測模型，將生命周期某個階段的度量信息及開發過程的度量信息輸入預測模型，計算出該階段的缺陷密度等級。若預測的缺陷密度等級較低，意味著質量的前景很樂觀，本階段無需額外增加缺陷預防投入，可以將資源投入到生命周期的下一個階段的缺陷預防上，實現資源的合理配置；反之，意味著應額外進行質量控制，并增加在該階段缺陷預防方面的投入。

（2）查找 《缺陷屬性數據集》，獲取該階段引入缺陷的共性原因及對應的預防措施；

（3）根據項目質量要求，使用改進的ODC方法分析風險等級高的度量元，例如分析取值在5級以上的度量元，進一步補充缺陷原因和預防措施。

（4）結合項目實際情況，對缺陷原因及相應預防措施進行補充和篩選，針對性地進行缺陷預防，降低缺陷密度。

基于改進的AODE預測模型及改進ODC方法的缺陷預防流程如圖3所示（注：缺陷預防不必考慮系統測試階段，圖1中預測的是注入或遺留的缺陷，故需要考慮系統測試階段）

圖3 基于改進的AODE預測模型及改進ODC方法的缺陷預防流程

使用該流程應注意以下幾點。

（1）對于有特殊要求的項目，可以通過調整改進的multi－AODE預測模型的度量元的數目、權重、度量標準和取值范圍，實現對可能帶來風險的度量值的放大，犧牲1類錯誤率來保證較低的2類錯誤率；

（2）運用改進ODC分析可能的缺陷原因并獲取預防措施時，不能局限于缺陷數據集中現有的經驗數據，需重視對度量元的分析，并且充分考慮項目的實際情況，實現對缺陷原因和獲取預防措施進行篩選和補充，以增加預防的針對性，節省項目成本；

6 實驗驗證與分析

選擇某項目中業務邏輯和軟件規模相似的兩個子系統：A系統和B系統作對比實驗，說明如何使用改進的AODE預測模型及改進ODC方法進行缺陷預防，以驗上述缺陷預防流程的效果。

其中B系統作為實驗組，按圖3所示流程進行缺陷預防；A系統作為對照組，不采取預防措施，按原有流程進行開發。

（1）對B系統的設計階段進行預測，“開發過程度量”、“需求度量”、“設計度量”的數據采集結果如下。

1）開發過程度量

＠attribute CMMI｛3｝ %項目過程能力成熟度

＠attribute qualityControl｛4｝ %質量控制的有效性

＠attribute attitude｛6｝ %人員工作熱情及態度

＠attribute communication｛4｝ %人員交流溝通有效性

＠attribute complexity｛3｝ %產品業務邏輯的復雜性

＠attribute experience｛3｝ %開發團隊的經驗水平

＠attribute staffStability｛1｝ %人員的連續性

2）需求度量

＠attribute requirementBreakdown｛3｝ %需求分解的正確性

＠attribute requirementReview｛3｝ %需求評審的充分度

＠attribute requirementStability｛5｝ %需求穩定性

＠attribute requirementDetailed Degree｛2｝ %需求粒度

＠attribute userParticipation｛3｝ %用戶的參與程度

＠attribute userExpressiveness｛4｝ %用戶對需求的表達能力

＠attribute domainKnowledge｛4｝ %用戶的應用領域經驗

3）設計度量

＠attribute designStandardability｛7｝ %設計過程的規范性

＠attribute designerParticipation｛6｝ %設計人員在早期的參與程度

＠attribute requirementAcknowledge｛4｝ %設計人員對需求的理解

＠attribute codeKnowledge｛5｝ %設計人員對編碼技術的了解

＠attribute moduleComplexity｛3｝ %軟件模塊的復雜度

＠attribute designDetailed Degree｛3｝ %設計粒度

＠attribute designReview｛5｝ %設計評審

輸入上述度量數據，使用預測模型進行運算，輸出＠attribute requirementDefect｛［1.05，1.125）｝，預測結果表明設計階段的缺陷密度等級較高，可采取針對性預防措施，以降低缺陷密度。

（2）從 《缺陷屬性數據集》中獲取設計階段引入缺陷的共性原因及對應的預防措施；

（3）使用改進的ODC方法分析取值在5級以上的度量元，進一步補充缺陷原因和預防措施。

（4）對缺陷原因及相應預防措施進行補充和篩選，分析項目實際情況，去掉預防措施。

1）重視工作效率，避免過度加班；

2）明確設計標準與規范；

3）防范內部攻擊；

考慮到本項目涉及到裝備管理方面的業務知識和相關規則，增加預防措施。

（1）對設計人員進行業務知識及業務規則培訓；

（2）加強編碼人員和設計人員間的溝通，使他們對控制／邏輯流程的設計思路有更好的理解；

若實踐證明有效，應及時將這兩個預防措施加入缺陷數據集中，并作正交化分類，豐富和完善缺陷數據集。

綜合上述3個方面，得到設計階段應采取的缺陷預防措施如下。

（1）規范流程、加強管理；

（2）培養員工的良好的工作態度及責任意識

（3）培養良好的工作氛圍；

（4）加強風險分析；

（5）控制需求文檔版本，避免頻繁變更；

（6）加強設計分析人員內部的溝通以及與需求人員間的溝通，讓設計人員及早參與到項目中；

（7）嚴格的設計評審；

（8）充分考慮軟件運行平臺和軟件的可移植性；

（9）考慮軟件內部模塊間的兼容及前后版本間的兼容；

（10）記錄系統日志便于問題的分析跟蹤；

（11）考慮安全性與易用性或功能的折中；

（12）事先考慮可能發生的異常，做好相應的安全處理；

（13）對設計人員進行業務知識及業務規則培訓；

（14）加強編碼人員和設計人員間的溝通，使他們對控制／邏輯流程的設計思路有更好的理解。

由于需求分析階段、編碼階段的缺陷預防流程與上述過程相似，限于篇幅，這里不一一列舉。實驗組B系統和對照組A系統各階段檢測出的缺陷數對比如圖4所示。

圖4 實驗組B系統和對照組A系統各階段檢測出的缺陷數對比

從圖4可以看出，由于采用了缺陷預防措施，相比A系統，B系統各個階段引入的缺陷數均大為減少：需求分析階段的缺陷減少了21%，架構設計階段的缺陷減少了18%，編碼實現階段的缺陷減少了29%。此外，由于在上游階段減少了大量缺陷，實驗組的開發周期比對照組縮短了23%。這一結果證明本文所提出的軟件缺陷預防流程的可行性和有效性。

7 結束語

本文提出了一套完整的軟件缺陷預防流程：將生命周期某個階段的度量信息及開發過程的度量信息輸入預測模型，計算出該階段的缺陷密度等級，根據缺陷密度等級確定在缺陷預防上的投入力度，并使用改進的ODC方法分析該階段引入或遺留缺陷的根本原因，針對根本原因分析可行預防措施，從而有針對性地進行缺陷預防，在減少軟件缺陷的同時還能夠節省成本、縮短項目周期［11］。

本文在解決實際項目問題的同時，也是將缺陷預測和改進ODC方法運用在缺陷預防領域的一次嘗試。雖然經過了實際項目的驗證，本文提出的軟件缺陷預防流程仍需在實際運用中不斷收集反饋意見，并加以改進完善。下一步將對缺陷預測模型做更深入的研究，根據項目特征，對不同的項目采用不同的預測模型，實現預測準確性的最優化。此外，繼續收集各種類型的項目缺陷數據，獲得更加全面的缺陷數據集以提高缺陷預防的有效性和準確性。可以預見，隨著本文提出的缺陷預防流程在實際項目中的不斷應用與改進，缺陷數據集與預測模型會日益豐富與完善，預防效果也會越來越好。

［1］Chang Ching－Pao，Chu Pchih－Ping.Defect prevention in software processes：an action－based approach［J］.Journal of Systems and Software，2007，80（4）：1－27.

［2］James McCurley，Dennis R Goldenson.Performance effects of measurement and analysis：perspectives from CMMI high maturity organizations and appraisers［M］.Software Engineering Measurement and Analysis，2010：45－55.

［3］Lee Shufang，Bai Xiaoying，Chen Yinong.Automatic mutation testing and simulation on OWL－S specified web services［C］／／IEEE Computer Society 41st Annual Simulation Symposium，2008：149－156.

［4］Marc McDonald，Robert Musson，RossSmith.The practical guide to defect prevention［M］.Microsoft Press，2007：1－78.

［5］WANG Qing，WU Shujian，LI Mingshu.Software defect prediction［J］.Journal of Software，2008，19（7）：1566－1577（in Chinese）.［王青，伍書劍，李明樹.軟件缺陷預測技術［J］.軟件學報，2008，19（7）：1566－1577.］

［6］Fenton NE，Martin N，William M，et al.Project data incorpora－ting qualitative facts for improved software defect prediction［C］／／Proc of the 3rd Int＇l Workshop on Predictor Models in Software Engineering.Washington，DC：IEEE Computer Society，2007：11－20.

［7］ZHOU Feng，MA Li.Software defect prediction model based on AODE and resampling［J］.Computer Engineering and Design，2011，32（1）：210－212（in Chinese）.［周豐，馬力.基于AODE和再抽樣的軟件缺陷預測模型［J］.計算機工程與設計，2011，32（1）：210－212］

［8］Van der Walt C，Etienne Barnard.Data characteristics that determine classifier performance［J］.SAIEE Africa Research Journal，2007，98（3）：87－93.

［9］YIN Xiangle，MA li，GUAN Xin.Research of software defects classification［J］.Computer Engineering and Design，2008，29（19）：4910－4912（in Chinese）［尹相樂，馬力，關昕.軟件缺陷分類的研究［J］.計算機工程與設計，2008，29（19）：4910－4912］

［10］Robert W Stoddard II，Dennis R.Goldenson.Approaches to process performance modeling：A summary from the sei series of workshops on CMMI high maturity measurement and analysis［M］.Software Engineering Institute，Carnegie Mellon University，2010：15－42.

［11］Dennis R Goldenson，James McCurley，Robert W Stoddard II.Use and organizational effects of measurement and analysis in high maturity organizations：Results from the 2008SEI state of measurement and analysis practice surveys［M］.Software Engineering Institute，Carnegie Mellon University，2009：23－61.