基于持續集成的軟件度量

姜 文，劉立康

(西安電子科技大學 通信工程學院，西安 710071)

基于持續集成的軟件度量

姜 文，劉立康

(西安電子科技大學 通信工程學院，西安 710071)

軟件度量是針對軟件開發項目、過程及產品進行數據定義、收集和分析的持續度量化過程；持續集成工具上的的構建工程每天自動完成從版本庫更新代碼、靜態檢查、編譯、出包、自動化用例測試等任務，在進行集成構建的過程中可以為軟件度量提供多種相關的度量數據；結合工作實踐，敘述了基于持續集成的軟件度量的原理；軟件度量管理涉及到的角色；軟件度量實現過程；敘述了基于持續集成的兩種類型的軟件度量指標的定義以及提取方法；最后詳細敘述了在軟件度量過程中遇到的幾個典型案例；工作實踐表明在軟件的開發過程中做好軟件度量工作有助于軟件開發部門控制、預測、和改進軟件產品的質量與軟件開發過程；從而提高軟件質量和軟件開發效率，降低軟件開發成本。

軟件度量；持續集成；靜態檢查；軟件版本；集成構建

0 引言

軟件度量(software metrics)是對軟件在開發過程中進行的數據持續性采集、分析量化的過程。在軟件版本進行開發的過程中進行軟件度量有助于盡早發現軟件存在的問題，進行軟件缺陷預測，從而保證軟件產品的質量。

隨著軟件行業開發技術不斷發展，軟件持續集成與配置管理技術也不斷深入發展，已經成為軟件開發過程中非常重要的組成部分。通過運行持續集成的構建工程可以比較方便的來獲取某些軟件度量數據。將這些質量數據進行加工、分析之后匯總到由公司質量部門的網站上，方便產品的質量工程師與產品經理隨時查看本產品的各項度量數據，從而提高產品軟件源代碼的質量和安全性。

本文以持續集成工具ICP-CI為例，敘述基于持續集成的軟件度量的原理；軟件度量管理和涉及到的角色；基于持續集成的軟件度量實現過程；敘述了基于持續集成的兩種類型的軟件度量指標的定義以及提取方法；最后詳細敘述了軟件度量過程中的幾個典型案例。

1 基于持續集成的軟件度量原理

持續集成工具搭建的構建工程可以每天通過制定定時任務來自動完成從版本庫更新代碼、靜態檢查、編譯、出包、自動化用例測試等任務。在進行集成構建的過程中ICP-CI的主控服務器的MySQL數據庫會將許多數據記錄在數據庫中，主要包括在ICP-CI上進行集成構建成功與失敗的結果、靜態檢查的結果、編譯的結果；以及靜態檢查步驟、編譯步驟、出包步驟、自動化測試步驟的時間；自動化測試用例數目、成功的用例數、運行阻塞的用例數、運行失敗的用例數；失敗的步驟所在的位置以及各類代碼質量檢查工具的運行結果等。在集成構建的過程中可能發生大量的各種問題，這就為軟件度量數據采集提供了大量的數據資料。

1.1 軟件度量類型

1.1.1 軟件源代碼質量度量

軟件源代碼在靜態測試和編譯過程中出現問題的各種數據，可以用來度量軟件代碼質量，檢查并反饋軟件源代碼的各種缺陷。

1.1.2 軟件版本包的質量度量

集成構建中的出包步驟充分反映了各個軟件模塊在集成過程中的問題，出包的相關數據可以作為重要的模塊集成度量指標。

1.1.3 功能點測試的度量

通過調用自動化測試用例包，可以初步測試大量的軟件功能點，這些數據可以提取有關功能點度量數據，出包的相關數據也反映了功能點開發的進展情況，可以作為軟件功能開發進度的度量指標。

1.2 軟件度量的數據采集

在ICP-CI工具的頁面上搭建度量數據工程，將其他構建工程在集成構建過程中的各階段所需要的時間以及構建結果數據分別記錄到ICP-CI工具自帶的MySQL數據庫中。持續集成工程師可以登錄MySQL數據庫查看對已經完成構建工程的各種數據。

