基於Jmeter+Maven+Jenkins持續整合介面測試框架
基於Jmeter+Maven+Jenkins持續整合介面測試框架
前言
前段時間公司正好準備開始進行介面測試及介面監控方面的工作,為了使得介面測試及介面功能監控,所以我根據以往對Jmeter的使用經驗,設計了一套最簡單的Jmeter持續整合介面測試框架。雖然網上這塊的資料也不少,但在做的過程中也遇到不少的坑,寫作本文主要的目的是為了記錄,但鑑於目前網上能找到的相關資料都寫得比較雜亂,所以本著開源共享的精神,也一併分享於此,希望更多人能夠受益,大家一起進步。
本文將由以下幾個部分組成:
- 框架組成簡介
- 框架選型特點
- 遇到主要的坑
- 後期可能的擴充套件
框架組成簡介
廢話不多說,首先上一張框架架構示意圖,簡單明瞭,然後再來分別解釋各個部分的組成和具體操作步驟。由於時間有限,來不及自己做圖,直接引用一下網上現成的圖片。:)
由上圖可知,該框架主要由三個部分組成:Jmeter、Jenkins和Git,但其實還有一個非常重要的角色:Maven,所以我們總共應該會用到四個工具。作為框架的設計者,我們除了要實現框架外,更應該知道每個部分的作用,接下來分別看看:
** Jmeter作為執行者的角色,每次負責執行具體的介面/效能測試指令碼,並得到結果,生成報表。
** Maven和Git是作為管理者角色,前者主要負責專案的依賴管理,而後者主要負責專案的程式碼管理。
** Jenkins作為排程者,主要根據我們設定的build觸發條件和事件呼叫jmeter進行測試
框架選型特點
市面上能達到我們目的的工具和框架很多,為什麼要這樣選型?這裡簡單地說明一下。我是開源愛好者,開源的好處自不必多說,所以一般只要有開源工具代替商業工具的,我都會選擇開源工具實現。對於本框架來說,這四個工具都是開源免費,並且經過長時間的使用已經可謂非常成熟,所以更是不二選擇。
首先,說說介面測試工具的選擇。介面測試可選擇的面也非常廣,常見的有soupUI、httpclient等,甚至可以自己用jave或python寫工具來實現。但選擇Jmeter而不是這些介面工具的原因是,通常介面測試與效能測試是相通的,如果我們在寫好介面測試指令碼後,在後面的效能測試過程中能完全複用現成的這些測試指令碼,那麼就大大提高了我們的指令碼複用率,減少了很多重複的工作量,也使得框架的擴充套件性大大增強。Jmeter則是非常好的一個選擇,它不但可以完成介面測試,做效能測試也是非常專業的,各種外掛應有盡有,實在不行還可以自己寫plugin,真是爽得不要不要的。
其次,對於專案管理工具而言,很多人其實是用Ant在結合jmeter使用。Ant和Maven同為軟體構建工具,但Maven的定位是軟體專案管理和理解工具,所以Maven除了具備Ant的功能外,還增加了以下主要的功能:
1)使用Project Object Model來對軟體專案管理;
2)內建了更多的隱式規則,使得構建檔案更加簡單;
3)內建依賴管理和Repository來實現依賴的管理和統一儲存,不管專案更換到了任何主機上,都不用關心依賴檔案,隨時可以更新和配置;
4)內建了軟體構建的生命週期;
另外,Ant本身build.xml檔案的規則也是比較繁雜的,而基於Project Object Model的pom.xml檔案則相對友好得多。
第三,對於基於git的程式碼管理,就不多了,自己建立一個github專案,隨時隨地都可以通過git終端拉取,非常方便。
第四,Jenkins對於持續整合的重要性就不言而喻了,並且方便測試程式碼與開發程式碼之間的整合和驗證。
遇到主要的坑及要點
接下來記錄下在框架實施過程中遇到的主要的坑以及一些比較重要的地方。
一、Jmeter
Jmeter部分在該框架中與正常普通使用無異,不再累述。
二、Maven
在搭建本框架時,在Maven部分遇到的主要問題總結如下:
關於eclipse中自帶的maven
如果大家使用的是Eclipse的話,最好不要使用eclipse自帶的Maven,原因有二:一是不好控制maven版本的更新;二是程式碼移植時也可能會造成maven版本不一致的問題。
關於自定義jar包的處理
如果是專案裡有自己寫的自定義jar包,在maven的pom檔案中進行引用的時候是有講究的。因為大家都知道,Jmeter專案中不管是引用第三方jar包或自定義的jar包時,都需要將該jar包放置於jmeter的lib/ext目錄中。如果該jar能夠在maven的中央倉庫中找到,那麼可以直接參照maven的jmeter外掛中的wiki裡面關於引用第三方jar包的說明進行配置即可。但如果是自己寫的jar包,由於並沒有在maven的中央倉庫中,所以為了使maven在build時能夠順利找到該jar包,必須先在本地倉庫中通過install命令安裝該jar包,命令格式如下:
mvn install:install-file -Dfile=[path-of-jar] -DgroupId=[path-in-local-repository] -DartifactId=[foldername] -Dversion=[versionname] -Dpackaging=jar
比如我在工程中的配置如下:
這樣安裝後,maven會在本地倉庫中自動生成com/demo/jmeter/demo/1.0.0/路徑,並且將mydemo-1.0.0.jar放在該路徑下面,供maven進行引用。
把jar包install到本地倉庫後,我們在pom.xml中應該如何進行配置才能使maven每次在build時自動引用該jar包並放到jmeter的lib/ext目錄中呢?答案如下:
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>com.lazerycode.jmeter</groupId>
<artifactId>jmeter-maven-plugin</artifactId>
<version>2.0.3</version>
<executions>
<execution>
<id>jmeter-tests</id>
<goals>
<goal>jmeter</goal>
</goals>
</execution>
</executions>
<configuration>
<jmeterExtensions>
<artifact>com.demo.jmeter:demo:1.0.0</artifact>
</jmeterExtensions>
</configuration>
</plugin>
</plugins>
</build>
[...]
</project>
如此配置完畢後,那麼每次maven在build時,便可以順利地在本地倉庫中找到指定的jar包,並放入jmeter對應的路徑下。(PS:如果有多個類似的jar包,則只需分別先install到本地倉庫,並增加多個“<artifact></artifact>”標籤即可)
對於Jmeter三大配置檔案的處理
對於Jmeter三大配置檔案的處理。如果在專案中使用了自定義的properties檔案,或修改了jmeter自帶的jmeter.properties/system.properties,那麼需要將這些properties檔案跟jmeter的jmx指令碼放在同一個資料夾內,即test/jmeter/xxx.properties(jmeter資料夾一般是自己建的),否則jmeter無法獲取修改後的properties檔案。
三、 Github
對於Github的專案管理這塊,主要有以下幾個基本操作需要注意。
建立自己的github專案並上傳專案檔案
這個比較簡單,直接在github上先註冊個賬號,然後建立一個專案即可。關鍵是如何上傳自己的專案檔案到github上的專案檔案中,簡單說下步驟。
a. 首先建立deploy keys。因為一般是通過ssh協議來上傳,所以有必要先在本機生成ssh key,才能允許授權github專案的讀寫訪問。具體步驟就不再累述,請參考文章:https://help.github.com/articles/generating-an-ssh-key/
b. 然後在github的專案內找到ssh形式的訪問地址,拷貝到記憶體中,如下圖所示。
再在本地任意目錄建立一個資料夾,並在git命令列內路由到該資料夾,輸入以下命令:
git clone the-path-of-your-github-project
這將會把github上的專案路徑拷貝到本地目錄中,並生成git控制檔案,接下來就可以把本地的檔案上傳到github上了。
首先將檔案加入本地倉庫:git add .
接下來commit到遠端倉庫:git commit -m “log-message”
再提交到master分支:git push -u origin master (過程中需要輸入github使用者名稱和密碼)
注意,此處由於上傳的是maven專案工程,所以要注意,一般只需要上傳src資料夾和pom.xml檔案,不要將target資料夾上傳到github中。
四、Jenkins
在Jenkins中我們只需要建立一個maven工程,其中部分配置如下
** 原始碼管理選git,直接指定github上的專案git地址即可;
** 構建觸發器如果是線上介面監控一般選擇定時構建,以一定的時間週期進行觸發。如果是測試環境的介面監控,則選擇“Build after other projects are built”或“Build when a change is pushed to GitHub”,表示依賴於開發上傳程式碼的時間;
** build裡面選擇指定pom.xml(注意將github裡面的pom.xml放置在根目錄,否則jenkins可能無法識別路徑),“Goals and options”這裡填寫“clean verify”;
** post steps,由於介面測試對結果的處理是包含在測試報告裡面的,所以一般無法使用jenkins自帶的對build結果的判斷,需要自己寫指令碼來解析測試結果,並生成相關的報告,併傳送郵件。這些事情可以自己寫個自定義的jar來處理,然後指定jenkins去呼叫即可。
設定完畢後,儲存,完畢。
後期可能的擴充套件
在Jmeter指令碼專案中根據公司業務補充更多的介面測試指令碼
指令碼複用,利用Jmeter的效能監控外掛,監控介面效能
增加更多配置內容,使得本框架更加靈活可定製,增加可配置化模組(Jmeter Properties、郵件通知、測試報告展現等)
加入效能場景分析模型,直接擴充套件介面測試指令碼為效能測試指令碼,實現介面和業務壓力測試
相關文章
- jenkins+ant+jmeter介面自動化的持續整合測試框架JenkinsJMeter框架
- Apworks框架實戰(三):單元測試與持續整合框架
- 搭建持續整合介面測試平臺(Jenkins+Ant+Jmeter)JenkinsJMeter
- Linux 核心的持續整合測試Linux
- Jenkins+Ant+Jmeter搭建持續整合的介面測試平臺JenkinsJMeter
- 使用 Xcode Server 持續整合 & 打包測試XCodeServer
- .net持續整合測試篇之Nunit引數化測試
- .netcore持續整合測試篇之測試方法改造NetCore
- .net持續整合測試篇之Nunit that斷言
- 軟體測試持續整合的方法實踐
- SoapUI實踐:自動化測試、壓力測試、持續整合UI
- 基於jmeter,jenkins,ANT介面,效能測試框架JMeterJenkins框架
- 聊聊持續測試
- 基於Jenkins快速搭建持續整合環境Jenkins
- 介面效能測試 —— Jmeter併發與持續性壓測JMeter
- Django測試與持續整合:從入門到精通Django
- 持續整合之路——資料訪問層的單元測試(續)
- 前端專案基於GitLab-CI的持續整合/持續部署(CI/CD)前端Gitlab
- 基於Jenkins+Git+Docker的持續整合(上)JenkinsGitDocker
- 基於Jenkins+Git+Docker的持續整合(下)JenkinsGitDocker
- 基於 Docker 打造前端持續整合開發環境Docker前端開發環境
- 持續整合、持續部署、持續交付、持續釋出
- .net持續整合測試篇之Nunit常見斷言
- 思考如何將自動化測試加入持續整合中
- Android App持續整合效能測試:啟動流量(1)AndroidAPP
- 持續整合持續部署持續交付_持續整合與持續部署之間的真正區別
- 加速Java應用開發速度3:單元/整合測試+持續整合Java
- 持續整合、持續交付、持續部署簡介
- 基於 BDD 理論的 Nebula 整合測試框架重構(下篇)框架
- 基於 BDD 理論的 Nebula 整合測試框架重構(上篇)框架
- 整合持續整合工具
- 基於jenkins搭建一個持續整合伺服器Jenkins伺服器
- [原創]淺談持續整合在測試中的應用
- jenkins介面、UI自動化持續整合JenkinsUI
- 聊聊持續測試與安全
- .netcore持續整合測試篇之搭建記憶體伺服器進行整合測試一NetCore記憶體伺服器
- iOS 持續整合iOS
- 關於DVCS、持續整合和特性分支