一種軟件代碼缺陷管理方案研究

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

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

0 引言

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

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

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

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

1 軟件代碼缺陷管理方案

本文提出的軟件代碼缺陷管理方案是在缺陷分類方法基礎上通過缺陷管理系統工具實現對軟件代碼缺陷的管理。

1.1 軟件代碼缺陷分類方法

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

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

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

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

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

1.2 軟件代碼缺陷管理系統

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

1.2.1 缺陷數據生成

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

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

1.2.2 缺陷屬性管理

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

Table 2 Transformation rules corresponding to state property values表2 “狀態”屬性值對應的轉換規則

1.2.3 缺陷分類過程管理

根據缺陷狀態屬性值確定缺陷處理流程所處階段，并隨缺陷狀態屬性值的變化進行缺陷處理流程的流轉來實現缺陷分類。缺陷分類實現方式如圖1 所示。

Fig.1 Implementation of defect classification圖1 缺陷分類實現方式

1.2.4 缺陷數據跟蹤與分析

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

2 原型系統及應用

2.1 原型系統設計

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

Fig.2 Architecture design of prototype system圖2 原型系統體系結構設計

2.2 應用實例

本文應用實例如圖3 所示。

Fig.3 Composition of application example environment圖3 應用實例環境組成

本實例中軟件代碼缺陷管理系統接入軟件開發工具鏈。當第三方調度引擎從配置管理庫中檢出代碼進行編譯和測試后，基于原始的測試記錄生成軟件缺陷報告或更新軟件代碼缺陷屬性，并通知相應負責人處理。負責人處理完相應任務后會觸發軟件代碼缺陷屬性的更新以及自動流轉并通知相應負責人處理，在軟件代碼缺陷管理系統中進行缺陷數據的跟蹤和分析。

3 效果評價

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

Fig.4 Comparison of application effects圖4 應用效果對比

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

4 結語

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