王 磊，曾成修，符 為，謝 磊

（西南電子設(shè)備研究所，四川 成都 610036）

0 引言

隨著信息技術(shù)的發(fā)展，軟件在業(yè)務(wù)能力生成中發(fā)揮著越來越重要的作用。為確保軟件產(chǎn)品質(zhì)量可控，軟件開發(fā)組織按照工程化的方法進行軟件產(chǎn)品研制。如何對測試驗證中發(fā)現(xiàn)的軟件缺陷進行有效管理進而推進現(xiàn)有產(chǎn)品的順利研制及后續(xù)的持續(xù)改進，一直是軟件工程關(guān)注的熱點。

對軟件缺陷進行管理是很多軟件開發(fā)組織的重要工作。隨著GJB5000A［1］等軟件過程成熟度模型推廣，軟件缺陷文檔化，軟件缺陷處理分析相關(guān)工作愈加重要，但CMMI并沒有指出如何具體開展這些工作，導(dǎo)致軟件開發(fā)組織一般根據(jù)自己的理解作出不同的軟件缺陷管理方案，例如模棱兩可的數(shù)據(jù)解釋、加入報告者主觀意見等［2］。因此，有必要采用結(jié)構(gòu)化方法進行缺陷文檔化。缺陷數(shù)據(jù)的結(jié)構(gòu)化收集和分析方法有缺陷分類法［3］、根本原因分析法（RCA）［4］以及IEEE Std 1044［5］、GJB/Z 141［6］、正交缺陷分類（ODC）［7］、Hewlett-Packard缺陷分類［8］、APP缺陷問題評論分類方法［9］等。雖然這些針對特定環(huán)境上下文設(shè)計的方法在特定需求方面有效，但是其適應(yīng)性也被認為是應(yīng)用缺陷分類方法的主要挑戰(zhàn)之一［10-12］。同時，對文檔化后的缺陷數(shù)據(jù)進行存儲和處理分析常需要借助工具進行。目前，常見的軟件缺陷工具包括Trac、Redmine、Bugzilla、JIRA、YouTRACK、Pivotal Tracker 等開源或商業(yè)工具［13］，以及定制開發(fā)的系統(tǒng)［14-15］。這些工具作為一個獨立的系統(tǒng)運行，導(dǎo)致缺陷屬性值與缺陷分類內(nèi)容值的準確性和一致性難以保證［16］，數(shù)據(jù)錄入和維護成本較高引發(fā)數(shù)據(jù)分析便利性和有效性不足，缺陷處理流程的一致性不足產(chǎn)生技術(shù)和管理“兩張皮”現(xiàn)象。

目前典型的軟件代碼缺陷管理方案為基于GJB/Z 141附錄C.3 的軟件缺陷分類標準，使用類似文獻［14］的定制缺陷管理工具進行缺陷管理。此種軟件代碼缺陷管理方案存在缺陷分類方法適應(yīng)性不足和管理工具準確性、一致性、便利性不足等問題。

針對上述典型軟件代碼缺陷管理方案存在的問題，本文從軟件代碼缺陷分類方法和管理工具兩方面進行研究，提出一種全新的軟件代碼缺陷管理方案并構(gòu)建原型系統(tǒng)，從5 個方面對其應(yīng)用效果進行評價。評價結(jié)果顯示，本文方法可以明顯改善現(xiàn)有軟件代碼缺陷管理方案中存在的問題，對缺陷進行有效管理并提高效率。

1 軟件代碼缺陷管理方案

本文提出的軟件代碼缺陷管理方案是在缺陷分類方法基礎(chǔ)上通過缺陷管理系統(tǒng)工具實現(xiàn)對軟件代碼缺陷的管理。

1.1 軟件代碼缺陷分類方法

軟件代碼缺陷來源于軟件源代碼，分類方法關(guān)注源代碼特性，考慮完整性、正交性以及分類一致性等質(zhì)量特性，做到方便易用且真實可靠。軟件代碼缺陷分類方法如下：

（1）分類過程。軟件缺陷的分類涉及從缺陷識別到缺陷關(guān)閉的活動序列，包括識別、調(diào)查、行動和處置。每個活動包含記錄、分類和確定影響3 個步驟。

（2）分類屬性。分類屬性及其含義如表1 所示。

Table 1 Classification attributes and their meaning表1 分類屬性及其含義

