【文章內(nèi)容簡介】 在 兩個 HTTP 請求取樣器之間交替 。更多信息，見邏輯控制器。 取樣器 取樣器告訴 JMeter 發(fā)送請求到服務(wù)器。 JMeter 取樣器包括： ? FTP 請求 ? HTTP 請求 ? JDBC 請求 ? Java object 請求 ? LDAP 請求 ? SOAP/XMLRPC 請求 ? WebService (SOAP) 請求 每個取樣器有一些你可以設(shè)置的屬性。你可以通過添加一個或多個配置元件到取樣器來進一步定制它。注意 JMeter 發(fā)送請求按照取樣器出現(xiàn)在樹中的順序。 如果你想發(fā)送多個相同類型的請求（例如， HTTP Request）到相同的服務(wù)器，可以考慮使用一個默認配置元件。每個控制器有一個或者多個默認配置元件（見下）。 記得添加一個監(jiān)聽器到線程組來查看 /保存你的請求結(jié)果到磁盤。 如果你對使用 JMeter 平臺的基礎(chǔ)驗證器到你的請求響應(yīng)感興趣，添加一個斷言到請求控制器。例如， 在壓力測試一個 web 程序時，服務(wù)器會返回一個成功的HTTP 響應(yīng)代碼，但是這個頁面有錯誤或者被忽略部分。你可以添加斷言來檢查某個 HTML 標簽，一些 錯誤字符串，等等。 JMeter 允許你使用正則表達式創(chuàng)建斷言。 JMeter 內(nèi)建取樣器 邏輯 控制器 保持 邏輯控制器讓你定制當發(fā)送請求時 JMeter 使用的判斷邏輯。邏輯控制器還可以作為下列任何元件的子元件：取樣器（請求）、配置元件、和其他邏輯控制器。邏輯控制器可以改變來自它們的子元件的請求順序。它們可以修改請求本身，導(dǎo)致 JMeter 重復(fù)請求，等。 理解邏輯控制器在測試計劃中的效果，考慮下列測試樹： ? 測試計劃 o 線程組 ? 僅一次控制器 ? 登錄請求 (一個 HTTP 請求 ) ? 加載搜索頁面 (HTTP 取樣器 ) ? Interleave Controller ? 搜索 A(HTTP 取樣器 ) ? 搜索 B(HTTP 取樣器 ) ? HTTP 默認請求 (配置元件 ) ? HTTP 默認請求 (配置元件 ) ? Cookie 管理器 (配置元件 ) 這個測試的第一件事就是登錄請求僅在第一次經(jīng)過時被執(zhí)行。隨后的迭代會忽略它。這應(yīng)使用僅一次控制器。 登陸后，下一個取樣器加載搜索頁面（ 假設(shè)一個用登錄的 web 應(yīng)用程序，并到達搜索頁面去搜索）。這僅是一個簡單的請求，不會被任何邏輯控制器過濾。 加載搜索頁面后，我們要做一個搜索。事實上，我們想做兩個不同的搜索。然而，在每個搜索之間我們想要自己重新加載搜索頁面。我們通過 4個簡單 HTTP 元件這樣做。 (load search, search A, load search, search B). Instead, we use the Interleave Controller which passes on one child request each time through the test. It keeps the ordering (ie it doesn39。t pass one on at random, but remembers its place) of its child elements. Interleaving 2 child requests may be overkill, but there could easily have been 8, or 20 child requests. 注意 HTTP 默認請求屬于插入控制器。假如 Search A和 Search B共享同樣的PATH 信息（一個 HTTP 請求說明中包括域，端口，方法，協(xié)議路徑和參數(shù)，附加其他可選項）。兩個搜索請求訪問同樣的后端搜索引擎（比方 說 Servle，或者cgi 腳本），這樣是說得通的。與其兩者都配置使用相同信息的 HTTP 取樣器，我們可以抽象那些新到一個單獨的配置元件。當內(nèi)部控制 器通過 Search A或者 Search B傳遞時，它會從 HTTP 默認請求配置元件中獲得值填充空白。所以我們可以為那些請求保留 PATH 域 為空，然后把那些信息放到配置元件。在這個例子中， 這至多是一個很小的好處，但它顯示了這個特性。 在這個樹中下一個元件是另一個 HTTP 默認請求，這個時間被添加到線程組本身。這個線程組有一個內(nèi)建的邏輯控制器，因此它正好使用這個配置元件做為 上面的描述。它填充任何穿過的請求的空白。 在 web 程序中你所有的 HTTP 取樣器元件 DOMAIN 域為空，這是極度有用的，替代的，把那些信息放到 HTTP 默認請求元件中，添加到線程組。通過這樣 做，你可以在一個同的服務(wù)器通過改變你測試計劃中的一個域來測試你的程序。另外，你必須編輯每 個取樣器。 最后一個元件是一個 HTTP Cookie 管理器。一個 Cookie 管理器應(yīng)該添加到所有web 測試上 否則 JMeter 會忽略 Cookie。通過在線程組級添加它，我們可以確定所有的線程分享同樣的 Cookie。 邏輯控制器可以組合達到不同的結(jié)果。見內(nèi)建邏輯控制器列表。 監(jiān)聽器 監(jiān)聽器提供訪問 JMeter 收集當 JMeter 運行的關(guān)于測試計劃的信息。圖形結(jié)果監(jiān)聽器在一張圖上繪制響應(yīng)時間。 查看結(jié)果樹 監(jiān)聽器顯示了請求和響應(yīng)取樣器的細節(jié)，并且以基礎(chǔ)的 HTML 和 XML 顯示響應(yīng)表現(xiàn)。其他監(jiān)聽器提供了摘要 或者集合信息。 另外，監(jiān)聽器可以指導(dǎo)它們收集的數(shù)據(jù)到一個文件供以后用。在 JMeter 中每一個監(jiān)聽器提供一個域來指出存儲數(shù)據(jù)的文件。 在測試中監(jiān)聽器可以添加到任何位置。它們僅僅會從它們等級或者它們以下等級的元件收集數(shù)據(jù)。 伴隨 JMeter 有很多有趣的監(jiān)聽器。 定時器 默認， JMeter 線程發(fā)送請求時不在請求間暫停。我們建議你通過添加一個可用的定時器到你的線程組來指定一個延遲。如果你不添加延遲， JMeter 會在短時間內(nèi)產(chǎn)生太多請求，可能會壓倒你的服務(wù)。 定時器會使 JMeter 在一個線程開始每個請求間延 遲一段時間。 如果你選擇添加多于一個定時器到一個線程組， JMeter 會在執(zhí)行取樣器前獲得定時器數(shù)量并暫停那個時間量。 斷言 斷言允許你斷言關(guān)于從測試服務(wù)器收到的響應(yīng)的行為。使用斷言你本質(zhì)上你可以測試你的應(yīng)用程序返回你期望的結(jié)果。 例如，你可以斷言一個查詢的響應(yīng)會包含一些特殊的文本。你指定的文本可能是Perl 風(fēng)格的正則表達式， 并且你可以指出這個響應(yīng)是包含這個文本，還是匹配整個響應(yīng)。 你可以添加一個斷言到任何取樣器。例如你可以添加一個斷言到 HTTP 請求檢查文本 /HTML。 JMeter 會檢查在 HTTP 響應(yīng)中表現(xiàn)的文本。如果 JMeter 沒有找到這個文本，它會標記這個為一個失敗的請求。 為了查看斷言結(jié)果，添加一個斷言監(jiān)聽器到線程組。 配置元件 配置元件配合取樣器工作。雖然它不發(fā)送請求（除了 HTTP 代理服務(wù)器），但是它可以添加或者修改請求。 一個配置元件進能訪問有所代替元件所在的樹分支的內(nèi)部。例如，如果你在一個簡單邏輯控制器里面設(shè)置一個 HTTP Cookie 管理器， Cookie 管理器很容易訪問web Page 1和 web Page 2HTTP 請求。但是不能訪問 web Page 3。 同樣，一個在樹枝內(nèi)部的配置元件比在父支的同樣元件有更高的優(yōu)先級。例如，我們定義兩個 HTTP 默認請求元件， Web Defaults 1和 Web Defaults 2。 如果我們把 Web Defaults 1放置在一個循環(huán)控制器內(nèi)部，僅 Web Page 2可以訪問它。另一 HTTP 請求會使用 Web Defaults 2，如果我們把它放置在線程組 (所有其他分支的父支 )。 圖 1 測試計劃展示配置元件的可達性 前置處理器元件 前置處理器在取樣器請求建立前執(zhí)行一些行為。如果前置處理器附屬于取樣器元件，那么它會僅在那個取樣器元件運行前執(zhí)行。前置處理器最常用來在取樣請求運行前修改它的設(shè)置，或者更新不能從響應(yīng)文本提取的變量。 當前置處理器執(zhí)行時，詳細信息見作用域規(guī)則。 后置處理器元件 后置控制器在取樣器請求建立后執(zhí)行一些行為。如果后置處理器附屬于取樣 器元件，那么它會僅在那個取樣器元件運行后執(zhí)行。后置處理器最常用來處理響應(yīng)數(shù)據(jù)，常用來從它里面提取數(shù)值。 \\\\\\詳細見作用域規(guī)則關(guān)于前置處理器執(zhí)行。 執(zhí)行順序 1. 配額制元件 2. 前置處理器 3. 定時器 4. 取樣器 5. 后置處理器 (如果 SampleResult 不為空 ) 6. 斷言 (如果 SampleResult 不為空 ) 7. 監(jiān)聽器 (如果 SampleResult 不為空 ) Please note that Timers, Assertions, Pre and PostProcessors are only processed if there is a sampler to which they apply. Logic Controllers and Samplers are processed in the order in which they appear in the tree. Other test elements are processed according to the scope in which they are found, and the type of test element. [Within a type, elements are processed in the order in which they appear in the tree]. For example, in the following test plan: ? Controller o PostProcessor 1 o Sampler 1 o Sampler 2 o Timer 1 o Assertion 1 o PreProcessor 1 o Timer 2 o PostProcessor 2 The order of execution would be: PreProcessor 1 Timer 1 Timer 2 Sampler 1 PostProcessor 1 PostProcessor 2 Assertion 1 PreProcessor 1 Timer 1 Timer 2 Sampler 2 PostProcessor 1 PostProcessor 2 Assertion 1 Properties and Variables JMeter properties are defined in (see Gettting Started Configuring JMeter for more details). Properties are global to jmeter, and are mostly used to define some of the defaults JMeter uses. For example the property remote_hosts defines the servers that JMeter will try to run remotely. Properties can be referenced in test plans see Functions read a property but cannot be used for threadspecific values. JMeter variables are local to each thread. The values may be the same for each thread, or they may be different. If a variable is updated by a thread, only the thread copy of the variable is changed. For example the Regular Expression Extractor PostProcessor will set its variables according to the sample that its thread has read, and these can be used later by the same thread. For details of how to reference variables and functions, see Functions and Variables Note that the values defined by the Test Plan and the User Defined Variables configuration element are made available to the whole test plan at startup. If the same variable is defined by multiple