集成構建過程中采集度量數據需要根據構建類型標志位篩選出定時完整構建的數據，將這些數據上報到質量部門的匯總數據庫中。產品版本持續集成工程執行定時完整構建，需要在“管理”頁面上選擇定時構建的具體時間，構建任務，構建類型一定要選擇完整構建。完整構建是指包含構建工程的所有步驟，對于持續集成工程，包括代碼更新、基本靜態檢查、編譯、出包與自動化用例測試；對于源代碼靜態測試，包括代碼更新與所有靜態檢查步驟。

通過持續集成可以大大提高軟件度量數據的采集效率。獲得軟件開發過程中每一天的軟件度量數據，通過針對這些度量數據進行質量監控，可以盡早發現軟件的各種缺陷。

2 基于持續集成的軟件度量管理和涉及到的角色

在基于持續集成的軟件度量活動中，涉及到的角色有產品經理、公司質量部、軟件開發組、軟件測試組、持續集成工程師、產品質量工程師。軟件度量管理如圖1所示。

圖1 軟件度量管理用例圖

2.1 產品經理

制定軟件產品度量計劃，確定度量指標中的統計承諾值。度量計劃提交給公司質量部門審查。關注度量數據的變化，指導和參與度量數據異常處理。

2.2 公司質量部

負責搭建與維護公司的質量網站，審查軟件項目組的度量計劃，對度量數據進行統計分析，指導項目組處理各種度量數據異常問題。

2.3 軟件開發組

在產品的整個度量周期中關注開發組負責的軟件模塊的相關度量數據，當出現度量數據異常時，參與分析異常的度量數據并實施改進。

2.4 軟件測試組

在產品啟動度量采集之前，進行相關的自動化環境搭建，并配合持續集成工程提供相關的測試用例腳本。參與度量數據異常的分析和處理。

2.5 持續集成工程師

在產品啟動度量采集之前，將軟件產品版本信息提供給公司質量部門接口人，安排該版本在公司質量部進行數據呈現時的導航樹配置。

負責持續集成度量數據與源代碼質量度量數據的采集，采集的度量數據上報公司質量部；當出現產品度量數據異常時，參與度量數據異常情況的定位和處理；確保從ICP-CI主控服務器上采集的度量數據在度量周期內全部達標。

2.6 產品質量工程師

審計產品版本的質量計劃，定期針對產品的度量數據進行審計，督促軟件項目組及時處理度量數據異常問題，參與不達標度量數據的定位與解決，保證在度量周期內所有的度量數據達標。

3 基于持續集成的軟件度量實現過程

3.1 度量數據采集環境的部署

度量采集工具的功能是從產品ICP-CI主控服務器的MySQL數據庫中定時完整構建條件的度量數據，然后將數據上報到公司質量部的數據庫中。

主控服務器(Master)安裝ICP-CI-Windows-Master之后，為了采集度量數據需要將公司自研的度量采集工具部署到主控服務器上，具體部署過程如下：

1)登入ICP-CI的主控服務器，關閉ICP-CI相關與MySQL服務的相關進程；

2)度量數據采集工具解壓之后為ICP-CI.jar，將該文件部署到Master的master/bin目錄下；

3)在啟動ICP-CI工具的腳本startup.bat中加入啟動度量數據采集工具的語句：CALL ICP_CI.jar；

4)啟動MySQL數據庫后，再執行startup.bat啟動ICP-CI工具的網頁版頁面。

3.2 基于持續集成的軟件度量的分類

基于持續集成的軟件度量可以分為兩種類型：軟件版本可用性度量與軟件源代碼靜態測試度量。

3.2.1 軟件版本可用性度量

軟件版本可用性度量需要在產品迭代開發開始階段進行軟件度量，測試經理安排自動化測試工程師完成產品版本的自動化測試用例腳本的編寫與自動化測試環境的搭建。持續集成工程師在ICP-CI工具上搭建產品版本的持續集成工程，在完成出包步驟后執行測試組提供的自動化測試用例腳本。

