DoxRunner
​
Overview
A section is one of the building blocks of the documents described in this site, including sections specific to each Test Case.
​
The Solution document also has some sections that complement those in the Test Cases. However the focus on this page will be those in a Test Case.
Almost all sections in a Test Case work with the Process Raw operation when parameterising a raw script. Most are optional.
​
They are managed by DoxRunner's Manage Test Case Sections operation.
​
One section is mandatory: Transaction Timers.
​
Generic section structure
​
Like those in the Solution document, the sections in a Test Cases are semi-structured.
They consist of a bookmark, a title, body text, and in most cases, a table.
​
Bookmark
​
All Test Case section bookmarks conform to Microsoft Word rules. They start with P_ ,followed by the Test Case ID, and end in a section identifier. They are located immediately in front of the section's title as shown in the illustration below.
The section identifier matches that of the corresponding test case section bookmarks.
​
Bookmark Example
For example, the bookmark for the Text Data File section in a Test Case with ID REP007 is:
P_REP007_TextDataFile
By comparison, the corresponding section in the Solution document is: V_TextDataFile.
In these cases the section identifier is TextDataFile. Refer to the full list here.
​
Section Title
​
The title of any section is free-form text up to 200 characters, but the Microsoft Word style should begin with I_Appendix_n
or I_Heading_n. It must be immediately preceded by the bookmark discussed above. Refer to the illustration below.
The triangle at the end of the title is optional and is designed simply to facilitate manual navigation within the document. Where appropriate, the triangle contains a link to the top of the Test Case, which in turn links to the top of the Test Case Summary section.
Body Text
​
The body text is located between the section title and the table. It can be any text up to 1,000 characters. The Microsoft Word style should be I_BodyText.
There should not be any heading styles between the section title and the table, otherwise the Test Case and Script operations will get confused.
Table
​
Most managed sections in the Test Case document have a table that contains the actual rules. Refer to the specific section for the structure of the table, which describes the mandatory and ideal column headings. Other columns can be added. The column headings of the mandatory and ideal columns are important, so make sure you conform.
Relationship with corresponding solution document sections
Unless they were deleted, some sections appear in both the Solution document and one or more Test Case. Those sections that fall into this category are made clear in the Section Overviews.
​
For these sections, there are three scenarios that you may decide to implement:​
​
Scenario 1:
Delete all of these sections from the Solution document and only use the rules specified in each Test Case.
​
In brief:
​
All rules common to one or more Test Cases are defined in those Test Cases. That is, common rules are repeated.
All rules specific to one Test Case are defined in that Test Case.
​
Advantages:
Simple - All rules for a Test Case are together in the Test Case.
​
Disadvantages:
If there are rules that are common to one or more Test Cases, then they will need to be repeated for each Test Case.
​
Scenario 2:
​
Delete all of these sections from the Test Case Template so that none of them appear in any Test Case.
​
In brief:
​
All rules common to one or more Test Cases are defined in the Solution document. That is, common rules are NOT repeated.
All rules specific to one Test Case are also defined in the Solution document.
​
Advantages:
Simple - All rules are defined in one place.
​
Disadvantages:
Obsolete rules may not be identified so the list may grow unnecessarily;
All rules for a Test Case may not be easily identified;
The Process Raw operation will need to read in all rules when processing a single Test Case, taking longer to execute, especially if there are a lot of rules.
​
Scenario 3 (recommended):
​
Use a combination of the two. That is, rules specific to a Test Case and no other Test Case are defined in the Test Case and rules that are common across two or more Test Cases are defined in the Solution document.
​
In brief:
​
All rules common to one or more Test Cases are defined in the Solution document. That is, common rules are NOT repeated.
All rules specific to one Test Case are are defined in that Test Case.
​
Advantages:
Common rules will not need to be repeated across multiple Test Cases.
​
Disadvantages:
The rules for a specific Test Case may appear in two places. That is, those rules unique to a Test Case will be listed in the Test Case, while those common to several Test Cases will appear in the Solution document version. Note that the rules defined in both the Test Case and the Solution document for the same parameter name take precedence.
​
Section operations
​
All sections in any Test Case can be manually managed. However, unlike the Solution document and the Test Case Template, DoxRunner has the facility to assist in adding or deleting an optional section. Most sections are optional, but don't delete the Transaction Timer section.
​
Follow the More Details link so that deleting and adding sections are done properly.
​
Section overviews
​
All sections in any Test Case are described below in brief, with links to more detailed documentation and operations.
Test accounts can only be managed using Text Data Files, the LoadTest Database, or VTS - there is no specific section for them.
Transaction Timers can only be found in the Test Cases, where they are mandatory.
​
Transaction Timer section
​
Transaction timers are critical to the measurement of response times during a test. DoxRunner provides the facility to document several attributes of them in such a manner that they can be applied to a raw script with minimal effort during script recording.
​
The section is mandatory and is highly structured. It consists of a bookmark, a section title, body text, and a table.
​
Bookmarks to the section title have the Test Case ID embedded in them as shown here:
-
P_<test case ID>_Timers
​
It looks better on a page with landscape orientation.
​
The table must contain at least three columns headed ID, Name. and Phase.
​
Ideally, the table should also contain these columns: Notes, Expected Result, Think Time, Response Time NFR, and Validation.
​
Additional columns are not advised due to the already large width. If added, they are ignored by DoxRunner's Test Case and Script operations.
​
Example:
​
Test data sections
​
Many scripts rely on test data for their successful execution during a test. DoxRunner caters for three types of test data as shown in the paragraphs below. All of them are optional and can be deleted.
If the parameter of a rule is duplicated in the appropriate Test Data section of the Solution document, then the version in the test case is used.
​
These sections are highly structured and consist of a bookmark, a section title, body text, and a table.
​
Bookmarks to the section title of each have the Test Case ID embedded in them:
-
P_<test case ID>_TextDataFiles;
-
P_<test case ID>_LoadTestDatabase;
-
P_<test case ID>_VTS.
​
The table must contain at least two columns headed Parameter and Configuration. Additional columns are ignored by DoxRunner's Test Case and Script operations. A Description column is optional but recommended.
​
Text Data Files
​
LoadRunner's native method of managing test data is to use Text Data Files. This section contains their rules and is optional, so it can be deleted.
If the parameter of a rule is duplicated in the Test Data section of the Solution document, then the version in the test case is used.
​
Example:
​
LoadTest Database
​
Using a MySQL database is far more flexible than LoadRunner's standard methods of handling test data. The LoadTest Database section is optional and, if used, contains the rules needed. The MySQL infrastructure will need to be set up and four add-in files need to be acquired from DoxRunner.
If the parameter of a rule is duplicated in the LoadTest Database section of the Solution document, then the version in the test case is used.
​
Example:
​
Virtual Table Server (VTS)
​
VTS is another method that LoadRunner uses to manage test data. The VTS section contains the rules and is optional. DoxRunner doesn't cater for all VTS functions.
If the parameter of a rule is duplicated in the VTS section of the Solution document, then the version in the test case is used.
​
Example:
​
Correlation rules
Correlation is critical to the execution of scripts during a test. DoxRunner caters for two types of correlation as shown in the paragraphs below.
​
Both sections are highly structured and consist of a bookmark, a section title, body text, and a table. They are optional and can be deleted.
​
Bookmarks to the section title of each have the Test Case ID embedded in them:
-
P_<test case ID>_BoundaryCorrelation.
-
P_<test case ID>_RegexCorrelation.
The table must contain at least three columns headed Parameter, Role, and Configuration. Additional columns are ignored by DoxRunner's Test Case and Script operations. A Description column is optional but recommended.
​
The Role column can only contain Request or Response.
​
If the parameter of a rule is duplicated in the appropriate Correlation Rules section of the Solution document, then the version in the test case is used.
​
Boundary Correlation
​
The rules in this section define how web_save_param_ex functions are configured, and where they are located in a raw script.
​
If the Role column contains "Request", then the Configuration column needs to contain sufficient details (primarily the LB and RB) to be able to identify the appropriate values in all Requests from the raw script.
​
If the Role contains "Response", then the Configuration column needs to contain sufficient details (primarily the LB and RB) to be able to identify the appropriate values in all Responses from the script's CodeGenerationLog.txt file.
​
Example:
​
REGEX Correlation
​
DoxRunner provides the facility to document REGEX rules, but the DoxRunner Script operations do not yrecognize them.
If the Role column contains "Request", then the Configuration column needs to contain sufficient details (primarily the LB and RB) to be able to identify the appropriate values in all Requests from the raw script.
​
If the Role contains "Response", then the Configuration column needs to contain the REGEX that is to replace the values identified in the Request.
​
Example: N/A
​
Other parameters
In addition to the parameterisation of test data shown in the Test Data sections and the Correlation sections above, DoxRunner's Test Case and Script operations recognize another four types of parameter as illustrated below. The Process Raw operation uses these sections to enhance raw script parameterisation. All of them are optional and can be deleted.
If the parameter of a rule is duplicated in the Other Parameters section of the Solution document, then the version in the test case is used.
​
These sections are highly structured and consist of a bookmark, a section title, body text, and a table.
​
Bookmarks to the section title of each have the Test Case ID embedded in them:
-
P_<Test Case ID>_Custom;
-
P_<Test Case ID>_DateTime;
-
P_<Test Case ID>_Random;
-
P_<Test Case ID>_AdditionalAttributes.
​
The table in each must contain at least two columns headed Parameter and Configuration. Additional columns are ignored by DoxRunner's Test Case and Script operations. A Description column is optional but recommended.
​
Custom Parameters
​
The standard VUGen configuration for Custom parameters allows the scripter to define when to update its value (either Once, Each Iteration, or Each Occurrence). The scripter manually places the assignment in the script and replaces the appropriate values with the parameter name.
​
DoxRunner automates most of this process.
​
Example:
​
Additional Attributes
​
Additional Attributes aren't reflected in VUGen as a parameter name. However there is a benefit in doing so. The DoxRunner Process Raw operation automatically converts all documented Additional Attributes into a parameter. Hence the documentation requires you to assign a parameter name to all documented Additional Attributes.
​
Example:
​
Other Rules
​
In addition to the parameter rules summarized above, DoxRunner supports the documentation of four other rule types. Each can be used by DoxRunner's Process Raw operation to configure a raw script.
They are all optional and can be deleted.
If the parameter of a rule is duplicated in the Other Rules section of the Solution document, then the version in the test case is used.
​
These sections are highly structured and consist of a bookmark, a section title, body text, and a table.
​
Bookmarks to the section title of each have the Test Case ID embedded in them:
-
P_<Test Case ID>_NFRs;
-
P_<Test Case ID>_Headers;
-
P_<Test Case ID>_SAPGUI;
-
P_<Test Case ID>_Configuration
​
Non-Functional Requirements (NFRs)
​
NFRs are critical to performance testing, but not necessarily for scripting.
​
If used, the table must contain at least three columns headed Category, ID, and Requirement. Additional columns are ignored by DoxRunner's Test Case and Script operations. A Description column is optional but recommended.
Documenting them serves three purposes:
-
Any person reading the document should be aware of the NFRs used;
-
Timers in the Timers section can be linked to an NFR (via the ID cell);
-
The Process Raw operation follows the link in the Timers section and inserts a comment in the resulting script.
​
Example:
​
SAPGUI Functions
​
The SAPGUI section is only of use if you are using LoadRunner's SAPGUI protocol. If not, manually delete this section from the Solution document.
The Process Raw operation extracts values from the documented SAPGUI function arguments and includes them in the left hand pane of the Parameter Association form. The person executing the Process Raw operation is then able to assign those values to the parameters on the right hand pane.
​
Example:
​
