Explore topic-wise InterviewSolutions in .

Variables and functions are UTILISED in JMeter, just as they are in any other programming language, to MAKE scripts reusable (since a function can be called again and again without having the need to write the same code again and again). Variables can be used to hold any value and then referenced anywhere in your code, just like any other programming language. So, with JMeter, it may be your server name, path, port number, or whatever else you want to save in a variable and utilise in multiple places afterwards.

JMeter has a number of built-in routines that can be used to test various situations. If you're accessing an application on your machine IP rather than an EXTERNAL URL, for example, you can use the machine IP function to get your IP address. JMeter's Function Dialogue may be FOUND in the settings menu, where you can examine the definition and function string.

The syntax for calling a variable and function in your script is shown below.

• Variable – {varName}.
  Here, varName denotes the name of the variable.
  Example – {name}
• Function – {_functionName}.
  Here, functionName denotes the name of the function.
  Example – {_counter()}, {_threadNum} etc.

JMETER supports a number of STANDARD protocols, including:

• Web: HTTP/HTTPs
• Web Services: SOAP / XML-RPC
• Database VIA JDBC drivers
• Directory: LDAP
• Messaging ORIENTED service via JMS
• Service: POP3, IMAP, SMTP
• FTP (File Transfer Protocol) Service

The HTTP(s) Test SCRIPT Recorder records all of your application's HTTP(s) queries to the server. It will only collect HTTP(s) requests, as the NAME implies. You can also use this recorder's grouping feature to structure your requests so that comparable requests are kept together. As needed, add URL patterns to the include and exclude lists. In order for JMeter to work, some configurations must be done there.

The following are the steps to CAPTURE HTTPS traffic: -

• HTTP(s) Test script recorder is to be added to WorkBench.
• To start the proxy server, type in the port number.
• Select "Workbench" as the target, or include a Recording CONTROLLER in the test plan and use the same target to save all recordings.
• The proxy server should now be running.
• Manually configure your browser's proxy SETTINGS to the same port number as the test script recorder.

A workbench is a STORAGE location for adding some components to the test plan if necessary. Workbench components are not immediately SAVED with the test plan. They MUST be saved as test fragments individually. The HTTP(s) Test script recorder is a key component of the Workbench, as it allows you to record HTTPS REQUESTS and then apply a load on +9859 them to ASSESS response time.

Performance testing is examining server responses in multiple formats before delivering them to the client. As a sampler component of JMeter is implemented, listeners give a graphical representation of data gathered by JMeter regarding those test cases. The user can view sampler results in the FORM of tables, graphs, TREES, or plain text in a log file.

Listeners can be changed at any point during the test, including within the test plan. JMeter provides roughly 15 listeners, but the most commonly USED ones are table, tree, and graph. In short, Listeners are used to storing the results of load testing execution in various formats, such as a table, tree, graph or any other appropriate format that may be given to the client. JMeter COMES with a variety of built-in listeners, and many more can be added through PLUGINS, depending on your needs. The following are a few of the inbuilt listeners: View Results in Table,  Graph Results, Aggregate Report, Aggregate Graph, Response Time Graph and Assertion Results.

Correlation is the process of taking values from a server response and then storing them in a VARIABLE that will be used in SUBSEQUENT requests. Correlation is the way of ACQUIRING some value from one step's response and transferring it to another step's request. It catches and saves the server's dynamic answer before passing it on to subsequent requests. When a response returns different data for each ITERATING request, it is termed dynamic, and this can sometimes affect subsequent requests. Correlation is a critical step in the performance load test SCRIPTING process since if it isn't handled properly, the script will become ineffective. One of the most fundamental components of scripting is a correlation. It retrieves dynamic data from previous requests and posts it to new requests.

For example, if you need to test any login feature and need to use the session ID or the cookie ID, you can obtain the values from the login page's GET response and use them dynamically for login in a POST request.

JMeter sends requests immediately, with no latency between samplers or requests. Your server will be overburdened if you perform load/stress testing immediately. Then it won't be able to PROVIDE you with realistic FINDINGS and won't be able to mimic real-world user traffic. JMeter Timers are the answer to all of these ISSUES. To apply a wait between each sampler/request, a timer element can be added to a test plan.

Both Gaussian and Poisson Timers are based on a mathematical FORMULA with a constant delay and offset. 

• JMeter Gaussian Random Timer is used to produce and add a random delay before executing a sampler, as the name implies. Each user request is delayed for a random period of time using the Gaussian Random Timer element. Based on the Gaussian CURVE distribution, it has a random deviation around the Constant Delay Offset. The sum of the Gaussian distributed value (with mean 0.0 and standard deviation 1.0) times the deviation value you choose and the offset value is the delay (think) time.
• JMeter Poisson Random Timer is also used to produce and add a random delay before executing a sampler. The Poisson Distribution Function is used to create this timer. The total of the Poisson distributed value multiplied by the defined lambda value and the offset value is the delay (think) time. 