（3）細化分類屬性值?？蛇M一步細化的分類屬性值為：①類別（Type）：數(shù)據(jù)（Data）、接口/時序（Interface/ Tim?ing）、邏輯/運算（Logic/Algorithm）、描述（Description）、語法（Syntax）、標準（Standards）、其它（Other）；②狀態(tài)（Status）：未確認（Unknown）、未閉環(huán)（Open）、已閉環(huán)（Closed）；③優(yōu)先級（Priority）：高（High）、中（Medium）、低（Low）；④嚴重等級（Severity）：嚴重（Critical）、一般（Major）、輕微（Minor）、可忽略（Inconsequential）；⑤發(fā)現(xiàn)方法（Detection activity）：綜合（synthesis）、審查（Inspection）、走查（Walkthrough）、評審（Review）、審計（Audit）、靜態(tài)分析（Static analysis）、單元測試（Unit testing）、組裝測試（Integration testing）、配置項測試（CSCI testing）、系統(tǒng)測試（System testing）、其它（Other）；⑥處置結(jié)果（Disposition）：已移除（Corrected）、未發(fā)現(xiàn)（Not found）、相關(guān)的（Referred）、重復(fù)的（Duplicate）。

1.2 軟件代碼缺陷管理系統(tǒng)

軟件代碼缺陷管理系統(tǒng)在設(shè)計時兼顧有效性和效率原則。基于有效性考慮，軟件代碼缺陷管理系統(tǒng)應(yīng)滿足：①缺陷屬性管理：基于缺陷分類標準的統(tǒng)一規(guī)則定義缺陷屬性并設(shè)置屬性值；②缺陷數(shù)據(jù)跟蹤和分析：實現(xiàn)缺陷及其屬性變化的信息記錄、條件查詢顯示和缺陷態(tài)勢分析?；谛士紤]，軟件代碼缺陷管理系統(tǒng)應(yīng)滿足：①缺陷數(shù)據(jù)生成：缺陷數(shù)據(jù)通過缺陷分類標準與測試結(jié)果原始數(shù)據(jù)的轉(zhuǎn)換規(guī)則便捷地從測試結(jié)果原始數(shù)據(jù)中直接獲取，與原始數(shù)據(jù)記錄內(nèi)容一致，鏈接到原始數(shù)據(jù)及其上下文信息，能隨原始數(shù)據(jù)變化實時更新；②缺陷分類過程管理：缺陷分類過程根據(jù)缺陷數(shù)據(jù)的屬性值變化實時自動流轉(zhuǎn)并通知到相應(yīng)人員。

1.2.1 缺陷數(shù)據(jù)生成

通過數(shù)據(jù)訪問引擎訪問測試結(jié)果原始記錄數(shù)據(jù)，通過缺陷分類標準與測試結(jié)果原始數(shù)據(jù)的轉(zhuǎn)換規(guī)則直接生成缺陷數(shù)據(jù)。缺陷數(shù)據(jù)生成規(guī)則為：①從原始記錄數(shù)據(jù)中逐條取出缺陷原始數(shù)據(jù)，通過缺陷身份識別（例如關(guān)鍵字值）判斷缺陷數(shù)據(jù)庫中是否存在包含此條缺陷數(shù)據(jù)的條目。如果存在則使用缺陷原始數(shù)據(jù)更新該條缺陷條目相關(guān)值，如果不存在則在缺陷數(shù)據(jù)庫中增加缺陷條目并根據(jù)缺陷原始數(shù)據(jù)設(shè)置其相關(guān)值；②對于已在原始記錄數(shù)據(jù)中消失的缺陷，在缺陷數(shù)據(jù)庫中設(shè)置該條缺陷條目相關(guān)值為與“消失”匹配的值。

當測試結(jié)果原始記錄數(shù)據(jù)變化時，缺陷數(shù)據(jù)庫同步規(guī)則為：①當原始記錄數(shù)據(jù)生成或再次生成時自動觸發(fā)缺陷數(shù)據(jù)生成；②當對測試結(jié)果進行確認引起原始記錄數(shù)據(jù)中“原始缺陷狀態(tài)”標記變更時自動觸發(fā)對應(yīng)的缺陷條目數(shù)據(jù)更新。數(shù)據(jù)同步實現(xiàn)機制為：①采用第三方調(diào)度引擎（例如Jenkins）根據(jù)前置輸出自動實時調(diào)度后續(xù)操作；②采用按鈕觸發(fā)或定時輪詢方式實現(xiàn)操作。

1.2.2 缺陷屬性管理

