JMeter--測試計劃的要素

這篇文章接上一篇(即 JMeter 第2篇)

文章里的每一句話都是我斟酌過的,我認為需要有注釋或者插圖的地方都會有相應的說明,因為水平能力問題依然不能保證每一句話的正確性。更多的是作為參考。

3. 測試計劃的要素(Elements of a Test Plan)


本節(jié)描述測試計劃的不同部分。

最小測試將包括測試計劃、線程組和一個或多個采樣器(Samplers)。


線程組和采樣器

?

3.0 測試計劃(Test Plan)


測試計劃對象有一個名為“函數(shù)測試模式(Functional Testing)”的復選框。如果被選中,它將導致JMeter記錄每個示例從服務器返回的數(shù)據(jù)。如果您在測試監(jiān)聽器中選擇了一個文件,那么該數(shù)據(jù)將被寫到文件中。如果您正在進行一個小的運行,以確保JMeter的配置正確,并且您的服務器正在返回預期的結(jié)果,那么這將非常有用。其結(jié)果是文件將迅速增長,JMeter的性能將受到影響。如果你正在做壓力測試,這個選項應該是關(guān)閉的(默認是關(guān)閉的)。

如果您沒有將數(shù)據(jù)記錄到文件中,這個選項沒有作用。

您還可以使用監(jiān)聽器(listener)上的Configuration按鈕來決定保存哪些字段。

?

3.1 線程組(Thread Group)


線程組元素是任何測試計劃的起點。所有的控制器和采樣器都必須在一個線程組之下。其他元素,例如監(jiān)聽器,可以直接放在測試計劃下,在這種情況下,它們將應用于所有線程組。顧名思義,線程組元素控制JMeter用于執(zhí)行測試的線程數(shù)。線程組的控件允許您:

  • 設置線程數(shù)
  • 設置過渡時期(Ramp-Up Period)
  • 設置執(zhí)行測試的次數(shù)。

每個線程將完全獨立于其他測試線程執(zhí)行測試計劃。多個線程用于模擬與服務器應用程序的并發(fā)連接。

過渡期間告訴JMeter要花多長時間來“過渡”到所選線程的總數(shù)。如果使用了10個線程,并且加速周期是100秒,那么JMeter將花費100秒來啟動和運行所有10個線程。在前面的線程開始之后,每個線程將啟動10(100/10)秒。如果有30個線程,并且加速周期為120秒,那么每個后續(xù)線程將被延遲4秒。

在測試開始時,需要足夠長的時間來避免過大的工作負載,并且足夠短,最后的線程在第一個線程完成之前就開始運行(除非一個線程想要這樣做)。

Ramp-up =線程的數(shù)量做上下調(diào)整。

默認情況下,線程組被配置為在其元素中循環(huán)一次。

線程組還提供一個調(diào)度器(scheduler)。單擊線程組面板底部的復選框,以啟用/禁用額外字段,您可以在其中輸入測試持續(xù)時間、啟動延遲、運行的開始和結(jié)束時間。您可以配置持續(xù)時間(秒)(Duration (seconds))啟動延遲(秒)(Startup Delay (seconds))來控制每個線程組的持續(xù)時間以及它開始的秒數(shù)。當測試啟動時,JMeter將在啟動線程組的線程之前等待啟動延遲(秒),并運行配置的持續(xù)時間(秒)。注意這兩個選項覆蓋了啟動時間結(jié)束時間。

另外(盡管不推薦,因為不太靈活)您可以使用另外兩個字段啟動時間結(jié)束時間。當測試開始時,JMeter將在必要時等待,直到達到啟動時間。在每個周期結(jié)束時,JMeter檢查是否達到了結(jié)束時間,如果達到了,則停止運行,否則測試將繼續(xù)進行直到循環(huán)結(jié)束。

線程組

?

3.2 控制器(Controllers)


JMeter有兩種類型的控制器:采樣器和邏輯控制器。這些驅(qū)動了測試的處理。

采樣器告訴JMeter向服務器發(fā)送請求。例如,如果您想要JMeter發(fā)送一個HTTP請求,請?zhí)砑右粋€HTTP請求采樣器。您還可以通過向采樣器添加一個或多個配置元素來定制一個請求。有關(guān)更多信息,請參見Samplers。

