基于測試需求的持續(xù)集成環(huán)境研究與實(shí)踐

李興凱+曾東旭+陳敏

摘要：基于軟件開發(fā)中的測試需求，分析和研究持續(xù)集成環(huán)境問題，提出最小持續(xù)集成環(huán)境概念，并給出典型最小構(gòu)成。對軟件開發(fā)各階段的不同測試進(jìn)行可持續(xù)集成需求分析，指出多設(shè)備環(huán)境配置是其中最不穩(wěn)定、最易出錯和最需要持續(xù)集成的。對4G LTE無線網(wǎng)絡(luò)的多設(shè)備環(huán)境配置需求及對持續(xù)集成工具的Web訪問局限性進(jìn)行了分析，并在Jenkins平臺上實(shí)現(xiàn)了Web訪問的二次封裝。

關(guān)鍵詞：持續(xù)集成；Jenkins；自動化測試；Web訪問

DOIDOI：10.11907/rjdk.171128

中圖分類號：TP306

文獻(xiàn)標(biāo)識碼：A 文章編號：1672-7800（2017）006-0011-04

0 引言

持續(xù)集成（Continuous Integration，CI）思想源于軟件開發(fā)中的極限編程（eXtreme Programming，XP），是其12個最佳實(shí)踐中的1個[1]。持續(xù)集成是為了保障產(chǎn)品質(zhì)量，實(shí)現(xiàn)開發(fā)測試的快速迭代，盡早發(fā)現(xiàn)并解決問題。越來越多的人開始接受持續(xù)集成理念，自覺或不自覺地在項(xiàng)目中借鑒持續(xù)集成思想，使用持續(xù)集成工具，甚至開發(fā)自己的持續(xù)集成環(huán)境和工具。

1 最小持續(xù)集成環(huán)境

隨著軟件規(guī)模的不斷增大，測試用例數(shù)量隨之不斷增長，手工配置系統(tǒng)應(yīng)用環(huán)境，手工進(jìn)行軟件測試變得越來越低效。用自動化腳本維護(hù)測試用例、執(zhí)行測試、返回測試結(jié)果的自動化測試成為趨勢。最小持續(xù)集成環(huán)境只需要一個任務(wù)定時啟動器和一個執(zhí)行自動化測試的腳本，是實(shí)現(xiàn)持續(xù)集成的最簡單方式。如圖1所示，自動化測試腳本用于實(shí)現(xiàn)項(xiàng)目的具體測試需求，在Linux環(huán)境下可以用Crontab命令作為任務(wù)定時啟動器，在Windows環(huán)境下可以用計劃任務(wù)Bat命令作為任務(wù)定時啟動器。這樣，用一個自動化腳本和一個周期性配置命令就能搭建出最簡單的持續(xù)集成環(huán)境，但這種最小持續(xù)集成環(huán)境所實(shí)現(xiàn)的功能也相對簡單。 Crontab和Bat都是特定格式的命令文本，定時任務(wù)的查看和維護(hù)需要相應(yīng)的背景知識，對于普通測試人員而言不夠方便和直觀。

2 軟件開發(fā)中的測試需求和可持續(xù)集成需求

2.1 測試需求分析

版本同步——軟件項(xiàng)目一般是多人同時開發(fā)，不同模塊和功能完成的時間前后不一，在執(zhí)行編譯命令前需要進(jìn)行代碼同步。

版本構(gòu)建——用于將已完成的代碼進(jìn)行編譯，如C++和Java等編譯性語言可分別使用GCC和Javac等編譯命令產(chǎn)生可執(zhí)行的二進(jìn)制文件，而解釋類語言一般不需要編譯。對于產(chǎn)品版本分支較多的情況，可能有多個選項(xiàng)控制產(chǎn)生多個不同目標(biāo)版本。

單元測試——主要用于函數(shù)級和類級的測試，可用Gtest和Junit等測試框架編寫用例。而代碼覆蓋率檢查和代碼靜態(tài)檢查也可以劃歸為單元測試范疇，可使用Gcov和Jcoco等工具檢查代碼覆蓋率，可使用Cpplint和Jtest等工具進(jìn)行代碼靜態(tài)檢查。

集成測試——在單元測試的基礎(chǔ)上，對組裝后的模塊或子系統(tǒng)進(jìn)行測試，一般用代碼和腳本模擬外部行為，對集成模塊進(jìn)行測試。

