Debugging a JMeter Test Plan

In a previous post about JMeter, I described the creation of a primitive load test. When developing more complex scripts, you cannot do without debugging. Unfortunately, in JMeter this technique is not entirely obvious. Below, with a simple example, I will show several methods for debugging a test plan. At the same time, I will demonstrate the use of elements such as HTTP Request Defaults, Regular Expression Extractor, If Controller, and some others.



We will test the search engine on the site. Let the script take a word or phrase from a file, ask a question to a search engine, get an answer in the form of one or several pages, randomly select one of the pages, also randomly select one of the links and follow it. A total of three queries, except in special cases (when little is found or nothing is found).
It raced.
Run the JMeter GUI and for the sake of order we rename the proposed empty test plan (Test plan) to Search test (in general, today I’ll try to behave culturally and, in particular, to devote time to the distinct naming of script elements, this helps). Right-click on the Search test element in the tree on the left and, saying Add-> Config element-> HTTP Request Defaults , let's hammer in the server address there:



I entered HTTP Request Defaults so as not to enter the server address in each request. And when will it need to be changed? Avoid duplication. I was going to behave culturally, so I try.
Search Test-> Add-> Thread Group . Here we will leave everything by default for now.

Thread Group-> Add-> Config Element-> CVS Data Set Config. With the help of this element we will read our words from the file, in each line upon request.



By the way, we already have something to debug. The script does not go anywhere yet, but already reads something from the file and puts it into a variable (I called it searchPhrase). The sooner we start testing, the healthier we will be. Let's add items for debugging.
Thread Group-> Add-> Sampler-> Debug Sampler .
Thread Group-> Add-> Listener-> View Results Tree . Here and there we leave all the default settings.
Save ( File-> Save ), run ( Run-> Clear All , Run-> Start ). We look in View Results Treeand we see that the script, as we wanted, was executed once. Click on the only result in the Results Tree ( Debug Sampler ) and go to the third tab, Response data. In the last line we see: searchPhrase = test . Just in my first line of the file with the words test is written . Hooray, it somehow works.



Now let's try to correct the script so that it runs through the entire file with words and ends. To do this, Thread Groupset Loop Count: Forever in the properties , and for CSV Data: read word list Recycle on EOF? = False, Stop thread on EOF? = True.

We check. File-> Save , Run-> Clear All , Run-> Start. We see that the cycle was completed 17 times, by the number of lines in my file. Wonderful.



Somewhat darkens the joy is that JMeter displays the Cyrillic alphabet crookedly. Looking ahead, I’ll say that he reads it really normally and writes what is needed in the request, so you can put up with this jamb. In the old versions, he did not understand the Russian names of the elements, then they repaired, probably this one will be repaired over time.

Add an HTTP request. Note the syntax of how we access our variable, into which the phrase was read: $ {searchPhrase}. The Server Name or IP field is empty - the value is substituted from HTTP Request Defaults . We will rename the request to HTTP Request: search (we will have several requests and it is wrong to confuse them together).



We try. Aw, mistake!



We are debugging, where without errors. After carefully reading the server’s response, we recall that he needs the User-Agent header. Easy. Add another element under Search test: HTTP Header Manager. It can be seen that by default JMeter does not transmit any headers. Click Add and add the User-Agent.



We try. This time everything went smoothly. HTTP Request: search turned green in the result tree. Having stepped on it, you can consider the details: in the Sampler result tab - the headers of the server response, Request - the URL and HTTP header that we added, and in the Response data - the body of the response.

Recall that we wanted, having received the answer, if it consists of several pages, select a random page, and already take a link to the document from it. We’ll go to parse the response and get a link to the page from it. On HTTP Request: search we say Add-> Post Processors-> Regular Expression Extractor . Let's start small: let's try to extract a specific link from the page. From the server’s response just above, we’ll take a link to a page and paste it into the Regular Expression field. We call the returned variable pageLink (sounds better than var1 or reResult).



