A step in a scenario can be thought of as a single user action. That action may be clicking on a link, logging into your application, going directly to a specific URL, putting a widget in a shopping cart, or entering credit card information.
The first step in a scenario should be accessing a URL. Usually this will be the home page of your application because that is where most people start. LoadStorm will parse the HTML returned for the home page, and it will identify all of the referenced resources such as images, CSS, and external Javascript files. It will then immediately start sending requests to your server for those files in the same way a browser would.
The parsed HTML also tells LoadStorm what links (anchor tags) are available on this page. When you are creating a new step in a scenario, the tool presents this list of possible links to you if you select the radio button for “Click on a Link”. You may choose a specific path for this user type by selecting one of the links in the table, or you may tell LoadStorm to randomly select a link on this page. Having several sequential steps in a scenario that are all randomly linking will give you good coverage of browsing patterns for users that are “just looking around” on your site.
When configuring a scenario step that clicks a link, LoadStorm follows the link by searching for the text between the open and close anchor tags. If it doesn’t find that text, then the fall back is to match the XPATH. We stored the XPATH when the scenario was created (essentially an address inside the page’s DOM). The XPATH is a unique identifier that allows us to click on the anchor such as an image or the HREF attribute or execute the Javascript.
This methodology of identifying and activating links is why LoadStorm can successfully request the correct server resource when the session ID is appended to the URL query string.
We advise you NOT to create steps of random linking followed by a specific link on a particular page. It is likely that the random links won’t end up on the correct page where that specific link exists. Rather, it is acceptable to have some steps that go to specific pages followed by some random clicks.
The third type of step is form submission. With a step of this type, you will see a tab for each form that was found on this page when we parsed the HTML. For example, you may see 2 tabs representing forms for Search and Login on your home page.
Choosing a tab reveals the form fields such as username, password, etc. You can have LoadStorm fill in those form fields with a constant value, but most people would prefer to input realistic data from a file of values. For instance, it would be a better load test if 1,000 users logged in with different usernames and passwords because the database access and application logic will more accurately reflect real-world conditions. Caching can greatly improve your performance, and logging in as John Doe every time will probably use mostly cached resources rather than make your application work harder to produce 1,000 different personalized pages.
You can upload any type of data set for completing a form. We accept CSV formatted files, and the columns (data fields) can be whatever you want. Use the first row of the file to name the columns. In the step creation, you will be able to select any column in your uploaded data set to fill-in a field on the form by selecting it from a drop-down menu.
There are 3 radio buttons at the bottom that represent how to submit the form. The most common is the first radio button because it corresponds to the submit form button on your page. The second choice is to force the form to submit without a button click. This is useful when there is Javascript that is supposed to submit the form, but it isn’t working with LoadStorm for some reason. The third option is rarely used, but it can be useful in unusual in certain circumstances we have seen in military applications or ERP applications where another step is needed to actually submit the form.