JMeter Concepts

To use JMeter, you must construct and then run a TestPlan. A TestPlan consists of one to many ThreadGroups. You can think of a thread as a simulated user, and a ThreadGroup as a list of simulated users. The general rule is that the more threads you add, the harder your system resources will get hit.

Once you create all the elements in the TestPlan, you begin your test. JMeter then compiles your test elements and creates a single TestPlan object. From the TestPlan, a JMeterEngine is formed. The JMeterEngine creates threads, and each thread iterates through the test cases. 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. The following figure shows an active test loaded in the TestPlan node and a test under construction in the WorkBench node.

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 app 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 app; 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.