Load Testing by Example
Configuring a Testcase for Unique User Logins
Overview
This tutorial demonstrates configuration of a typical testcase to use a unique identity (username/password) for each virtual user (a.k.a. VU or simulated user) in prepration for load testing.As an example, a testcase will be created for an ASP.NET sample program - the ASP.NET Issue Tracker System included in the Microsoft ASP.NET Starter Kit. However, the procedure will be nearly identical for any web-based login system in which the user enters a username and password into forms on a web page.
Prerequesites: This guide assumes a basic understanding of the Load Tester product. The Load Tester videos are a good introduction to the main features. It is assumed you have recorded a testcase.
Please note that this tutorial is based on Load Tester 3.5. The procedure is similar in other versions, but the details may vary slightly.
Creating the Login testcase
For this example we will be using an extremely simple scenario. It has three steps:- Go to application homepage
- Login
- Logout
After recording the testcase, it will look like the picture below. Note that the middle page (after a successful login) shows the issues relevant to the user. When other users login, this page will only show issues that are relevant to that issue. In our sample database, the only issues that will be relevant to our tests users are those issues the user created. Thus when user user000 enters the system, only issues created by user000 will be displayed. We will use this to visually verify proper operation of the testcase when we replay it.
Configuring Unique Identities
In order for each VU to assume a different identity, it must provide a different username and password when the fields from the login page are submitted. Effectively, it must simulate filling out the login page:
The easiest way to do this is using the User Identity wizard. It can also be done manually, which will be demonstrated later in this tutorial.
Running the User Identity Wizard
There are a number of ways to invoke the User Identity wizard. The first time you attempt to replay the testcase (using the
button),
you will presented
with the Testcase
Configuration
wizard. Choose the Use
Different Logins option:
Choosing this option and pressing the Next button will invoke the User Identity wizard. If you have already completed the Testcase Configuration wizard, you will need to open the User Identity wizard manually. This can be done via the pop-up menu in the Navigator for the testcase, the main Edit menu or a toolbar button, as shown below:
The first page of the User Identity wizard is shown below. For any authentication based on entering fields in a web page, you should choose Authentication via a Web Page form. Other authentication methods (NTLM, client certificates, etc) are not covered here.
On the next page, choose a unique identity:
Next, enter the username and password that were used to record the testcase. The wizard will use this to locate the pages in the testcase where the username and/or password are used. For best results, ensure that the username and password used during the recording are not used anywhere in the testcase that are part of an authentication process.
If you have already created or imported a dataset, choose the I have already... option and skip the next section of the tutorial. To create a new dataset now, choose the create a dataset option on the next page:
Creating a new dataset
A dataset will be created where you can enter usernames and passwords to be used when replaying the testcase. Double-click the user1 cell and enter a username. Then press the enter button to move to the next cell to enter a password. Repeat the above step to enter a few username/password pairs.
After entering the username/password pairs, press Next and Finish.
Using an existing dataset
If a dataset already exists with the usernames and passwords, choose the dataset and fields from the lists, as shown below. Search for "dataset" in the Help system for instructions on creating datasets and importing values into a dataset from a text file (e.g. a CSV file).
Press the Next and Finish buttons.
Testing the configuration
The testcase is now ready to be replayed. If you already pressed the replay button (
),
the replay will start as soon as the configuration wizards are
complete. If you ran the wizards manually, push the replay button now.After the replay completes, selecting the second page in the testcase will show a list of testcases relevant to the user that is logged in. In the picture below, you can see that these are all issues created by user000, confirming that the user identity for user000 was used to enter the system.
The testcase is now configured correctly for using unique user identities. During a load test, different identities will be used by each VU, simulating the real-world condition of multiple different users entering the system.
If you are interested in examining the details of what the wizard did, continue on to the next section. Otherwise, skip the next section.
Examing the configuration details
The Fields view will show the fields used in the replay. The picture below shows that the username user000 and password pass000 were used during the replay.
To see what the changes the wizard applied to the testcase we need to look at the fields from the base testcase, rather than a replay. Switch back to the recording by selecting it from the replay drop-down at the top of the editor.
After selecting the testcase, the fields will be displayed as shown below:
The txtUsername and txtPassword fields have been configured to use values from the dataset as shown. These changes were made by the User Identity wizard.
Conclusion
Using the User Identity wizard, testcases for most web applications that use a login page can be easily configured to simulate multiple user identities during a load test. The user simply provides a list of usernames and passwords and the wizard does the rest!
Feedback & Comments
Comments about this report may be posted at the company blog post.
Metadata
Christopher L Merrill
©2007 Web Performance, Inc.; v1.1
Version History
v1.0 - 1st public release (11 September 2007)
v1.1 - email cleanup (23 Jan 09)