系統(tǒng)測試——將已經(jīng)確認(rèn)的軟件、硬件、外設(shè)、網(wǎng)絡(luò)等元素結(jié)合在一起，對整個系統(tǒng)進(jìn)行確認(rèn)性測試，一般用真實(shí)設(shè)備對系統(tǒng)進(jìn)行測試。

負(fù)載測試——用于測試系統(tǒng)在不同負(fù)載情況下的性能表現(xiàn)和持續(xù)正常運(yùn)行能力，一般采用高性能服務(wù)器作為測試的觸發(fā)源。

驗(yàn)收測試——用于測試產(chǎn)品的功能和性能是否與需求說明書一致，如α測試是公司內(nèi)部人員模擬真實(shí)用戶的操作行為和習(xí)慣對產(chǎn)品進(jìn)行測試，而β測試是真實(shí)用戶直接對產(chǎn)品進(jìn)行測試。

如圖2所示，版本同步、版本構(gòu)建和單元測試一般可以在單機(jī)環(huán)境中完成，而集成測試和系統(tǒng)測試則可能涉及多個模擬或真實(shí)的外部設(shè)備，負(fù)載測試根據(jù)具體實(shí)現(xiàn)不同，可以只在單機(jī)完成，也可能涉及多個外部設(shè)備。

版本同步是開發(fā)人員將本地代碼與遠(yuǎn)端服務(wù)器代碼進(jìn)行同步，更新到最新版本或某個指定版本，一般只在開發(fā)人員的工作主機(jī)中完成。版本構(gòu)建和單元測試雖然可以只在單機(jī)中完成，但為了提高構(gòu)建和測試效率，也可以將單機(jī)串行任務(wù)劃分為多個任務(wù)，分發(fā)到多個服務(wù)器上并行執(zhí)行，在多個服務(wù)器執(zhí)行完畢后，將執(zhí)行結(jié)果返回給主控服務(wù)器，由主控服務(wù)器判斷整個任務(wù)是否成功。將單機(jī)串行任務(wù)變成多服務(wù)器的并行任務(wù)，可以大大提高構(gòu)建和測試的執(zhí)行效率，但也使單機(jī)測試變成了涉及多個外部設(shè)備的協(xié)同測試，增加了持續(xù)集成實(shí)現(xiàn)的復(fù)雜度。

不同的軟件測試需求，涉及的實(shí)際網(wǎng)絡(luò)環(huán)境也各不相同，對于可能涉及多個外部設(shè)備的集成測試、系統(tǒng)測試、負(fù)載測試，要想實(shí)現(xiàn)持續(xù)集成，還必須考慮產(chǎn)品的版本部署和多個外部設(shè)備的環(huán)境配置等準(zhǔn)備工作。

2.2 可持續(xù)集成需求分析

隨著開發(fā)者對持續(xù)集成思想的不斷接納，持續(xù)集成實(shí)踐早已不再局限于極限編程領(lǐng)域。從軟件開發(fā)測試流程來看，版本同步、版本構(gòu)建、單元測試、集成測試、系統(tǒng)測試、負(fù)載測試等階段都可以通過腳本實(shí)現(xiàn)自動化，都有持續(xù)集成需求。而驗(yàn)收測試一般是產(chǎn)品研發(fā)人員與用戶共同參與的測試，測試過程有很多的人工操作和干預(yù)，較少對其納入持續(xù)集成范疇。如圖3所示，是從測試需求角度分析軟件開發(fā)過程中的可持續(xù)集成部分。

版本同步是指用CVS、SVN、ClearCase、Git等版本控制工具將代碼更新到最新版本或指定版本，這個過程可以用腳本封裝起來，對于指定版本情況，可以設(shè)計腳本接受參數(shù)輸入。版本構(gòu)建是指對剛剛同步過的版本進(jìn)行編譯和鏈接。根據(jù)測試階段和目的不同，構(gòu)建產(chǎn)生的可能不是最終的產(chǎn)品版本，如表1所示。

