jmeter沒法知足敏捷理念怎麼辦，使用二次開發集中管理！

apache jmeter是apache軟件基金會出品的一款用於接口測試，壓力測試的開源軟件，因爲其免費開源，插件j自由擴展，跨平臺，因此理論上能夠支持全部種類的接口測試。jmeter自身也已經提供了許多優秀的插件，極大地加強了jmeter的能力。

問題引入

jmeter提供了兩種運行模式，一種是GUI模式，一種是CLI模式，這兩種運行模式有各自的場景：

GUI-圖形用戶界面：

顧名思義，用戶能夠在任意支持java的操做系統上打開一個jmeter客戶端，由於GUI模式下提供了可視化的腳本編排工具，所以經常使用於腳本編排。

CLI：

命令行模式，也叫non-GUI，headless（無頭模式），能夠在不啓動jmeter圖形客戶端的狀況下發起腳本測試，CLI模式是更經常使用的jmeter運行模式，由於不須要啓動圖形客戶端，因此該模式下佔用的資源會更少，是在負載測試和壓力測試中最經常使用的運行模式。

不管使用jmeter執行何種類型的測試，都離不開腳本的編排，GUI模式下當然能夠編排腳本，可是這種方式在面對如今愈來愈盛行的敏捷開發及devops理念時稍微顯得愛莫能助，主要的問題在如下幾個方面：

碎片化嚴重：當新的需求完成或舊的需求發生變動時，須要從新編排測試腳本，腳本很難管理或碎片化很是嚴重。

歷史記錄難以回溯：每次使用jmeter進行性能測試都會生成新的日誌、報告，使用本地文件系統管理這些數據可行，可是想要回溯腳本的整個執行歷史基本上是不可能的。

溝通成本高：針對每個開發需求的測試及缺陷的管理被強制性隔離，測試人員與開發人員的溝通成本極高，這與敏捷及devops的理念是不符的。

質量管控：產品或項目在發版前的質量控制靠測試人員人工控制，當面對大型的項目中成百上千個測試用例時，靠人工控制產品或項目的質量，困難重重。

沒有針對不一樣管理人員的報告：測試人員關心用例的成功率、開發經理關心缺陷趨勢、開發者關心缺陷產生的緣由、項目經理關心測試覆蓋率……，這些都須要有一套平臺集中管理測試數據才能實現。

基於以上的問題，想要集中管理jmeter腳本相關的測試數據，首先要解決的一大問題就是：脫離jmeter GUI模式，在本身的測試平臺上實如今線編排測試腳本，這將會涉及到jmeter的二次開發。

從目前apache官方放出來的資料來看，只有所有的源代碼、客戶端使用手冊，就鏈接口文檔都是殘缺不全的，再加上jmeter自身做爲一個平臺，第三方能夠經過插件擴展的方式對jmeter進行加強，所以二次開發的難度很高，須要進行技術攻關。

上圖來源於jmeter的官方網站，能夠從其導航菜單看出，僅提供了用戶使用手冊、java DOC

問題探究

經過研究jmeter軟件架構和腳本的結構，發現其軟件核心在ApacheJmeter_core.jar， ApacheJmeter_components.jar這兩個jar包上，它們分別的功能以下：

1. ApacheJmeter_core.jar，定義Jmeter全部的核心接口、工具類、報表生成邏輯、通用的斷言、執行相關邏輯……

2. ApacheJmeter_components.jar，定義通用GUI組件、菜單控制、GUI界面的渲染、表單的生成邏輯……

而jmeter的腳本則是在統一的規範下生成的，以下圖：

圖中是測試計劃的插件標籤腳本，它包含了guiclass和testclass兩個核心的通用屬性，外加其它不一樣數據類型的字段，其它的插件也是一樣的格式，它們分別的含義以下：

1.標籤上屬性均爲通用屬性，這些屬性是由ApacheJmeter_core.jar中的AbstractJMeterGuiComponent類定義，其中：

• guiclass表示jmeter在GUI模式渲染該插件時使用哪一個類；

• testclass表示jmeter在執行腳本到該插件時使用哪一個類；

• testname是插件的自定義名稱；

• enabled表示是否啓用該插件，只有enabled爲true的插件都會被執行。

2. 標籤下的子標籤表示該插件的自定義屬性，由插件的開發廠商根據插件的功能本身肯定。

綜合以上的分析結果，能夠發現，想要在測試平臺上集成jmeter腳本編排，核心的即是研究每個插件的guiclass，肯定屬性的定義及值的約束規則。肯定完以上的技術要點就完成了二次開發技術攻關，剩下的只有對須要二次開發插件的表單字段的默認值肯定、約束規則確認。

技術攻關完成了，下面來到下一個主題，如何構造一個jmeter腳本？觀察下面的jmeter腳本代碼：

在前面的插件標籤腳本中有講到，全部的jmeter插件都是由通用屬性加上自定義屬性表示，在通用屬性中定義的guiclass會定義插件的字段，可是jmeter的字段是和gui插件深度綁定的，若是爲了編排插件引入guiclass類的初始化，會額外增長大量的內存開銷，這裏就須要作一些變更，當確認完guiclass類中的插件字段後，渲染腳本的時候直接繞開它，使用自定義的方式來組裝插件字段。

Jmeter擁有大量的插件，包括官方的和第三方的，數量衆多，插件在腳本中的位置也不是固定不變的，這帶來了兩個問題：

1. 插件太多，必需要有一個統一的構建方式構建插件，以不變應萬變；

2. 編排的腳本中插件的層級沒法事先肯定。

針對第一個問題，輪到設計模式出場，23種設計模式中的建造者模式正好能夠適應這種須要以不變應萬變的場景。

註釋：建造者模式（Builder Pattern）又叫生成器模式，其定義爲：將一個複雜對象的構造與它的表示分離，使一樣的構建過程能夠建立不一樣的表示，這樣的設計模式被稱爲建造者模式。它是將一個複雜的對象分解爲多個簡單的對象，而後一步一步構建而成。它將變與不變相分離，即產品的組成部分是不變的，但每一部分是能夠靈活選擇的。

針對第二個問題，雖然腳本中插件的層級沒法事先確認，可是在jmeter客戶端能夠肯定任何一個插件的下一級插件有哪些，這個時候輪到遞歸出場。

解決方案示例

綜合以上全部的問題分析，作完了全部的前置準備工做後，能夠開始插件的組裝邏輯的編寫，下面以TestPlan插件爲例：

遞歸遍歷插件表單封裝，經過事先肯定的jmeter插件層級並封裝在插件json中，遍歷時能夠很容易控制任務層級的插件字段的封裝。

建造者構造插件字段，經過建造者模式提供統一的抽象，屏蔽jmeter底層，只須要調用對應插件的Builder就能夠構建相應的插件腳本。

總結

經過以上關於jmeter二次開發整個研究流程，能夠將技術性問題的處理流程總結以下：

1. 描述清楚需求，給出初步的技術方案；

2. 針對技術方案作分析，找出可能存在的技術難點；

3. 針對每個技術難點，從不一樣的角度分析並找到問題的解決方案；

4. 針對每個解決方案作技術論證，論證方案可行性，肯定最終的解決方案；

5. 綜合各個解決方案，進行綜合論證，肯定整個大的方案是可行的；

6. 實施方案，經過單元測試驗證全部的邏輯是符合需求。

其餘優質文章

【知識科普】普遍應用的敏捷開發方法論，極限編程與持續集成！

【Azure】混合環境下的身份驗證

【經驗分享】銀行應用運維平臺設計與建設建議