缺陷屬性值可以通過缺陷分類標準與測試結(jié)果原始數(shù)據(jù)的轉(zhuǎn)換規(guī)則獲得。轉(zhuǎn)換規(guī)則綜合考慮缺陷分類標準的規(guī)則定義和原始記錄數(shù)據(jù)使用自身規(guī)則定義，在語義轉(zhuǎn)換后確保缺陷相關(guān)屬性值的完整性、正交性和一致性。對于不同數(shù)據(jù)源的測試結(jié)果，轉(zhuǎn)換規(guī)則需考慮共性數(shù)據(jù)的融合和差異性數(shù)據(jù)的屏蔽、篩選及補充。以“狀態(tài)”屬性為例，其定義為：①未確認：測試結(jié)果未經(jīng)人工確認；②已確認未閉環(huán)：測試結(jié)果已經(jīng)人工確認，確定為缺陷需修復(fù)但還未修復(fù)；③已閉環(huán)：測試結(jié)果經(jīng)人工確認不是缺陷或經(jīng)人工確認是缺陷但已修復(fù)?！盃顟B(tài)”屬性值對應(yīng)的轉(zhuǎn)換規(guī)則如表2 所示。

Table 2 Transformation rules corresponding to state property values表2 “狀態(tài)”屬性值對應(yīng)的轉(zhuǎn)換規(guī)則

1.2.3 缺陷分類過程管理

根據(jù)缺陷狀態(tài)屬性值確定缺陷處理流程所處階段，并隨缺陷狀態(tài)屬性值的變化進行缺陷處理流程的流轉(zhuǎn)來實現(xiàn)缺陷分類。缺陷分類實現(xiàn)方式如圖1 所示。

Fig.1 Implementation of defect classification圖1 缺陷分類實現(xiàn)方式

1.2.4 缺陷數(shù)據(jù)跟蹤與分析

基于缺陷屬性及其變化信息的記錄結(jié)果進行缺陷查詢跟蹤與態(tài)勢分析。查詢條件依托分類屬性及其附屬屬性獲得，包括時間與空間維度，例如發(fā)現(xiàn)時間、糾正時間、編號、名稱、類別、狀態(tài)、資產(chǎn)、制品、優(yōu)先級、嚴重等級、發(fā)現(xiàn)方法、發(fā)現(xiàn)版本、糾正版本、處置結(jié)果等分類屬性以及處理人員、所屬產(chǎn)品、所屬團隊等附屬屬性及其組合。態(tài)勢分析包括種類分析和收斂趨勢分析。種類分析對查詢獲得的一定數(shù)量的缺陷進行分類統(tǒng)計，分類項為某一查詢條件項。收斂趨勢分析以若干個均勻的時間點為橫軸，以同一類性質(zhì)（如累計發(fā)現(xiàn)數(shù)、累計關(guān)閉數(shù)、當期發(fā)現(xiàn)數(shù)、當期關(guān)閉數(shù)）的缺陷數(shù)量為縱軸進行收斂趨勢分析，以及以軟件版本為橫軸，以缺陷密度為縱軸進行收斂趨勢分析。

2 原型系統(tǒng)及應(yīng)用

2.1 原型系統(tǒng)設(shè)計

軟件代碼缺陷管理原型系統(tǒng)采用分層結(jié)構(gòu)，分為數(shù)據(jù)層、業(yè)務(wù)支撐層、業(yè)務(wù)邏輯層和表示層，如圖2 所示。數(shù)據(jù)層存儲系統(tǒng)運行所需的數(shù)據(jù)，包括缺陷數(shù)據(jù)庫和系統(tǒng)運行數(shù)據(jù)庫，采用SQL Server 數(shù)據(jù)庫。缺陷數(shù)據(jù)庫存儲缺陷及其跟蹤數(shù)據(jù)，包括缺陷條目及其屬性、缺陷狀態(tài)變化及缺陷處理流程流轉(zhuǎn)記錄等數(shù)據(jù)。系統(tǒng)運行數(shù)據(jù)庫存儲支撐系統(tǒng)運行的數(shù)據(jù)，包括數(shù)據(jù)地址配置記錄、業(yè)務(wù)參數(shù)配置記錄及系統(tǒng)運行日志等數(shù)據(jù)。業(yè)務(wù)支持層對業(yè)務(wù)活動的實現(xiàn)提供支持，包括網(wǎng)絡(luò)鏈路通信引擎、數(shù)據(jù)訪問引擎、數(shù)據(jù)庫引擎、郵件通信引擎、報表生成引擎等。網(wǎng)絡(luò)鏈路通信引擎使用TCP 協(xié)議實現(xiàn)客戶端與服務(wù)器端通過以太網(wǎng)進行通信，數(shù)據(jù)訪問引擎實現(xiàn)對測試結(jié)果原始記錄數(shù)據(jù)的訪問，例如使用Web API 接口。數(shù)據(jù)庫引擎使用ADO.NET 實現(xiàn)對SQL Server 數(shù)據(jù)庫的操作，郵件通信引擎使用SMTP/POP3 協(xié)議實現(xiàn)郵件收發(fā)操作，報表生成引擎使用第三方Office 組件實現(xiàn)報表生成，業(yè)務(wù)邏輯層按照業(yè)務(wù)邏輯規(guī)則實現(xiàn)業(yè)務(wù)功能。業(yè)務(wù)邏輯規(guī)則包括缺陷定義規(guī)則、缺陷處理流程規(guī)則、數(shù)據(jù)同步規(guī)則和缺陷態(tài)勢分析規(guī)則。表示層是人機交互界面接口，包括數(shù)據(jù)地址的配置、業(yè)務(wù)參數(shù)的配置、查詢跟蹤和態(tài)勢分析結(jié)果呈現(xiàn)、報表導(dǎo)出等。