單元測試時，產(chǎn)生的是供單元測試用的版本，版本中除了包含產(chǎn)品代碼外，還包含對產(chǎn)品代碼進(jìn)行測試的樁函數(shù)（Stub）代碼和測試用例。集成測試時，由于可能涉及輔助測試的模擬設(shè)備，構(gòu)建產(chǎn)生的版本中可能包括與模擬設(shè)備相關(guān)的接口代碼。系統(tǒng)測試和驗(yàn)收測試時，一般是將產(chǎn)品設(shè)備放在真實(shí)的系統(tǒng)應(yīng)用場景中，由于不再涉及模擬設(shè)備接口代碼，因此應(yīng)該產(chǎn)生正式版本。

負(fù)載測試比較特殊，不是驗(yàn)證產(chǎn)品的功能，而是檢驗(yàn)產(chǎn)品的最大用戶數(shù)、最快響應(yīng)時間、最高處理能力等性能指標(biāo)。如果實(shí)現(xiàn)方式基于產(chǎn)品本身系統(tǒng)，版本中包含的內(nèi)容就與單元測試類似；如果實(shí)現(xiàn)方式基于模擬設(shè)備，版本中包含的內(nèi)容就與集成測試類似；如果實(shí)現(xiàn)方式是真實(shí)設(shè)備直接測試，版本中包含的內(nèi)容與系統(tǒng)測試和驗(yàn)收測試一樣，只需要編譯正式版本即可。

當(dāng)軟件項(xiàng)目規(guī)模較大時，如果編譯時間較長，可以用腳本實(shí)現(xiàn)多服務(wù)器并行編譯，此時還需考慮編譯的任務(wù)分發(fā)和結(jié)果回收等問題。

本文版本同步和版本構(gòu)建劃分為兩部分，因?yàn)榘姹就揭话阍陂_發(fā)者的單機(jī)環(huán)境中完成更新，而版本構(gòu)建可交由多服務(wù)器并行實(shí)現(xiàn)以提高效率，是為了突出兩者持續(xù)集成的環(huán)境差別，實(shí)際項(xiàng)目中可以一起劃分到源代碼的版本管理和維護(hù)范疇。

多設(shè)備環(huán)境準(zhǔn)備——對于有多個網(wǎng)絡(luò)設(shè)備的環(huán)境，一般是在版本構(gòu)建完成后，將生成的版本部署到被測產(chǎn)品設(shè)備中。

由于存在多個網(wǎng)絡(luò)設(shè)備，可能涉及多個網(wǎng)絡(luò)設(shè)備的連接和配置問題。如果測試時使用了模擬其它網(wǎng)元的模擬設(shè)備，就要考慮模擬設(shè)備的連接和配置問題；如果模擬設(shè)備與被測產(chǎn)品有版本匹配問題，還要考慮模擬設(shè)備的版本同步、版本構(gòu)建和版本部署等，相當(dāng)于同時管理兩套代碼的部署問題。對于有多個網(wǎng)絡(luò)設(shè)備參與的測試，設(shè)備之間的連接和配置必不可少，而且是測試環(huán)境搭建中最不穩(wěn)定、最易出錯和最應(yīng)該實(shí)現(xiàn)持續(xù)集成的部分。如果每次都是人工手動配置，出錯的概率會很高，一般可以用腳本實(shí)現(xiàn)自動化配置，避免由于人工操作失誤而導(dǎo)致配置失敗。

測試執(zhí)行——是持續(xù)集成的最核心部分，用測試用例驗(yàn)證產(chǎn)品是否滿足設(shè)計需求。在具體執(zhí)行測試前，要考慮測試用例列表準(zhǔn)備、執(zhí)行順序設(shè)置、失敗重試次數(shù)設(shè)置、日志目錄設(shè)置等自定義的選項(xiàng)。這種測試前的準(zhǔn)備一般用腳本實(shí)現(xiàn)，用戶只要輸入?yún)?shù)即可完成設(shè)置。對于把測試用例從單機(jī)串行執(zhí)行改為多服務(wù)器并行執(zhí)行的情況，測試腳本還要考慮如何進(jìn)行用例分發(fā)、結(jié)果回收、報告生成、日志歸集等功能。

日志歸集和結(jié)果報告——在測試執(zhí)行完成后，要對生成的日志文件進(jìn)行歸集以備后用，要對執(zhí)行的結(jié)果進(jìn)行分析以判斷成功或是失敗，還可以對比歷史結(jié)果生成執(zhí)行成功趨勢圖，并用郵件的方式將測試結(jié)果、執(zhí)行時間、日志路徑和鏈接地址等信息發(fā)送給相關(guān)開發(fā)測試人員。