邏輯控制器允許您定制JMeter用來決定何時發(fā)送請求的邏輯。例如,您可以添加一個Interleave邏輯控制器來在兩個HTTP請求采樣器之間進行切換。有關(guān)更多信息,請參見邏輯控制器。

?

3.2.1 采樣器(Samplers)

采樣器告訴JMeter向服務器發(fā)送請求并等待響應。它們按照出現(xiàn)在樹中的順序進行處理??刂破骺捎糜谛薷囊粋€采樣器的重復次數(shù)。

jmeter的樣本器包含:

  • FTP Request
  • HTTP Request (can be used for SOAP or REST Webservice also)
  • JDBC Request
  • Java object request
  • JMS request
  • JUnit Test request
  • LDAP Request
  • Mail request
  • OS Process request
  • TCP request
Samplers

每個采樣器都有幾個屬性可以設置。您可以通過在測試計劃中添加一個或多個配置元素來進一步定制一個采樣器。
如果要向同一服務器發(fā)送同一類型的多個請求(例如,HTTP請求),請考慮使用缺省配置元素。每個控制器都有一個或多個默認元素(參見下面)。

請記住在測試計劃中添加監(jiān)聽器,以便查看測試結(jié)果。

如果您想讓JMeter對您的請求的響應執(zhí)行基本驗證,請向采樣器添加一個斷言(Assertion)。例如,在壓力測試web應用程序時,服務器可能返回一個成功的“HTTP響應”代碼,但是頁面可能有錯誤,或者可能缺少部分。您可以添加斷言來檢查某些HTML標記、常見錯誤字符串等。JMeter允許您使用正則表達式創(chuàng)建這些斷言。

內(nèi)置邏輯控制器的列表(JMeter's built-in samplers)

?

3.2.2邏輯控制器(Logic Controllers)

邏輯控制器允許您定制JMeter用來決定何時發(fā)送請求的邏輯。邏輯控制器可以更改來自其子元素的請求的順序。他們可以自己修改請求,導致JMeter重復請求,等等。

要理解邏輯控制器對測試計劃的影響,請考慮以下測試樹:

  • Test Plan
    ??* Thread Group
    ????* Once Only Controller
    ???????* Login Request (an HTTP Request)
    ????* Load Search Page (HTTP Sampler)
    ????* Interleave Controller
    ???????* Search "A" (HTTP Sampler)
    ???????* Search "B" (HTTP Sampler)
    ???????* HTTP default request (Configuration Element)
    ????* HTTP default request (Configuration Element)
    ????* Cookie Manager (Configuration Element)
    該測試樹在 JMeter 的顯示如下:
    test tree

關(guān)于這個測試的第一件事是登錄請求將只在第一次執(zhí)行。后續(xù)的迭代將跳過它。這是由于僅一次控制器的影響。

登錄后,下一個取樣器將加載搜索頁面--Load Search Page(想象一個用戶登錄的web應用程序,然后進入搜索頁面進行搜索)。這只是一個簡單的請求,沒有經(jīng)過任何邏輯控制器的過濾。
注意:Load Search Page在這里就是一個 HTTP 請求。

加載搜索頁面之后,我們要進行搜索。實際上,我們想做兩個不同的搜索。但是,我們希望在每次搜索之間重新加載搜索頁面本身。我們可以通過4個簡單的HTTP請求元素(加載搜索、搜索“A”、加載搜索、搜索“B”)來實現(xiàn)這一點。相反,我們使用Interleave Controller(交替控制器),它在每次測試中傳遞一個子請求。它保持排序(也就是說,它不是隨機傳遞一個,而是“記住”它的子元素的位置)。交叉兩個子請求可能有點過了頭,但是很可能有8個或20個子請求。

注意屬于Interleave控制器的HTTP請求默認值。假設“Search A”和“Search B”共享相同的路徑信息(HTTP請求規(guī)范包括域、端口、方法、協(xié)議、路徑和參數(shù),以及其他可選項)。這是有意義的——這兩個都是搜索請求,攻擊相同的后端搜索引擎(比方說servlet或cgi-script)。我們可以將這些信息抽象為單個配置元素,而不是在路徑字段中使用相同的信息配置兩個HTTP Samplers。當Interleave控制器“傳遞”來自“Search A”或“Search B”的請求時,它將用HTTP默認請求配置元素的值填充空格。因此,我們?yōu)檫@些請求保留PATH字段為空,并將這些信息放入Configuration元素中。在這種情況下,這充其量只是一個小好處,但它展示了這個特性。

