雷建勝,蘇 曉,金明磊

(1.天津航天中為數(shù)據(jù)系統(tǒng)科技有限公司,天津 300301; 2.天津大學(xué)電氣自動化與信息工程學(xué)院,天津 300072)

0 引 言

隨著敏捷開發(fā)用戶需求不斷變化的需要，傳統(tǒng)的瀑布模型已經(jīng)逐漸被摒棄[1]，然而每當(dāng)用戶需求發(fā)生變化時，軟件就需要進行全部功能的測試，由此產(chǎn)生了大量重復(fù)的測試任務(wù)[2-4]。而傳統(tǒng)的人工測試不僅效率低下，且重復(fù)做同樣的測試本身也會產(chǎn)生很多錯誤，因而有必要引入自動化測試，每添加一些新功能或修改舊功能時，測試人員都可通過調(diào)整測試腳本對軟件進行自動化測試，保證修改后的產(chǎn)品可以在最短時間內(nèi)發(fā)現(xiàn)問題并解決，大大地提高了開發(fā)效率，保證了軟件質(zhì)量，降低了后期的維護成本[5-7]。本文以Web網(wǎng)頁端軟件發(fā)開為例，說明基于Jenkins的分布式可持續(xù)集成自動化測試平臺的設(shè)計與實現(xiàn)。

1 分布式可持續(xù)集成自動化測試的引入

Web軟件測試的基本目的是盡可能全面地模擬被測軟件需求的輸入和點擊操作，將其產(chǎn)生的結(jié)果與預(yù)期結(jié)果進行對比分析，尋找軟件的bug。而通過自動化測試來實現(xiàn)各種輸入和點擊操作，修改功能的重復(fù)測試或添加后的回歸測試可以大大地減少測試人力成本并且提高軟件質(zhì)量[8-10]。

然而傳統(tǒng)的Web軟件開發(fā)模式為開發(fā)人員和測試人員共用一套前后臺服務(wù)，這樣產(chǎn)生的問題是開發(fā)人員和測試人員無法同步開發(fā)，隨著開發(fā)人員代碼的不斷提交，軟件功能總是在變化，不利于自動化測試工作的開展，因此需要通過將代碼分支線管理，每條支線建立一個服務(wù)，通過分布式持續(xù)集成的方式來解決該問題[11-15]。

將開發(fā)人員和測試人員使用的前后臺服務(wù)分離開，定期自動進行代碼更新構(gòu)建，開發(fā)人員只關(guān)注代碼的提交，而測試人員只需要關(guān)注當(dāng)前軟件版本的功能，無需考慮此時開發(fā)人員研發(fā)的新功能。這樣可以大大地降低開發(fā)人員和測試人員之間的開發(fā)矛盾，提高軟件開發(fā)效率[16-18]。

2 總體設(shè)計

2.1 系統(tǒng)總體架構(gòu)

系統(tǒng)總體架構(gòu)如圖1所示,包括裝有Jenkins服務(wù)的主節(jié)點、用于開發(fā)人員使用的開發(fā)節(jié)點服務(wù)器、為測試人員提供的測試服務(wù)節(jié)點、為測試節(jié)點提供前后臺服務(wù)的測試節(jié)點服務(wù)器和測試通過后穩(wěn)定運行的生產(chǎn)節(jié)點服務(wù)器[19]。

圖1 系統(tǒng)架構(gòu)圖

1)開發(fā)節(jié)點服務(wù)器。為開發(fā)人員提供開發(fā)服務(wù)，是開發(fā)人員提交代碼的唯一節(jié)點。該節(jié)點總是保持最新的軟件版本。

2)提供測試服務(wù)節(jié)點。為測試人員的測試腳本提供前后臺服務(wù)支撐，在測試人員編寫完對應(yīng)版本的自動化測試腳本后，將對應(yīng)版本的代碼從開發(fā)節(jié)點服務(wù)器合并至該節(jié)點，開發(fā)節(jié)點服務(wù)器是其代碼的唯一來源。

3)測試節(jié)點服務(wù)器。保證測試人員開發(fā)完成的測試腳本按照設(shè)定的循環(huán)時間持續(xù)不斷地重復(fù)運行，進行持續(xù)的自動化測試，用以尋找一些潛在的bug。

