JMeter Quick Reference Guide



JMeter Quick Reference Guide[Type the document subtitle]Contents TOC \o "1-3" \h \z \u Introduction PAGEREF _Toc390336166 \h 3JMeter Script structure PAGEREF _Toc390336167 \h 3Test Plan PAGEREF _Toc390336168 \h 4Thread Group PAGEREF _Toc390336169 \h 4Samplers PAGEREF _Toc390336170 \h 4Config Elements PAGEREF _Toc390336171 \h 4Controllers PAGEREF _Toc390336172 \h 4Assertions PAGEREF _Toc390336173 \h 4Post Processors PAGEREF _Toc390336174 \h 4Timers PAGEREF _Toc390336175 \h 5Listeners PAGEREF _Toc390336176 \h 5Script Recording PAGEREF _Toc390336177 \h 5Script customizations PAGEREF _Toc390336178 \h 111.Parameterization PAGEREF _Toc390336179 \h 112.Correlation PAGEREF _Toc390336180 \h 113.Page Verification PAGEREF _Toc390336181 \h 124.Transactions PAGEREF _Toc390336182 \h 125.Think times PAGEREF _Toc390336183 \h 12Samplers PAGEREF _Toc390336184 \h 12HTTP Request PAGEREF _Toc390336185 \h 12BSF Sampler PAGEREF _Toc390336186 \h 14Debug Sampler PAGEREF _Toc390336187 \h 16Config Elements PAGEREF _Toc390336188 \h 17Http Header Manager PAGEREF _Toc390336189 \h 17HTTP Cookie Manager PAGEREF _Toc390336190 \h 18HTTP Cache Manager PAGEREF _Toc390336191 \h 20HTTP Authorization Manager PAGEREF _Toc390336192 \h 20User Defined Variables PAGEREF _Toc390336193 \h 22CSV Dataset Config PAGEREF _Toc390336194 \h 22Logical Controllers PAGEREF _Toc390336195 \h 26Transaction Controller PAGEREF _Toc390336196 \h 26If Controller PAGEREF _Toc390336197 \h 26While Controller PAGEREF _Toc390336198 \h 27Timers PAGEREF _Toc390336199 \h 28Constant Timer PAGEREF _Toc390336200 \h 28Constant Throughput Timer PAGEREF _Toc390336201 \h 29Gaussian Random Timer PAGEREF _Toc390336202 \h 30Pre Processors PAGEREF _Toc390336203 \h 30User Parameters PAGEREF _Toc390336204 \h 30Post Processors PAGEREF _Toc390336205 \h 31Regular Expression Extractor PAGEREF _Toc390336206 \h 31Assertions PAGEREF _Toc390336207 \h 34Response Assertion PAGEREF _Toc390336208 \h 34Listeners PAGEREF _Toc390336209 \h 34View Results in Tree PAGEREF _Toc390336210 \h 34Aggregate Report PAGEREF _Toc390336211 \h 37View Results summary PAGEREF _Toc390336212 \h 38Summary Report PAGEREF _Toc390336213 \h 38Running Performance Test PAGEREF _Toc390336214 \h 40Load Generator configuration PAGEREF _Toc390336215 \h 40Conclusion PAGEREF _Toc390336216 \h 40IntroductionJMeter is an open source performance testing tool developed by Apache. The latest version of JMeter can be downloaded from the URL: . Automation of the user activities in JMeter is UI driven and hence no scripting language / Framework / IDE are needed to start with. However, Individuals with Java development knowledge will have an added advantage of extending the standard JMeter. This document is helpful in recording a JMeter script for Web Applications, understanding the existing JMeter scripts, execute the scripts and debug if needed. The target audience for this document is the individuals with Development background / Automation background who meet the below requirementsRequirementsKnowledge of Performance Testing conceptsBasic understanding of Web Applications, browser features, HTTP(S) communicationBasic Idea on XML (to read the JMX script using an editor), Java ScriptJMeter Script structureFrom the above diagram, it is clear that Listeners and Config elements can be configured at any level, thus defining the scope for them. If the listeners are defined at the Sampler level, they work only for that sampler. If they are defined at the thread group level, they can work with all the samplers under the thread group. If they are defined at the Test Plan level, they are applicable to all the thread groups and all the samplers under the thread groups.However, this works a little different for the Config elements. Each of the config elements have their own scope which would be explained in detail at the Config Elements section.Test PlanA test plan contains the overall settings of the performance test. A test plan can have multiple Config elements, listeners and Thread Groups. The test plan can control the execution (parallel or sequential) of thread groups and can also be used to save the responses. Thread GroupA thread group is where the number of threads (users), ramp-up rate and the start times of the thread group are defined. All the items under a thread group are executed by multiple threads/users. A thread group can have multiple samplers, config elements, controllers etc.SamplersThese are the actual requests made from the JMeter tool. These samplers can be a HTTP Request, Web Service request or JDBC request or can be even a java request. For performance testing the web applications using JMeter, each thread group will have several HTTP requests which will be executed by multiple threads concurrently and thus causing the load on the web applicationConfig ElementsConfig elements are the ones to needed / can be configured the way the samplers /thread groups / test plan are executed. The most commonly used HTTP config elements are HTTP Cookie Manager, HTTP Cache manager, HTTP Auth Manager. Similarly to run a JDBC sampler, the JDBC config element has to be specified.ControllersControllers are used to control the flow of a thread through the thread group. All the conditions like If, for, while etc. are the examples of ControllersAssertionsAssertions are to validate the response that is received when a request (a sampler is executed) is made to the application. The assertions can be text assertions, XML assertions, XpathetcPost ProcessorsPost processors are used to perform actions once a response is received for a particular sampler request. The most commonly used post processor is the regular expression extractorTimersTimers are used to delay the execution of the thread or to make the thread wait for the specified time. The commonly used timers are constant timer, Gaussian random timer etcListeners Listeners are the reporting entity of JMeter which can be configured at the sampler / thread group /test plan level. The most commonly used listeners are View results tree, View results summary and aggregate report.Script RecordingScript recording in JMeter can be done by sniffing all the communication that is happening on a proxy. Below are the steps involved in recording a sample web application. Launch JMeter from the bin folder by clicking on JMeter.batAdd a thread group to the test plan. Right click on Test plan Add threads thread GroupAdd Http(s) script recorder to workbench. Right click on Work Bench Add Non-Test Elements HTTP(S) Test Script RecorderConfigure HTTP(S) Test Script Recorder. Specify the proxy port (8080 is default). Choose Target Controller as Test Plan > Thread Group and Grouping as “Put each group in a new transaction controller”, click on Add suggested ExcludesClick on Start. Click OK on the pop-up. Now JMeter is configured to listen to all the communication happening on port 8080.Launch your browser and go to network settings and configure the browser to run on proxy. In IE, the navigation is: Tools Internet options connections LAN Settings Use a proxy server for your LAN. Below is the screenshot:In case of Firefox, the navigation is Tools Options Advanced Network Settings Manual Proxy configuration. Screenshot is as below:Launch the application in the browser which is running on the proxy. Under thread group a new transaction controller should be created as seen below:Click on Transaction controller and change the Name of the transaction to make more meaningful.Perform the next user action and rename the transaction controller name. If you see more than one transaction controller being recorded for the same user action, move all the requests under the transaction controller to one and rename the controller.Repeat this for the complete navigation to be automated. Once the complete navigation is recorded, go to HTTP(S) Test Script Recorder and click on Stop Button.Save the JMeter script. The script would be save as a JMX file and can be viewed in any editor as an XML file. When loaded in JMeter, the script is seen as UI controls. Each element of the JMeter script is explained in detail in the coming sections.Note: Ensure to change the browser settings to normal.Script customizationsOnce a JMeter script is recorded, it cannot be played back or it cannot be used directly for the performance test. Any Performance test script should be customized to implement the below to simulate the realistic user behavior on the application:Parameterization – To send different user inputs to the script. This is to simulate the real user inputs like the user name and passwords, search criteria, billing and shipping address etc. In JMeter, the most common way of implementing parameterization is through CSV data set config, which is a part of Config Elements. CSV Data Set Config is used to read the values from a CSV file and store the values into JMeter variables.Correlation – Handling the dynamic data in the user request. This is to simulate the real user behavior of user selections either check boxes, radio buttons or dropdown picks etc. Correlations involve in identifying the dynamic data of a request and capture the dynamic data from the any of the previous responses and pass on to the current request. Regular Expression extractor which is a part of Post processors is used for correlation. Page Verification: This is to ensure that the correct response is received during the performance tests. A text which is static, specific to that request would be searched. If the text is not found, the tool assumes that the response received is not a valid response. Response Assertion which is a part of Assertions is commonly used for Page verification with the Web based applicationsTransactions: The objective of this customization is to measure the response time for each user action. An user action can contain more than one request and to measure the end user experience all the such requests which belong to one user action are clubbed together in JMeter as Transaction Controller, which provides the overall response time of the all the requestsThink times: To simulate the real user wait times between the requests (to enter the inputs / think / reading the content), think times should be included in the scripts. In JMeter, Timers are used to wait between the user requests.SamplersHTTP RequestHttp Request belongs to the Sampler category. The core of a Web based JMeter script is the HTTP Requests. An Http request (HTTP Sampler) in JMeter looks as below:The most important attributes in a HTTP request are:Server Name or IP: Host name or URL of the applicationAttribute NameDescriptionExample(s)Server Name or IPThe URL of the application being tested. This should only include the name/IP address. Should not contain the protocol, port etcIcint172.16.10.Icsta.Port NumberPort on which the application is running. If the protocol is http, it runs on port 80 by default and if the protocol is https, the default port is 443. Default ports need not be mentioned8080900190301080ProtocolThe protocol the application uses.HTTP/HTTPSMethodThe HTTP Method that is used to send the request to the server. The request can be sent to the server using HTTP request methods like GET, POST, PUT, DELETEPathThe relative path of the user request/hcas/Authentication/searchParameters/Body DataThe form data that is sent to the server as part of the request. If it is parameters, the data would be sent as key and value pairs. If it is body data the looks like a query string.For parameters:Name: UsernameValue: QaTestUser_00965Name: PasswordValue: testP@55The same would be seen as below if it is body data:Username=QaTestUser_00965&Password=testp@55EncodeThe data in the parameter will be URL encoded if this is checkedFor example of password field is checked for encode it would be seen as testP%4055 where %40 is the URL encoded form of the character “@”.Use keep Alive enables to keep the connection open after serving the response. This is used to simulate the persistent connections in HTTP1.1.BSF SamplerThis sampler allows you to execute a piece of code written in any BSF scripting language. By default JMeter supports the below languages in a BSF sampler:Java ScriptJexlXsltBelow is the screenshot of this sampler.We would need to select the language type from the dropdown. In the above example, JavaScript has been selected.Attributes:Below are the important attributes of a BSF samplerAttributeDescriptionExampleScripting LanguageName of the BSF scripting language to be used. Not all the languages in the drop-down list are supported by default. The following are supported: jexl, javascript, xslt. Others may be available if the appropriate jar is installed in the JMeter lib directory.Java scriptJexlXsltPythonScript FileName of a file to be used as a BSF script with the full path. if a relative file path is used, then it will be relative to directory referenced by "user.dir" System propertyC:\users\testacct\desktop\sample.jsParametersList of parameters to be passed to the script file or the script.ScriptThe script can be directly written in this section if the file name is not specified. If the file name is specified, only that part would be executed and the code written here would be ignored.Refer to the screenshotDebug SamplerThe Debug sampler is used to debug the script, especially to ensure all the JMeter variables has got the right data in them. This is added during the debug phase of the script and should be deleted / disabled while executing the performance test. The Debug Sampler can be configured to control the list of things to be displayed response data Pane in the View Results tree listener. Usually the JMeter Variables is the only one set to true with the debug sampler.Below are the attributes that are given to a Debug SamplerAttributes:AttributeDescriptionExampleNameDescriptive name for this element that is shown in the tree.NoJMeter PropertiesIf this is set to yes, all the JMeter properties would be displayed in the Response pane of View results tree listenerTrue/FalseJMeter VariablesTo display the JMeter variables and their values in the response pane of view results tree listenerTrue/FalseSystem PropertiesTo display the system propertiesTrue/FalseConfig ElementsHttp Header ManagerAn important aspect of a HTTP Request is the headers. The headers in a JMeter script are recorded as below:Usually the header management is taken care by the performance tools automatically. However, if the application has some customized headers, those have to be handled in the request explicitly.HTTP Header Manager is always added as a child to HTTP Request sampler. The scope of Http Header Manager is usually at the sampler level because each request can have different request headers. If most of the request headers are the same for all the Http requests, this can be defined at the thread group level so that it is applied for all the Http request samplers. The additional headers can be added through another Http Header manager at the sampler level. For example the below screenshot highlights the way additional headers are added.The default headers are added at the thread group level and the additional headers are added at the sampler level.When the request is executed, the View results tree listener’s Request pane shows that all the seven (7) headers are sent as part of the request. Please find below the screenshot: HTTP Cookie ManagerThe Cookie Manager element has two functions: Store and send the cookies similar to that of a web browser - If you have an HTTP Request and the response contains a cookie, the Cookie Manager automatically stores that cookie and will use it for all future requests to that particular web site. Each JMeter thread has its own "cookie storage area". So, if you are testing a web site that uses a cookie for storing session information, each JMeter thread will have its own session. Note that such cookies do not appear on the Cookie Manager display, but they can be seen using the View Results Tree Listener.Manually add a cookie to the Cookie Manager - However, if you do this, the cookie will be shared by all JMeter threads.Usually Http Cookie Manager is added at the thread group level. Attributes:AttributeDescriptionRequiredNameDescriptive name for this element that is shown in the tree.NoClear Cookies each IterationIf selected, all server-defined cookies are cleared each time the main Thread Group loop is executed. YesCookie PolicyThe cookie policy that will be used to manage the cookies. "Compatibility" is the default, and should work in most cases. YesImplementationHC3CookieHandler (HttpClient 3.1 API) or HC4CookieHandler (HttpClient 4 API). Default is HC3CookieHandler.?YesUser-Defined CookiesThis section is used to add cookies manually. However these cookies are usually hard coded values. You can add / delete cookies, save them to a file and can be loaded laterNo Add ButtonAdd an entry to the cookie table.N/ADelete ButtonDelete the currently selected table entry.N/ALoad ButtonLoad a previously saved cookie table and add the entries to the existing cookie table entries.N/ASave As ButtonSave the current cookie table to a file (does not save any cookies extracted from HTTP Responses).N/AHTTP Cache ManagerThe HTTP Cache Manager is used to add caching functionality to HTTP requests within its scope. By default, Cache Manager will store up to 5000 items in cache using LRU algorithm. Use property to modify this value. The scope of the Http Cache Manager is usually at the thread group level.HTTP Authorization ManagerThe Authorization Manager used to send the login information for web pages that are restricted using server authentication. The most commonly used method is windows NTLM authentication mechanism. This type of authentication is seen when the browsers access a restricted page, a login dialog box is displayed. JMeter transmits the login information when it encounters this type of page. The scope of a Http Authorization manager is at the thread group level or at the test plan level.AttributesAttributeDescriptionRequiredNameDescriptive name for this element that is shown in the tree.NoClear auth on each iteration?Used by Kerberos authentication. If checked, authentication will be done on every iteration of Main Thread Group loop even if it has already been done in a previous one. This is helpful to simulate a new virtual user every iteration. The limitation is that, this does not work in case of Basic, Digest authentication types. The NTLM authentication uses the same auth info for all iterations.YesBase URLA partial or complete URL that matches one or more HTTP Request URLs. As an example, say you specify a Base URL of "" with a username of "user" and a password of "pass". If you send an HTTPS request to the URL " ", the Authorization Manager sends the login information for the user named, "user".YesUsernameThe username to authorize.YesPasswordThe password for the user. YesDomainThe domain to use for NTLM.NoRealmThe realm to use for NTLM.NoMechanismType of authentication to perform. JMeter can perform different types of authentications based on used Http Request Sampler Implementations: Java implemented sample can perform only Basic Authentication, whereas http client 3.1 can perform Basic and digest type of authentication and HttpClient 4 can perform Basic, Digest and Kerberos types of AuthenticationsUser Defined VariablesUser Defined Variables are like Global Variables which will be processed at the beginning of the test plan execution irrespective of their position in the test plan at the beginning / inside a thread group or inside a sampler. Hence the scope of the user defined variables is at the test plan level and the value of a Global variable cannot be another variable which is defined at a later stage of the test plan. Below are the attributes for User Defined Variables element.AttributesAttributeDescriptionRequiredNameDescriptive name for this element that is shown in the tree.NoUser Defined VariablesVariable name/value pairs. NoCSV Dataset ConfigThe most common way of achieving parameterization is reading the values from a file. In JMeter, this is achieved through CSV Data Set Config which is used to read lines from a file, and split them into variables. If a CSV dataset config is specified within a thread group, then the scope is within the thread group. Threads from other thread group cannot access the file. If the same is defined at the test plan level, then all the threads under any thread group can share the contents of the CSV/text file mentioned in the CSV dataset config. The most important aspect of a CSV Dataset config is the sharing mode of the file among the threads.AttributesAttributeDescriptionRequiredNameDescriptive name for this element that is shown in the tree.NoFilenameName of the file to be read.?YesFile EncodingThe encoding to be used to read the file, if not the platform default.NoVariable NamesList of variable names (comma-delimited). YesDelimiterDelimiter to be used to split the rows read from the file YesAllow quoted data?Should the CSV file allow values to be quoted? If enabled, then values can be enclosed in?"?- double-quote YesRecycle on EOF?Should the file be re-read from the beginning on reaching EOF? (default is true)YesStop thread on EOF?Should the thread be stopped on EOF, if Recycle is false? (default is false)YesSharing Mode:Sharing ModeNumber file instances createdAll ThreadsOne instance for the entire test plan and every thread reads a line from the file and is updated every round. The file scope is global. All the thread groups and threads read from the same file. Current thread groupOne instance created per thread group. If there are 2 thread groups 2 instances of the file is created one for each thread and the thread group reads the values from their own instance and is updated every round. The scope is local to thread group. Each thread group will have its own instance and all the threads under the thread group will read a line from the file.Current threadOne instance per thread is created. If there are total of 10 threads, then 10 instances of the file are created. The scope is local to each thread and reads a value from the file every round.Below is the pictorial representation of how the file is being read with various sharing mode options:All threads sharing modeCurrent thread group sharing modeCurrent Thread sharing modeLogical ControllersAs the name suggests, the logical controllers are used to control the execution of a JMeter script. The most commonly used controllers are listed below:Transaction ControllerThe transaction controller is used to group all the samplers that make a transaction. This is used to measure the overall response time of a transaction instead of an individual sampler. When transaction controller is added, in the summary report or Aggregate report, the transaction controller would also be seen and its response times are measured.Example: When the user enters the user name and password in a web application, internally the application may have 5 – 6 requests. However, from the end user point of view it is just logging into the application. In this case, the overall response time for these 5 – 6 requests would make more sense to the end users than the individual request’s response time. Hence, all these 5 – 6 requests are grouped using a transaction controller.AttributesAttributeDescriptionRequiredNameDescriptive name for this controller that is shown in the tree, and used to name the transaction.YesGenerate Parent SampleIf this is checked, only the transaction’s response time is displayed in the aggregate report or summary report. If this is not checked, the individual requests and transaction are logged for their response times.YesInclude duration of timer and pre-post processors in generated sampleIf this is checked, the time taken at the Timer and pre-processor and post processors requests would also be included in the transaction’s response time. Recommended is not to check this attribute.YesIf ControllerThis is similar to any other If condition in any other language. If some requests are to be made based on condition, this controller is used. The condition is usually evaluated as a java script code and based on the condition the child samplers would be executed.AttributesAttributeDescriptionRequiredNameDescriptive name for this controller that is shown in the tree.NoCondition (default Javascript)By default the condition is interpreted as?Javascript?code that returns "true" or "false", but this can be overridden (see below). Also note that, if the JMeter variables used here are the regular expression extractors, it is always recommended to evaluate them as strings. For example Count is an regular expression extractor and there has to be a condition to check if the value is equal to zero or not, the recommended condition is:“${count}”==”0” instead of ${count}==0YesInterpret Condition as Variable Expression?If this is selected, then the condition must be an expression that evaluates to "true" (case is ignored). For example,?${FOUND}?or?${__jexl(${VAR} > 100)}?. Unlike the Javascript case, the condition is only checked to see if it matches "true" (case is ignored).YesEvaluate for all childrenIf this is checked, then the If condition is executed for every child of the controller. Else, it would be checked only once.YesWhile ControllerThe While Controller runs its children until the condition is "false".Attributes:AttributeDescriptionRequiredNameDescriptive name for this controller that is shown in the tree, and used to name the transaction.YesConditionblank, LAST, or variable/functionYesTimersConstant TimerA constant Timer will introduce a fixed delay between consecutive requests of the same thread.?. This is used as Think Times between two transaction controllers to emulate real time traffic.ParametersAttributeDescriptionRequiredNameDescriptive name for this timer that is shown in the tree.NoThread DelayNumber of milliseconds to pause.YesConstant Throughput TimerConstant Throughput Timer will introduce random delays between requests in such a way that a load/stress of required throughput is sent to the application. AttributesAttributeDescriptionRequiredNameDescriptive name for this timer that is shown in the tree.NoTarget ThroughputThroughput we want the timer to try to generate.YesCalculate Throughput based onThis thread only - each thread will try to maintain the target throughput. The overall throughput will be proportional to the number of active threads.All active threads in current thread group - the target throughput is divided amongst all the active threads in the group. Each thread will delay as needed, based on when it last ran.All active threads - the target throughput is divided amongst all the active threads in all Thread Groups. Each thread will delay as needed, based on when it last ran. In this case, each other Thread Group will need a Constant Throughput timer with the same settings.All active threads in current thread group (shared) - as above, but each thread is delayed based on when any thread in the group last ran.All active threads (shared) - as above; each thread is delayed based on when any thread last ran.YesGaussian Random TimerA Uniform Random Timer will delay consecutive requests of the same thread by a random interval within lower and upper bounds.?The random interval follows a Gaussian curve distribution. In the example below the thread waits between 300ms to 400ms, with a variation to the value which follows a Gaussian curve.AttributeDescriptionRequiredNameDescriptive name for this timer that is shown in the treeNoDeviationDeviation in milliseconds.YesConstant Delay OffsetNumber of milliseconds to pause in addition to the random delay.YesPre ProcessorsUser ParametersUser parameters work exactly the same way as user defined variables, except that they are executed only at their designated position. All the user defined variables are executed at the beginning of the test plan and hence no JMeter variables that are captured or created during the execution cannot be used in User defined variables. User Parameters are helpful to serve this purpose. The JMeter variables created or captured before user parameters can be used in the user parameters. Below is the screenshot of a simple user parameter:Below are the attributes of user parameters:AttributeDescriptionRequiredUpdate Once per IterationIf this is not set, the variable is evaluated every time it has to be used. If this is set the variable is evaluated once per Iteration per user. The most common thing is to check this field.NONameName of the variableYESUser_1Value of the variableYESThere is a provision to send different values to different threads instead of the same value. This can be achieved by clicking on Add User and corresponding value as seen below:Now in the above example, thread 1 will read the value Test1, thread 2 will read the value Test2, thread 3 will read Test 3, and thread 4 will read the value 4. If there are more threads, then thread5 will read the value Test1, thread 6 will read Test2 and so on.There is also provision to add multiple variables by click on Add Variable button.Post ProcessorsRegular Expression ExtractorRegular expression extractor is used to capture the dynamic data from the response (header or body / from the main sample or sub samples or even from another JMeter variable) and store it into a variable for future use. It allows the user to extract values from a server response using a Perl-type regular expression. As a post-processor, this element will execute after each Sample request in its scope, applying the regular expression, extracting the requested values, generate the template string, and store the result into the given variable name.Attributes:AttributeDescriptionRequiredNameDescriptive name for this element that is shown in the tree.NoReference NameThe name of the JMeter variable in which to store the result. YesRegular ExpressionThe regular expression used to parse the response data. This must contain at least one set of parentheses "()" to capture a portion of the string.YesTemplateThe template used to create a string from the matches found. This is an arbitrary string with special elements to refer to groups within the regular expression. The syntax to refer to a group is: '$1$' to refer to group 1, '$2$' to refer to group 2, etc. $0$ refers to whatever the entire expression matches.YesMatch No.Indicates which match to use. The regular expression may match multiple times.Use a value of zero to indicate JMeter should choose a random match.A positive number N means to select the nth match.YesDefault ValueIf the regular expression does not match, then the reference variable will be set to the default value. No, but recommendedExamples:Assuming the server response is as below:Regular expression Extractor and their outputs would be as below:Regular ExpressionTemplateMatch NoOutput"closeDate":"(.*?)","txnCount":(.*?),"netAmount":(.*?)},$1$12014-05-22T00:00:00"closeDate":"(.*?)","txnCount":(.*?),"netAmount":(.*?)},$2$123"closeDate":"(.*?)","txnCount":(.*?),"netAmount":(.*?)},$3$1700.10000000"closeDate":"(.*?)","txnCount":(.*?),"netAmount":(.*?)},$1$22014-05-23T00:00:00"closeDate":"(.*?)","txnCount":(.*?),"netAmount":(.*?)},$2$252"closeDate":"(.*?)","txnCount":(.*?),"netAmount":(.*?)},$3$22083.68000000"closeDate":"(.*?)","txnCount":(.*?),"netAmount":(.*?)},$1$02014-05-28T00:00:00"closeDate":"(.*?)","txnCount":(.*?),"netAmount":(.*?)},$2$036"closeDate":"(.*?)","txnCount":(.*?),"netAmount":(.*?)},$3$0826.18000000AssertionsResponse AssertionResponse Assertions are used to validate if the response received is valid or not. This can be done either by searching for the response code or searching for some static text which is specific to that request. The most commonly used response assertion is as below:ListenersListeners are the reporting entities in JMeter that gather some details from the test. Each listener serves a purpose and below is the most important listeners that are used with any JMeter tests:View Results in TreeThis listener is widely used while debugging the script for single user / multi users. This listener shows all the samplers in a tree view and every sampler has three important panes as shown below:The pane Sampler request shows the response headers, time taken to load the response and high level details of the response. If any of the samplers is failed, it would be marked in Red in the tree view.The request pane shows the request headers and body (if any) to check if the request is sent properly to the server or not:Response Data is the response received from the serverAggregate ReportThis gives the overall details about the samplers like the sampler name, the total number of times a sampler executed, response times (average, median, 90% line, min, max), error rate, throughput rate and response sizeThe aggregate report can be written to a file so that the data can be used later.The contents of an Aggregate Report are as below:Label – The Sampler Name / Transaction controller name# Samples: Number of times a sampler or transaction executedAverage/ Median / Min / Max: The corresponding response time metrics in milliseconds for the specific sampler90% line: The maximum response time for 90% of samples. This is calculated as the 90th value when the response times are sorted for a sampler which was executed 100 times.Error%: The % of the time the sampler / transaction controller failedThroughput: The total number of times the sampler executed per unit time (seconds or minutes)KB/S: The total response size received for the sampler per unit timeThe same data can be exported to a CSV file which can be used later. Configure button enables to control what has to be written to the file.View Results summaryView Results summary stores the information about every sampler, which will be helpful in analyzing a sampler’s trend. Again this data can be written to a file for future use.Summary ReportThe additional information that summary report provides the std. deviation of the response times from their average values.Other listenersAll the listeners that start with jp@gc are the graphical representation of the corresponding data. To have them listed under the listeners, all the standard plugins should be imported. They can be imported from the URL: Running Performance TestThread pool has to be configured to specify the user load, duration of the test. Once this information is verified, click on Run button to start the test. This will be running the test with the specified users for specified duration. However, to ensure that the script is running without errors, please check the log by clicking on the Warning Icon to the top right. Monitor the machine’s CPU and memory utilization during the test to figure out the maximum user load that can be generated from a single machine. Load Generator configurationJMeter supports the distributed testing where the user load can be distribute across several machines called load generators. The Load Generators should be able to communicate with the controller machine (by default JMeter listens on port 1099). Running the distributed tests involve in stepsConfigure jmeter.properties file to add the host name or IP address of the Load Generators:Start jmeter-server.bat in all the load generatorsOnce the above steps are completed, close JMeter and open again (to take the properties change reflected) and navigate to Run Remote start choose one of the LG and click. This will launch the test from the chosen load generator. The most important point to be remembered is the thread pool settings are transferred to the LG and each LG will generate the same number of threads. For example if a thread pool has 25 threads and distributed testing is in place, the final user load would be 25* number of LGs configured.ConclusionThis document is to provide a basic understanding of JMeter for Web Application automation. Considering the features provided by JMeter, this document may not be useful for other protocols like Web services, JDBC etc. To automate such protocols, the individuals should have at least the basic idea on how the corresponding protocols work. The detailed documentation would be available at the URL: ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download