樹中的下一個元素是另一個HTTP默認請求(HTTP default request),這次添加到線程組本身。線程組有一個內(nèi)置的邏輯控制器,因此,它使用的配置元素與上面描述的完全一樣。它填入任何經(jīng)過的請求的空格。在web測試中,在所有HTTP取樣器(HTTP Sampler )元素中保留域字段為空是非常有用的,而不是,將這些信息放到一個HTTP默認請求元素中,并添加到線程組中。通過這樣做,您可以通過更改測試計劃中的一個字段,在不同的服務器上測試應用程序。否則,你必須編輯每一個采樣器。

最后一個元素是HTTP Cookie管理器。應該將Cookie管理器添加到所有web測試中——否則JMeter將忽略Cookie。通過在線程組級別添加它,我們確保所有HTTP請求將共享相同的cookie。

可以將邏輯控制器組合起來以實現(xiàn)各種結(jié)果。請參閱內(nèi)置邏輯控制器的列表。

?

3.2.3 測試片段(Test Fragments)

Test Fragment元素是存在于與Thread Group元素相同級別的測試計劃樹上的一種特殊類型的控制器。它與線程組的區(qū)別在于,它不會執(zhí)行,除非模塊控制器Include_Controller引用它。

這個元素純粹用于測試計劃中的代碼重用


Test Fragment

?

3.3 監(jiān)聽器(Listeners)


監(jiān)聽器提供對JMeter運行時收集的有關(guān)測試用例的信息的訪問。圖結(jié)果監(jiān)聽器在圖上繪制響應時間。“查看結(jié)果樹”監(jiān)聽器顯示采樣請求和響應的細節(jié),并可以顯示響應的基本HTML和XML表示。其他監(jiān)聽器提供匯總信息或聚合信息。

此外,監(jiān)聽器可以將數(shù)據(jù)定向到文件,以便以后使用。JMeter中的每個監(jiān)聽器都提供一個字段,用于指示要存儲數(shù)據(jù)的文件。還有一個配置按鈕,可用于選擇保存哪些字段,以及使用CSV還是XML格式。

監(jiān)聽器查看結(jié)果

注意,所有監(jiān)聽器都保存相同的數(shù)據(jù);唯一的區(qū)別在于數(shù)據(jù)在屏幕上顯示的方式。

監(jiān)聽器可以添加到測試中的任何地方,包括直接在測試計劃下。他們將只從其同級和子級的元素收集數(shù)據(jù)。

有幾個監(jiān)聽器與JMeter一起出現(xiàn)。

?

3.4 定時器(Timers)


默認情況下,JMeter線程按順序執(zhí)行采樣,不會暫停。我們建議您通過向線程組添加一個可用的計時器來指定延遲。如果不添加延遲,JMeter可能會在很短的時間內(nèi)發(fā)出太多請求,從而使服務器不堪重負。

計時器將導致JMeter在其范圍(scope)內(nèi)的每個采樣器之前延遲一定的時間。

如果您選擇向一個線程組添加多個定時器,JMeter會在執(zhí)行計時器應用程序的采樣器之前,將計時器暫停的時間加起來。計時器可以作為采樣器或控制器的子級添加,以限制應用它們的采樣器。

要在測試計劃中的單個位置提供暫停,可以使用測試動作(Test Action)采樣器。

scope: 3.10節(jié)
?

3.5 斷言(Assertions)


斷言允許您斷言從被測試的服務器接收的響應的事實。使用斷言,您實際上可以“測試”應用程序正在返回預期的結(jié)果。

例如,您可以斷言對查詢的響應將包含某些特定的文本。您指定的文本可以是一個perl樣式的正則表達式,您可以指出響應是包含文本,或者它應該與整個響應相匹配。

您可以向任何采樣器(Sampler)添加斷言。例如,可以向HTTP請求添加一個斷言,該請求檢查文本“</HTML>”。然后,JMeter將檢查該文本是否存在于HTTP響應中。如果JMeter找不到文本,那么它將把它標記為失敗的請求。

注意,斷言適用于所有在其范圍內(nèi)(scope)的采樣器。若要將斷言限制為單個采樣器,請將斷言添加為采樣器的子級。