4)生產(chǎn)節(jié)點服務(wù)器。該節(jié)點的服務(wù)是為用戶準(zhǔn)備的，在功能開發(fā)和測試通過后，將對應(yīng)通過測試的版本合并到該節(jié)點上，以供用戶使用，并提出修改優(yōu)化意見，更好地滿足敏捷開發(fā)模式的需求。該服務(wù)器上運行的是通過測試后的穩(wěn)定版本，為測試服務(wù)節(jié)點提供唯一的代碼來源。

2.2 自動化測試流程

分布式可持續(xù)集成自動化測試的流程如圖2所示：

1)開發(fā)人員進行軟件業(yè)務(wù)開發(fā)，完成后向開發(fā)節(jié)點提交源代碼，同時告知測試人員新的功能和舊的改動，之后開發(fā)人員繼續(xù)進行下一步的開發(fā)。

2)測試人員根據(jù)新開發(fā)的功能進行自動化測試腳本的開發(fā)和調(diào)整，完成后將測試腳本提交到測試節(jié)點上，并從開發(fā)節(jié)點將對應(yīng)版本的代碼合并，并將代碼提交到測試服務(wù)的節(jié)點上。

3)之后進行多次回歸測試，并將發(fā)現(xiàn)的問題報告給開發(fā)人員進行修改，若沒問題，則將代碼合并到生產(chǎn)節(jié)點上供用戶使用并提出修改意見，同時測試節(jié)點不斷地進行回歸測試并將所發(fā)現(xiàn)的問題報告給開發(fā)人員。

圖2 分布式可持續(xù)集成自動化測試的測試流程

從圖2可以看出，開發(fā)人員和測試人員互不干擾，并不會因為當(dāng)前開發(fā)的新功能而影響測試人員的工作，而自動化測試腳本同時也可以持續(xù)不斷地在測試節(jié)點服務(wù)器上使用測試服務(wù)節(jié)點提供的前后臺服務(wù)并不斷地進行回歸測試，大大地降低了一些隱性bug的存在。

除此之外，相比于傳統(tǒng)的手動測試來說，該模式下測試人員僅僅需要在代碼版本庫中控制系統(tǒng)代碼版本的迭代更新和自動化測試腳本的開發(fā)即可，而不需要在版本迭代時人工處理各個服務(wù)節(jié)點的代碼更新、打包和運行操作，對于前后臺分離開發(fā)微服務(wù)的開發(fā)模式來說，優(yōu)勢是巨大的。將微服務(wù)中每個子服務(wù)的代碼更新打包運行操作都交給Jenkins統(tǒng)一控制，減少了測試人力的消耗，將節(jié)省下來的測試人力投入到自動化測試腳本開發(fā)中，實現(xiàn)系統(tǒng)的自動化測試，提高系統(tǒng)測試次數(shù)和質(zhì)量，大大減少系統(tǒng)的bug，提高軟件質(zhì)量。

2.3 總體原則

1)開發(fā)人員每天至少提交一次代碼。

2)Jenkins每天對開發(fā)節(jié)點、提供測試服務(wù)的節(jié)點和生產(chǎn)節(jié)點進行一次集成構(gòu)建，同時也支持人工手動構(gòu)建。對測試節(jié)點進行輪詢構(gòu)建，運行測試腳本進行回歸測試。在自動測試的基礎(chǔ)上加上人工的一些輔助操作，可大大提高軟件的測試效率，盡可能地減少軟件bug。

3)開發(fā)節(jié)點向提供測試服務(wù)節(jié)點合并代碼要在測試人員開發(fā)完測試腳本提交到測試節(jié)點之后，否則會因為新功能加入或者舊功能的修改無法匹配上一版本的自動化測試腳本而導(dǎo)致回歸測試失敗。

3 分布式可持續(xù)集成平臺的搭建

3.1 創(chuàng)建節(jié)點

圖3 分布式節(jié)點列表

