1. Introduction
1.1 History
1.2 The Future
2. Getting Started
2.1 Requirements
2.1.1 Java Version
2.1.2 Operating Systems
2.2 Optional
2.2.1 Java Compiler
2.2.2 SAX XML Parser
2.2.3 Email Support
2.2.4 SSL Encryption
2.2.5 JDBC Driver
2.2.6 Apache SOAP
2.3 Installation
2.3.1 Downloading the Latest Release
2.3.2 Downloading Nightly Builds
2.4 Running JMeter
2.4.1 JMeter's Classpath
2.4.2 Using a Proxy Server
2.4.3 Non-GUI Mode
2.4.4 Distributed Mode
2.4.5 Overriding Properties Via The Command Line
2.4.6 Logging and Error Messages
2.5 Configuring JMeter
3. Building a Test Plan
3.1 Adding and Removing Elements
3.2 Loading and Saving Elements
3.3 Configuring Tree Elements
3.4 Running a Test Plan
3.5 Scoping Rules
4. Elements of a Test Plan
4.1 Thread Group
4.2 Controllers
4.2.1 Samplers
4.2.2 Logic Controllers
4.3 Listeners
4.4 Timers
4.5 Assertions
4.6 Configuration Elements
4.7 Pre-Processor Elements
4.8 Post-Processor Elements
5. Building a Web Test Plan
5.1 Adding Users
5.2 Adding Default HTTP Request Properties
5.3 Adding Cookie Support
5.4 Adding HTTP Requests
5.5 Adding a Listener to View/Store the Test Results
5.6 Saving the Test Plan
5.7 Running the Test Plan
6. Building an Advanced Web Test Plan
6.1 Handling User Sessions With URL Rewriting
6.2 Using a Header Manager
7. Building a Database Test Plan
7.1 Adding Users
7.2 Adding JDBC Requests
7.3 Adding a Listener to View/Store the Test Results
7.4 Saving the Test Plan
7.5 Running the Test Plan
8. Building an FTP Test Plan
8.1 Adding Users
8.2 Adding Default FTP Request Properties
8.3 Adding FTP Requests
8.4 Adding a Listener to View/Store the Test Results
8.5 Saving the Test Plan
8.6 Running the Test Plan
9. Building an LDAP Test Plan
9.1 Adding Users
9.2 Adding Login Config Element
9.3 Adding LDAP Request Defaults
9.4 Adding LDAP Requests
9.5 Adding a Listener to View/Store the Test Results
9.6 Saving the Test Plan
9.7 Running the Test Plan
10. Building a Webservice Test Plan
11. Building a JMS Point to point Test Plan
12. Building a JMS topic Test Plan
13. Building a Monitor Test Plan
14. Listeners
15. Remote Testing
16. Best Practices
16.1 [ALL] Limit the Number of Threads
16.2 [HTTP] Where to Put the Cookie Manager
16.3 [HTTP] Where to Put the Authorization Manager
16.4 Using the Proxy Server to record test scripts
17. Help! My boss wants me to load test our web app!
18. Component Reference
19. Functions
20. Regular Expressions
21. Glossary

------------------------------------------------------------------------------------------------------------------------------------------

1. Introduction

Apache JMeter is a 100% pure Java desktop application designed to load test client/server software (such as a web application ). It may be used to test performance both on static and dynamic resources such as static files, Java Servlets, CGI scripts, Java objects, databases , FTP servers , and more. JMeter can be used to simulate a heavy load on a server, network or object to test its strength or to analyze overall performance under different load types. Additionally, JMeter can help you regression test your application by letting you create test scripts with assertions to validate that your application is returning the results you expect. For maximum flexibility, JMeter lets you create these assertions using regular expressions. 1.1 History Stefano Mazzocchi of the Apache Software Foundation was the original developer of JMeter. He wrote it primarily to test the performance of Apache JServ (a project that has since been replaced by the Apache Tomcat project). We redesigned JMeter to enhance the GUI and to add functional-testing capabilities. 1.2 The Future We hope to see JMeter's capabilities rapidly expand as developers take advantage of its pluggable architecture. The primary goal of further development is to make JMeter the most useful regression testing tool as possible, without compromising JMeter's load-testing capabilities.

2. Getting Started