Fig.2 Architecture design of prototype system圖2 原型系統(tǒng)體系結(jié)構(gòu)設(shè)計

2.2 應(yīng)用實例

本文應(yīng)用實例如圖3 所示。

Fig.3 Composition of application example environment圖3 應(yīng)用實例環(huán)境組成

本實例中軟件代碼缺陷管理系統(tǒng)接入軟件開發(fā)工具鏈。當?shù)谌秸{(diào)度引擎從配置管理庫中檢出代碼進行編譯和測試后，基于原始的測試記錄生成軟件缺陷報告或更新軟件代碼缺陷屬性，并通知相應(yīng)負責(zé)人處理。負責(zé)人處理完相應(yīng)任務(wù)后會觸發(fā)軟件代碼缺陷屬性的更新以及自動流轉(zhuǎn)并通知相應(yīng)負責(zé)人處理，在軟件代碼缺陷管理系統(tǒng)中進行缺陷數(shù)據(jù)的跟蹤和分析。

3 效果評價

效果評價目標為評價本文軟件代碼缺陷管理方案及其原型系統(tǒng)較現(xiàn)有軟件缺陷管理方案的問題改善程度。改善程度度量值通過使用專家評分法對比兩種軟件代碼缺陷管理方案在同一軟件配置項中進行軟件代碼缺陷管理應(yīng)用效果獲得。用于對比的典型軟件代碼缺陷管理方案為基于GJB/Z 141 附錄C.3 的軟件缺陷分類標準，使用類似文獻［14］的定制缺陷管理工具進行缺陷管理。選取1 個軟件產(chǎn)品為系統(tǒng)控制軟件，由C/C++語言開發(fā)，代碼規(guī)模約2 萬行，效果評價周期為該軟件產(chǎn)品的編碼實現(xiàn)階段。針對現(xiàn)有軟件缺陷管理方案中存在的問題，選取5 個評價指標進行效果評價，分別為：①缺陷分類的細致程度及環(huán)境適應(yīng)性；②缺陷分類內(nèi)容值的準確性和一致性；③缺陷數(shù)據(jù)記錄和維護便利性；④缺陷跟蹤和分析的有效性；⑤缺陷處理流程流轉(zhuǎn)的實時性。選取10 名評價專家進行打分，評價專家均為專業(yè)從事軟件工程5 年以上的工程師。每項評價指標分值為0～5 分，得分由評價專家打分后求加權(quán)平均值得到。

Fig.4 Comparison of application effects圖4 應(yīng)用效果對比

兩種軟件代碼缺陷管理方案的應(yīng)用效果評價得分對比如圖4 所示。從圖中可以看出，本文方案的應(yīng)用效果較另一種方案在5 個方面評價指標上均有顯著改善，其中，缺陷分類的細致程度及環(huán)境適應(yīng)性分值提高了68%，缺陷分類內(nèi)容的準確性和一致性分值提高了50%，缺陷數(shù)據(jù)記錄和維護便利性分值提高了125%，缺陷跟蹤和分析有效性分值提高了33%，缺陷處理流程流轉(zhuǎn)的實時性分值提高了60%。評價結(jié)果表明本文方案在解決現(xiàn)有方案不足方面有明顯改善，提高了效率。

4 結(jié)語

本文針對現(xiàn)有軟件缺陷管理方案在工程應(yīng)用中存在的問題，從缺陷分類方法和缺陷管理系統(tǒng)兩方面展開研究，提出一種全新的軟件代碼缺陷管理方案。通過對比另一種基于GJB/Z 141 的軟件缺陷管理方案，應(yīng)用表明該方案在解決現(xiàn)有方案不足方面有顯著效果。但由于缺陷分類方法與特定應(yīng)用環(huán)境的耦合關(guān)系，本文研究成果的普適性仍有不足。另外，研究中發(fā)現(xiàn)不同來源的缺陷原始數(shù)據(jù)自身規(guī)則定義差別較大，如何有效對多源原始缺陷數(shù)據(jù)進行數(shù)據(jù)融合還需進一步研究。