項目的節(jié)點列表如圖3所示,HSMB_DEV_BASE節(jié)點為開發(fā)節(jié)點，供開發(fā)人員使用，Katalon節(jié)點為測試節(jié)點，該節(jié)點輪詢構(gòu)建，不斷地進行回歸測試，HSMB_PER_UI_TEST節(jié)點為提供測試服務(wù)節(jié)點，供測試人員使用，為Katalon測試節(jié)點提供前后臺服務(wù)支撐，HSMB_UI_TEST節(jié)點為生產(chǎn)節(jié)點供用戶使用，用于提出優(yōu)化意見和修改反饋。

3.2 配置節(jié)點

圖4 節(jié)點配置

以開發(fā)節(jié)點為例，其他節(jié)點類似，如圖4所示,將“用法”設(shè)置為“只允許綁定到這臺機器的Job”，即只有在節(jié)點服務(wù)器中開啟與Jenkins服務(wù)器的連接，該節(jié)點才可工作，對于Windows系統(tǒng)節(jié)點來說將“啟動方式”設(shè)為“通過Java Web啟動代理”。

圖5 連接Jenkins服務(wù)器命令

如圖5所示,Jenkins提供了2種方式使遠端節(jié)點連接至Jenkins,分別為在瀏覽器中啟動，或者在命令行中啟動，本項目選取第二種方式，在圖片最下方提供了一段命令：java-jar agent.jar-jnlpUrlhttp://10.0.4.151:9010/computer/HSMB-DEV-BASE/slave-agent.jnlp -secret 6ef578b5994772c6319be700bea9f-638610e2b7d7b1ae31bcd410617fa5748a0 -workDir "C://jenkins_workspace"。該命令是Jenkins提供的一段遠程連接的命令，將該命令存儲到.bat批處理文件中，并與Jenkins提供的agent.jar文件一起存放到節(jié)點服務(wù)器的同一路徑下，先在節(jié)點服務(wù)器中運行批處理文件使節(jié)點連接到Jenkins服務(wù)器，然后Jenkins服務(wù)器便可對該節(jié)點進行代碼更新并構(gòu)建運行等操作。

3.3 創(chuàng)建任務(wù)并配置任務(wù)

創(chuàng)建4個新的構(gòu)建任務(wù),通過設(shè)置任務(wù)的Restrict where this project can be run屬性將4個任務(wù)分別對應(yīng)圖3中的4個遠端節(jié)點。Jenkins的構(gòu)建周期采用了cron語法，包括5個字段(MINUTE HOUR、DOM MONTH、DOWHSMB_DEV_BASE、HSMB_PER_UI_TEST、HSMB_UI_TEST)的構(gòu)建周期，采用H8***格式，即每天早上8點進行自動構(gòu)建。而自動化測試需要持續(xù)地進行回歸測試，因此Katalon節(jié)點設(shè)置為H8-17/2**1-5格式，即周一～周五從上午8點～下午5點每隔2 h進行一次自動化回歸測試。

3.4 更新代碼及構(gòu)建

由于Katalon不支持集成到SVN上，因此采用Git作為測試人員和開發(fā)人員的版本控制工具，開發(fā)人員和測試人員分別將代碼提交到代碼版本庫中，按照3.3節(jié)中設(shè)定的構(gòu)建頻率進行代碼更新構(gòu)建。

圖6 部分構(gòu)建命令

如圖6所示,上半部分為HSMB_DEV_BASE、HSMB_PER_UI_TEST和HSMB_UI_TEST節(jié)點采用的構(gòu)建方式，首先找到上一次構(gòu)建的進程并結(jié)束，之后進入該服務(wù)的文件目錄下。由于前后臺服務(wù)采用的是微服務(wù)的架構(gòu)，無法通過配置服務(wù)的Source Code Management屬性進行代碼更新，因此通過git pull命令進行代碼更新[20-22]。同時采用mvn clean install進行打包編譯形成最新的jar包后使用java -jar命令啟動該jar包，圖中完成了系統(tǒng)管理后臺服務(wù)的啟動，圖6的下半部分為Katalon節(jié)點的構(gòu)建命令，因為Katalon支持命令行運行腳本且只是一個服務(wù)，可以通過配置服務(wù)的Source Code Management屬性來進行代碼版本的更新，首先進入到項目的文件目錄下，直接通過命令行運行不同的測試腳本來實現(xiàn)自動化測試，由命令“Test Suites/demo_test/AirportManage”可以看出圖中運行的為機場管理模塊的自動化測試腳本。