版本部署——在所有的測試執(zhí)行完成后，如果沒有出現(xiàn)測試用例失敗，就可以將經(jīng)過測試的產(chǎn)品版本部署到實(shí)際應(yīng)用環(huán)境中。

在多設(shè)備環(huán)境配置時，也涉及版本部署問題，但其是將各網(wǎng)絡(luò)設(shè)備的版本部署到實(shí)際測試環(huán)境中，包括單元測試的版本、集成測試的模擬工具版本、系統(tǒng)測試的被測產(chǎn)品版本。而在被測產(chǎn)品版本成功通過所有測試后的版本部署，是將經(jīng)過驗(yàn)證的真實(shí)軟件產(chǎn)品版本部署到實(shí)際的應(yīng)用環(huán)境中。

3 持續(xù)集成工具選擇

明確了軟件的測試需求和可持續(xù)集成需求后，就要考慮采用什么樣的測試工具。在項(xiàng)目初始階段，為了實(shí)現(xiàn)快速的持續(xù)集成環(huán)境搭建，可以用本文開頭所述的“最小持續(xù)集成環(huán)境”方案。但隨著項(xiàng)目規(guī)模不斷增大，項(xiàng)目數(shù)量不斷增多，“最小持續(xù)集成環(huán)境”的任務(wù)啟動和進(jìn)度監(jiān)控等顯得不夠直觀。而且多個用戶通過配置crontab或bat文件管理持續(xù)集成任務(wù)也容易造成配置沖突，缺少全局性的任務(wù)規(guī)劃和管理。如果多個用戶在同一個時間段配置了某些很耗系統(tǒng)資源的任務(wù)，就會造成在某段時間內(nèi)系統(tǒng)資源占用率高、任務(wù)執(zhí)行耗時長、甚至日志文件讀寫沖突等問題。

針對以上可能存在的問題，可以考慮選擇CruiseControl[2-3]、Apache Continuum[4]、Jenkins/Hudson[5]（Jenkins源于Hudson早期版本分支）等第三方持續(xù)集成工具。以近年來廣泛應(yīng)用的開源項(xiàng)目Jenkins為例，其具有可定制化的項(xiàng)目Web配置界面，在項(xiàng)目建立時可以配置源碼管理、構(gòu)建觸發(fā)器、構(gòu)建環(huán)境、構(gòu)建、構(gòu)建后操作和通用設(shè)置6方面內(nèi)容，涵蓋了項(xiàng)目測試時進(jìn)行持續(xù)集成部署的各個方面。配置時可以直接在瀏覽器中輸入要執(zhí)行的腳本或路徑；在腳本啟動后，可以通過Web頁面實(shí)時查看執(zhí)行進(jìn)度；在腳本執(zhí)行完成后，圖形化標(biāo)記結(jié)果成功或失敗，并可將執(zhí)行結(jié)果發(fā)送到配置的郵件地址。

Jenkins官方網(wǎng)站中對其基本定位是一個可以支持多種自動化模式的自動機(jī)，支持任務(wù)串聯(lián)和并聯(lián)，并形象地這種串并聯(lián)后任務(wù)執(zhí)行模式稱為管道（Pipeline）[6]。如圖4所示，是將圖2的軟件測試需求與圖3的軟件開發(fā)過程中的可持續(xù)集成部分結(jié)合，將實(shí)現(xiàn)不同功能的眾多小任務(wù)像管道一樣連接起來構(gòu)成一個持續(xù)集成的大任務(wù)。Jenkins管道模式支持多任務(wù)并行，在完成必要的準(zhǔn)備任務(wù)后，完成特定功能的眾多小任務(wù)可實(shí)現(xiàn)并行啟動，合理規(guī)劃和設(shè)計小任務(wù)的串并聯(lián)，可以大大提高任務(wù)的執(zhí)行效率。

持續(xù)集成的目標(biāo)是實(shí)現(xiàn)軟件開發(fā)的持續(xù)迭代，持續(xù)集成工具為這一目標(biāo)提供了更加簡單和高效的實(shí)現(xiàn)方式，加上針對具體項(xiàng)目的自動化測試腳本，就使得原本必須手動執(zhí)行的構(gòu)建、測試、部署等工作變得不再困難。

4 基于Jenkins的無線4G LTE網(wǎng)絡(luò)持續(xù)集成實(shí)踐

