敖海洋 余明珠 呂恬

【摘 要】隨著軟件產(chǎn)業(yè)的不斷發(fā)展，軟件缺陷成為制約軟件質量的關鍵因素。如何管理和跟蹤在測試和使用過程中發(fā)現(xiàn)的軟件缺陷，對于提高缺陷修復效率具有一定的現(xiàn)實意義。目前軟件缺陷管理存在平臺遷移困難，數(shù)據(jù)遷移困難，導入導出資源困難，對于缺陷沒有可視化圖表展示等問題。系統(tǒng)使用GitBlit作為版本庫，Jenkins進行持續(xù)集成，使團隊成員能夠良好地協(xié)作，針對需求的變更能良好地應對，系統(tǒng)的質量也在一定程度上得到了提高。在缺陷管理系統(tǒng)中使用持續(xù)集成框架，對項目代碼進行測試，及時發(fā)現(xiàn)系統(tǒng)缺陷，同時減少系統(tǒng)的潛在缺陷。

【關鍵詞】持續(xù)集成；缺陷管理；SSM框架；Jenkins

中圖分類號： TP393.09 文獻標識碼： A 文章編號： 2095-2457（2018）05-0049-002

【Abstract】With the continuous development of software industry， software defects become the key factor restricting the software quality. How to manage and track the software defects which are found in the process of testing and using has practical significance for improving the efficiency of defect repairing.From the view of current disadvantages in software defect management，such as difficulties of platform migration，the data migration，importing and exporting resources and the visualization of the defects of the visual displaying shortage etc.The system utilizes GitBlit as a repository， Jenkins for continuous integration，so that team members can work well together.Changes in the demand for a good response，the quality of the system has also been improved to some extent.Using the Continuous Integration Framework in a defect management system enables project code testing，timely detection of system defects， and reduction of potential system defects.

【Key words】Continuous integration；Defect management；SSM framework；Jenkins

0 引言

近年來，隨著計算機技術的不斷發(fā)展，軟件作為不可或缺的元素進入人們的生活之中[1]。在軟件的開發(fā)與使用的過程當中，缺陷的產(chǎn)生往往會極大地影響軟件的開發(fā)與使用。因此，需要一套功能完備的缺陷管理系統(tǒng)來對缺陷進行管理和跟蹤，方便開發(fā)人員與測試人員溝通交流，對缺陷進行及時修改和管理。在軟件系統(tǒng)開發(fā)過程中，往往存在著項目進度不可控、軟件質量無法保證、開發(fā)風險較大、成本經(jīng)常超出預算、軟件測試效率過低等問題，因此項目中引入持續(xù)集成，提高缺陷管理系統(tǒng)的質量與開發(fā)效率。持續(xù)集成的目標是利用開發(fā)人員的生產(chǎn)力，同時通過使集成成為軟件工程周期中一個簡單自然的部分來降低集成風險[2]。

1 持續(xù)集成

1.1 持續(xù)集成的概念

持續(xù)集成（CI）是一種軟件開發(fā)實踐，讓軟件開發(fā)團隊在一天之內多次自動構建軟件。持續(xù)集成建立在敏捷開發(fā)的方式之上[3]，它提倡團隊開發(fā)人員多次對現(xiàn)有的開發(fā)工作進行集成，然后每一次的集成都通過自動化構建軟件來實現(xiàn)，包括有項目的自動化編譯、單元測試、自動化發(fā)布等環(huán)節(jié)，這樣有利于在早期發(fā)現(xiàn)軟件項目中的缺陷，大大減少集成的問題，讓從而降低開發(fā)軟件的風險。持續(xù)集成的主要流程如圖1所示。常用構建工具包括Jenkins、Travis、Codeship、Strider四種。本系統(tǒng)中主要用Jenkins。

1.2 國內外現(xiàn)狀

隨著持續(xù)集成核心價值逐漸被人們認可，很多國外軟件公司開始進行持續(xù)集成的研究[4]，逐漸有一些持續(xù)集成工具被開發(fā)出來，其中Jenkins，CruiseControl， Bamboo，QuickBuild是業(yè)界相對流行的幾款持續(xù)集成服務器。ThoughtWorks公司開發(fā)的CruiseControl是最早面世的一款持續(xù)集成服務器，為CI過程的推廣做出了很大的貢獻。Jenkins作為開源持續(xù)集成工具的后起之秀，市場份額上已經(jīng)超過了早期CI工具。Jenkins采用Java語言開發(fā)，Jenkins的主要特點：簡潔的Web界面、易用性、監(jiān)控可視化、功能插件化等。Google在軟件開發(fā)行業(yè)有比較領先的持續(xù)集成技術，Google也一直在優(yōu)化和改進現(xiàn)有的一些持續(xù)集成框架，從而能不斷提高持續(xù)集成的效率。

