劉 博,汪宇昕

(1 北京縱橫機電技術(shù)開發(fā)公司， 北京 100094； 2 北京師范大學(xué)附屬實驗中學(xué)， 北京 100032)

軌道交通機車車輛軟件大多是嵌入式軟件，在行業(yè)競爭日趨激烈背景下，要求產(chǎn)品不斷壓縮上市時間，才能搶占市場獲得主動權(quán)。然而，在硬件發(fā)展日益穩(wěn)定，而軟件問題卻逐漸突出的形勢下，軟件的交付周期和質(zhì)量問題開始引起人們的重視，特別是需要團隊共同協(xié)作的軟件產(chǎn)品。例如，典型的瀑布模型開發(fā)過程，先由個人負責(zé)開發(fā)模塊，由于開發(fā)進度不同或溝通等問題，往往等到多數(shù)模塊都完成后才能開始執(zhí)行集成測試，那么發(fā)現(xiàn)的問題數(shù)量可能會爆炸性的增長[1]。

持續(xù)集成起源于極限編程開發(fā)方法，是Martin Fowler和Matthew Foemmel于2000年提出的一項軟件開發(fā)實踐[2]。簡單來說持續(xù)集成是指開發(fā)團隊中的每個成員都盡量頻繁的把工作提交到版本庫，構(gòu)建服務(wù)器自動將新提交的代碼與原有資源構(gòu)建成一個新版本，通過測試來驗證新提交的代碼沒有對項目造成破壞[3]。

文中基于Jenkins，一種持續(xù)集成工具，實現(xiàn)了嵌入式軟件持續(xù)集成的閉環(huán)測試過程。通過配置Jenkins、自動化測試工具、版本控制軟件和測試報告插件，當(dāng)檢測到版本庫有變化時，工具會自動下載和測試版本庫中的程序，如果發(fā)現(xiàn)問題，則立刻通知開發(fā)人員[4]。本方案不僅能夠密切監(jiān)視代碼庫的正確性，包括代碼質(zhì)量和覆蓋率；而且可以在無人值守的情況下自動完成預(yù)先設(shè)定好的測試任務(wù)，完成重復(fù)的測試過程，通過提供更快地識別和修復(fù)集成以及回歸相關(guān)問題，達到更平滑、更快的交付和更少的問題[6]。

1 系統(tǒng)設(shè)計

1.1 系統(tǒng)架構(gòu)設(shè)計

持續(xù)集成作為敏捷開發(fā)的最佳實踐已被廣泛研發(fā)團隊采用，其中Jenkins作為重要的開源持續(xù)集成工具之一，為持續(xù)集成測試提供了一個方便的平臺。其不僅支持多種第3方插件，而且它的配置和管理功能也能強大，包括系統(tǒng)配置、插件安裝、日志記錄和權(quán)限管理等[5]。

文中主要采用Jenkins + Subversion(SVN) + Sygwin + C++Test組成持續(xù)集成系統(tǒng)。其中Jenkins為持續(xù)集成服務(wù)器(CI Server)；Subversion為開源的源代碼管理工具，保存源代碼和變更記錄；Sygwin為軟件開發(fā)環(huán)境，提供軟件測試編譯器；C++Test為一款商業(yè)測試軟件，支持包括標(biāo)準(zhǔn)規(guī)則檢查，以及測試用例調(diào)用、覆蓋率統(tǒng)計和度量分析等。之所以選擇商業(yè)測試軟件，是由于軌道交通機車車輛軟件產(chǎn)品在行業(yè)標(biāo)準(zhǔn)要求下，對于軟件有明確的測試指標(biāo)，例如：執(zhí)行靜態(tài)分析、動態(tài)測試，統(tǒng)計單元測試覆蓋率等[7]，一般商業(yè)軟件能夠同時滿足這些要求。在第2節(jié)內(nèi)容中，將使用嵌入式軟件代碼對該集成策略進行驗證，在第3節(jié)測試基于Maven開發(fā)的測試報告插件。

1.2 持續(xù)集成流程