It depends on your system's hardware SETUP, which includes a processor, JVM, and allotted memory -Xmx, AMONG other THINGS. The number of components in your test plan, such as the number of config items or PROCESSORS, as well as whether you are using GUI or Non-GUI Mode, have an impact on thread count.

In JMeter, assertions are used to validate the response to a request that you have given to the SERVER. The assertion is the process of comparing the expected and actual results of a request at runtime. If you want to apply assertion to a certain Sampler, make it a child of that Sampler. By adding "Assertion Listener" to the Thread Group, you can see assertion outcomes. Other listeners will be ABLE to see failed assertions as well.

Some common assertions in JMeter are:

• Response Assertion: Response Assertion is used for combining and comparing pattern strings against one or more server response values.
• Size Assertion: Size Assertion is used to check WHETHER the server response includes the expected number of bytes.
• Duration Assertion: The Duration Assertion is used to check whether or not a server response is received within a defined time limit. If the response takes longer than the specified time, the sample request will be marked as unsuccessful.
• XML Assertion: XML Assertion is used to check whether the server response DATA contains a valid XML document.
• HTML Assertion: HTML Assertion is used to ensure that the response contains proper HTML syntax and that JTidy is not being used (HTML Syntax Checker). If the HTML syntax response is incorrect, the test will FAIL.

Data parameterization allows test scripts to be reused by removing the need for hardcoding values for the same request with varied parameters. In a SINGLE test script, parameterization is the process of establishing distinct datasets for different users. For instance, in the same script, executing numerous users with different credentials. As a result, it's one of the most important components of creating performance testing.

The data parameterization provided by JMeter is listed below:

• Config of a CSV Data Set - The CSV Data Set Config READS all values from a CSV file, stores them in variables, and uses them as Test Data during execution. The "CSV Data Set Config" allows you to save unique user data such as NAMES, emails, and passwords in CSV files as an external data source. JMeter can read the CSV file line by line with the help of this config element, and then use split parameters to assign different values to separate threads.
• Variables that are defined by the user - User-defined variables (UDV) are used to define specific variables that can hold values that you need in several places. UserDefinedVariables differ from CSVDataSetConfig in that CSV can hold hundreds of thousands of values, whilst UDV is only suited for tiny data sets.

You can also specify variable/user values in UDV. This COULD be useful in instances where two users should use the same value and the next two users should use a different value. Also, if you declare a variable at the Test Plan/Thread Group level and then have the same variable with a different value inside one of two thread groups or a specific sampler. In this scenario, the local variable will override the GLOBAL variable.

JMeter's config components are USED to CUSTOMISE or change the sampler queries sent to the SERVER. These components are inserted at the same level as or higher than the samplers we want to configure. A Sampler and a configuration ELEMENT WORK in conjunction. Configuration elements can be used to set defaults and variables for subsequent usage by samplers. These elements are processed at the start of the scope before any samplers in the same scope.

The execution order of the test plan elements is -

• Configuration elements- The Configuration Element allows us to declare variables that Samplers can utilise to access data.
• Pre-processors- PreProcessors are JMeter elements that are used to perform actions prior to the execution of sampler queries in a test scenario.
• Timers- A JMeter Timer is an inbuilt JMeter plug-in that can assist you in timing out your sampler requests. MANY testers refer to this pause in requests as "think time," as it SIMULATES the time spent by real users between steps in a real-world scenario.
• Samplers- JMeter uses samplers to make several types of queries to a server. JMeter provides genuine queries to the web server under test using samplers. Except for Test ACTION, each sampler delivers one or maybe more sample results.
• Post-processors- After the sampler, a Post-Processor element is executed and can be used for the post-condition response. If a Preprocessor is included in a test plan, it will be run after the response has been received. A Post-Processor is frequently used to extract information from a response to a specific action.
• Assertions- In JMeter, assertions are used to verify the response to a request that you have given to the server. The assertion is the process of comparing the expected and actual results of a request at runtime.
• Listeners- A listener is a component that displays the sample results. The OUTPUT can be displayed in the form of a tree, tables, graphs, or simply SENT to a log file.

 In JMeter, there are two types of processors: the Pre-Processor and the Post-Processor.

• Pre-Processors run before the MAIN sampler and have the ability to CHANGE the scope of the sampler. PreProcessors are JMeter elements that are used to perform actions PRIOR to the execution of sampler requests in a test scenario. PreProcessors can be used for a variety of performance TESTING tasks, such as retrieving data from a database, setting a timeout between sampler operations, or generating test data.
• Post Processors run after the main sampler and apply to all samplers in the same Test Plan scope. They're useful for extracting fields from server responses and storing them in variables. The Post Processors are test plan elements that are used to do certain activities after a sampler request has been processed. These post processors are TYPICALLY used to extract specific data from a sampling request's response, for example, we can extract the value of session variables from an HTTP request and send the value of the session variable to subsequent requests.

