測試jenkins介紹初稿

1、 文檔來源為:從網(wǎng)絡(luò)收集整理.word 版本可編輯.歡迎下載支持.【關(guān)鍵字】測試持續(xù)集成簡介（持續(xù)集成是什么）Continuous integration.持續(xù)集成源于極限編程(XP)，是一種軟件實(shí)踐，軟件開發(fā)過程中集成步驟是一個漫長并且無法預(yù)測的過程。集成過程中可能會爆發(fā)大量的問題，因此集成過程需要盡可能小而多，實(shí)際上持續(xù)集成講的是不斷的去做軟件的集成工作。持續(xù)集成作用（使用持續(xù)集成和不適用持續(xù)集成的區(qū)別）l 場景一、某項(xiàng)目最后做模塊集成的時候，發(fā)現(xiàn)很多接口都不通，甚至有的模塊連安裝包都沒有。l 場景二、沒有可用的軟件包，需要人手動去編譯打包最新的代碼。l 場景三、搭建測試環(huán)境的時候需要手動

2、去解壓包然后一系列拷貝修改配置等等。l 場景四、團(tuán)隊(duì)成員或者 teamleader 想了解當(dāng)前項(xiàng)目的狀態(tài)，該如何去展示這些信息。持續(xù)集成就是用來解決以上問題，它的價值主要在于減少重復(fù)的步驟，降低項(xiàng)目的風(fēng)險(xiǎn)，任何時間任何地點(diǎn)生成可用的軟件，增強(qiáng)項(xiàng)目的可見性等。持續(xù)集成實(shí)踐（持續(xù)集成怎么做）持續(xù)集成，最簡單的形式是包括一個監(jiān)控版本控制系統(tǒng)（SVN 等等）變化的工具。當(dāng)變化被發(fā)覺時，這個工具可以自動的編譯并測試你的應(yīng)用。下面是持續(xù)集成中一些良好的實(shí)踐l 維護(hù)一個單一的代碼庫l 使建立自動化l 使建立自測試l 每人每天都向主線提交代碼l 每次提交都應(yīng)在集成機(jī)上進(jìn)行建立l 快速建立l 使任何人都能輕易獲

3、得可執(zhí)行文件l 人人都能看到正在發(fā)生什么l 自動化部署(上面是持續(xù)集成介紹，下面引出 jenkins)jenkins 簡介持續(xù)集成是一種實(shí)踐，而 jenkins 可以幫助團(tuán)隊(duì)去盡量好的去完成這種實(shí)踐l Jenkins 是基于 java 語言的開源持續(xù)集成工具，提供了一套非常易用的用戶界面l jenkins 類似于 eclipse，基于插件化的架構(gòu)，方便功能的擴(kuò)展，目前有幾百個現(xiàn)成插件可以使用，這些插件涵蓋從版本控制、建立工具、代碼質(zhì)量、建立通知、集成外部系統(tǒng)、UI 定制、游戲等等各個方面1文檔來源為:從網(wǎng)絡(luò)收集整理.word 版本可編輯. 文檔來源為:從網(wǎng)絡(luò)收集整理.word 版本可編輯.歡迎

4、下載支持.安裝 jenkinsjenkins 默認(rèn)提供了三種安裝方式1.最簡單的方式是通過 java web 的啟動方式，訪問/jenkins-the-definitive-guide 默認(rèn)第一次下載 jenkins.jnlp 即可啟動2.下載可執(zhí)行的 war 包啟動 jenkins3.部署到 tomcat 中（推薦）一個最簡單的 jenkins 應(yīng)用在介紹該應(yīng)用前，先提及兩個非常重要的概念l job一個完整的建立可能需要很多步驟，每個步驟都稱作是一個job。一個 job 是一個專一做某事的步驟，比如編譯，測試，打包，部署等等。jenkins 中默認(rèn)提供了四種不同類型的 jobl Jenkin

