Document Test Accounts

TopOfPage

Document Test Accounts

Overview

Test accounts are very important when testing an application that requires login credentials. Applications also vary widely in their login criteria. Some prevent specific login IDs to log in multiple times concurrently, while some require testing user concurrency of hundreds or thousands, and, in those cases, even if a login ID can login multiple times, caching may become an issue if there are limited test accounts. Password security is also a strong requirement in most organisations.

To improve the efficiency of scripting in a number of situations, DoxRunner's Test Case and Script operations provide a number of mechanisms for instrumenting a script for test accounts.

Test Accounts can be viewed as yet another type of data management, so there is no specific Test Account section. They should be added to one of the three types of test data rules section (Text Data File, VTS, or LoadTest Database).

ManualConfiguration

Manual Parameterization

The three paragraphs below are provided for background information only.

It is common for an application to include a login page, with the User ID and Password appearing in a VUGen request as attribute pairs. Depending on the application, the attribute pair names (User ID and password) could be anything, but the attribute values will be those used by the scripter to log in while recording.

After recording, a scripter will typically create a text file containing the test accounts, place it into the script's folder, manually identify the request containing the test account and its password, and parameterise them. The test account Id may be configured as Unique / Once or Random / Once. If the password remains the same across all User IDs, then there will not be a password column and the password will be hard coded in the script, using the lr_encrypt function. Otherwise the password will be configured as a separate column and configured to use the "Same line as..." the test account Id. There may be other attributes associated with the test account that require parameterizing, such as Role or User Location or First / Last Name, or anything. Each one requires extra keystrokes for the scripter to parameterize.

In general these actions aren't a lot of work, but can be tedious if a lot of scripts and a lot of test accounts are involved. Even if not a lot of scripts are involved, mistakes can be made when re-recording. In addition, unless strict standards are enforced, each scripter will have his or her own parameter names and file names, meaning that other team members who may need to maintain a script will take a little longer to become familiar with it.

DoxRunner's Test Case and Script operations manage test accounts in the same manner as other test data:

as a Text Data File;
as a table in the LoadTest Database;
Configured in VTS.

TextDataFile

LoadTestDatabase

Using Test Accounts in a LoadTest Database

If the LoadTest Database is used, one table within it can be dedicated to test accounts. The columns within the table can be defined using any manner the scripter chooses.

Using the GetAndBurn() function and the Status column, is effectively the same as the text data file Unique / Once operation.

Typically the Status for each Test ID will be set to 0 at the beginning of a test. The GetAndBurn() function will set it to 1, meaning no other LR instance will reference it during the test.

Make sure the mysql_update_status() function is manually inserted in vuser_end so that the status is restored to its original value after the test ends. If any instance fails during the test, the User IDs can be easily identified because the status will remain at 1. Make sure you manually reset them to 0 after troubleshooting.

The GetAndBurn() function will need to be manually inserted into vuser_init.c after the database initialization function.

Using Test Accounts in a Text Data File

Test accounts can be used in a standard Text Data File, which DoxRunner can manage.

Note that if each User ID needs a separate password, it will need to be in a separate column, but will not be encrypted unless extra code is used.