Basic load testing is a good starting point and helps find common performance issues. But it often doesn’t show how an application behaves in real-world situations or under heavier, more complex use. This blog explains why basic testing is not enough and why it’s important to test in ways that match real user actions. When tests reflect real usage, the results are more useful and accurate. With Apache JMeter, we’ll look at more advanced testing methods such as creating complex test plans using nested thread groups, adding logic with If and While controllers, setting timers, adding checks (assertions), and using CSV files to add real data to tests.
We’ll also talk about JMeter plugins, which add extra features and make your tests more powerful. You’ll learn which plugins are most helpful, what they do, and how to install and use them. For more complex needs, we’ll show how to use Groovy scripting and JSR223 for custom actions and handling detailed data.This helps make your tests smarter and more flexible. At the end, we’ll share some handy tips, best practices, and pitfalls to steer clear of. These should help you boost your performance testing game and make the most of JMeter’s cool features.
Why Basic Load Testing Isn’t Enough
Common challenges of basic Performance testing
- Limited Realism: Basic performance tests often use simple scripts that don’t really show how users actually use the system. This can give you results that don’t match real-world performance.
- Limited Load Testing: Basic tests sometimes miss the mark when trying to mimic real-world traffic. They might not pick up on performance problems that only show up under heavy loads—think times when tons of users are hitting the system simultaneously..
- Inflexibility: Basic test scripts often miss the mark when trying to reflect the chaotic reality of real-world usage.They have difficulty adjusting to changes in user behavior, variations in data, or unexpected traffic surges. This stiffness makes it tough to uncover those hidden, underlying performance problems.
- Overlooking Edge Cases: Standard testing tends to zero in on the usual suspects – typical user behavior. But, it often gives the cold shoulder to edge cases or those less common actions users might take. These edge cases can be really important for understanding performance in real-life situations.
- Insufficient Metrics: Basic tests might not track enough metrics to give you a complete picture of performance.
Real User Behaviour vs. Testing Assumptions
Basic load testing often operates under a key assumption: that users will follow a consistent, predictable path. In reality, the way people act online is way more diverse and complicated than we often think. If we really want to get a handle on how things perform, we can’t just stick to pre-planned tests. We need to see how actual users are engaging with these applications in the real world.
A Wide Range of Devices and Network Conditions:
Your users aren’t all accessing your site on high-speed connections or the latest devices. A lot of users are on mobile devices, older browsers, or slower network connections, which isn’t usually reflected in basic tests. These conditions can really affect how things perform, especially if you’re targeting a global audience or one that’s mostly on mobile.
Every User Journey Is Unique:
Users interact with your app in all sorts of unique ways. Some might race through a task, while others take their time, checking out various features, jumping between pages, or even stepping away and coming back later. Basic testing usually focuses on fixed workflows and can miss the complexities of real user behaviour, leaving blind spots in your performance insights.
Emotional and Behavioural Responses:
Users are not just data points; they’re individuals with expectations. When your site slows down or acts unpredictably, users don’t just patiently wait. They refresh, click multiple times, or abandon the session entirely. These real-time behaviours can generate spikes in server load and expose issues that pre-scripted tests don’t account for.
Designing Complex Test Plans in JMeter
Nested Thread groups
What Are Nested Thread Groups in JMeter?
In JMeter, Thread Groups stand for the virtual users who are carrying out the test. When designing complex tests, you might want to simulate different user actions happening at the same time but with varied load and timings. For example:
Some users might log in and start browsing immediately.
Others might be interacting with the application only after waiting for a few minutes.
With Nested Thread Groups, you can mimic various user actions all within one test plan. Every nested group can be independently set with its own number of threads, ramp-up period, and loop count, which makes it perfect for representing a range of user experiences in a single test.
How to Set Up Nested Thread Groups in JMeter
Let’s now take the DemoBlaze website as an example and explain how to use Nested Thread Groups in JMeter for simulating user behavior on this site.
We’ll simulate the following user actions on DemoBlaze:
-User login: Logging into the site.
-Browse products: Browsing different products.
-Add to cart: Adding products to the cart.
-Checkout: Proceeding to checkout and placing an order.
Note: For a guide on creating a basic test plan, check out our blog post: Apache JMeter: Your Gateway to Performance Testing and Beyond. In this post, we cover the essentials, including how to create a test plan, set up a thread group, and design a simple test for logging into an application.
Step 1: Setup the Test Plan
-Create a Test Plan in JMeter.
-Add a Main Thread Group by right-clicking on the Test Plan → Add → Threads (Users) → Thread Group.
Step 2: Add HTTP Header Manager (Global Level):
-Right-click on the Test Plan → Add → Config Element → HTTP Header Manager.
-Name the element: Global Header Manager.
-In the HTTP Header Manager, click ‘Add’ to create new header rows and input the following:
- Name: Content-Type Value: application/json
-Name: Accept
Value: /
Step 3: Add Nested Thread Groups
In this step, we’ll define the individual user journeys by adding Nested Thread Groups for different actions:
Login Simulation:
-Start by right-clicking the Main Thread Group. From the menu, navigate to Add, then Threads (Users), and click on Thread Group.
-Name this new thread group Login Simulation.
-Set the Number of Threads (Users) to 20 (simulating 20 users).
-Set the Ramp-Up Period to 10 seconds.
-Set Loop Count to 1 (each user logs in once).
-Add HTTP Request to simulate login:
-Server Name: api.demoblaze.com
-Path: /login
-Method: POST
Add Products to Cart
-Start by right-clicking the Main Thread Group. From the menu, navigate to Add, then Threads (Users), and click on Thread Group.
-Name this new thread group Add To Cart.
Set the Number of Threads (Users) to 30.
-Set the Ramp-Up Period to 15 seconds.
-Set Loop Count to 1 (users add products once).
If you want to add something to your cart, start by finding the product’s ID. Once you have it, include that ID when making the request to add the item.
- Add an HTTP Request sampler to your Thread Group to fetch the request ID from the entries API endpoint
-Method: GET
-Server Name: api.demoblaze.com
-Path: /entries
-Body Data: {} (leave it empty, or use {} to match actual site usage)
- Add JSON Extractor to Capture the ID Right-click the HTTP Request component, hover over ‘Add’, then ‘Post Processors‘, and click ‘JSON Extractor’
-Name: Extract Product ID
-Names of created variables: productId
-JSON Path Expressions: $.Items[0].id
-Match Numbers: 1
-Default Values: 1 (optional)
Read The Full Blog Here:- JigNect Technologies
Top comments (0)