The easiest way to begin using JMeter is to first download the latest production release and install it. The release contains all of the files you need to build and run Web, FTP, JDBC, and JNDI tests. If you want to perform JDBC testing, then you will, of course, need the appropriate JDBC driver from your vendor. JMeter does not come with any JDBC drivers. Other software that you may want to download: BeanShell Java Activation Framework - needed for JavaMail Java Mail - needed for mail visualiser and SOAP tests JMS - for JMS samplers General Java download page See the JMeter Classpath section for details on installing additional jars. Next, start JMeter and go through the Building a Test Plan section of the User Guide to familiarize yourself with JMeter basics (for example, adding and removing elements). Finally, go through the appropriate section on how to build a specific type of Test Plan. For example, if you are interested in testing a Web application, then see the section Building a Web Test Plan . The other specific Test Plan sections are for JDBC , FTP , and JNDI . Once you are comfortable with building and running JMeter Test Plans, you can look into the various configuration elements (timers, listeners, assertions, and others) which give you more control over your Test Plans.

2.1 Requirements

JMeter requires your computing environment meets some minimum requirements. 2.1.1 Java Version JMeter requires a fully compliant JVM 1.3 or higher. We are making a strong effort currently to be compatible with the 1.3 JVM's, though it is expected JMeter performs best with 1.4 or better. Because JMeter uses only standard Java APIs, please do not file bug reports if your JRE fails to run JMeter because of JRE implementation issues. Java 1.3 does not include SSL (HTTPS) support - you'll need to download JSSE. Also, it does not perform as well as later Java versions. Use the latest version of Java 1.4 or 1.5 for best results 2.1.2 Operating Systems JMeter is a 100% Java application and should run correctly on any system that has a compliant Java implementation. JMeter has been tested and works under: Unix (Solaris, Linux, etc) Windows (98, NT, 2000, XP) OpenVMS Alpha 7.3+

2.2 Optional

If you plan on doing JMeter development or want to use Sun's Java Standard Extension packages, then you will need one or more optional packages listed below. 2.2.1 Java Compiler If you want to build the JMeter source or develop JMeter plugins, then you will need a fully compliant JDK 1.3 or higher. 2.2.2 SAX XML Parser JMeter comes with Apache's Xerces XML parser . You have the option of telling JMeter to use a different XML parser. To do so, include the classes for the third-party parser in JMeter's classpath , and update the jmeter.properties file with the full classname of the parser implementation. 2.2.3 Email Support JMeter has limited Email capabilities. It can send email based on test results, and has a POP/IMAP sampler. It does not currently support SMTP sampling. To enable Email support, add Sun's JavaMail packages and the activation packages to JMeter's classpath . 2.2.4 SSL Encryption To test a web server using SSL encryption (HTTPS), JMeter requires that an implementation of SSL be provided (such as Sun's Java Secure Sockets Extension -- JSSE ). Include the necessary encryption packages in JMeter's classpath . Also, update jmeter.properties by registering the SSL Provider. There is also the SSL Manager , for greater control of certificates. Note: if you are running JDK1.4, then you do not have to download JSSE because Sun integrated it into JDK1.4 as a standard library. The JMeter proxy server (see below) does not support recording SSL (https). 2.2.5 JDBC Driver You will need to add your database vendor's JDBC driver to the classpath if you want to do JDBC testing. Make sure the file is a jar file, not a zip. 2.2.6 Apache SOAP Apache SOAP requires mail.jar and activation.jar. You need to download and copy these two jar files to your jmeter/lib directory. Once the files are in there, JMeter will automatically pick them up. See the JMeter Classpath section for details on installing additional jars.

2.3 Installation

Installing JMeter is a snap. Specifics depend on which release file you downloaded. Note: avoid installing JMeter in a path with spaces in the name. This causes problems for remote testing. 2.3.1 Downloading the Latest Release We recommend that most users run the latest release . To install a release build, simply unzip the zip/tar file into the directory where you want JMeter to be installed. Provided that you have a JRE/JDK correctly installed and the JAVA_HOME environment variable set, there is nothing more for you to do. 2.3.2 Downloading Nightly Builds If you do not mind working with beta-quality software, then you can download and run the latest nightly build . To install a nightly build, unzip the _bin and _lib zip/tar files into the same directory structure. Provided that you have a JRE/JDK correctly installed and the JAVA_HOME environment variable set, JMeter should be installed successfully.