國內對持續(xù)集成的研究相對較晚。百度在2009年引入敏捷開發(fā)，后來隨著的發(fā)展，在2010年開始在項目中融入持續(xù)集成方式。2009年，華為也引入了敏捷開發(fā)模式，由于華為云計算的發(fā)展需要，逐漸在開發(fā)過程中加入了持續(xù)集成。在最近幾年中，阿里、騰訊等大型互聯(lián)網(wǎng)公司也開始研究持續(xù)集成。

1.3 持續(xù)集成的必要性

傳統(tǒng)的軟件開發(fā)方式是：對項目進行分析，劃分模塊然后分別開發(fā)，等所有的模塊都開發(fā)完畢后再在一起進行集成測試[5，6]。這種軟件開發(fā)方法存在很多問題：首先，這種方法適合各個模塊之間沒有聯(lián)系或者聯(lián)系很少的情況，但是現(xiàn)在大部分軟件模塊與模塊之間，人員與人員之間聯(lián)系緊密；其次，軟件的功能要求愈來愈高，軟件也越來越復雜，單純的模塊劃分的方法已經(jīng)不能滿足當前的求需；最后，很多軟件的模塊分開能正常工作，但是集成在一起就會出現(xiàn)缺陷，而且還可能會讓缺陷越改越多，這會導致軟件質量差和產(chǎn)品發(fā)布延遲。因此開發(fā)團隊不得不尋找一種新的方案來解決面臨的問題。持續(xù)集成通過頻繁地構建代碼，保證項目一直都能夠正常運行，降低了發(fā)布產(chǎn)品失敗風險，提高了產(chǎn)品質量。同時持續(xù)集成能夠減少發(fā)布產(chǎn)品的重復勞動，節(jié)約人力成本。

2 系統(tǒng)設計

由于在軟件系統(tǒng)的開發(fā)過程中，往往存在著項目進度不可控、軟件質量無法保證、開發(fā)風險較大、成本經(jīng)常超出預算、軟件測試效率過低等問題，因此在本項目中引入持續(xù)集成，采用GitBlit作為版本庫，SSM作為系統(tǒng)框架，借此來提高缺陷管理系統(tǒng)的質量與開發(fā)的效率。本系統(tǒng)擬以迭代的方式系統(tǒng)地檢測刪除來實現(xiàn)缺陷管理。在知識庫中注冊與缺陷相關的事件和規(guī)則，使模型變得智能化。使用分布式協(xié)作工具使軟件檢查員能夠毫無差距和重疊地履行職責。定制的檢驗過程評估準備了關于檢驗過程的性能和有效性的有用信息，這導致在項目生命周期的下一次迭代中持續(xù)改進。在真實的環(huán)境中實現(xiàn)模型以檢測和消除真實的缺陷顯示了模型的性能[7]。

2.1 所用框架SSM

SSM（Spring+SpringMVC+MyBatis）框架集由Spring、SpringMVC、MyBatis三個開源框架整合而成，是繼SSH之后，目前比較主流的Java EE企業(yè)級框架。具有易于上手、測試便捷、能優(yōu)化管理等顯著特點。其中Spring是一個輕量級的控制反轉（IoC）和面向切面（AOP）的容器框架。其提供了一種簡易的開發(fā)方式，避免了那些可能導致底層代碼變得混亂復雜的大量屬性文件和幫助類。SpringMVC提供了構建web應用程序的全功能MVC模塊，分離了控制器、模型對象、分派器以及處理程序對象的角色。MyBatis是一個支持普通SQL查詢，存儲過程和高級映射的優(yōu)秀持久層框架。選擇此框架作為項目開發(fā)框架，大大縮短了開發(fā)時間，并能統(tǒng)一并優(yōu)化缺陷管理。

2.2 設計流程

在調查研究現(xiàn)有的缺陷管理系統(tǒng)并總結出其中的問題后，選擇開源工具，設計并確定框架方案以及開發(fā)方案，進行系統(tǒng)實施。在此過程中需要搭建數(shù)據(jù)庫、GitBlit、Jenkins，前端使用JQuery EasyUI進行開發(fā)，系統(tǒng)采用Spring MVC+MyBatis框架。開發(fā)完成之后，對系統(tǒng)進行應用、評價和分析，并改進和推廣系統(tǒng)。系統(tǒng)設計流程圖2所示：

