JMeter 1.6 has a new UI layout. The window is divided into two sections. On the left is a tree which represents a test configuration. The tree represents both the hierarchical and ordered nature of the test. A test can be made up of one or many subtests and each of these subtests may have a particular ordering. The main display is on the right side of the window. Whenever an element in the tree is selected, its control panel is shown in the main display allowing you to enter your test data. When a visualizer is selected the main display will contain the visualizer's view of the current test.

Most functions in the UI are available from popup menus that appear when you right-click on an element in the test tree.

The test configuration tree begins with two elements - TestPlan and WorkBench. The TestPlan element will contain all the elements which make up your test. The WorkBench is simply an area to store test elements while you are in the process of constructing a test.

A TestPlan consists of one or more ThreadGroups. A ThreadGroup is a root element (it can not be nested) which may contain timers, listeners, controllers, Assertions, and config elements. A ThreadGroup also defines the number of threads available to the threadgroup.

• A timer is a simple element that controls how long JMeter should delay between each test sample when it runs. This allows JMeter to simulate human actions more closely. Timer element's are leaves in the test tree they can not contain sub-elements.
• A listener receives information about response data while JMeter runs. For instance, during testing of a website, a listener receives and collects sample data that indicates how many milliseconds it took the web server to respond to each request. Normally, these listeners are visualizers (represent the data visually in the main window), or reporters (store the data to file). Listeners are also leaves in a test configuration tree.
• A controller is an element that controls the flow of test samples. It also controls the process by which test samples are created. Controllers implement JMeter's various testing protocols. Logic Controllers may have other controllers and/or config elements as sub-elements, and Generative Controllers can only have config elements or assertions as sub-elements.
• An Assertion states a requirement that the server's response must satisfy. For instance, an Assertion element can be configured to assert that response text from a web server will include a particular string. If it does not, it will be reported as a failed sample by the assertion reporter.
• A Config Element represents a coherent set of information that is usually specifically targeted to a particular protocol or controller. For instance, setting up a database test requires three config elements - one to configure the basic information about the database (what host, what driver, login and password to use), one to configure the SQL query to be tested, and one to configure the pool of database connections (how many connections to store in pool, etc). Config Elements are leaves in the test configuration tree.

As a user, you create elements in the tree, and start your test when ready. When you start the test, JMeter "compiles" your test script (note: this doesn't refer to an executable script, as in Python or Perl, but to the data in the hierarchical tree). All elements in the tree are added up - meaning child objects are added to their parent objects until a single TestPlan object is created. A JMeterEngine is then created, and the TestPlan sends all of its ThreadGroups to the engine. The engine creates threads, and each thread iterates through the test cases.