要查看斷言結(jié)果,請向線程組添加斷監(jiān)聽器。失敗的斷言也將出現(xiàn)在樹視圖和表監(jiān)聽器中,并將計數(shù)到錯誤%年齡,例如在聚合和摘要報告中。

?

3.6 配置元件/素(Configuration Elements)


配置元件

配置元件與采樣器緊密配合。盡管它不發(fā)送請求(除了 HTTP(S) Test Script Recorder),但它可以添加或修改請求。

配置元件只能從放置元素的樹分支中訪問。例如,如果你把一個HTTP Cookie Manager放在一個簡單的邏輯控制器,Cookie Manager只會訪問HTTP請求控制器將在簡單的邏輯控制器(見圖1)。Cookie管理器都可以訪問HTTP請求“Web Page 1”和“Web Page 2”,而不是“Web Page 3”。

此外,樹分支中的配置元素比“父”分支中的相同元素具有更高的優(yōu)先級。例如,我們定義了兩個HTTP請求默認元素“Web Defaults 1”和“Web Defaults 2”。由于我們在循環(huán)控制器中放置了“Web Defaults 1”,因此只有“Web Page 2”可以訪問它。其他HTTP請求將使用“Web Defaults 2”,因為我們將它放在線程組(所有其他分支的“父”)中。


配置元件

?

3.7 前置處理器元素(Pre-Processor Elements)


前置處理器

前置處理器在發(fā)出采樣請求之前執(zhí)行一些操作。如果前置處理器附加到采樣器元素,那么它將在采樣器元素運行之前執(zhí)行。前置處理器通常用于在示例請求運行之前修改其設置,或者更新未從響應文本中提取的變量。有關(guān)何時執(zhí)行前置處理器的詳細信息,請參閱scoping rules(3.10節(jié))

?

3.8 后置處理器元素(Post-Processor Elements)


后置處理器在采樣請求完成后執(zhí)行一些操作。如果后置處理程序附加到采樣器元素,那么它將在采樣器元素運行之后執(zhí)行。后置處理器通常用于處理響應數(shù)據(jù),通常用于從中提取值。有關(guān)何時執(zhí)行后置處理器的詳細信息,請參閱scoping rules(3.10節(jié))。

?

3.9 執(zhí)行順序(Execution order)


  • 配置元件/素(Configuration elements)
  • 前置處理器(Pre-Processors)
  • 定時器(Timers)
  • 采樣器(Sampler)
  • 后置處理器(Post-Processors (unless SampleResult is null))
  • 斷言(Assertions (unless SampleResult is null))
  • 監(jiān)聽器(Listeners (unless SampleResult is null))

請注意,定時器、斷言、預處理器和后處理器只有在應用它們的采樣器時才被處理。邏輯控制器和采樣器按照它們出現(xiàn)在樹中的順序進行處理。其他測試元素根據(jù)找到它們的范圍和測試元素的類型進行處理。[在類型中,元素按照它們出現(xiàn)在樹中的順序進行處理]。

例如,在下面的測試計劃中:

  • Controller
    ?Post-Processor 1
    ?
    Sampler 1
    ?Sampler 2
    ?
    Timer 1
    ?Assertion 1
    ?
    Pre-Processor 1
    ?Timer 2
    ?
    Post-Processor 2

執(zhí)行的順序是:

Pre-Processor 1
Timer 1
Timer 2
Sampler 1
Post-Processor 1
Post-Processor 2
Assertion 1

Pre-Processor 1
Timer 1
Timer 2
Sampler 2
Post-Processor 1
Post-Processor 2
Assertion 1

?

3.10 范圍規(guī)則(Scoping Rules)


JMeter測試樹包含分層和有序的元素。測試樹中的一些元素是嚴格的層次結(jié)構(gòu)(偵聽器、配置元素、后處理器、前處理器、斷言、計時器),而一些元素主要是有序的(控制器、采樣器)。當您創(chuàng)建測試計劃時,您將創(chuàng)建一個有序的示例請求列表(通過Samplers),它表示要執(zhí)行的一系列步驟。這些請求通常是在控制器中組織的,這些控制器也是有序的。給定以下測試樹:


test tree

請求的順序是,1、2、3、4。

有些控制器影響子元素的順序,您可以在組件引用中閱讀這些特定的控制器。

