DoxRunner
Macquarie University Student Accommodation
Overview
​
LoadRunner does not support a parameter type of LoadTest Database. It manages data using Text Data Files and/or VTS.
However, managing data using the LoadTest Database has advantages over the other two methods, and DoxRunner has extensive support for it. Like all DoxRunner rules, LoadTest Database parameter rules are documented in a Word document within the context of a DoxRunner section.
It uses a MySQL database and integrates with a LoadRunner script via four specialised files.
​
The illustration below shows how they are configured in a DoxRunner document.
​
Parameter
​
The Parameter name is mandatory. It must be unique and only appears in the column with heading Parameter in the table of any LoadTest Database section.
​
It must also conform to LoadRunner rules.
​
Configuration
The Configuration is mandatory. In the context of LoadTest Database rules, it must contain two Configuration Items (Tablename and Operation) as described below and illustrated on the right.
​
1. Tablename
​
The name of the MySQL table is mandatory;
​
It can be preceded by the Configuration Item ID 'Table:' if the context is not clear.
​
2. Operation
​
The Operation is mandatory and must be one or more of the following separated by a comma.
​
It can be preceded by the Configuration Item ID 'Operation:' if the context is not clear.
Get and burn
Get random
Get sequential
Put
Update
Update status
​
Section Management - LoadTest Database Rules
Common Characteristics
​
A LoadTest Database section is optional, is semi-structured, and may appear in three places:​​
-
Any Test Case;
-
The Solution document;
-
The Test Case Template document.
​
Each instance of the LoadTest Database section consists of:
-
a Section Title;
-
a Bookmark;
-
free-form Body Text;
-
a Table with a minimum of two columns (Parameter and Configuration).
​
The Bookmark:​
-
Mandatory;
-
Location: Immediately before the Section Title;
-
Structure: Depends on which document it is embedded in:
-
Test Case: P_PRI108_LoadTestDatabase (where PRI108 is the Test Case ID)
-
Test Case Template: P_LoadTestDatabase
-
Solution document: V_LoadTestDatabase
-
​
The Section Title:
-
Mandatory;
-
Location: immediately after the Bookmark;
-
Structure: Free-format text;
-
Style: I_Heading n or I_Appendix n, where n can be an integer from 1 to 5;
-
Length: Cannot be longer than 200 characters.
​
The Body Text
-
Optional;
-
Location: between the Section Title and the Table;
-
Structure: free-format text;
-
Style: I_BodyText;
-
Length: Cannot be longer than 1,000 characters.
​​
The Table:
-
Mandatory;
-
Location: immediately below the Body Text (or Section Title if there is no Body Text):
-
A minimum of two rows:
-
A Heading row and a Data row (one data row per rule);
-
If there are no rules, the Data row can contain empty cells (or the section can be deleted);
-
-
A minimum of two columns:
-
A Parameter column and a Configuration column;
-
More columns can be added;
-
A Description column is recommended.
-
-
All cells in the Parameter and Configuration columns must conform to specific rules, as described in the Overview above.​
​
​
Advice
​
Assess whether the section is necessary. This decision will need to take into consideration three factors:​
-
Whether you have the appropriate MySQL database infrastructure set up;
-
Whether the Test Case needs LoadTest Database rules;
-
Which scenario you have chosen when assessing the relationship between Test Case sections and Solution document sections.
​
Assess the Section Title and update it if necessary.
​
Make sure the table has the two mandatory columns (Parameter and Configuration), each with the specified heading text.
​
Assess the table to see whether more columns are appropriate, especially a Description column.
​
Assess the Body Text between the Section Title and the Table and update it if necessary.
​
Make sure its bookmark is visible and located immediately before the first character of the Section Title (see each of the examples further down this page).
​
Do not change the bookmark.
​
The section looks better when on a page with portrait orientation.
​
Test Case Section characteristics
​
In a Test Case, the LoadTest Database section is optional and can be located anywhere between the Description sections and the Transaction Timer section.
​
It is semi-structured as described above.
​
If you know that a test case won't require LoadTest Database rules, you may decide to delete the section. This can be done in two ways:
-
Using the DoxRunner Manage Sections operation;
​
If you deleted the section from the test case and decide to re-add it, then it can be done in two ways also:
-
Using the DoxRunner Manage Sections operation;
​
If the Solution document also contains a LoadTest Database section with a Parameter name that is the same as one in a test case, then the one in the test case takes precedence.
​
The illustration below shows a typical LoadTest Database section as it appears in a Test Case. Note the following points:
-
The Bookmark must be structured as shown in the previous section:
-
That is, "P_", followed by the Test Case ID, followed by "_LoadTestDatabase";
-
For example, if the Test Case ID is TCN35, then the bookmark should be P_TCN35_LoadTestDatabase;
-
-
The symbol is an optional link to the top of the Test Case for easier navigation.
​
Example
​
Test Case Template Section characteristics
​
The LoadTest Database section is optional and can be located anywhere in the Test Case Template between the Description sections and the Transaction Timer section.
​
It is semi-structured. The structure is described above.
​
It must be referenced by a Bookmark that must be located immediately before the Section Title.
The Bookmark is structured as follows: P_LoadTestDatabase
​
The Body Text is expected to contain generic text that will be copied to any new Test Case then updated by the scripter.
​
The Table must have a minimum of two rows - a Heading row and a Data row - and two columns as shown below.
It is recommended that you leave the table empty and populate it only after it's incorporated into a Test Case. If the Data row contains a rule, then that rule is copied to any new test case.
​
Example
​
Solution Document Section characteristics
​
The LoadTest Database section is optional and can be located anywhere in the Solution document.
​
LoadTest Database rules are normally defined in the LoadTest Database section of a Test Case, however they can also be documented in the Solution document. This is optional. A LoadTest Database section is included in the original downloaded version of the Solution document and is available unless it was manually deleted after the document was downloaded.
​
There is only one way to add rules to the LoadTest Database section of a Solution document and that is to manually insert them into the table.
​
If it exists, the section it is semi-structured. The structure is described above and illustrated below. It's structure is identical to the Test Case.
​
It must be referenced by a Bookmark that must be located immediately before the Section Title.
The Bookmark is structured as follows: V_LoadTestDatabase
​
Why would you use the Solution document to document LoadTest Database rules? You don't need to, but if there are rules that are common across multiple Test Cases, then they may be easier to manage if placed in the Solution document instead. In fact, to take an extreme view, you can document -all- LoadTest Database rules in the Solution document and define -none- in the Test Cases, if that is easier to manage. The choice is yours.
​
If a rule in a Data row of the Table contains a Parameter name that is the same as one in a Test Case then the one in the test case takes precedence.
​
Example
​
Add a LoadTest Database Rule
​
In all cases, each LoadTest Database rule is added as a row in the table that is embedded in a LoadTest Database section. The section must exist in the appropriate place beforehand.
​
They can be added to a Test Case in two ways:​
-
Manually add a row in the table that should exist in the appropriate LoadTest Database section;
-
Via the green Parameter Association screen during a Process Raw operation.
​
It can only be added to the Solution document or the Test Case Template manually.
An empty table is present in the Test Case Template when downloaded from this site. Rules are not normally added to this table, but can be in the rare case where a rule is known to be needed in all (or most) new test cases.
​
The Reverse Engineer operation does not recognize LoadTest Database rules.
​
​
Add a LoadTest Database rule manually
This can be done in a test case, the Solution document, and the Test Case Template. Make sure the LoadTest Database section exists. It should exist unless you have deleted it.
​
Adding a rule manually is simply a matter of adding a row to the table and typing in the details, making sure there is one row per parameter as illustrated below.
Only the Parameter and Configuration columns are used by the Process Raw operation. Extra columns can be added, but are ignored by the Process Raw operation. A Description column is optional but recommended.
Refer to the Overview above for details of each column. Take particular note of the Configuration column.
​
List of valid Operations
Follow the links to see the skeleton code that the Process Raw operation places in the DatabaseOperations.c file.
Get Random Reads a record randomly from the table given a status and, optionally, a where clause.
The record is also available to be updated later by one of the two update functions below.
Get and burn Reads a record randomly from the table given a status and, optionally, a where clause.
Increments the status by 1 and re-writes the record. The record is also available to be updated later by one of the two update functions below.
Put Creates a new record given the status and a list of columns.
Update Re-writes the record previously read, given the list of columns to update and a status.
Update status Updates the record previously read, but only updates the status.
Add using the Green Parameter Association Screen
​
If, during the Process Raw operation, it is noticed that a LoadTest Database rule can be applied to an Unassociated Name / Value Pair (that is, one that appears in the top left hand pane of the green Parameter Association screen), then it can be added to the Test Case.
​
This is done implicitly if you type in new details in the boxes at the bottom of the top right hand pane. Note that the Description isn't added here - it must be added to the rule in the table manually once the Process Raw operation has completed.
​
Add using the Reverse Engineer Operation
​
The Reverse Engineer operation is designed to update the documentation for a Test Case from a legacy script.
However LoadTest Database rules are not included in this process.
​
Delete a LoadTest Database Rule
​
A LoadTest Database rule can be deleted from a Test Case in two ways:
-
Manually delete a row in the table that should exist in the appropriate LoadTest Database section;
-
Via the Green Parameter Association form during a Process Raw operation.
​
It can only be deleted from the Solution document or the Test Case Template manually.
​
Delete manually
Except for the last one, deleting a LoadTest Database rule is simply a matter of manually deleting the appropriate row in the table in the relevant LoadTest Database section.
​
Deleting the last rule can be done in two ways:
-
Simply clear all cells in the row (do not delete the row);
-
Delete the entire section.
​
If it is expected that there will be no need for any more in that test case or the Solution document, consider deleting the section altogether, making sure you delete its associated bookmark too.
​
Delete via the green Parameter Association screen
The green Parameter Association screen is displayed during the Process Raw operation. When it is displayed, any of the LoadTest Database rules can be deleted as shown in the illustration below.
​