4.1 多設(shè)備環(huán)境配置

不同于單機(jī)軟件，有多個網(wǎng)絡(luò)設(shè)備時涉及多個網(wǎng)元，配置更復(fù)雜，更容易出錯。如圖5所示的無線4G LTE網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，包括基站（eNodeB）、用戶設(shè)備（UE）和核心網(wǎng)（EPC）等多個網(wǎng)絡(luò)設(shè)備。其中，深色eNodeB是真實(shí)被測設(shè)備，淺色eNodeB是輔助測試設(shè)備，可能是真實(shí)的，也可能是模擬的。多設(shè)備之間的通信接口，根據(jù)4G LTE網(wǎng)絡(luò)標(biāo)準(zhǔn)協(xié)議規(guī)定，eNodeB和UE之間的是uu接口，eNodeB和EPC之間的是s1接口，eNodeB之間的是x2接口。對eNodeB的測試就是驗(yàn)證eNodeB與UE和EPC之間的信令流程是否滿足協(xié)議規(guī)定，數(shù)據(jù)傳輸是否穩(wěn)定可靠。而在測試之前，保證eNodeB與眾多網(wǎng)絡(luò)設(shè)備之間的連通性，配置設(shè)備運(yùn)行參數(shù)和檢查產(chǎn)品版本匹配等問題，都是多設(shè)備環(huán)境配置必須考慮的。

以工作中實(shí)際的4G LTE項(xiàng)目為例，使用上述可持續(xù)集成需求分析方法進(jìn)行多設(shè)備環(huán)境配置需求分析。如表2所示，系統(tǒng)測試和集成測試只有多設(shè)備環(huán)境，對系統(tǒng)測試而言，涉及兩個真實(shí)eNodeB的版本部署和參數(shù)配置、真實(shí)UE參數(shù)配置、真實(shí)EPC版本部署和參數(shù)配置；對集成測試而言，涉及一個真實(shí)eNodeB版本部署和參數(shù)配置、一個模擬eNodeB版本部署和參數(shù)配置、模擬UE參數(shù)配置、模擬EPC版本部署和參數(shù)配置。單元測試用樁函數(shù)（Stub）屏蔽底層接口消息，有單服務(wù)器環(huán)境和多服務(wù)器環(huán)境兩個版本，多服務(wù)器版本除了考慮單個服務(wù)器配置外，還要考慮多服務(wù)器并行測試時的任務(wù)分發(fā)和結(jié)果回收；負(fù)載測試也有單機(jī)環(huán)境和多設(shè)備環(huán)境兩個版本，負(fù)載測試的單機(jī)環(huán)境與單元測試的單機(jī)環(huán)境類似，也是由樁函數(shù)（Stub）屏蔽底層接口消息，只是測試用例更偏向大容量、高負(fù)載、多并發(fā)的應(yīng)用場景；負(fù)載測試的多設(shè)備環(huán)境網(wǎng)絡(luò)組成與集成測試類似，除了一個真實(shí)的被測eNodeB之外，其它設(shè)備都是模擬的。4.2 Web統(tǒng)一訪問頁面實(shí)踐

在Jenkins服務(wù)器搭建完畢后，任務(wù)的建立、訪問和配置都是通過Web頁面完成，這使得任務(wù)的參數(shù)配置、腳本嵌入、進(jìn)度監(jiān)控、日志查看等都變得十分方便。Jenkins的任務(wù)顯示由橫向選項(xiàng)和縱向列表兩部分組成，如圖6所示，是無線4G LTE項(xiàng)目Jenkins服務(wù)器搭建完畢后的Web頁面。

隨著項(xiàng)目數(shù)量不斷增多，Web訪問界面的選項(xiàng)卡變得越來越擁擠，如果項(xiàng)目的名字過長，一個頁面只能放置有限的幾個項(xiàng)目。雖然可以在一個項(xiàng)目中建立多個子項(xiàng)目，并在子項(xiàng)目中再建立多個孫項(xiàng)目，建立起層級關(guān)系。但這樣建立起來的Jenkins項(xiàng)目層級太多，劃分的子孫項(xiàng)目太多，某些子孫項(xiàng)目可能只是為了實(shí)現(xiàn)啟動、停止、用戶認(rèn)證或服務(wù)器連接等小任務(wù)而建立。更重要的是如果單個項(xiàng)目層級太多，日志文件就被分散在多個子孫項(xiàng)目中，當(dāng)某個項(xiàng)目執(zhí)行失敗時，為了查看這個失敗日志，就要一層層地進(jìn)入子孫項(xiàng)目，訪問不夠方便，項(xiàng)目關(guān)系不夠明確。

