Implement compaund Web Test

[AlexKaras]

Dear colleagues,

I am pretty sure that compaund Web Test is in your plans for the next LoadNinja update.

The purpose of compaund Web Test is similair to the Call Scenario operation from LoadComplete and its purpose to make it possible to create reusable parts of Web Test.

For example, assume that I need to load test a scenario when 80% of VUs just browse some goods catalogue and only 20% of all VUs do a purchase.

Current implementation of LoadNinja requires that the browse sequence must be recorded (and supported) twice - for browse test and for browse and purchase one.

Compaund Web Test should eliminate this duplication.

[Jonathan_Smith]

Would love to have a feature like this, I am currently rebuilding our existing suite of tests from Visual Studio in Load Ninja and this is the one thing I can already see if going to be missed and will make maintaining tests harder going forwards.

With all of my previous work I created it under an encapsulated approach so that I could maintain commonly used scripts, for example, a test that goes to the homepage, then logs in, opens an account and logs out would be 4 parts that could be easily maintained and then reused multiple times to make other tests like Home > Login > Logout, Home > Products, etc all reusing the same scripts that if changed I only had to alter once to update.

[Tom_S]

Hi Jonathan

I think that we have a solution for this. We have an option to record more actions to the existing script. So you can create a basic script as you mentioned, then by using the option "Save As" you can copy this script, and then you can add more steps to it by using the option "Record new step", and LoadNinja will playback the script to the chosen point and then it will allow you to record new steps. 

Let me know if that helps. 

[AlexKaras]

@Tom_S :

Hi,

Not sure this is a solution. Adding new steps still leaves us with more than one identical copy of the initial sequence (e.g. login procedure) and thus maintenance problem is not eliminated.

For example: assume there are 'Login>Logout" and "Login>BrowseHomePage>Logout" sequences (aka load tests). Now something changed in, say, Login process. What can be suggested except re-recording of both existing sequences to reflect changes in Login and make both tests to be again up-to-date?

[MPunsky]

Hi @AlexKaras ,

I agree that the solution should be to create re-usable 'modules" that can then be added simply to new scripts.  The way that I foresee this working would be that a 'Library' of re-usable modules could be created with things like:

1. Load Homepage and login
2. Fill out a form
3. Perform a search
4. Logout

When creating any new script, an option would exist that would enable insertion of a module.  However, it would not be a one-time insertion - but rather, it would update from the module any time the script is used.  In this way, you could make changes in one single place (the library), and ANY script that uses that module would then be updated the next time it was used.

Does this sound right?

[Jonathan_Smith]

Hi @Tom_S 

I gave it a try yesterday using the Save As feature to try and make it work but unfortunately as it currently is the best you could do is create the starting point test to copy and then record anything after that, even if its a duplicate piece. Correct me if I'm wrong and couldn't find it but the Save As can only create a new test and not copy a piece to an existing one.

Other thing I hit is that it looks like all tests must start with a page navigation event which means you aren't able to create purely partial test pieces that only contain mouse, keyboard, etc events that depend on a previous piece doing the initial navigation.

Hi @MPunsky 

That's exactly right yes, to give an example from what I am migrating across from Visual Studio to LoadNinja.

The way I designed our test structure there is a folder of tests called "Components", each one of these is responsible for the actual page interactions and only contain a part of a full test, e.g. Login, Open Account, Secure Messages, etc. each item encapsulation to itself and its purpose to be chained together for use.

I then have a "User Journey" folder of tests which only ever call Components and never the page directly, these ones are responsible for orchestrating the whole journey under test and managing the top level items like the input data, output logging, etc.

To match that up to what you said, the Components would be the Modules and the User Journeys would be the Test Script that references the Modules

[AlexKaras]

@MPunsky :

Hi,

> Does this sound right?

Yes, it does. Exactly so.

My vision of the discussed functionality:

-- User records complete scenario (e.g. load homepage, login, simple search, logout actions);

-- User can clone recorded scenario, remove / comment out all not necessary lines and save the result as a new 'module' (say, Logout);

-- User can repeat the above process and create OpenHomepage, Login and SimpleSearch 'modules';

-- User can edit any existing recorded scenario and replace recorded line(s) with 'module(s)' from modules library;

-- User can update existing module in the library (using any of: removing / pasting its line(s) or by overwriting the whole module with a new one Saved As using the same name) and this update must be reflected in all scenarios that use (reference) this modified module.

I hope that that the above corresponds to your vision as well, doesn't it?

[Tom_S]

Hi @AlexKaras and @Jonathan_Smith,

I hope that you are doing well.

Based on your suggestions and comments I created a Feature Request under Jira number #SMLD-4356.

We will review it with our product team, to find out the best way to implement this kind of feature.

Tom
CC

[AlexKaras]

@Tom_S :

Hi Tom,

Thank you for this. Hope, that this will improve LoadNinja's usability.

Best,

   /Alex

=================

[Jonathan_Smith]

@Tom_S That's great to hear, hopefully this can bring some great maintainability and re-usability to future LoadNinja scripts.