2.3 系統(tǒng)實現(xiàn)

持續(xù)集成缺陷管理平臺主要包括核心模塊、數(shù)據(jù)分析模塊、測試模塊、前端展示模塊。

2.3.1 核心模塊

用戶輸入缺陷信息，通過HTTP協(xié)議傳輸?shù)椒掌鳎环掌魍ㄟ^SMTP協(xié)議向用戶發(fā)送缺陷狀態(tài)。工作流程如下：

（1）用戶在瀏覽器訪問缺陷管理系統(tǒng)，在相應頁面填寫缺陷的詳細信息，在提交表單時，通過http協(xié)議發(fā)送post請求到服務器；服務器接收請求。將缺陷信息打包，通過服務器的SMTP，發(fā)送到管理者。

（2）缺陷被處理或者關閉時，服務器將對應的缺陷狀態(tài)打包通過SMTP發(fā)送到相關人員。

2.3.2 數(shù)據(jù)分析模塊

數(shù)據(jù)分析模塊負責處理核心模塊傳遞的各類參數(shù)，包括如下操作：

（1）過濾：過濾返回數(shù)據(jù)中的無效冗余信息；

（2）解析：對數(shù)據(jù)進行分類分析，計算

（3）存儲：將數(shù)據(jù)進行分類存儲，方便日后整理分析；

（4）顯示：將數(shù)據(jù)發(fā)送至前臺展示模塊。

2.3.3 前端展示模塊

前臺展示模塊負責實現(xiàn)用戶與平臺的交互功能、數(shù)據(jù)可視化展示。

2.3.4 測試模塊

在系統(tǒng)開發(fā)過程中結合持續(xù)集成，自動對開發(fā)代碼進行上傳持續(xù)集成。在不同測試人員對系統(tǒng)編寫單元測試代碼后，系統(tǒng)直接集成，以便及時檢查出系統(tǒng)的缺陷。

3 結語

系統(tǒng)利用GitBlit作為版本庫，Jenkins進行持續(xù)集成，針對現(xiàn)在國內外缺陷管理系統(tǒng)存在的問題（如：平臺遷移困難，數(shù)據(jù)遷移困難，導入導出資源困難，對于缺陷沒有可視化的圖表展示）進行了改進，完成了缺陷管理。在項目開發(fā)中結合持續(xù)集成可以大大節(jié)省開發(fā)時間；基于持續(xù)集成的缺陷管理系統(tǒng)在缺陷管理過程中降低了缺陷管理的復雜度，方便測試、開發(fā)人員對缺陷進行跟蹤、管理。隨著軟件產(chǎn)業(yè)的不斷發(fā)展，軟件項目的開發(fā)效率也逐漸成為行業(yè)關注的熱點問題，合理管理軟件缺陷在軟件項目開發(fā)過程中將越來越被重視。在持續(xù)集成系統(tǒng)的背景下考慮驗收測試的發(fā)展已經(jīng)是一個重大轉變[8]。

【參考文獻】

[1]于廣輝.基于Scrum的軟件缺陷管理系統(tǒng)設計與實現(xiàn)[D].大連理工大學，2014.

[2]Abdul F A，F(xiàn)hang M C S.Implementing Continuous Integration towards rapid application development[C]// International Conference on Innovation Management and Technology Research.IEEE，2012：118-123.

[3]陶鎮(zhèn)威.基于Jenkins的持續(xù)集成研究與應用[D].華南理工大學，2012.

[4]張力文.基于Jenkins的項目持續(xù)集成方案研究與實現(xiàn)[D].西南交通大學，2017.

[5]戴建國，趙慶展，郭理，秦懷斌.持續(xù)集成在項目開發(fā)中的應用研究[J].計算機工程與設計，2009，30（10）：2573-2576.

[6]陳剛，羌鈴鈴.軟件項目開發(fā)中的持續(xù)集成研究[J].項目管理技術，2011，9（12）：103-106.

[7]Taba N H， Ow S H.Software Defect Management Using a Comprehensive Software Inspection Model[J].Software Engineering， 2012， 2（4）：160-164.

[8]Stolberg S.Enabling Agile Testing through Continuous Integration[C]//Agile Conference.IEEE，2009：369-374.