4 實施驗證

本文的實施環(huán)境由1臺運行Jenkins主節(jié)點的服務(wù)器和4臺分別運行開發(fā)節(jié)點、測試節(jié)點、提供測試服務(wù)節(jié)點、生產(chǎn)節(jié)點的服務(wù)器組成。經(jīng)驗證，每天早上8點對開發(fā)節(jié)點、提供測試服務(wù)節(jié)點、生產(chǎn)節(jié)點自動構(gòu)建。對測試節(jié)點每隔1 h進行自動構(gòu)建，運行自動化測試腳本。構(gòu)建成功的部分截圖如圖7所示。

圖7 開發(fā)線構(gòu)建成功圖

圖8 測試線構(gòu)建成功圖

圖7和圖8分別是系統(tǒng)開發(fā)線構(gòu)建成功截圖和回歸測試線構(gòu)建成功截圖，從圖中可以看出開發(fā)線每天上午8點21分進行代碼的更新、打包，啟動操作的構(gòu)建。由于實際中并不會一直循環(huán)自動回歸測試，對于項目測試來說也沒必要，回歸測試線設(shè)置在工作日每天從上午8點～下午5點之間每隔2 h進行一次自動回歸測試即可。一天可回歸測試4次，且這個時間是可以修改的，在項目后期如果需要可以隨意調(diào)整測試次數(shù)。

以國家海洋局天空協(xié)同海上目標(biāo)監(jiān)測系統(tǒng)為例，該系統(tǒng)中的任務(wù)管理采用手動測試，之后在設(shè)備管理、數(shù)據(jù)管理和系統(tǒng)管理中引入了自動化測試技術(shù)，并將之前開發(fā)的任務(wù)管理也進行了自動化測試的開發(fā)。前后任務(wù)管理測試所需時間對比如表1所示。

表1 任務(wù)管理自動化測試及手動測試所需時間對比

由表1可知手動測試無需編寫測試腳本。在編寫測試用例和測試數(shù)據(jù)上，2種方法花費時間相同。在初次測試并分析結(jié)果時，自動化測試由于要調(diào)試測試腳本使其可正常運行，需要較長時間，而手動測試不需要編寫測試腳本，只需手動測試一遍并記錄分析測試結(jié)果，因此所需時間較少。但是在回歸測試中，自動化測試只需要花費25 min的測試時間加平均5 min的分析記錄結(jié)果總共30 min的時間，而手動回歸測試和初次測試一樣需要花費1天×1人的時間，可以看出在回歸測試方面自動化測試速度相比手動測試在理想狀態(tài)下快了48倍。

在當(dāng)前敏捷開發(fā)的模式中回歸測試是要經(jīng)常進行的，對于手動測試來說也是消耗時間最多的工作，對于軟件開發(fā)來說新添加的功能或者舊功能的改動總是會不經(jīng)意間影響其他功能，因此想要保證軟件質(zhì)量，經(jīng)常的回歸測試是必不可少的，然而在項目后期由于資源時間有限，手動回歸測試的次數(shù)是有限的，這時自動化測試的優(yōu)勢就很明顯了，自動化測試只需要一次開發(fā)便可多次使用，在提高了測試次數(shù)的同時還減少了測試人員的重復(fù)工作量，在提升測試效率的同時還提高了bug發(fā)現(xiàn)率，大大提升了軟件質(zhì)量。

5 結(jié)束語

分布式可持續(xù)集成的自動化測試旨在盡可能地減少人力，減少開發(fā)者重復(fù)部署，減少測試人員重復(fù)測試，讓更多的流程變得自動化，對于測試者來說更多的時間是投入到回歸測試中，而本文通過Jenkins平臺設(shè)計并實現(xiàn)了分布式可持續(xù)集成的自動化測試平臺，在回歸測試方面大大提高了測試效率，很好地滿足了敏捷開發(fā)模式的需求，為項目開發(fā)的流程優(yōu)化提供了新的思路。