持續(xù)集成基本實現(xiàn)過程如圖1所示，主要包括代碼提交、創(chuàng)建項目、構(gòu)建、測試和測試結(jié)果反饋，具體步驟如下：

(1)開發(fā)人員A與B分別負責(zé)同一項目的不同模塊開發(fā)，假設(shè)這些模塊之間存在接口關(guān)系。當(dāng)完成接口設(shè)計和基礎(chǔ)邏輯，具備集成測試條件時，提交到源代碼管理庫SVN。同時，提前在測試環(huán)境下編寫集成測試用例，直到測試用例能夠覆蓋所有需求；

(2)將被測軟件提交到“源代碼管理庫”。SVN將記錄當(dāng)前提交的版本和修改時間等情況，后續(xù)的新增模塊和變更都在此基礎(chǔ)上不斷納入SVN進行管理；

(3)“創(chuàng)建項目”是在Jenkins中創(chuàng)建項目空間，和進行基本信息設(shè)置的過程，例如：源代碼版本庫的鏈接、輪詢周期、觸發(fā)構(gòu)建條件等；

(4)當(dāng)Jenkins輪詢發(fā)現(xiàn)源代碼管理庫發(fā)生改變時觸發(fā)“構(gòu)建”過程，檢查被測代碼在開發(fā)環(huán)境下是否能夠通過編譯，如果有錯誤則通知開發(fā)人員，并停止測試。測試之前的編譯檢查，是執(zhí)行測試的基本進入條件；

(5)在“自動化測試”階段，使用自動化測試工具事先編寫好的測試用例進行靜態(tài)規(guī)則檢查和動態(tài)測試；

(6)測試完成后，以電子郵件形式“通知”開發(fā)人員測試結(jié)論。默認情況下，Jenkins為每個失敗和不穩(wěn)定的構(gòu)建發(fā)送一封電子郵件。

圖1 持續(xù)集成流程圖

2 Jenkins項目配置過程

2.1 源代碼管理庫

SVN作為版本控制工具，項目開發(fā)人員提交代碼到版本庫SVN，可通過配置Jenkins觸發(fā)條件，設(shè)置定時檢查版本庫更新情況，或者設(shè)置SVN鉤子post-commit，當(dāng)版本庫有代碼更新時，Jenkins自動下載最新代碼到工作空間[8]。例如，Jenkins周期輪詢使用了cron風(fēng)格語法，包括5個由空格分隔的字段：

MINUTE HOUR DOM MONTH DOW

在本方案中要求每小時執(zhí)行一次測試，配置方式為：“0 */1 * * *”

2.2 構(gòu)建

將開發(fā)完成的嵌入式子系統(tǒng)代碼導(dǎo)入工作空間，使用gcc交叉編譯器，對工程進行編譯，編譯過程在Makefile中實現(xiàn)。在構(gòu)建腳本中進行判斷編譯是否成功，當(dāng)編譯發(fā)生錯誤時終止測試；反之，繼續(xù)執(zhí)行集成測試。見表1，通過make命令執(zhí)行編譯檢查。

2.3 自動化測試

當(dāng)工程構(gòu)建通過后，啟動軟件測試工具C++Test對代碼進行測試，由于該軟件支持命令行操作，因此可以通過腳本的方式啟動靜態(tài)規(guī)則檢查和動態(tài)測試，其中靜態(tài)規(guī)則檢查集通過 -config進行設(shè)置，指定要求的規(guī)則集。動態(tài)測試使用測試工具C++Test命令行- cpptestcli，指定工程路徑C:...cpptestscan.bdf，調(diào)用預(yù)先設(shè)計好的測試工程。在測試用例執(zhí)行過程中，如果發(fā)生錯誤，可查看Jenkins控制臺，或者將控制臺信息作為日志導(dǎo)出查看，使用-appconsole命令。本項目自動測試腳本見表1。

表1 Jenkins構(gòu)建配置腳本

2.4 測試報告