2.4 Running JMeter

To run JMeter, run the jmeter.bat (for Windows) or jmeter (for Unix) file. JMeter must be started from the JMeter bin directory (where those files are found). The jmeter.bat file attempts to change to the appropriate directory if it can. 2.4.1 JMeter's Classpath JMeter automatically finds classes from jars in its /lib and /lib/ext directories. If you have developed new JMeter components, then you should jar them and copy the jar into JMeter's /lib/ext directory. JMeter will automatically find JMeter components in any jars found here. If you don't want to put the extension jars in the lib/ext directory, then define the property search_paths in jmeter.properties. Do not use lib/ext for utility jars; it is only intended for JMeter components. Other jars (such as JDBC, and any support libaries needed by the JMeter code) should be placed in the lib directory. Note: JMeter will only find .jar files, not .zip. You can also install utility Jar files in $JAVA_HOME/jre/lib/ext, or (since 2.1.1) you can set the property user.classpath in jmeter.properties Note that setting the CLASSPATH environment variable will have no effect. This is because JMeter is started with "java -jar", and the java command silently ignores the CLASSPATH variable, and the -classpath/-cp options when -jar is used. [This occurs with all Java programs, not just JMeter.] 2.4.2 Using a Proxy Server If you are testing from behind a firewall/proxy server, you may need to provide JMeter with the firewall/proxy server hostname and port number. To do so, run the jmeter.bat/jmeter file from a command line with the following parameters: -H [proxy server hostname or ip address] -P [proxy server port] -N [nonproxy hosts] (e.g. *.apache.org|localhost) -u [username for proxy authentication - if required] -a [password for proxy authentication - if required] Example : jmeter -H my.proxy.server -P 8000 -u username -a password -N localhost Alternatively, you can use --proxyHost, --proxyPort, --username, and --password JMeter also has its own in-built HTTP Proxy Server , which can be used for recording HTTP (but not HTTPS) browser sessions. This is not to be confused with the proxy settings described above, which are used when JMeter makes HTTP or HTTPS requests itself. 2.4.3 Non-GUI Mode (Command Line mode) For non-interactive testing, you may choose to run JMeter without the GUI. To do so, use the following command options -n This specifies JMeter is to run in non-gui mode -t [name of JMX file that contains the Test Plan]. -l [name of JTL file to log sample results to]. -r Run all remote servers specified in jmeter.properties (or remote servers specified on command line by overriding properties) The script also lets you specify the optional firewall/proxy server information: -H [proxy server hostname or ip address] -P [proxy server port] Example : jmeter -n -t my_test.jmx -l log.jtl -H my.proxy.server -P 8000 2.4.4 Server Mode For distributed testing , run JMeter in server mode, and then control each server from the GUI. The jmeter-server/jmeter-server.bat script should start rmiregistry for you with the appropriate classpath. if it fails to do so, read the details about starting the jmeter server. Run jmeter-server/jmeter-server.bat, plus these optional commands: The script also lets you specify the optional firewall/proxy server information: -H [proxy server hostname or ip address] -P [proxy server port] Example : jmeter-server -H my.proxy.server -P 8000 2.4.5 Overriding Properties Via The Command Line Java system properties, JMeter properties, and logging properties can be overriden directly on the command line (instead of modifying jmeter.properties). To do so, use the following options: -D[prop_name]=[value] - defines a java system property value. -J[prop name]=[value] - overrides a JMeter property. -L[category]=[priority] - overrides a logging setting, setting a particular category to the given priority level. The -L flag can also be used without the category name to set the root logging level. Examples : jmeter -Duser.dir=/home/mstover/jmeter_stuff \ -Jremote_hosts=127.0.0.1 -Ljmeter.engine=DEBUG jmeter -LDEBUG N.B. The command line properties are processed early in startup, but after the logging system has been set up. Attempts to use the -J flag to update log_level or log_file properties will have no effect. 2.4.6 Logging and error messages If JMeter detects an error, a message will be written to the log file. The log file name is defined in the jmeter.properties file. It is normally defined as jmeter.log , and will be found in the JMeter startup directory, i.e. bin. When running on Windows, the file may appear as just jmeter unless you have set Windows to show file extensions. [Which you should do anyway, to make it easier to detect viruses and other nasties that pretend to be text files...] As well as recording errors, the jmeter.log file records some information about the test run. For example: 10/17/2003 12:19:20 PM INFO - jmeter.JMeter: Version 1.9.20031002 10/17/2003 12:19:45 PM INFO - jmeter.gui.action.Load: Loading file: c:\mytestfiles\BSH.jmx 10/17/2003 12:19:52 PM INFO - jmeter.engine.StandardJMeterEngine: Running the test! 10/17/2003 12:19:52 PM INFO - jmeter.engine.StandardJMeterEngine: Starting 1 threads for group BSH. Ramp up = 1. 10/17/2003 12:19:52 PM INFO - jmeter.engine.StandardJMeterEngine: Continue on error 10/17/2003 12:19:52 PM INFO - jmeter.threads.JMeterThread: Thread BSH1-1 started 10/17/2003 12:19:52 PM INFO - jmeter.threads.JMeterThread: Thread BSH1-1 is done 10/17/2003 12:19:52 PM INFO - jmeter.engine.StandardJMeterEngine: Test has ended The log file can be helpful in determining the cause of an error, as JMeter does not interrupt a test to display an error dialogue. 2.4.7 Full list of command-line options Invoking JMeter as "jmeter -?" will print a list of all the command-line options. These are shown below. -h, --help print usage information and exit -v, --version print the version information and exit -p, --propfile {argument} the jmeter property file to use -q, --addprop {argument} additional property file(s) -t, --testfile {argument} the jmeter test(.jmx) file to run -l, --logfile {argument} the file to log samples to -n, --nongui run JMeter in nongui mode -s, --server run the JMeter server -H, --proxyHost {argument} Set a proxy server for JMeter to use -P, --proxyPort {argument} Set proxy server port for JMeter to use -u, --username {argument} Set username for proxy server that JMeter is to use -a, --password {argument} Set password for proxy server that JMeter is to use -J, --jmeterproperty {argument}={value} Define additional JMeter properties -D, --systemproperty {argument}={value} Define additional System properties -S, --systemPropertyFile {filename} a property file to be added as System properties -L, --loglevel {argument}={value} Define loglevel: [category=]level e.g. jorphan=INFO or jmeter.util=DEBUG -r, --runremote Start remote servers from non-gui mode -d, --homedir {argument} the jmeter home directory to use