基于上述考慮，可以嘗試對Jenkins的Web訪問接口進(jìn)行二次封裝，不讓用戶直接訪問Jenkins的默認(rèn)Web頁面，而是通過如圖7所示的定制界面進(jìn)行任務(wù)的配置和提交。在點(diǎn)擊提交按鈕后，用戶會收到任務(wù)開始郵件，給出任務(wù)執(zhí)行的鏈接地址，可以隨時監(jiān)控任務(wù)進(jìn)度；在任務(wù)執(zhí)行完成后，用戶將收到結(jié)束通知郵件，給出日志文件的鏈接地址。如果任務(wù)失敗，還會給出失敗子任務(wù)或?qū)O任務(wù)的鏈接地址，不必一層層地進(jìn)入子孫項(xiàng)目查找；如果任務(wù)沒有失敗，用戶只需查看任務(wù)開始郵件和成功結(jié)束郵件，甚至無需知道Jenkins的存在。

這種對Jenkins Web頁面進(jìn)行二次封裝的任務(wù)提交方式，讓用戶只關(guān)注項(xiàng)目本身，不必關(guān)注具體用什么持續(xù)集成工具實(shí)現(xiàn)，只有在查看日志時才會訪問到Jenkins的Web頁面。相比于使用Jenkins本身的Web服務(wù)，二次封裝方案對用戶屏蔽了持續(xù)集成工具，增加了Web服務(wù)器的開發(fā)成本，但實(shí)現(xiàn)了讓開發(fā)人員聚焦于開發(fā)和測試，而不是工具的目的。這種二次封裝方案，可以用于大項(xiàng)目合并，比如某些項(xiàng)目已經(jīng)搭建了基于Jenkins的持續(xù)集成環(huán)境，而另外一些項(xiàng)目搭建了基于CruiseControl的持續(xù)集成環(huán)境。在項(xiàng)目合并時，可以統(tǒng)一Web訪問接口，屏蔽掉原來兩個項(xiàng)目的持續(xù)集成工具，只關(guān)注任務(wù)提交和執(zhí)行結(jié)果，而將持續(xù)集成工具作為任務(wù)管理和日志查詢的工具。

5 結(jié)語

持續(xù)集成的目的是為了保證產(chǎn)品質(zhì)量，在軟件開發(fā)過程中更好地支持快速迭代，高質(zhì)量地完成開發(fā)和測試任務(wù)。持續(xù)集成工具的選擇要根據(jù)項(xiàng)目的實(shí)際需求和網(wǎng)絡(luò)環(huán)境，可以用最小持續(xù)集成環(huán)境，也可以自主開發(fā)持續(xù)集成工具，還可以使用Jenkins/Hudson、Apache Continuum、CruiseControl等持續(xù)集成工具。第三方持續(xù)集成工具普遍通過Web頁面進(jìn)行任務(wù)訪問和配置，經(jīng)過二次封裝的統(tǒng)一Web訪問頁面，可以讓用戶更加聚焦于開發(fā)和測試，而不是工具本身。在項(xiàng)目中選擇什么樣的持續(xù)集成環(huán)境和工具取決于項(xiàng)目的具體需要，還要考慮團(tuán)隊成員的知識儲備和能力等問題。

參考文獻(xiàn)：

[1] KENT BECK.Extreme programming explained：embrace change[M].Addison-Wesley Professional：US ed Edition，1999.

[2] KEVIN A LEE.IBM Rational clearcase，ant，and cruisecontrol： the java developer's guide to accelerating and automating the build process[M].1 edition.IBM Press，2006.

[3] CruiseControl初探[EB/OL].http：//cruisecontrol.sourceforge.net/index.html.

[4] Continuous integration and build server[EB/OL].http：//continuum.apache.org/.

[5] Register for jenkins world 2017[EB/OL].https：//jenkins.io/.

[6] Jenkins （software）[EB/OL].https：//en.wikipedia.org/wiki/Jenkins_（software）.

（責(zé)任編輯：孫 娟）