• A Thread Group is a collection of threads that are all working on the same problem. Every JMeter test plan starts with this element. Multiple thread groups are PROVIDED, each of which can be set to imitate how users interact with the application, how the load is sustained, and for how long.
• JMeter's samplers allow JMeter to make various types of requests to a server. JMeter PROVIDES genuine QUERIES to the web server under test using samplers. Except for Test Action, each sampler generates one or more sample RESULTS. The sample results can be viewed in several WAYS and have various features (success/failure, elapsed time, data quantity, etc.).

Pattern-based regular expressions are used to FIND and manipulate text in Jmeter. JMeter uses the pattern matching software Apache Jakarta ORO to parse regular expressions or patterns used throughout a JMeter test plan.

We can save a lot of TIME and have more flexibility when creating or improving a Test Plan by using regular expressions. When it's impossible or very difficult to predict an OUTCOME, regular expressions provide an easy way to acquire information from sites. Regular Expressions are used to dynamically extract values from responses. These values can be kept for reporting purposes or used in a subsequent request. Both Pre-Processors and Post-Processors make use of regular expressions.

The distinction between contains and matches, as used on the Response Assertion test element, is worth mentioning.

• The term “contains” indicates that at least some of the target was matched by the regular expression. CONSIDER the string ‘alphabet’ and the regular expression ‘ph.b.’. Because the regular expression matches the substring 'phabe', we can say that 'alphabet' contains 'ph.b.'.
• The term "matches" refers to the regular expression matching the entire target. As a result, 'alphabet' and 'al.*t' are "matched."

A master-slave configuration is a type of distributed testing in which multiple machines are used to load test a SINGLE server. 

It's critical that all machines are connected to the same network and have the same JMeter VERSION. In distributed testing, one machine is designated as the master, while the others are designated as slaves.

The procedure is as FOLLOWS:

• Edit the JMeter.properties file on the master system and add the IP addresses of slave machines to the remote host column.
• Save the file and then reopen JMeter.
• Select Remote Start from the RUN menu in JMeter and enter the IP address of the system to be invoked.
• To start all the slave machines for testing, go to the RUN menu and select Remote Start all.

Distributed testing refers to the use of numerous machines for LOAD testing (Load testing is the technique of simulating several users accessing a software at the same time in order to MIMIC the expected usage of the application), with one serving as the master and the others as slaves. It is CRITICAL to notice that all machines must be connected to the same network and run the same version of Java and JMeter.

We'll utilise a local client as a master to manage the test execution for multiple remote clients, and each remote client will act as a slave to run the test on our target server. Each slave system runs the load tests according to the master's exact device specifications. As a result, distributed performance testing enables us to HANDLE a greater number of CONCURRENT users contacting the target server.

The following are some of the features of Apache JMeter:

• The ability to load and performance test a wide range of apps, servers, and protocols. This includes the following :
  • Web - HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, …)
  • SOAP (SIMPLE Object Access Protocol)/ REST (Representational State Transfer) Web Services
  • FTP (File Transfer Protocol)
  • Database via JDBC (Java Database Connectivity)
  • LDAP (Lightweight Directory Access Protocol)
  • Message-oriented middleware (MOM) via JMS (Java Message Service)
  • Mail - SMTP (Simple Mail Transfer Protocol)(S), POP3 (Post Office Protocol 3)(S) and IMAP (INTERNET Message Access Protocol)(S)
  • Native commands or shell scripts
  • TCP (Transmission Control Protocol)
  • Java Objects
• Full-featured Test IDE for recording  (from browsers or native applications), DEVELOPING, and debugging Test Plans (A Test Plan is where you add elements that are needed for your JMeter Test.)
• To load-test from any Java-compatible OS (Linux, Windows, Mac OSX,...), use CLI mode (Command-line mode (formerly termed Non-GUI) / headless mode).
• It has the option to generate a DYNAMIC HTML report that is full and ready to present.
• The ability to extract data from the most popular response formats, such as HTML, JSON, XML, or any textual format, allows for easy correlation.
• Complete portability and Java purity are GUARANTEED in Jmeter.
• Concurrent sampling by several threads and simultaneous sampling of distinct functions by separate thread groups are both possible with a full multithreading framework.
• It also has the option of test results caching and analysis/replaying offline.
• Extensible core:
  • Pluggable Samplers offer limitless testing capabilities.
  • With pluggable timers, you can choose from a variety of load statistics.
  • Plugins for data analysis and visualisation offer a lot of flexibility and personalization.
  • The employment of functions can be utilised to offer dynamic input to a test or to manipulate data.
  • 3rd party Open Source libraries for Maven, Gradle, and Jenkins make Continuous Integration simple.