持續集成工程師在ICP-CI工具上搭建產品版本的代碼質量工程。通過部署檢查工具來提取版本可用性度量數據。軟件版本可用性度量指標如表1所示：

(1)CI構建成功率：(一個度量周期內CI構建成功次數)/(一個度量周期內CI構建總次數)；

(2)每日版本可用率：(一個度量周期內CI構建成功的天數)/(一個度量周期內進行CI構建總天數)，工作日有一次CI構建成功可以確認該日為CI構建成功日；

表1 版本可用性度量指標

(3)構建恢復時長：一次CI構建失敗到下一次CI構建成功的時間間隔；

(4)有效構建天數比：(一個度量周期內有效CI構建成功的天數)/(一個度量周期內工作日數)，有效CI構建是指可以作為度量數據的構建。

度量周期通?？梢赃x擇七天、十五天、一個月。

軟件產品版本可用性度量大多選擇以月為單位，在度量周期中的度量指標達不到要求時，就會發郵件知會產品經理、質量工程師與持續集成工程師，需要分析定位產品版本可用性指標數據不達標的原因。通常有兩類問題導致的版本可用性度量指標異常：1)軟件產品自身缺陷，2)持續集成運行環境問題。

3.2.2 軟件產品源代碼靜態測試度量

對于軟件產品源代碼靜態測試數據的度量，由于各產品的情況不同，質量部門無法給出統一的度量指標來判定產品的源代碼是否符合公司的標準，需要在產品迭代開發開始階段，由產品經理根據產品特點，對于某些度量項的度量指標分別給出指標承諾值，并將這些承諾值提交到質量部門進行審核，質量部門審核通過之后，這些度量項的指標承諾值和度量數據一起上報質量部門。

持續集成工程師在ICP-CI工具上搭建產品版本的代碼質量工程。通過集成各種檢查工具來提取軟件產品源代碼靜態測試數據度量。軟件源代碼靜態測試數據的度量指標如表2中所示：

表2 軟件源代碼靜態測試度量指標

1) 代碼質量缺陷指數(Qualiti Deficit Index)：是通過質量缺陷模型計算出來的，展示系統歸一化和總的質量缺陷指數。QDI取值的計算方法：

總的QDI是設計缺陷×權重的累加值，總的QDI和系統的規模大小有關。

歸一化QDI=1000*(總的QDI/有效代碼行數)。

通過將Infusion工具集成到ICP-CI工具中，完成對代碼質量缺陷指數(QDI)的數據采集任務。

2) 代碼重復度：重復的代碼行數和總代碼行數之比。通過將Simian工具集成到ICP-CI工具中，完成對代碼重復度數據采集任務。

3)代碼圈復雜度(全量代碼)：，需要將SourceMonitor工具集成到ICP-CI工具中，完成對代碼中所有的函數進行圈復雜度數據采集。

4)代碼圈復雜度(新增代碼)：統計新增代碼的圈復雜度時，需要將SourceMonitor工具集成到ICP-CI工具中，完成對當前現有的代碼與基線的代碼進行比對，篩選出新增的函數，并完成針對新增函數的圈復雜度數據采集。

5)PC-Lint檢查：針對C/C++語言源代碼的經典靜態檢查工具，可以通過將PC-Lint工具集成到ICP-CI工具中，完成對軟件代碼進行PC-Lint檢查，被檢查出來的缺陷可以分為錯誤、告警以及提示這三個級別。

6)FindBugs檢查：針對Java語言源代碼的經典靜態檢查工具，可以通過將FindBugs工具集成到ICP-CI工具中，完成對軟件代碼進行FindBug檢查，被檢查出來的缺陷可以分為錯誤、告警以及提示這三個級別。

7)Coverity/Fortify檢查：重量型的軟件源代碼缺陷靜態測試工具，需要通過插樁編譯的方式在檢查過程中編譯生成中間文件，將中間文件上傳到專門的分析平臺上分析之后得到缺陷報告，缺陷根據問題級別可以分為高、中、低三個級別。Coverity與Fortify工具可以對C/C++代碼進行靜態檢查，也可以對Java進行靜態檢查。