according to the results of execution, we expect that exactly this is the one that gets into the variable .
We try. \ File-> Save , Run-> Clear All , Run-> Start .



Uh ... Why pageLink = 0? Because regexp was not found. Why not found? Because the question mark must be escaped, that's why! Beavis, you cormorant
Then this: .

Quite a different matter. Now the results:
pageLink= We would regeksp to mind: . Change Template to $ 1 $ - we will pick up the first group. It’s not necessary to select groups 2 and 3 - ([^ &] *), ([^ "] *), without brackets. It's just that not everyone is so lucky as we are today, and often we have to take not a ready URL, but construct it it’s from pieces, and it’s very convenient to use Template here , for example, you can write it there .
pageLink_g=0
pageLink_g0=
searchPhrase=test


find.pl?text=$1$&start=$2$

After execution, we get:
pageLink= Honestly, debugging regular expressions for JMeter is a separate song and sometimes it takes a lot of time. The manual fairly advises for their debugging to make a separate test plan and load the page from the local file so as not to torment the remote server and not waste time. Sometimes regexps in JMeter behave strangely, for example, an expression that works fine in Notepad ++ may not find anything in JMeter. They write that the engine is Apach Jakarta ORO . It will be necessary to read on occasion. Add a second HTTP request to the test plan and parse its result. In the HTTP Request form, we leave everything by default, only in the Path field we write
pageLink_g=3
pageLink_g0=
pageLink_g1=search.htm?query=test&nStart=20
pageLink_g2=test
pageLink_g3=20
searchPhrase=test



${pageLink}. We agreed to go to the document from the second page of the search. Regexp, accordingly, will be different:

. After the request and Regular Expression Extractor add Debug Samlper. Of course, we give all elements unique and meaningful names. Debugging.

Finally, add the last request - access to the found document. Since we are not going to parse its result, we don’t set Debug Sampler after it either, it will not show us anything new.



We’ll finalize the test plan a little more. If in the search results we have only one page or nothing at all, JMeter will go to some unprecedented URL like http://0, and may be offended by us. To prevent this from happening, add a check. Thread Group-> Add-> Logic Controller-> If Controller . In the Condition prescribes"${pageLink}" != "0". For clarity, rename the controller (clarity is never superfluous). Now drag it, set it after Debug Sampler: page. Drag HTTP Request: pageunder If Controller. Now attention: pull out RE: docLinkfrom under HTTP Request: pageand put it after If Controller.



It turns out this. The response with which post-processors work (including Regular Expression Extractor ) is global for the thread. If If Controller said no and HTTP Request: pagedidn’t succeed, it RE: docLinkwill analyze the response remaining after the first HTTP request. What I did Regular Expression Extractor a descendant of HTTP Request before does not make much sense, it is only important that it comes later (but it seems to me that the plan looks clearer if the post-processor is a descendant of the sampler).

In our file with a list of words, we spoil the first word so that it is definitely not found. We try: it works. In the View Results TreeHTTP Request: page did not appear, but HTTP Request: documentgave an error. Well, maybe not the first time it works. Even most likely not from the first. For example, I first wrote ${pageLink} != "0", and this condition always gave False, and with quotes everything worked as it should.

It is necessary to gradually round off. We won’t breed around the last HTTP request of If Controller. As the final touches, we add after each request a random delay of 0-30 s (for realism), and the Summary Report and Graph Results listeners at the end of the test plan .



Well, we debugged the execution logic. You can start testing, but that's another matter.
The only thing: before starting to drive the test to the fullest, it is advisable to disable debugging elements, including the View Results Tree , since they are pretty slow:



Just in case , I’ll remind you: before you hammer a productive server, especially someone else’s, it’s worth thinking again whether we are doing everything right. And then there are all sorts of cases.
Good luck

PS
Environment:
Apache Jmeter 2.3.4
java full version “1.6.0_13-b03”
Windows Vista Home

PPS Here is a good article on debugging test plans, but asks for registration:
Tips for debugging your JMeter tests