5、s 家目錄jenkins 為每個項(xiàng)目都會建立一個 workspace 目錄，源碼會下載到這個目錄下，然后編譯等動作都在該目錄中進(jìn)行。下面是一個 jenkins 的家目錄結(jié)構(gòu)jobs 下面按照項(xiàng)目的維度進(jìn)行劃分，每個項(xiàng)目下有builds 和 workspace 目錄，其中源碼會保存在各個項(xiàng)目的 workspace 中，builds 目錄包含建立的歷史記錄。假設(shè)項(xiàng)目基于 svn 控制系統(tǒng)，并且有簡單的編譯打包腳本。該應(yīng)用要實(shí)現(xiàn)的功能是檢測到代碼提交后觸發(fā)建立動作，調(diào)用已有的編譯打包腳本生成可用的軟件包。（上面的配置步驟就不列出來了，想講的話可以大概講講也可以截圖）這個最簡單的 jenkins 應(yīng)用

6、執(zhí)行的原理是應(yīng)用 svn 的插件，當(dāng)有代碼提交的時候被插件檢測到，jenkins 將源碼下載到本地的 workspace（包括編譯打包腳本），此時 jenkins 調(diào)用本地項(xiàng)目源碼中的編譯打包腳本（在配置 job 的時候指定）。這就是最簡單的一個流程，復(fù)雜的流水線建立都是基于此而完善的。觸發(fā)建立的條件除了上面提到的提交建立，能夠觸發(fā)建立的方式還有以下幾種l 隔某段時間建立一次，比如隔一小時自動建立一次。l 定時輪詢 SCM 的改變?nèi)ビ|發(fā)建立，比如隔一小時去輪詢一次 svn 是否有更改，有的話觸發(fā)建立，否則不做處理。l 手動建立自動化測試Jenkins 不僅僅能做源碼編譯打包的動作，Jenkin

7、s 中有很多插件可以方便的實(shí)現(xiàn)自動化測試。l 單元測試2文檔來源為:從網(wǎng)絡(luò)收集整理.word 版本可編輯. 文檔來源為:從網(wǎng)絡(luò)收集整理.word 版本可編輯.歡迎下載支持.l 功能測試l 集成測試l 性能測試l 驗(yàn)收測試進(jìn)行自動化測試僅僅是一部分功能，關(guān)于測試結(jié)果的收集和展示jenkins 也能夠做到，并且是以圖形化的方式展示出來。只需要告訴jenkins 測試結(jié)果在哪里，它會自動去取，并生成可視化的圖形。另外一種關(guān)于自動化測試的是代碼的覆蓋率，jenkins 同樣支持對代碼覆蓋率的統(tǒng)計(jì)。上圖中的自動化測試給出詳細(xì)的失敗列表通知持續(xù)集成講究的是快速的發(fā)現(xiàn)問題，盡早的發(fā)現(xiàn)問題，因此當(dāng)出現(xiàn)問題（編

8、譯失敗，用例通過率不足等）時需要有通知的手段讓相關(guān)的人員了解情況。Jenkins 提供了豐富的通知插件，最常用的是 Email 通知，當(dāng)然除此之外還有l(wèi) 即時通訊軟件l IRCl 桌面通知代碼質(zhì)量代碼質(zhì)量的度量同樣也非常重要，比如圈復(fù)雜度，checkstyle，findbugs 等等的靜態(tài)檢查。這些檢查都可以使用jenkins 的插件完成，jenkins 負(fù)責(zé)收集質(zhì)量結(jié)果，做圖形展示，很方便開發(fā)人員根據(jù)質(zhì)量結(jié)果進(jìn)行代碼重構(gòu)。自動化部署自動化部署目的就是減少不必要的時間。最簡單的是自己實(shí)現(xiàn)部署的腳本然后供jenkins 去調(diào)用，但是對于復(fù)雜的部署需求，自己實(shí)現(xiàn)腳本恐怕有些力不從心，我們可以借助插

