JMeter testing
JMeter is a testing tool to simulate thousands of users for web testing purposes. It uses Java Threads for this.
0 Results
Posts Tagged - testing
JMeter performance testing
We’re going to use a test app. Supposedly, this app has passed a first development iteration, and has passed unit and functional testing. With JMeter we measure its performance.
Performance testing should start early and continue through the whole dev process.
JMeter is not a browser. It doesn’t execute JavaScript!
Performance Testing
Performance is related to how fast an app executes an operation. Performance testing is about how an app or resource performs under a given load, to see its impact. It should be done after the app has passed all functional tests and we’re sure it works correctly.
Performance testing is measured in terms of:
- response time: request time + processing time + network latency.
- throughput: number of transactions (request/response) / unit of time (ms / seconds).
- reliability: how well the app detects and handles errors. number of errors / number of requests.
-
scalability: tells how well the system expands its capacity in terms of response time, throughput and reliability when additional resources are added.
- vertical scalability: adding more memory or additional CPUs.
- horizontal scalability: adding servers to a cluster.
Performance requirements
They’re are usually set up in contracts, such as:
- average / maximum response time.
- pages per second the system should be able to support.
- users per hour the system should be able to support.
Process to follow
- Design and build tests: We have to know the app and its usage patterns.
- Prepare test environment: configure a test env similar to prod.
- Run the test: validate the script and test data. Monitor server logs!
- Analyze the results
- Optimize
- Retest
Types of Performance Tests
- Increase the number of users.
- Increase the number of requests.
Almost always you should execute a smoke test first. This is a test with light load to verify the test works correctly.
A load test is a test that’s performed at a specific load level. Usually you’ll perform them at many load levels to monitor the app’s behavior.
A stress test tests the app with loads past its normal working range, to see up to which point it stays stable and responsive.
At a spike test the app is subjected to brief periods of sudden increments in the load beyond its maximum capacity, to see if the app is robust enough to work during and after the spike.
Endurance tests, where the app is subjected to load within its limits for a long duration (hours or even days) to search for memory leaks.
JMeter
JMeter is a testing tool to simulate thousands of users. It uses Java Threads for this.
Configure a Test Plan
In JMeter the components of a test are organized in a tree, where each component has a scope that determines to what other components it has access to.
Test Plan
Test Plan is the root element of a test, where all overall settings are specified and all the other elements are contained.
It allows us to:
- Define variables to the entire test.
- There we can set to run Thread Groups consecutively, instead of parallel.
- We may run tearDown Thread Groups. They run at the end of the test, after a graceful shutdown of the main Threads. They won’t be run if the test is forcibly stopped.
- If we select Functional Test Mode, JMeter will save information from the server responses to result files. Beware, as this files grow quickly and they impact performance. Only for small tests.
- We may add jar files or directories to classpath, so they will load just for the test script.
Thread Groups
They’re the entry point of a test and controls the number of threads (users) JMeter will use to execute a test. We also have setUp and tearDown Thread Groups.
We may:
- Set the number of users and the time it will take to create them. This creation can be delayed until they’re needed.
Configuration Elements
They’re used to set up default configurations and variables for later use by other components. They can be placed under any other component.
They are classified into:
- elements that allows us to set variables: CSV Data Set Config, Counter or Random Variable.
- elements that allows us to define a Configuration: JDBC Connection Configuration, KeyStore Configuration, Login Config Element.
- managers that allow us to manage configuration params: HTTP Header Manager, HTTP Cookie Manager, HTTP Cache Manager.
- default configuration elements: HTTP Request Defaults, FTP Request Defaults, Java Request Defaults.
The most common used are:
- CSV Data Set Config used to read the content of a CSV file and turn it into variables.
- HTTP Header Manager allows us to add or override HTTP Request Headers.
- HTTP Cookie Manager For each user, it stores and sends a cookie like a browser; Allows to manually add a cookie that will be shared by all users.
- HTTP Cache Manager Adds caching functionality to HTTP Request. Each user has its own cache.
- User defined variables allows you to define a set of variables. They’re processed once at the start of the test and are shared between old thread groups.
He created an HTTP Request Defaults and added the IP and port number, so he doesn’t need to repeate this at every component.
Java testing notes
Codearte’s Catch exception
The only thing it does, it’s to do a bit easier to test and assert for exceptions in a Test Driven Development-like way. To use together with AssertJ. It only has two methods which are useful to me:
// When
BDDCatchException.when(this.instance)
.methodWhichThrowsException();
// Then
Assertions
.assertThat(BDDCatchException.caughtException())
.isNotNull()
.isExactlyInstanceOf(IndexOutOfBoundsException.class);