Download (direct link):
When you start JMeter, you see two top-level nodes in its tree: the TestPlan node and the WorkBench node. The TestPlan node holds the active TestPlan you are ready to run. In the WorkBench area, you can construct and configure tests. You must move the test elements and configuration to the TestPlan node before you actually run it. Figure 10.1 shows an active test loaded in the TestPlan node and a test under construction in the WorkBench node.
I ¨ßÀöëåÜë JMdn
¹ Hun Report UfIioth He*
If AdUpmgdud * WMFWy«
ft fdc ?4 ?-1x3
? Ñ-ã Ù* fifriJt
t ttfwRfeM* f “ ¹tfiwh
V "! [ riifcn* '«¹g
QsdOutrv Q&JOwrv Qsd Query ÒÓ Cmbrl Ãåíò
? Ijf-ifr HppJtS 3 7**'* v.-,v—X*r
N-J*!“? -A J ij p.-? ijrju1.1
OffUUt S' Jf.UTlTtrrb
Ml TPS * HTTP
iesfcfel Vj J D C
Figure 10.1: JMeter WorkBench and TestPlan Nodes.
A timer is a simple element that is added to a ThreadGroup. Remember, we said that a thread is like a simulated user; without a timer, that thread becomes a hyper user. If you do not add a timer, the simulated user will keep hitting the site with no delay; however fun this scenario might be, it rarely simulates a real-world user. Thus you add timers to slow down the simulated users (threads) so they behave like real-world users. JMeter has three types of timers: constant timer, Gaussian random timer, and uniform random timer. We typically use the constant timer to create a repeatable test, and we use a Gaussian random timer to simulate real-world user activity.
Another element you'll typically add to a ThreadGroup is a controller. JMeter uses two types of controllers: testing and logic. You use a testing controller to test your system with various protocols (JDBC, HTTP, FTP,
and so on). The testing controller does the sampling, but it does not record the results—for that, you need to add something else.A logical controller controls the flow. It controls the iterative behavior of sub-controllers.
A controller may contain many config elements that help you configure the controller. When you run a test, every element in the TestPlan receives every config element that is above it. For example, a timer inserted into the TestPlan at the highest level applies to all testing controllers.
You'll also typically add a listener to a ThreadGroup. A listener receives sampling data and either graphs it or stores it. Thus JMeter uses two types of listeners: visualizers and reporters. A testing controller collects sampling data and publishes it to one or more listeners, which may store the data in a file or display it in a graph. The View Results listener shows the text returned from a Web site. We use it to make sure the Web application is returning real HTML and not an error page.
Enough theory, concepts, and overview: Let's dive in and use JMeter to test a Web application; then, later in this chapter, we'll test some JDBC queries. The following sections walk step by step through building a TestPlan that first tests navigating through our pet store example and then tests filling out forms on the backend management piece created in the JUnit chapter.
Using JMeter to Test a Web Application Navigation
In this example, we'll set up a ThreadGroup, add Web-test controllers to the ThreadGroup, set up a timer, and set up a graph listener. We follow these steps:
1. Start JMeter. After installing JMeter, you will see a directory called bin in the JMeter home directory. Go to bin and type ''jmeter''; this script will work under Unix and Windows because the makers of JMeter created both types of start-up scripts.
2. We'll add a ThreadGroup to the TestPlan. Right-click on the TestPlan node, select Add, and select ThreadGroup from the pop-up menu (see Figure 10.2).
Fit fiui Rppwt OpIifPrl Http
Figure 10.2: Adding a ThreadGroup to the JMeter TestPlan.
3. Expand the TestPlan node and select the ThreadGroup node. Note that the number of threads is set to 1. Although one thread is not a realistic load test, it's great when we are developing a test. We don't want to launch 100 simulated users (threads) when we don't know if our TestPlan works.
4. Change the name of the ThreadGroup to Navigation, because we're going to set up this type of test.
5. In order for the test to do something, we need to add a controller. Right-click the ThreadGroup node and add a WebTesting Controller, as shown in Figure 10.3.
Figure 10.3: Adding a WebTesting Controller.
6. We need to configure the Web-testing controller. We will set up several Web-testing controllers to simulate navigating down the Web application from the home page to the product page of the pet store sample application. Set up the first controller as follows:
? Set the name to HomeWebTest.
? Set the domain to localhost (or wherever petstore is running).
? Set the port to 80, which is the default (or whatever port the Web application
server is set to run on).
? Set the path to pet (as in http://localhost/pet).