Parent page: Load/Performance Testing with NeoLoad

Although recording is necessary phase in creation of load scripts, I prefer constructing my own modules based on results of reverse engineering analysis of captured client/server communication. Partially because this way I create reusable structures with containers, partially because I want to control setting of think time and pacing, – but mostly because I must take into account much more situations than those recorded as “happy path”.

In today’s post I’m bringing one simple example to illustrate the point.
Let’s look at hypothetical online payment system with a particular user workflow:

• Log in
• Select Account
• Make a Payment
• Receive Confirmation
• Log out

We want to test this workflow under load, but we still care that it’s functionally valid.
If a user fails to login, would it make sense to execute further requests? We know we’ll get errors, and those errors will become a distracting “noise” in the load log. If the system failed to provide account page, would it make sense to send payment request, even if it will succeed? The real user won’t be able to by-pass failing pages, and getting to know of those “bottlenecks” in advance is a valuable test result.
The main judgment automation engineer needs to make is to identify which failures require ending the script (closing virtual user) and which failures allow to continue. Of course, once the virtual user is closed, we need to start another one to keep up the load.

In NeoLoad, the described actions will be –

Inject Try/Catch Statements

Configure Validation Conditions

Apply Settings for Try/Catch

In case of complex data validations you might want first to extract values from the response, and then work with them in JavaScript node.