測試結(jié)束后，Jenkins輸出測試結(jié)果趨勢圖，顯示測試用例總數(shù)和失敗用例數(shù)，并可查看控制臺打印信息。為了方便查看詳細的測試信息，本方案使用自行開發(fā)的插件，提取C++Test生成的測試報告內(nèi)容，測試人員能夠在Jenkins中查看測試結(jié)果見圖2。報告中列出了被測項目里每個代碼文件的錯誤和位置，可直接鏈接到源代碼相應(yīng)代碼。

圖2 測試報告

2.5 通知

持續(xù)集成系統(tǒng)的另一個主要優(yōu)勢在于能夠快速向開發(fā)者提供測試反饋信息。一般情況下，測試過程是定時觸發(fā)且無人值守的，那么就需要測試系統(tǒng)在執(zhí)行時，及時記錄測試過程，執(zhí)行完畢后，迅速反饋測試結(jié)果。Jenkins提供了3種反饋方式：Email、IM、RSS，在每次構(gòu)建失敗，或者第1次構(gòu)建成功時會發(fā)出通知。

3 測試插件開發(fā)

Jenkins已經(jīng)形成了內(nèi)容豐富的插件庫，作為開源工具，可供測試人員實現(xiàn)持續(xù)集成配置。本次開發(fā)使用的IDE是MyEclipse。開發(fā)環(huán)境需要安裝JDK(版本1.8.0_65)、Maven(版本3.5.2)，配置環(huán)境變量、添加path路徑，見圖3。

圖3 安裝JDK與Maven

由于Jenkins是基于maven的java項目，因此其插件就是在maven框架下開發(fā)。安裝maven相關(guān)擴展工具，再配置setting.xml文件，如圖4，否則編譯時會報錯。

圖4 配置Maven的setting.xml

使用maven創(chuàng)建一個插件項目，好處是插件可以根據(jù)pom.xml里的dependency能夠自動下載相關(guān)的jar包并解決依賴問題。Maven項目的目錄結(jié)構(gòu)是默認的標(biāo)準(zhǔn)模板，以本插件開發(fā)目錄為例(見圖5)，主要包括src/main/java源代碼目錄，src/main/test測試代碼目錄，src/main/resources存放插件jelly界面設(shè)計。

圖5 Maven工程文件目錄結(jié)構(gòu)

該插件最終顯示形式見圖2，實現(xiàn)了收集、篩選和分類測試結(jié)果的功能，例如：“Warnings Trend”匯總了測試中的全部問題，“Summary”按照3個重要等級對問題進行分類，“Details”可以顯示被測代碼的具體錯誤信息，紅色代表嚴(yán)重錯誤、黃色代表輕微錯誤。

4 總結(jié)與展望

實現(xiàn)了基于Jenkins對嵌入式項目進行持續(xù)集成的嘗試，通過編寫、配置自動化測試腳本和插件完成測試，發(fā)現(xiàn)代碼問題16處。在修改程序后，無需提交測試人員執(zhí)行回歸測試，而是項目在1 h內(nèi)(根據(jù)需要)自動進行構(gòu)建和重新集成測試，且完成測試后能夠立刻通知相關(guān)人員。此方式不僅減輕了開發(fā)和測試人員重復(fù)提交測試的工作，并且有效降低代碼問題爆炸式出現(xiàn)的可能性，時刻監(jiān)視著版本庫中代碼的測試狀態(tài)。

方案仍有很多需要優(yōu)化和嘗試的方面。首先，當(dāng)遇到大型項目或者需要頻繁提交版本控制系統(tǒng)的項目，即擁有大量的構(gòu)建任務(wù)時，經(jīng)常輪詢SCM服務(wù)器可能導(dǎo)致網(wǎng)絡(luò)查詢飽和構(gòu)建任務(wù)排隊，從而降低了測試效率。如何優(yōu)化輪詢時間和觸發(fā)條件，需要進一步試驗。另外，Jenkins更強大的功能之一是它能夠跨大量的機器調(diào)度構(gòu)建作業(yè)，分布式構(gòu)建可以用來吸收額外的負載，應(yīng)對構(gòu)建作業(yè)中的高峰期。針對大型項目的配置方案，值得今后深入研究。