This tutorial discusses JMeter, a Java-based, collection of several applications, a load and performance testing tool with a specific purpose.
This article mainly covers the following:
All examples are based on the Java 8 update 0.20,eclipse Luna 4.4, JMeter 2.11, MySQL Community Server 5.6.21 development environment. Then let's get started!
DirectoryIntroduction
The technology used
Tutorial Content Introduction
Installation
User interface
Requests that are available
Test plans and test components
Execution order
Start and stop
Test Plan for HTTP requests
MySQL test plan
JUnit Request Test Plan
Record Test
Plug - ins
Best practices
Summarize
Download
Resources
Using different technologies and protocols, JMeter is a tool for configuring and performing load testing, performance testing, and stress testing.
It can simulate different types of requests, such as various types of databases, FTP, HTTP, HTTPS, or other service-side applications.
It's a good idea to start with the following concepts:
JMeter was originally used to test Web applications, but its capabilities have been expanded and can now be tested for most applications, as well as functional testing in your program.
The technology usedJMeter is a Java desktop application whose user interface is implemented using the Swing Java API. Based on these two points, JMeter is a cross-platform tool that can run on any device that has a Java virtual machine installed on the operating system (Windows, Linux, Mac).
Its framework supports concurrent and multithreaded or thread group execution. This is useful for configuring load tests and stress tests.
It is extensible and provides a large number of available plugins.
JMeter is a sub-project under the Apache Software Foundation and is completely free and open source (http://www.apache.org/licenses/).
This article is for developers and software designers who do not have jmeter experience, and describes how to use the JMeter tutorial.
Some examples and usage instructions are provided for possible configurations and test plans. In the next section, we'll see how to install JMeter, configure it, run it, and save and analyze the results of different test plans.
InstallationIn order for JMeter to be installed and run on your computer, you need to follow these steps:
| 1 | Java_home=c:\program files\java\jdk1.8.0_20 |
Be careful to set up your Java version correctly.
Then test whether the Java environment is successfully installed on your device, using the following command line:
| 1 | Java-version |
You should output a message similar to the following:
| 123 | Java version "1.8.0_20" Java (tm) SE Runtime Environment (BUILD1.8.0_20-B26) Java HotSpot (tm) 64-bit Server VM ( Build25.20-b23, Mixed mode) |
| 12345678 | Apache-jmeter-2.9apache-jmeter-2.9binapache-jmeter-2.9docsapache-jmeter-2.9extrasapache-jmeter-2.9libapache-jmeter-2.9lib Extapache-jmeter-2.9libjunitapache-jmeter-2.9printable_docs |
The JMeter GUI is very intuitive to use. There are general menus for file processing, such as: New, open, saved, save as, etc. There are also menu items that are available to start and stop test plans that are configured. Each test plan, thread group, test plan node (we will see more of this in the next chapter) can be provided by clicking the right mouse button and providing different context menu options.
You can also change the language of the user interface, there are many languages to choose from.
As we said, the graphical user interface is very intuitive and easy to use, providing a handy and understandable tooltip for each menu and action. Aside from that, it's not about quality, so why is jmeter so widely used? Because it is easy to understand, and easy to learn.
Requests that are availableJMeter provides almost any kind of system test configuration. In general, the following protocols are included:
Basically, using JMeter, you can do the following: Create, configure, execute the test plan, and analyze the results. A test plan is a specific description of the set of requests that are configured for a local or remote server (or client).
In a test plan configuration, you can specify multiple input and output parameters to configure the basic conditions that make the test plan execute successfully or fail.
The JMeter test plan is made up of different components. Here's a list of the most important components that guide how you can add them using the JMeter user interface and what these plug-ins do:
Thread Group (Threadgroup)A thread group is basically a combination of different test plan elements, which is the core of a test plan that controls the basic core parameters.
In order to create a test plan, first you have to create a thread group that configures the following parameters: number of threads, transition period, number of cycles, and behavior in case of error:
A thread group also has a start and end time for configuration options. You can configure the start and end times for your tests by clicking the check box "Scheduler", which pops up a panel with scheduling parameters.
Once the configuration is complete, you can start adding additional test plan elements to the thread group, such as samplers, listeners, and timers. We'll explain all of this in the next chapter.
Sampling Device (Samplers)The sampler is used to send requests to different types of servers. They are the basic elements of every Test plan, and everything revolves around these samplers: the sampler executes the request (based on the configured request), and these requests produce one or more responses, which are subsequently parsed.
Here's a list of samplers available in JMeter (we'll see some of them in this tutorial):
As we can see in the list above, there are many different types of samplers. This list is incomplete because there are many other implementations that are different from the JMeter plug-in. The configuration of each sampler depends on the request it executes, which means that some samplers have some commonality of configuration, while others are completely different because of their respective requests.
Logical controller (logic Controllers)Logic controllers allow you to configure the order in which different samplers are executed within a thread group. The list contains all the available logical controllers in the JMeter:
The listener provides a different way to view the results that are produced by the sampler request. The listener parses the results in the form of a report, a tree structure, or a concise log file.
Listeners can also be added anywhere in the test plan, but they will only parse and collect data from the sampler within their respective application scope.
These are the JMeter available listeners:
You can use timers to define the wait time between requests. If not specified, JMeter executes the next request immediately after a request completes without any waiting time.
The timers that can be used in JMeter are as follows:
The assertion verifies the validity of the test plan by verifying the response generated by the sampler request. It is basically similar to unit test assertions, which are used to detect the response quality of the application being tested. You can configure any active assertions for each test plan.
Here is a list of assertions that can be used in JMeter:
By using configuration elements you can pass different parameters to the sampler request. They provide a way to create variables (different and dynamic) that are then used by the sampler. These parameters are executed when the parameter's owning node is started before the sampler is executed, which is why the sampler can rely on these variables.
Here is a list of all the configuration nodes used in JMeter:
The pre-processor is triggered before the sampler executes. They can be used to extract variables from the response that are subsequently used by the sampler through the configuration element.
Here are the elements that you can use as a predecessor processor:
A post processor is an element that is triggered after the sampler is executed. He can be used to parse response data and extract variables for subsequent use
The following elements are available for the Post processor:
The elements of the test plan are ordered and executed in the following ways:
-A configuration node
2 – Front-facing processor
3– Timer
4– Sampling Device
5– Post Processor (only performed if results are available)
6– assertion (executed only if results are available)
7– Listener (only performed if results are available)
A test plan can contain one or more test plans. It is common practice to group tests together through functional or technical logic.
Run/Stop test planTo run a test plan, you just need to click on the "Play" button:
Click the button "Play no pauses" to start a test and ignore all pauses:
You can stop the test by tapping the stop button:
You can also disable the execution of a test plan. You only need to "toggle" the status of the test plan:
As you can see in the above, non-executable plans are grayed out, but you can modify them or reconfigure them.
Web (HTTP) test planIn this chapter, we'll see how to create a test plan that tests a specific Web page over HTTP. For this purpose, I will use the http://www.wikipedia.org website.
With enough theoretical knowledge, we will now see how to configure a test plan for an HTTP request.
In this step, configuring the test plan may affect the behavior of the thread, and you can add an external class library that you might use. But we are not going to do that in this case.
In this step, you need to create a thread group that is responsible for executing all the test components, and configure the main properties: number of threads, seconds of transition, number of iterations.
Do this in the menu
Test Plan, ADD, Thread->threadgroup
You can also specify the behavior pattern in error conditions (continue, stop, stop the current thread ...). ）
In this step, add the Sampler to the test HTTP request:
ADD sampler->http Request
We need to set different properties for this kind of request:
In this example, set the name of the server to be tested: www.wikipedia.org (do not specify HTTP or HTTPS protocol). If necessary, you should modify the port, protocol, execution method and so on. This is not necessary in our case. There are several parameters for configuring the agent, timeout and different header information, but in our example, the default value is used.
This is necessary in order to see the results later, as we saw earlier in this tutorial, there are several optional configurations for our test plan for HTTP requests, and we use the result tree:
Add Listener, View Results Tree
In our example, we did not change anything, preserving the default values for all configuration properties.
file->save(or click "Control + S")
Run->start(or click "Play")
We can see that all the requests have been completed and as expected, they all provide a meaningful response, so it seems that the Web page we are testing is working properly (if this is our expected behavior). We can play. Turn these results and check all the returned data.
We have configured a test plan that sends a large number of requests to the specified server and resolves the response. Next we'll see how to use other types of test components, such as timers and assertions.
To add a timer, we just right-click the test plan and add a timer:
ADD timer->constant Timer
We configure 500 milliseconds. Each request waits 500 milliseconds after the last request execution completes.
In the test plan, right-click and add an assertion duration that configures the error assertion if the response time exceeds 100 milliseconds. The configuration for the main sample only option is as follows:
ADD Assertion->duration Assertion
Obviously this is because we configured the assertion duration to be only 100 milliseconds, and if we change that number to 2000 milliseconds, almost all requests will be delivered on time.ADD Assertion->size Assertion
We need to make sure that the response information is more than 5000 bytes in size:
If we run the test plan, we will see that the response information is always greater than the set value and the assertion will fail if the response information size is less than the set value.
Database Test Plan GuideWe'll see how to configure, run a test against the MySQL database, and analyze the results. This example is about MySQL, and you can use any other type of database such as Oracle,mongodb or anything else.
If you don't have MySQL installed on your PC, you can download and install MySQL server from http://dev.mysql.com/downloads/, which is very easy.
Download the MySQL connector (mysql-connector-java-5.1.6) and copy it to the Lib directory under the JMeter installation directory, in this case C:\jmeter\apache-jmeter-2.11\lib
Start the database server, and you can query it.
You can create a database that you want, and here's just a very simple example:
| 1234567891011 | Createdatabasejmeter; Use JMeter; Createtablejmeter_stuff (Idint,namevarchar (), Descriptionvarchar (50)); Insertintojmeter_stuff (id,name, description) VALUES (1, "Dani", "the Boss"); Insertintojmeter_stuff (id,name, description) VALUES (2, "Topo", "the Worker"); Insertintojmeter_stuff (id,name, description) VALUES (3, "Tupac", "the other"); |
As in the previous chapter, create a test plan: a new thread group, a JDBC-type configuration element, and a new JDBC type request, adding a listener in the same way to parse and view the results.
The only difference is the type of sampler, in which case the JDBC sampler is used.
| 1 | Select*fromjmeter_stuff; |
Add a new JDBC connection configuration to the sampler:
Add Connection configuration by right-clicking JDBC Sampler
Change the parameters as follows:
| 12345 | Variable boundtopool= samenameasinthe Samplerdatabaseurl=jdbc:mysql://localhost:3306/jmeterjdbc driver.mysql.jdbc.driverusername=password= |
Set User name password
You can verify and check the output in the same way as a test plan that is similar to the HTTP request. As long as you need, you can also add a predecessor processor, a post processor, an assertion, or any other element.
You can verify and check the output in the same way as a test plan that is similar to the HTTP request. As long as you need, you can also add a predecessor processor, a post processor, an assertion, or any other element.In this case, the output is the result of the SELECT statement.
You can use this sampler for updating data, and for modifying the SQL statements of the sampler configuration.
The following screen captures basic information about the result of the request response:
In this chapter, we will explain how to use JMeter with JUnit. From a load and performance standpoint, JMeter provides a very powerful mechanism for performing functional testing.
First, you need to create a JUnit test like the following:
| 123456789101112131415161718192021222324252627282930313233343536 | Publicclassjmetertest{ publicjmetertest () { //Just for testing purposes SYSTEM.OUT.PRINTLN ("Calling the constructor"); } @Before publicvoidsetup () throwsexception { //Just for testing purposes SYSTEM.OUT.PRINTLN ("Calling setup"); } @After publicvoidteardown () throwsexception { //Just for testing purposes system.out.println (" Calling TearDown "); } @Test Publicvoidtestme () &nbsP; { for (inti =0; I <30; i++) { //just asserting Randomly in order to check what happens in each case & Nbsp;intrandomnumber = (int) (Math.random () *100); system.out.println (Randomnumber); assertequals (0, randomnumber%2); } }} |
| 1 |
To see how JMeter uses them, this trial consists of two assertions, although the purpose of this tutorial is not to explain unit tests or junit tests in detail.
Hit the unit test into a jar package and copy it to/lib/junit under the JMeter installation directory. Make sure that the jar file contains the. class file of the test class that you want JMeter to execute. At the end of the article, you can find a Java project with a pom.xml file that you can use directly to generate the jar file. Now you just need to compile the code:
| 1 | MVN Compile |
or export your project directly from Eclipse or another IDE you like, generating a jar file that includes a bytecode.
As mentioned before, create a test plan and add a Junit type sampler: Add Sampler->junit Request, configure and execute the method you want to test.
In our case, we'll run a JUnit 4-based approach, but you can also tick the box to use JUnit 3.
Here, you can see the JUnit test results we just created:
As shown above, all of our tests (one test, 10 cycles) failed. This is expected behavior because we want our tests to fail. In fact, we just wrote a unit test, no functional meaning, is useless. Its purpose is to show how to configure JMeter to perform unit tests on these classes.
The content explained in this chapter helps you to test the functional testing and business logic of your application using the convenience features provided by JMeter. It is also interesting because it combines all the advantages of the Java language with the multithreading capabilities of JMeter.
HTTP Test recordNow we'll show you how to configure JMeter to log HTTP requests. For this we need to install Firefox on our machine, I am using version 32.
Go to Firefox network settings, select the Manual proxy option and set the local host server and port 8080 (in fact, this deepens your jmeter configuration). After that, select Use a proxy server for all protocols.
We added a new thread group and named it. The number of thread group threads configured is 50, the transition period is 10 seconds, and the number of cycles equals 1.
Add a new configuration element to the thread group you just created, and select "HTTP Request Defaults".
Here you should fill in the name of the server you want to test.
Now we add a record controller to the workbench.
Select the table, not the test plan, and add a test Script Recorder for the non-tested component.
You should now save the workbench and have nothing to do with your test plan. Saving a test plan does not mean that the workbench is saved.
The configuration records are as follows:
If you want to add a timer (constant type) to your recorder, the timer will be used by each HTTP request that is logged.
You will start the JMeter proxy server by tapping the Logger Start button.
If you are accessing a Web page to generate an HTTP request, such as using Firefox (which is configured after the first step in this chapter) to access http://www.oviedin.com, you will see different request portals appearing in your test Plan Recorder controller.
These records are actually HTTP requests for the Web pages that were previously accessed. Those records that are configured with the filter configuration test script will be saved. Can be reconfigured for use in your subsequent test plan.
JMeter Plug-inDifferent plug-in application scenarios and users, some of which need to be installed, some do not need to install.
Some very useful plugins that parse the results with some advanced options and use charts to analyze the results such as http://jmeter-plugins.org/wiki/GraphsGeneratorListener/.
There are also available plugins that can connect JMeter with your continuous integration tool, run JMeter directly from the CI software, and execute a test plan, such as "Https://wiki.jenkins-ci.org/display/JENKINS/Performance+Plugin".
As I said, as the number of plugins increases, it is not possible to list all the plugins. So when you implement your plug-in functionality, try to find out if there are any plugins available on the Internet, which is very valuable to you.
You can also create your own JMeter plugin, but this is beyond the scope of this article.
JMeter Best PracticesAt the end of the article, we'll write down two useful tips and best practices:
You can use the command line:
| 1 | Jmeter-n-T test.jmx-l test.jtl. |
Load testing with JMeter-the ultimate guide
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
