DoxRunner
Macquarie University Student Accommodation
Overview
A section is one of the building blocks of the documents described in this site. Each Test Case has it's own sections, but the focus of this page is on the sections in the Solution document.
Many sections are related to those in the Test Cases and work with the Process Raw operation when parameterising a raw script. Those are optional.
​
Two sections are mandatory: Test Case Summary and Configuration.
​
Generic section structure
​
Like those in the Test Cases, the sections in the Solution document are semi-structured. They consist of a bookmark, a title, body text, and a table.
​
Bookmark
​
All Solution document section bookmarks conform to Microsoft Word rules. They start with V_ and are followed by 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. For example, the bookmark for the Text Data File section in the Solution document is V_TextDataFile, while the corresponding section in a test case is P_<>_TextDataFile (where <> represents the Test Case ID). In this case 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. Where appropriate, the triangle contains a link to the Test Case Summary section to facilitate navigation.
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.
Table
​
All managed sections in the Solution 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 test case sections
Unless they were deleted from the Solution document, 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 Descriptions.
​
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 the Solution document must be manually managed. That is, deleting a section must be done manually. Adding a section must also be done manually. Most sections are optional, but don't delete the mandatory sections.
​
Follow the More Details links so that deleting and adding sections are done properly.
​
Section overviews
​
All sections in the Solution document 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 Test Cases, where they are mandatory.
​
Test Case Summary section
This section is mandatory and, as the name suggests, it contains a summary of the Test Cases. For obvious reasons there is no equivalent in any Test Case.
It enables the DoxRunner's Test Case and Script operations to navigate to specific test cases.
​
As a section, it is highly structured. It consists of a bookmark, a section title, body text, and a table.
​
-
Bookmark = V_TestCaseSummary
-
Table - must contain at least two columns with heading text Test Case ID and Test Case Name. A Description column is ideal.
​
There is no need to touch this section - DoxRunner's Test Case and Script operations will manage it. However, you can update the text and add columns to augment the information in it. Do not change the column headings of the two columns that are critical to the operation of DoxRunner's Test Case and Script operations - these are Test Case ID and Test Case Name.
​
The entries in the Test Case ID column contain bookmark hyperlinks to the top of the actual Test Case to facilitate navigation. For example, if you have just opened the Solution document with the intention of editing a specific Test Case, a fast way to get to it is as follows:
​
1. Follow the link to the Test Case Summary section that appears on the title page;
2. Follow the link to the Test Case that appears in the Test Case ID column.
​
Example:
​
Configuration section
This section is mandatory and must be tailored to suit the solution. It's used by the DoxRunner's Test Case and Script operations to find its way through your environment and the options you use. You won't be able to create test cases without it.
It acts like a .ini file in that it tells the DoxRunner's Test Case and Script operations how to go about its business. It is normally buried as an appendix to the Solution document because, once tailored to the solution, it has little relevance to a human reader. The image below is an example only. Each row of the table can be viewed as a Configuration Item (CI).
As a section, it is highly structured. It consists of a bookmark, a section title, body text, and a table.
​
-
Bookmark = V_Configuration
-
Table - must contain at least two columns with heading text Type and Value. A Description column is ideal.
Before creating any test cases you must review all CIs and make a decision about each.
​
Example:
Test data sections
​
Test data is critical to the execution of scripts during a test. DoxRunner caters for three types of test data:
-
Text data files;
-
Virtual table server;
-
LoadTest database.
The paragraphs below provide an overview. Follow the More Details links for more details.
All of them are optional so they can be deleted (manually) if not required.
If one rule appears in the Solution document and a Test Case, then the version in the Test Case takes precedence.
​
These sections are highly structured and consist of a bookmark, a section title, body text, and a table.
​
Bookmarks to the section title in the Solution document of each are:
-
V_TextDataFiles;
-
V_LoadTestDatabase;
-
V_VTS.
​
The tables 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.
​
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. Entries must be made in the Configuration section and the MySQL infrastructure will need to be set. Four add-in files need to be acquired from DoxRunner. If the parameter of a rule is duplicated in a test case, then the version in the test case is used.
​
Example:
​
Virtual Table Server (VTS)
​
VTS is another method of managing test data provided natively by LoadRunner. 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 a test case, 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 in the Solution document of each are:
-
V_BoundaryCorrelation.
-
V_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 a test case, then the version in the test case takes precedence.
​
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 contains sufficient details (primarily the LB and RB) to be able to identify relevant values in the Requests from the raw script.
​
If the Role contains "Response", then the Configuration column contains sufficient details (primarily the LB and RB) to be able to identify relevant values in the Responses from the script's CodeGenerationLog.txt file.
​
Example:
​
REGEX Correlation
​
If the Role column contains "Request", then the Configuration column contains sufficient details (primarily the LB and RB) to be able to identify all values in all Requests from the raw script.
​
If the Role contains "Response", then the Configuration column contains the REGEX that is to replace the values identified in the Request.
​
Example:
​
Other parameters
In addition to the parameterisation shown in the Test Data section 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 a test case, 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 in the Solution document of each are:
-
V_Custom;
-
V_DateTime;
-
V_Random;
-
V_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. This can be either Once, Each Iteration, or Each Occurrence. Normally the scripter places it in the script manually.
DoxRunner can automate that process using the documented rules.
​
Example:
​
Additional Attributes
​
Additional Attributes aren't reflected in VUGen as a parameter. However there is a benefit in doing so. The 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 three 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 they are duplicated in any test case, 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 in the Solution document of each are:
-
V_NFRs;
-
V_Headers;
-
V_SAPGUI;
​
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:
​
Headers
​
Header rules are only required if LoadRunner doesn't recognize some, as happens in some situations when recording SAP with Chrome.
​
If that's not the case, manually delete this section from the Solution document.
​
The table must contain at least two columns headed Name and Value. Additional columns are ignored by DoxRunner's Test Case and Script operations. A Description column is optional but recommended.
​
Example:
​
SAPGUI
​
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 table must contain at least two columns headed Function Name and Argument Number. Additional columns are ignored by DoxRunner's Test Case and Script operations. A Description column is optional but recommended.
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:
​