其他元素層次。例如,斷言在測試樹中是分層的。如果它的父類是請求,那么它將被應用到該請求。如果它的父類是控制器,那么它將影響該控制器的所有后代請求。在下面的測試樹中:

層次結(jié)構(gòu)示例

Assertion#1只應用于請求1,Assertion#2應用于請求2和3。

另一個例子,這次使用計時器:


復雜的示例

在本例中,請求被命名為反映執(zhí)行它們的順序。計時器#1將應用于請求2、3和4(注意,對于分層元素,順序是不相關(guān)的)。斷言#1只適用于請求3。計時器#2將影響所有請求。

希望這些示例能夠清楚地說明配置(分層)元素是如何應用的。如果您想象每個請求都被傳遞到樹分支上,傳遞給它的父分支,然后傳遞給它的父分支,等等,并且每次收集父分支的所有配置元素,那么您將看到它是如何工作的。

配置元素頭管理器、Cookie管理器和授權(quán)管理器與配置默認元素不同。配置默認元素的設置被合并到采樣器可以訪問的一組值中。但是,管理器的設置沒有合并。如果在采樣器的范圍內(nèi)有多個管理器,則只使用一個管理器,但是目前沒有辦法指定使用哪個管理器。

?

3.11 屬性和變量 (Properties and Variables)


JMeter屬性在JMeter.properties中定義(請參閱我的JMeter 第一篇文章第1.5節(jié)以了解更多細節(jié))。

屬性對于jmeter是全局的,并且主要用于定義一些默認的jmeter使用。例如,屬性remote_hosts定義了JMeter遠程運行的服務器。屬性可以在測試計劃中引用——參見Functions——read a property——但是不能用于特定于線程的值。

JMeter變量對每個線程都是本地的。每個線程的值可能相同,也可能不同。

如果一個變量被一個線程更新,那么只有該變量的線程副本被更改。例如,正則表達式提取器后置處理器將根據(jù)其線程讀取的示例設置其變量,這些變量稍后可以被相同的線程使用。有關(guān)如何引用變量和函數(shù)的詳細信息,請參見函數(shù)和變量。

注意,測試計劃(Test Plan)用戶定義的變量配置元素定義的值在啟動時對整個測試計劃可用。如果同一個變量由多個UDV元素定義,那么最后一個變量將生效。一旦一個線程啟動,初始的變量集將被復制到每個線程。其他元素如用戶參數(shù)前置處理器或正則表達式提取器后置處理器可用于重新定義相同的變量(或創(chuàng)建新的變量)。這些重新定義只適用于當前線程。

setProperty函數(shù)可用于定義JMeter屬性。這些是測試計劃的全局變量,因此可以用來在線程之間傳遞信息——這是需要的。

變量和屬性都是區(qū)分大小寫的。

?

3.12 使用變量來參數(shù)化測試 (Using Variables to parameterise tests)


變量不需要改變——它們可以定義一次,如果不改變,就不會改變值。因此,您可以將它們作為在測試計劃中經(jīng)常出現(xiàn)的表達式的縮寫。或者對于在運行過程中是常量的項,但是在運行之間可能會有所不同。例如,主機名或線程組中的線程數(shù)。

在決定如何構(gòu)建測試計劃時,請注意哪些項目在運行中是常量,但是在運行之間可能會發(fā)生變化。為這些變量確定一些變量名——可能使用命名約定,比如用C_K_前綴,或者只使用大寫字母,以區(qū)別于測試期間需要更改的變量。還要考慮哪些項需要在線程中是本地的——例如計數(shù)器或使用正則表達式后處理器提取的值。您可能希望對它們使用不同的命名約定。

例如,您可以在測試計劃中定義以下內(nèi)容:

HOST             www.example.com
THREADS          10
LOOPS            20

您可以將這些在測試計劃中引用為${HOST}${THREADS}等。如果以后想要更改主機,只需更改HOST變量的值。對于少量的測試來說,這樣做很好,但是在測試很多不同的組合時就變得單調(diào)乏味了。一種解決辦法是使用屬性來定義變量的值,例如:

HOST             ${__P(host,www.example.com)}
THREADS          ${__P(threads,10)}
LOOPS            ${__P(loops,20)}

然后,您可以更改命令行上的一些或所有值,如下所示:

jmeter … -Jhost=www3.example.org -Jloops=13

本文的原文出處。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容