9、件完成Puppet 或者 Chef。對于數(shù)據(jù)庫的自動化部署同樣有插件供我們選擇比如Liquibase。Jenkins 的高級功能l 高級構(gòu)建參數(shù)構(gòu)建類似普通的構(gòu)建任務(wù)，但是功能更強(qiáng)大?？梢詾楸敬螛?gòu)建指定一些參數(shù)，這些參數(shù)可能會在某幾個構(gòu)建中被使用到，參數(shù)的傳遞由jenkins 去維護(hù)。由此一個普通的構(gòu)建通過獲取不同的參數(shù)能夠表現(xiàn)的更多樣化。3文檔來源為:從網(wǎng)絡(luò)收集整理.word 版本可編輯. 文檔來源為:從網(wǎng)絡(luò)收集整理.word 版本可編輯.歡迎下載支持.更強(qiáng)大的是多配置構(gòu)建，類似參數(shù)構(gòu)建，提供一個配置列表，比如針對不同的數(shù)據(jù)庫或者瀏覽器的列表，jenkins 會自動的執(zhí)行不同場景下的測試，這

10、些測試可以并行的執(zhí)行，從而大大的減少了測試的時間。l 分布式構(gòu)建jenkins 也支持 master/slave 的分布式方式，master 主要用來分發(fā)構(gòu)建任務(wù)給 slave，實(shí)際的執(zhí)行在 slave 中 。Master 監(jiān)控 slave 的狀態(tài)，并收集展示構(gòu)建的結(jié)果。但是在實(shí)際情況中master 同樣可以執(zhí)行構(gòu)建任務(wù)。可以通過 master 指定某個項(xiàng)目總是運(yùn)行在特定的 slave 或者某類 slave 或者簡單的任何一臺 slave 中。分布式構(gòu)建中，jenkins 提供了對代理節(jié)點(diǎn)的監(jiān)控，如果發(fā)現(xiàn)某臺 slave 不可用，則會主動將其下線，避免后續(xù)的任務(wù)被分配到該節(jié)點(diǎn)上。所謂的流水線很

11、容易理解，就是整個構(gòu)建流程按照一定的流程去構(gòu)建。當(dāng)你的構(gòu)建步驟變得復(fù)雜的時候，并且并行和串行都有的時候，通常就不太容易管理了。流水線能夠方便的定義某個構(gòu)建后要觸發(fā)的下一個構(gòu)建，或者同時觸發(fā)的后面幾個構(gòu)建。當(dāng)然也能夠等待某幾個構(gòu)建執(zhí)行完畢后去執(zhí)行某一個構(gòu)建。其中 TheDependency Graph View 插件能夠幫助你分析構(gòu)建任務(wù)之間的關(guān)系。并且如果涉及到構(gòu)建的資源競爭，也提供了鎖的功能。l jenkins 安全管理jenkins 中有多個維度來管理安全，一個是安全域，一個是授權(quán)。安全域能夠識別出合法的用戶，授權(quán)則是針對合法的用戶給出不同的權(quán)限。最簡單的管理用戶賬號的方式是使用 jenk

12、ins 內(nèi)建的數(shù)據(jù)庫，但是也能夠和其他的用戶管理系統(tǒng)做集成。針對授權(quán)有好多種不同的策略，比如基于項(xiàng)目，基于角色。另外一種重要的功能是審計(jì)，也就是記錄用戶的操作日志。有兩種插件能夠?qū)崿F(xiàn)該功能。Audit Trail 插件能夠記錄用戶的操作動作。JobConfigHistory 插件能夠存儲前一個版本系統(tǒng)的變化和 job 的配置文件。持續(xù)集成一般會經(jīng)歷一下幾個階段l 階段一沒有構(gòu)建服務(wù)器最初的階段，團(tuán)隊(duì)沒有任何一種構(gòu)建服務(wù)器。軟件由開發(fā)人員手動的去構(gòu)建，盡管使用的是Ant 腳本或者類似的東西。源碼可能存儲在一個中央源碼倉庫中，但是開發(fā)者未必要定期的提交更改后的代碼。有時候在一個版本要發(fā)布的時候，開

