DoxRunner
Macquarie University Student Accommodation
Overview
​
In the context of this site, Boundary Correlation Rules represent a method of documenting those correlation rules that are primarily defined by LB and RB. The documentation is structured in such a manner that the rules can be automatically applied to a raw script that was re-recorded. This saves a lot of time when re-correlating a re-recording. It is a method that is part-way between the current auto-correlation provided by VUGen and the need to manually correlate each time it is re-recorded.
​
Update this table manually while correlating and it can be applied to future recordings. Although it's complex, and manual correlation is still required, the benefits when re-scripting are enormous, especially for complex correlation such as SAP NWBC and Dynamics CRM. It has the best of two worlds: Manual correlation and automated re-correlation.
​
A correlation rule consists of a minimum of two rows in the table, both rows representing one parameter. One row must have a Role of Request and the other must have a Role of Response. There can be multiple Request rules per parameter and multiple Response rules per parameter. The result of a rule is one or more web_reg_save_param_ex functions, positioned in the script file just prior to the request that caused the response that matches the Response rule.
​
The illustration on the right shows a typical rule as it was applied to a script by the Process Raw operation, and the illustration below that shows how it was documented.
The Correlation Rules section is described below.
​
Parameter
​
The Parameter name is mandatory. It appears in the column with heading Parameter in the table of any Boundary Correlation Rules section.
​
Unlike other parameter rules, a Parameter Name can appear multiple times in this column - in fact it should appear at least twice - once for a Request Role and once for a Response Role.
​
It must conform to LoadRunner rules.
​
Role
​
The Role is mandatory. Only two types of Role are valid - Request and Response.
Multiple request and response roles can be configured for each Parameter Name.
​
Configuration
​
The Configuration is mandatory and must have at least two Configuration Components (LB and RB) and, optionally, up to six, as detailed below.
​
Each Configuration Component is prefaced by a Configuration Component ID (eg. LB:, RB:, Scope:) and must be separated by a new line (refer to the example above for a typical format).
​
Refer also to the Boundary Correlation Operations page to understand how these components are used by the Process Raw operation.
​
1. LB:
​
The LB forms one of the standard lr_save_param_ex() arguments. Note that it should not be escaped for LoadRunner - the Process Raw operation will automatically escape it.
​
2. RB:
​
The RB forms one of the standard lr_save_param_ex() arguments. Note that it should not be escaped for LoadRunner - the Process Raw operation will automatically escape it.
​
3. Replace Option:
​
This Configuration Component is optional and is only applicable to a Request Role.
​
When the Process Raw operation identifies a Value in a Request rule, it replaces the Value with the appropriate Parameter. It then attempts to identify subsequent Requests that may be applicable to that Parameter. It does this using two possible ways:
-
by replacing ALL values with the Parameter;
-
by replacing only those values bounded by the LB and RB (this is the safer option, but may not be ideal in some cases).
​
The following Replace values are valid:
All Values;
By Boundary - the default.
​
4. Constraint:
​
This Configuration Component is optional and can apply to either a Request or a Response Role.
​
When the Process Raw is looking for an instance of a rule, it selects a Value between the specified LB and RB. However in some cases only values that contain a digit, or even may need to be all digits.
​
The following Constraint values are valid:
None (the default) - the Value can be any text;
Integer - the Value must be all digits;
Contains a digit - the Value must contain at least one digit.
​
5. Direction:
This Configuration Component is optional and is only applicable to a Response Role.
​
Normally, when searching for a Response that contains the Response rule, the Process Raw operation starts searching from the beginning of the CodeGenerationLog.log file and selects the first one that contains the Response rule and the appropriate Value from the Request. However in some cases, particularly SAP NWBC, there may be several instances and it may not necessarily be the first one (for example, controls that start with 'WD...' and are embedded in a SAPEVENTQUEUE argument to the Request). In the case of SAP NWBC, it is most likely the one closest to the Request. Hence the search should start at the Request and work backwards towards the top of the CodeGenerationLog.log file. In this case, the Direction component should be 'Up'.
​
The following Direction values are valid:
Up;
Down (the default).
​
6. Scope:
​
This Configuration Component is optional and is applicable to a Response Role.
​
The following Scope values are valid:
All (the default);
Body;
Headers;
Cookies.
​
Section Management - Boundary Correlation Rules
​
Common Characteristics
​
A Boundary Correlation Rules 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 Boundary Correlation Rules section consists of:
-
a Section Title;
-
a Bookmark;
-
free-form Body Text;
-
a Table with a minimum of three columns (Parameter, Role and Configuration).
​
The Bookmark:​
-
Mandatory;
-
Location: Immediately before the Section Title;
-
Structure: Depends on which document it is embedded in:
-
Test Case: P_PT001_BoundaryCorrelation (where PT001 is the Test Case ID)
-
Test Case Template: P_BoundaryCorrelation
-
Solution document: V_BoundaryCorrelation
-
​
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 last Data row can contain empty cells (or the section can be deleted);
-
-
A minimum of three columns:
-
A Parameter column, a Role column, and a Configuration column;
-
More columns can be added;
-
A Description column is recommended.
-
-
All cells in the Parameter, Role, 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 two factors:​
-
Whether the Test Case needs Boundary Correlation 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, Role, 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
​
In a test case, the Boundary Correlation Rules 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 Boundary Correlation 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;
-
Manually.
​
If the Solution document also contains a Boundary Correlation Rules section with a rule 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 Boundary Correlation Rules 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 "_BoundaryCorrelation";
-
For example, if the Test Case ID is TC535, then the bookmark should be P_TC535_BoundaryCorrelation;
-
-
The symbol is an optional link to the top of the test case for easier navigation.
​
Example
​
Test Case Template Section
​
The Boundary Correlation Rules 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_BoundaryCorrelation
​
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
​
The Boundary Correlation section is optional and can be located anywhere in the Solution document.
​
Boundary Correlation rules are normally defined in the Boundary Correlation section of a test case, however they can also be documented in the Solution document. This is optional. A Boundary Correlation 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 Boundary Correlation 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 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_BoundaryCorrelation
​
Why would you use the Solution document to document Boundary Correlation 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- Boundary Correlation 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 rule that is the same as one in a test case then the one in the test case takes precedence.
​
Example
​
Add a Boundary Correlation rule
​
In all cases, each Boundary Correlation rule is documented as a row in the table that is embedded in a Boundary Correlation 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 Boundary Correlation section;
-
Via the Reverse Engineer operation from a legacy script.
​
They 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.
​
​
Add a Boundary Correlation rule manually
This can be done in a test case, the Solution document, and the Test Case Template. Make sure the Boundary Correlation 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 at least one row containing a Role of Request and one for Response for each Parameter as illustrated below. Only the Parameter, Role, and Configuration columns are used by the Process Raw operation. There can be more than one Request and more than one Response per Parameter name.
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.
​
Add using the Reverse Engineer Operation
​
The Reverse Engineer operation is designed to update the documentation for a test case from a legacy script.
xxx rules are included in this process, however it's possible that not all rules are captured and documented.
Make sure you check the test case once the Reverse Engineer operation has completed.
​
Delete a Rule
​
Except for the last rule, deleting one can be done manually in all documents by simply deleting the respective row in the table.
​
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.
​
A rule can also be deleted from a Test Case via the green Parameter Association screen during a Process Raw operation, as described below.
​