8)危險函數檢查：針對C/C++語言源代碼執行的安全測試，需要將源代碼中的危險函數全部統計出來，可以通過將Csec_Check工具集成到ICP-CI工具中，完成對軟件代碼進行危險函數統計。

3.3 軟件產品版本交付使用后終止度量處理

軟件產品版本的迭代開發與測試活動結束后，版本交付使用轉為維護版本，產品版本研發階段結束。產品經理知會公司質量部，該產品版本轉為維護版本，該產品版本度量下線。由質量部門將目前處于度量中的產品版本轉到度量下線的版本中。這個版本不會在度量頁面上呈現新的度量數據，僅能從度量下線版本中查看該版本的歷史數據。

4 典型案例

某大型軟件公司有一個軟、硬件結合的大型軟件新項目，軟件代碼量為2000多萬行，在該產品開發階段，產品經理向公司質量部門提供該產品的產品名稱與產品版本號，公司質量部門為該產品添加相關的度量頁面，打開公司的軟件度量數據網站可以看到該產品的信息。在開展軟件度量的過程中處理了大量的各種問題，下面介紹幾個典型的工作案例。

4.1 自動化測試用例執行失敗的案例

持續集成工程師進行版本可用性度量時發現，在執行自動化測試用例腳本時部分用例會失敗，排查持續集成環境沒發現任何環境問題，聯系自動化測試工程師定位發現，由于新的版本包中lny進程會發生異常復位的情況導致自動化測試用例腳本執行失敗。聯系軟件開發工程師定位問題，發現是產品代碼缺陷導致的，軟件開發工程師修改源代碼之后合入版本庫，重新進行版本可用性度量，取得成功。

當月20個工作日，19天共進行CI構建19次，其中CI構建成功18次，有效構建天數18天。該月的版本可用性度量數據如表3所示。

表3 版本可用性度量數據實例

4.2 構建環境出現異常狀況的案例

持續集成工程師度量工程在執行編譯時，會出現超時失敗的情況，排查持續集成環境之后發現有一個編譯環境的ICP-CI進程啟動異常。重啟這個編譯環境之后，然后再啟動ICP-CI相關進程，重新進行版本可用性度量，終于執行成功。

當月22個工作日，共進行CI構建27次，其中CI構建成功22次，有效構建天數22天。該月的版本可用性度量數據如表4中所示。

表4 版本可用性度量數據實例

4.3 軟件源代碼問題導致度量數據異常的案例

進行源代碼靜態測試度量時，收到版本圈復雜度檢查未達標的提示，發現圈復雜度(新增代碼)的檢查結果數據為11.3大于承諾值10，數據不達標。持續集成工程師定位問題代碼的模塊之后聯系軟件開發組組長，最后確認是該模塊源代碼的函數圈復雜度超標。軟件開發工程師修改源代碼之后合入版本庫，重新進行源代碼靜態測試數據度量，次日和度量周期內后續的圈復雜度(新增代碼)度量數據為9.8。其他的源代碼靜態測試度量數據沒有出現任何異常。圈復雜度(新增代碼)度量數據如表5中所示。

表5 代碼圈復雜度(新增代碼)度量數據實例

5 結束語

長期的工作實踐表明基于持續集成的軟件度量在軟件開發過程中發揮了重要的作用。在集成構建過程中自動完成軟件產品的度量數據提取，可以快速地向質量部門提交度量數據。對于采集到的數據質量部門進行相關的分析和處理，可以以表格形式顯示到度量網站上，同時也給出相關度量數據的柱狀圖、折線圖和餅圖，以非常直觀的形式顯示度量數據的各種狀態和發展趨勢。工作實踐表明在軟件的開發過程中做好軟件度量工作有助于軟件開發部門控制、預測、和改進軟件產品的質量或軟件開發過程。軟件度量為軟件項目的質量管理提供了很好的保證。在很大程度上提高軟件產品的質量和開發效率，降低軟件開發的的成本。