13、發(fā)人員手動的去集成這些變化，這是一個非常痛苦的過程。l 階段二夜間的構(gòu)建4文檔來源為:從網(wǎng)絡(luò)收集整理.word 版本可編輯. 文檔來源為:從網(wǎng)絡(luò)收集整理.word 版本可編輯.歡迎下載支持.在這個階段，團(tuán)隊(duì)有一臺構(gòu)建服務(wù)器，并且定時的去執(zhí)行構(gòu)建任務(wù)（通常在夜里）。因?yàn)椴]有一個可靠的可重復(fù)的單元測試，所以這里的構(gòu)建通常只是代碼編譯。如果有自動化測試，也并沒有強(qiáng)制集成到構(gòu)建階段，也許根本不會正確的運(yùn)行。但是現(xiàn)在開發(fā)人員已經(jīng)能夠有規(guī)律的定期提交代碼了，至少在每天下班前。如果一個開發(fā)人員提交的代碼和另外一個人有沖突，構(gòu)建服務(wù)器會在第二天的早上將告警通過郵件發(fā)出來。然而，整個團(tuán)隊(duì)只是將構(gòu)建服務(wù)器作為一

14、個參考如果構(gòu)建掛了，他們并沒有意識去立即把它修復(fù)好，因此構(gòu)建可能會在一段時間內(nèi)不可用。團(tuán)隊(duì)現(xiàn)在已經(jīng)更加嚴(yán)格的使用持續(xù)集成和自動化測試了。構(gòu)建服務(wù)器被配置為當(dāng)有代碼提交的時候便會執(zhí)行構(gòu)建，團(tuán)隊(duì)的成員也可以很方便的看到是哪些代碼中的變化引起了構(gòu)建，這些變化引發(fā)了什么問題。除此之外，構(gòu)建腳本編譯應(yīng)用并且自動的執(zhí)行一些單元和集成測試。對于郵件，構(gòu)建服務(wù)器能夠更加積極主動的去呈現(xiàn)構(gòu)建中出現(xiàn)的問題。失敗的構(gòu)建也能夠被快速的修復(fù)。自動化的代碼質(zhì)量和覆蓋率度量也能夠執(zhí)行了，并且可以幫助評估代碼的質(zhì)量和測試的相關(guān)性和有效性。代碼質(zhì)量的構(gòu)建也能夠?yàn)閼?yīng)用生成API 文檔。所有的這些幫助團(tuán)隊(duì)去維護(hù)高質(zhì)量的代碼。團(tuán)隊(duì)中

15、可以設(shè)置一個醒目的屏幕去時刻展現(xiàn)項(xiàng)目的狀態(tài)。l 階段五更嚴(yán)格的測試持續(xù)集成的好處是非常接近立體的測試?，F(xiàn)在，測試驅(qū)動開發(fā)（TDD）被廣泛的應(yīng)用，對于自動構(gòu)建的結(jié)果更加的有信心。對于應(yīng)用程序不再是簡單的編譯和測試，而是會繼續(xù)更復(fù)雜的端到端測試和性能測試。l 階段六自動化驗(yàn)收測試和自動化部署驗(yàn)收測試驅(qū)動開發(fā)（Acceptance-Test Driven Development）在這個階段被應(yīng)用，引導(dǎo)開發(fā)的工作并且提針對項(xiàng)目的狀態(tài)提供一個高層次的報(bào)告。這些自動化測試使用行為驅(qū)動測試（Behavior-Driven Development）和驗(yàn)收測試驅(qū)動開發(fā)工具，并且從商業(yè)的角度生成開發(fā)人員不理解的報(bào)告。因?yàn)檫@些高層次的測試在項(xiàng)目的早期開展，因此能夠清晰的指出，哪些特性已經(jīng)完成了，哪些需要后面去完成。每當(dāng)代碼有改變或者夜里，應(yīng)用程序被自動的部署到 QA 的測試環(huán)境來完成測試。當(dāng)測試人員完成了充分的測試后，應(yīng)用程序可以被一鍵式的部署到生產(chǎn)環(huán)境。當(dāng)然也能夠通過構(gòu)建工具去備份當(dāng)前的發(fā)布版本，或者當(dāng)有問題出現(xiàn)的時候，回歸當(dāng)前的版本。l 階段七持續(xù)部署處于對自動化的單元、集成、驗(yàn)收測試的信