2.5 Configuring JMeter

If you wish to modify the properties with which JMeter runs you need to either modify the jmeter.properties in the /bin directory or create your own copy of the jmeter.properties and specify it in the command line. Note: since 2.1.2, you can define additional JMeter properties in the file defined by the JMeter property user.properties which has the default value user.properties . The file will be automatically loaded if it is found in the current directory. Similarly, system.properties is used to update system properties. Parameters Attribute Description Required ssl.provider You can specify the class for your SSL implementation. If you are using the JSSE from sun, then it is: com.sun.net.ssl.internal.ssl.Provider. JMeter, by default, should provide https support is you are using JDK1.4 or if you use JDK1.3 with the JSSE class jars in your JMeter classpath. No xml.parser You can specify an implementation as your XML parser. The default value is: org.apache.xerces.parsers.SAXParser No remote_hosts Comma-delimited list of remote JMeter hosts. If you are running JMeter in a distributed environment, list the machines where you have JMeter remote servers running. This will allow you to control those servers from this machine's GUI No not_in_menu A list of components you do not want to see in JMeter's menus. As JMeter has more and more components added, you may wish to customize your JMeter to show only those components you are interested in. You may list their classname or their class label (the string that appears in JMeter's UI) here, and they will no longer appear in the menus. No search_paths List of paths (separated by ;) that JMeter will search for JMeter add-on classes; for example additional samplers. This is in addition to any jars found in the lib/ext directory. No user.classpath List of paths that JMeter will search for utility classes. This is in addition to any jars found in the lib directory. No user.properties Name of file containing additional JMeter properties. These are added after the initial property file, but before the -q and -J options are processed. No system.properties Name of file containing additional system properties. These are added before the -S and -D options are processed. No See also the comments in the jmeter.properties file for further information on other settings you can change.

3. Building a Test Plan

A test plan describes a series of steps JMeter will execute when run. A complete test plan will consiste of one or more Thread Groups, logic conrollers, sample generating controllers, listeners, timers, assertions, and configuration elements. 3.1 Adding and Removing Elements Adding elements to a test plan can be done by right-clicking on an element in the tree, and choosing a new element from the "add" list. Alternatively, elements can be loaded from file and added by choosing the "open" option. To remove an element, make sure the element is selected, right-click on the element, and choose the "remove" option. 3.2 Loading and Saving Elements To load an element from file, right click on the existing tree element to which you want to add the loaded element, and select the "open" option. Choose the file where your elements are saved. JMeter will load the elements into the tree. To save tree elements, right click on an element and choose the "save" option. JMeter will save the element selected, plus all child elements beneath it. In this way, you can save test tree fragments, individual elements, or the entire test plan. 3.3 Configuring Tree Elements Any element in the test tree will present controls in JMeter's right-hand frame. These controls allow you to configure the behavior of that particular test element. What can be configured for an element depends on what type of element it is. The Test Tree itself can be manipulated by dragging and dropping components around the test tree. 3.4 Running a Test Plan To run your test plan, choose "start" from the "run" menu item. To stop your test plan, choose "stop" from the same menu. JMeter does not automatically give any indication of whether it is currently running. Some listeners make it obvious if JMeter is running, but the only way to be sure is to check the "run" menu. If "start" is disabled, and "stop" is enabled, JMeter is running your test plan (or, at least, it thinks it is). 3.5 Scoping Rules The JMeter test tree contains elements that are both hierarchical and ordered. Some elements in the test trees are strictly hierarchical (Listeners, Config Elements, Post-Procesors, Pre-Processors, Assertions, Timers), and some are primarily ordered (controllers, samplers). When you create your test plan, you will create an ordered list of sample request (via Samplers) that represent a set of steps to be executed. These requests are often organized within controllers that are also ordered. Given the following test tree: Example test tree The order of requests will be, One, Two, Three, Four. Some controllers affect the order of their subelements, and you can read about these specific controllers in the component reference . Other elements are hierarchical. An Assertion, for instance, is hierarchical in the test tree. If its parent is a request, then it is applied to that request. If its parent is a Controller, then it affects all requests that are descendants of that Controller. In the following test tree: Hierarchy example Assertion #1 is applied only to Request One, while Assertion #2 is applied to Requests Two and Three. Another example, this time using Timers: complex example In this example, the requests are named to reflect the order in which they will be executed. Timer #1 will apply to Requests Two, Three, and Four (notice how order is irrelevant for hierarchical elements). Assertion #1 will apply only to Request Three. Timer #2 will affect all the requests. Hopefully these examples make it clear how configuration (hierarchical) elements are applied. If you imagine each Request being passed up the tree branches, to its parent, then to its parent's parent, etc, and each time collecting all the configuration elements of that parent, then you will see how it works. The Configuration elements Header Manager, Cookie Manager and Authorization manager are treated differently from the Configuration Default elements. The settings from the Configuration Default elements are merged into a set of values that the Sampler has access to. However, the settings from the Managers are not merged. If more than one Manager is in the scope of a Sampler, only one Manager is used, but there is currently no way to specify which is used.

4. Elements of a Test Plan

The Test Plan object has a new checkbox to select called "Functional Testing". If selected, it will cause JMeter to record the data returned from the server for each sample. If you have selected a file in your test listeners, this data will be written to file. This can be useful if you are doing a small run to ensure that JMeter is configured correctly, and that your server is returning the expected results. The consequence is that the file will grow huge quickly, and JMeter's performance will suffer. This option should be off if you are doing stress-testing (it is off by default). If you are not recording the data to file, this option makes no difference. 4.1 ThreadGroup Thread group elements are the beginning points of any test plan. All elements of a test plan must be under a thread group. As the name implies, the thread group element controls the number of threads JMeter will use to execute your test. The controls for a thread group allow you to: Set the number of threads Set the ramp-up period Set the number of times to execute the test Each thread will execute the test plan in its entirety and completely independently of other test threads. Multiple threads are used to simulate concurrent connections to your server application. The ramp-up period tells JMeter how long to take to "ramp-up" to the full number of threads chosen. If 10 threads are used, and the ramp-up period is 100 seconds, then JMeter will take 100 seconds to get all 10 threads up and running. Each thread will start 10 (100/10) seconds after the previous thread was begun. If there are 30 threads and a ramp-up period of 120 seconds, then each successive thread will be delayed by 4 seconds. Ramp-up needs to be long enough to avoid too large a work-load at the start of a test, and short enough that the last threads start running before the first ones finish (unless one wants that to happen). Start with Ramp-up = number of threads and adjust as needed. By default, the thread group is configured to loop once through its elements. Version 1.9 introduces a test run scheduler . Click the checkbox at the bottom of the Thread Group panel to reveal extra fields in which you can enter the start and end times of the run. When the test is started, JMeter will wait if necessary until the start-time has been reached. At the end of each cycle, JMeter checks if the end-time has been reached, and if so, the run is stopped, otherwise the test is allowed to continue until the iteration limit is reached. Alternatively, one can use the relative delay and duration fields. Note that delay overrides start-time, and duration over-rides end-time. 4.2 Controllers JMeter has two types of Controllers: Samplers and Logical Controllers. Samplers tell JMeter to send requests to a server. For example, add an HTTP Request Sampler if you want JMeter to send an HTTP request. You can also customize a request by adding one or more Configuration Elements to a Sampler. For more information, see Samplers . Logical Controllers let you customize the logic that JMeter uses to decide when to send requests. For example, you can add an Interleave Logic Controller to alternate between two HTTP Request Samplers. For more information, see Logical Controllers . 4.2.1 Samplers Samplers tell JMeter to send requests to a server. JMeter samplers include: FTP Request HTTP Request JDBC Request Java object request LDAP Request SOAP/XML-RPC Request WebService (SOAP) Request Each sampler has several properties you can set. You can further customize a sampler by adding one or more Configuration Elements to it. Note that JMeter sends requests in the order that the samplers appear in the tree. If you are going to send multiple requests of the same type (for example, HTTP Request) to the same server, consider using a Defaults Configuration Element. Each controller has one or more Defaults elements (see below). Remember to add a Listener to your Thread Group to view and/or store the results of your requests to disk. If you are interested in having JMeter perform basic validation on the response of your request, add an Assertion to the Request controller. For example, in stress testing a web application, the server may return a successful "HTTP Response" code, but the page may have errors on it or may be missing sections. You could add assertions to check for certain HTML tags, common error strings, and so on. JMeter lets you create these assertions using regular expressions. JMeter's built-in samplers 4.2.2 Logic Controllers Logic Controllers let you customize the logic that JMeter uses to decide when to send requests. Logic Controllers may have as child elements any of the following: Samplers (requests), Configuration Elements, and other Logic Controllers. Logic Controllers can change the order of requests coming from their child elements. They can modify the requests themselves, cause JMeter to repeat requests, etc. To understand the effect of Logic Controllers on a test plan, consider the following test tree: Test Plan Thread Group Once Only Controller Login Request (an HTTP Request ) Load Search Page (HTTP Sampler) Interleave Controller Search "A" (HTTP Sampler) Search "B" (HTTP Sampler) HTTP default request (Configuration Element) HTTP default request (Configuration Element) Cookie Manager (Configuration Element) The first thing about this test is that the login request will be executed only the first time through. Subsequent iterations will skip it. This is due to the effects of the Once Only Controller . After the login, the next Sampler loads the search page (imagine a web application where the user logs in, and then goes to a search page to do a search). This is just a simple request, not filtered through any Logic Controller. After loading the search page, we want to do a search. Actually, we want to do two different searches. However, we want to re-load the search page itself between each search. We could do this by having 4 simple HTTP request elements (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 doesn'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. Note the HTTP Request Defaults that belongs to the Interleave Controller. Imagine that "Search A" and "Search B" share the same PATH info (an HTTP request specification includes domain, port, method, protocol, path, and arguments, plus other optional items). This makes sense - both are search requests, hitting the same back-end search engine (a servlet or cgi-script, let's say). Rather than configure both HTTP Samplers with the same information in their PATH field, we can abstract that information out to a single Configuration Element. When the Interleave Controller "passes on" requests from "Search A" or "Search B", it will fill in the blanks with values from the HTTP default request Configuration Element. So, we leave the PATH field blank for those requests, and put that information into the Configuration Element. In this case, this is a minor benefit at best, but it demonstrates the feature. The next element in the tree is another HTTP default request, this time added to the Thread Group itself. The Thread Group has a built-in Logic Controller, and thus, it uses this Configuration Element exactly as described above. It fills in the blanks of any Request that passes through. It is extremely useful in web testing to leave the DOMAIN field blank in all your HTTP Sampler elements, and instead, put that information into an HTTP default request element, added to the Thread Group. By doing so, you can test your application on a different server simply by changing one field in your Test Plan. Otherwise, you'd have to edit each and every Sampler. The last element is a HTTP Cookie Manager . A Cookie Manager should be added to all web tests - otherwise JMeter will ignore cookies. By adding it at the Thread Group level, we ensure that all HTTP requests will share the same cookies. Logic Controllers can be combined to achieve various results. See the list of built-in Logic Controllers . 4.3 Listeners Listeners provide access to the information JMeter gathers about the test cases while JMeter runs. The Graph Results listener plots the response times on a graph. The "View Results Tree" Listener shows details of sampler requests and responses, and can display basic HTML and XML representations of the response. Other listeners provide summary or aggregation information. Additionally, listeners can direct the data they collect to a file for later use. Every listener in JMeter provides a field to indicate the file to store data to. Listeners can be added anywhere in the test. They will collect data only from elements at or below their level. There are several interesting listeners that come with JMeter. 4.4 Timers By default, a JMeter thread sends requests without pausing between each request. We recommend that you specify a delay by adding one of the available timers to your Thread Group. If you do not add a delay, JMeter could overwhelm your server by making too many requests in a very short amount of time. The timer will cause JMeter to delay a certain amount of time between each request that a thread makes. If you choose to add more than one timer to a Thread Group, JMeter takes the sum of the timers and pauses for that amount of time before executing the samplers to which they apply. 4.5 Assertions Assertions allow you to assert facts about responses received from the server being tested. Using an assertion, you can essentially "test" that your application is returning the results you expect it to. For instance, you can assert that the response to a query will contain some particular text. The text you specify can be a Perl-style regular expression, and you can indicate that the response is to contain the text, or that it should match the whole response. You can add an assertion to any Sampler. For example, you can add an assertion to a HTTP Request that checks for the text, "</HTML>". JMeter will then check that the text is present in the HTTP response. If JMeter cannot find the text, then it will mark this as a failed request. To view the assertion results, add an Assertion Listener to the Thread Group. 4.6 Configuration Elements A configuration element works closely with a Sampler. Although it does not send requests (except for HTTP Proxy Server ), it can add to or modify requests. A configuration element is accessible from only inside the tree branch where you place the element. For example, if you place an HTTP Cookie Manager inside a Simple Logic Controller, the Cookie Manager will only be accessible to HTTP Request Controllers you place inside the Simple Logic Controller (see figure 1). The Cookie Manager is accessible to the HTTP requests "Web Page 1" and "Web Page 2", but not "Web Page 3". Also, a configuration element inside a tree branch has higher precedence than the same element in a "parent" branch. For example, we defined two HTTP Request Defaults elements, "Web Defaults 1" and "Web Defaults 2". Since we placed "Web Defaults 1" inside a Loop Controller, only "Web Page 2" can access it. The other HTTP requests will use "Web Defaults 2", since we placed it in the Thread Group (the "parent" of all other branches). Figure 1 - Test Plan Showing Accessability of Configuration Elements 4.7 Pre-Processor Elements A Pre-Processor executes some action prior to a Sampler Request being made. If a Pre-Processor is attached to a Sampler element, then it will execute just prior to that sampler element running. A Pre-Processor is most often used to modify the settings of a Sample Request just before it runs, or to update variables that aren't extracted from response text. See the scoping rules for more details on when Pre-Processors are executed. 4.8 Post-Processor Elements A Post-Processor executes some action after a Sampler Request has been made. If a Post-Processor is attached to a Sampler element, then it will execute just after that sampler element runs. A Post-Processor is most often used to process the response data, often to extract values from it. See the scoping rules for more details on when Pre-Processors are executed. 4.9 Execution order Timers - if any Sampler Post-Processors (unless SampleResult is null) Assertions (unless SampleResult is null) Listeners (unless SampleResult is null)

[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]  ... 下一页  >>