[1] (英)Norman E.Fenton，(美)Shari Lawrence Pfleeger，楊海燕等譯，軟件度量(原書第二版)[M]．北京：機械工業出版社，2004.

[2] 朱少民.軟件質量保證和管理[M]．北京：清華大學出版社，2007.

[3] 于 波，姜 艷.軟件質量管理實踐—軟件缺陷預防、清除、管理實用方法[M]．北京：電子工業出版社，2008.

[4] 趙宏遠.軟件度量、過程度量與歷史缺陷度量：工作量感知的缺陷預測能力比較[D].南京：南京大學，2013.

[5] Tibor Gyimothy，Rudolf Ferenc，Istvan Siket. Empirical validation of object-oriented metrics on open source software for fault prediction[J].IEEE Transactions on Software Engineering，2005，31(10)：897-910.

[6] 計春雷.全功能點方法和功能規模度量統一模型的研究與應用[D].上海：華東理工大學，2011.

[7] 姜 文，劉立康.基于SVN的應用軟件持續集成[J].計算機測量與控制，2016，24(3)：109-113.

[8] 姜 文，劉立康.軟件配置管理中的基線問題研究[J].計算機技術與發展，2016，26(6)：6-10.

[9] 姜 文，劉立康.基于持續集成的PC-Lint 靜態檢查[J].計算機技術與發展，2016，26(11)：31-36.

[10] 姜 文，劉立康.C++ 與Java 軟件重量級靜態檢查[J].計算機技術與發展，2016，26(8)：17-23.

[11] N Fenton，P Krause，M Neil.Software Measurement: Uncertainty and Causal Modeling[J]. IEEE Software，2002，19(4)：116-122.

[12] Taek Lee，Jaechang Nam，Dongyun Han，et al. Developer Micro Interaction Metrics for Software Defect Prediction[J]. IEEE Transactions on Software Engineering，2016，42(11)：1015-1035.

[13] Lakshmi P，Latha Maheswari T. An Effective rank approach to software defect prediction using software metrics[A]. 2016 10th International Conference on Intelligent Systems and Control (ISCO)[C].2016：1-5.

[14] Wang Shuo，Yao Xin.Using Class Imbalance Learning for Software Defect Prediction[J]. IEEE Transactions on Reliability，2013，62(2)：434-443.

[15] Yang Xiaoxing，Tang Ke，Yao Xin. A Learning-to-Rank Approach to Software Defect Prediction[J]. IEEE Transactions on Reliability，2015，64(1)：234-246.

Software Metrics Based on Continuous Integration

Jiang Wen，Liu Likang

(School of Telecommunication Engineering, Xidian University, Xi’an 710071,China)

The software metrics involved software development project, process and prodution data definition, collection, and analysis, it is a continuous quantitative process. Tasks as updating the code from the repository, static checking, compile, package, test automation cases are automatically running by building project in continuous integration tool, during the process of building a variety of related metrics data for software metrics are provided. In combination with working practice, the principle of software metrics based on continuous integration are described; the roles involved in the management of the software metrics; the process of software metrics implemented. Described two types definition of software metrics and extraction methods based on the continuous integration. At last, several typical cases encountered in the process of software metrics is described in detail. Practice shows that in the software development process, to do a good job of software metrics helps to control, prediction, and improve the quality of the software product and software development process in software development department. Improves the efficiency of software development and software quality, reduces the cost of software development.

software metrics; continuous integration; static checking; software version; integration building

2016-12-03；

2017-01-05。

國家部委基礎科研計劃：國防預研基金項目 (A1120110007)。

姜 文(1986-)，女，陜西西安人，工程師，碩士研究生，CCF會員(E200032324M)，主要從事圖像處理與分析，數據庫應用和軟件工程方向的研究。

1671-4598(2017)05-0136-04

10.16526/j.cnki.11-4762/tp.2017.05.038

TP311.56

A