top of page

 

Configuration

 

Getting Started

Documentation

Configuration Items

Test Case Operations​​​

​Script Operations

The configuration section contains a list of configuration Items (CIs) that DoxRunner depends on to navigate the documents.

 

They are usually not important to the business side of the solution, so in that context their inclusion is not important. So, depending on the organisational context, it may avoid confusion if the Configuration section is deleted from the Solution document prior to releasing it to anyone outside of the performance testing team.

​

But, unless releasing the Solution document to outside parties, do not delete it.​

​​

The configuration section is included in the Solution document at bookmark V_Configuration when you download it from this site. It is mandatory, and it is critical that you update it with details of your specific environment. Refer to Getting Started below.

​

It is not included in the Test Case Template when you download that document from this site because it is not expected to be needed in any Test Case. However, there may be occasions where a Test Case does require one or more Configuration Item to be different. In that situation, a configuration section can be added to any Test Case. Refer to the Test Case Operations section below to add it to a specific Test Case.

​

Only add the section it to the Test Case Template if you think you will need to have one or more CIs different in many Test Cases. If so, you will need to add it manually to the Test Case Template.

​​​

The CIs can be categorised into seven separate groups:

​

  1. Foundation CIs

  2. Folder CIs

  3. Timer CIs

  4. Validation Template CIs

  5. Correlation Option CI

  6. VTS CIs

  7. LoadTest Database CIs

​​

​​​​

Getting Started​

​

The Configuration section is included in the Solution document when it is downloaded from the DoxRunner site.

​

Referring to the Documentation section further in this page:

​

  1. ​Assess the Section Title and update it if necessary.

  2. ​Make sure the table has the two mandatory columns (Type and Value), each with the specified heading text. A Description column is included and is recommended.

  3. ​Assess the Body Text between the Section Title and the Table and update it if necessary.

  4. ​Make sure its bookmark is visible and located immediately before the first character of the Section Title. ​Do not change the bookmark.

  5. There is one Configuration Item (CI) per row. Assess each one and update them to suit the Solution.​

​​

Optional CIs can be deleted if they are irrelevant to the Solution. For example, if you have no intention of using the LoadTest Database facility, then the Database Name and Database Server Name CIs can be deleted.

​

CIs can  be added, but they will be ignored by DoxRunner operations.

​​

 

​

Documentation

​

Solution Document

Test Case

Test Case Template

Configuration Section

Configuration Items

​​​​​

​As with most Managed Items, Configuration Items are documented within a Microsoft Word section, as detailed in the following sections. ​

​

They usually only appear in the Solution document within the Configuration Section because they are usually the same across all Test Cases.

​

However, occasionally one or more Test Cases require one or more CIs to be different to those documented in the Solution document. Hence a Configuration section may, optionally, be documented in one or more Test Cases.

​

If many Test Cases require a Configuration Section, then one may be placed in the Test Case Template.

​​​​​

 

​

Solution Document

​​​

​​A Configuration section is mandatory in the Solution document, is semi-structured.  It can be located anywhere in it, but usually as the last section.

​

​It must be referenced by a Bookmark that must be located immediately before the Section Title. 

 

The Bookmark is structured as follows: V_Configuration

 

All possible CIs will be in the Solution document when you download it from the DoxRunner site. All you need to do is manually delete those you don't need, and manually update those you do.

 

​If a CI is the same as one in a Test Case, the one in the Test Case takes precedence in any DoxRunner operation.

​​​

​​

​

Test Case

​​

Normally a Configuration section is not required in a Test Case - those in the Solution document are referenced where required. However, if one or more CIs are required for a Test Case that needs to have a different value to the corresponding one in the Solution Document, then a Configuration section can be inserted into the Test Case containing those CI(s).

 

The value in the Test Case will override the corresponding one from the Solution document.

​

The section can be added using the Add Section Test Case Operation as shown in the illustration below.

 

The only difference between the Test Case version and the Solution document version is the Bookmark. It must contain the Test Case ID and is structured as follows (where CEP001 is an example Test Case ID). See also the Section Title further down this page.

P_CEP001_Configuration

​

​

 

​

Test Case Template

​

The Configuration section is not normally present in the Test Case Template that is downloaded from the DoxRunner site. ​

It's inclusion should only be considered if there are expected to be many Test Cases requiring it as discussed in the previous section.

​

If it is required, it must be added manually and located anywhere in the Test Case Template between the Description sections and the Transaction Timer section, preferably just before the Transaction Timer section.

​

It is semi-structured. The structure is identical to the versions in the test case and Solution document, with the only difference being the name of the referencing bookmark, which is: P_Configuration

​​

At this stage it must be added manually. Only add those CIs that you know will be required in the Test Cases.​

​​​

 

​

Configuration Section

​​​​​​​​​​​

Configuration Section Title

Configuration Section Description

Configuration Section Table

​Configuration Column Headings

​​​​​​

​​​​​A Configuration section is mandatory in the Solution document, is semi-structured, and usually appears only in the Solution document.  It can be located anywhere in it, but usually as the last section.

 

However in some cases, it may optionally appear in a Test Case and/or the Test Case Template, usually as a cut-down version.​​​

​​Each instance of the Configuration section consists of:

  • a Section Title;

  • a Bookmark;

  • a Description;

  • a Table with, ideally, three columns (Type, Value, and Description);

  • Only the Type and Value columns are mandatory, but the Description column is highly recommended;

  • More columns can be added.

​​​​

An example of the Configuration Section is reproduced in the illustration below.

​​

The Bookmark:​

  • Location: Immediately before the Section Title;

  • Structure: Depends on which document the section is embedded in:

    • Solution document: V_Configuration

    • Test Case: P_TST110_Configuration (where TST110 is the Test Case ID)

    • Test Case Template: P_Configuration

​​

The Section Title:

  • Structure: Free-format text immediately preceded by the Bookmark;

  • 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

  • Structure: free-format text and optional:

  • Location: between the Section Title and the Table;

  • Style: I_BodyText;

  • Length: Cannot be longer than 1,000 characters.

​​

The Table:

  • Location: immediately below the Body Text (or Section Title if there is no Body Text):

  • A minimum of five rows:

    • A heading row and 5 data rows;

    • A Type column and a Value column;

    • More columns can be added;

    • A Description column is recommended.

  • All cells in the Type and Value columns must conform to specific text, as described in following paragraphs.​

​​

 

​​

Configuration Section Title

​

The Section Title is slightly different depending on the document in which the section resides, as discussed in the following paragraphs.

​​

​​​​​​

Solution Document Section Title

​

The example in the illustration on the right shows the Section Title

and its three components as it is expected in the Solution Document:

​​​​​​

​       The Bookmark:​

  • It's mandatory;

  • Located immediately before the Title Text;

  • Indicated by the small vertical bar located immediately before the Title Text;

  • If you cannot see the vertical bookmark bar, it's a good idea to configure Word so that bookmarks are visible;

  • Do not move it or change it unless it's in the wrong place. DoxRunner depends on it during all Test Case operations;

  • Structure: V_Configuration;

  • Length: Cannot be longer than 30 characters.

​

       The Title Text can be manually modified to any text desired.

  • It's mandatory;

  • Located immediately after the bookmark and above the Section Description;

  • Structure: Free-format text;

  • Length: Cannot be longer than 200 characters;

  • Style: I_Heading n or I_Appendix n, where n can be an integer from 1 to 5.

​

       The triangle following the Title Text is a link to the top of the Test Case Summary Section. It is useful for navigating around the                  Solution document. It is useful, but not critical, so it can be deleted if it annoys you.​​​

​​​​​​

 

​

Test Case​​​​ Section Title

​

The example in the illustration on the right shows the Section Title and its three

components if, in the unlikely case, it were to be added to a Test Case:

​​​​​

​       The Bookmark:​

  • It's mandatory;

  • Located immediately before the Title Text;

  • Indicated by the small vertical bar located immediately before the Title Text;

  • If you cannot see the vertical bookmark bar, it's a good idea to configure Word so that bookmarks are visible;

  • Do not move it or change it unless it's in the wrong place. DoxRunner depends on it during all Test Case operations;

  • Structure: V_CEP001_Configuration (where CEP001 is the Test Case ID);

  • Length: Cannot be longer than 30 characters.

​

       The Title Text can be manually modified to any text desired.

  • It's mandatory;

  • Located immediately after the bookmark and above the Section Description;

  • Structure: Free-format text;

  • Length: Cannot be longer than 1,000 characters;

  • Style: I_Heading n or I_Appendix n, where n can be an integer from 1 to 5.

​

       The triangle following the Title Text is a link to the top of the Test Case. It is useful for navigating around the Test Case. 

        It is useful, but not critical, so it can be deleted if it annoys you.​​​

​​​​​​

​​

Test Case​​​​ Template Section Title

​

The example in the illustration on the right shows the Section Title and its

three components if it were to be added to the Test Case Template:

​​​​​

​       The Bookmark:​

  • It's mandatory;

  • Located immediately before the Title Text;

  • Indicated by the small vertical bar located immediately before the Title Text;

  • If you cannot see the vertical bookmark bar, it's a good idea to configure Word so that bookmarks are visible;

  • Do not move it or change it unless it's in the wrong place. DoxRunner depends on it during most Test Case operations;

  • Structure: P_Configuration;

  • Length: Cannot be longer than 30 characters.

​

       The Title Text can be manually modified to any text desired.

  • It's mandatory;

  • Located immediately after the bookmark and above the Section Description;

  • Structure: Free-format text;

  • Length: Cannot be longer than 200 characters;

  • Style: I_Heading n or I_Appendix n, where n can be an integer from 1 to 5.

​

       The triangle following the Title Text does not link to anywhere. It is a placeholder, ready for a link when a Test Case is created.

        It is useful, but not critical, so it can be deleted if it annoys you.​

​​

 

​

Configuration Section Description

​​​​

  • The Section Description is optional;

  • Location: between the Section Title and the Configuration Table;

  • Structure: free-format text;

  • Length: Cannot be longer than 1,000 characters;

  • Style: I_BodyText;

  • DoxRunner operations do not use this text.

​​​​​

 

​​

Configuration Table

​​​

The Configuration Table is the heart of the documented Configuration Items.

​

  • It's mandatory;

  • Located: immediately below the Section Description (or Section Title if there is no Section Description):

  • Must have a heading row with the exact heading text shown in the illustration below;

  • Data rows:

  • Ideally three columns:

  • Do not change the column heading text - DoxRunner operations use them;

  • All cells must conform to specific rules, as described in the Column Headings and Configuration Items below.​

​

* So long as the instance in the Solution document contains the five mandatory rows.

​​​​​​​​​

​

 

Configuration Column Headings​

​​​​

​​The illustration below shows the two mandatory column heading text.

​​​

The illustration below shows all of the Types of CI that DoxRunner recognises. Note the five mandatory Types;

 

The illustration below shows example Values;

​

The illustration below shows example Descriptions.

​

 

Type Column

​

Refer to xxx in the illustration above.

​

This column is simply the name of the CI. Only the CI Types present in the Solution document when it is downloaded and explained in more detail below are accepted. If any others are added, DoxRunner ignores them. If any are deleted, some DoxRunner operations may fail.

​​​

 

Value Column

​

Refer to xxx in the illustration above.

​

This column contains the value of the CI Type when DoxRunner operations need it.

​

 

Description Column

​​

Refer to xxx in the illustration above.

​

This column simply provides context for the CI. It is optional, and DoxRunner does not use it.

​​

 

​

Configuration Items

​​​​​​​​​​​

Foundation CIs

Folder CIs

Timer Name Template CI

Default Think Time CI

Correlation Option CI

Validation Template CIs

VTS CIs

LoadTest Database CIs

​​​​​​

​​DoxRunner uses CIs in many operations for a number of reasons. Five are mandatory, many are optional.

​

They only exist in the Solution document when it is downloaded from the DoxRunner site, not the Test Case Template.
 

However, a Configuration section can be added to a Test Case if one or more CIs only apply to that Test Case, overriding the one(s) in the Solution document.

​

Although it's not included in the Test Case Template when it's initially downloaded, it can be added manually if necessary, and it will then appear in all Test Cases that are created from it.

​

The CIs are grouped into eight categories as listed on the left and explained in more detail below.

​​​

 

​

Foundation CIs

​

There are six Foundation CIs. With the exception of the Protocol CI, they are simply for documentation purposes. Any of them can be deleted if they are not relevant to the solution.

 

 

Whenever the Process Raw operation is applied to a Test Case, it places the Value into vuser_init.c as a comment. See the  illustration below. The illustration also shows the Test Case Long Name and Generation Date, which aren't CIs but are included for reference.

 

The date refers to the date when the Process Raw operation was applied, not the date when it was recorded or last manually updated. 

 

Each of the six foundation CIs are described in more detail in the six paragraphs following the illustration.

 

 

Organisation

​

This is used for documentation only. Choose a short version of the organisation. It appears at the top right hand corner of all screens and as a comment in vuser_init.c as illustrated above.

​

​Solution

​

This is used for documentation only. It only appears as a comment at the top of vuser_init.c as illustrated above.

 

Project

​

This is used for documentation only. It only appears as a comment in at the top of vuser_init.c as illustrated above.

​

Release

​

This is used for documentation only. It only appears as a comment in at the top of vuser_init.c as illustrated above.

 

Environment

​

Normally performance testing is executed in its own environment, and there are many reasons for this. However, if the script needs to be executed in more than one, then there may be subtle differences between them.

 

The Value of the Environment CI will be inserted as a comment at the top of vuser_init.c as illustrated above, but it may be used for conditional execution also.

 

For example, if the script needs to be tested in a SIT environment but executed in an SVT environment, then it may be more convenient to toggle URLs between them, using a Global Custom parameter and/or an Additional Attribute based on this Environment CI.

​​

Protocol

 

The default is HTTP/HTML. Other values are:

  • Siebel

  • SAP Web

  • MS Dynamics CRM

 

The Value of the Environment CI will be documented at the top of vuser_init.c as illustrated above.

 

Some specialized operations are utilized by DoxRunner operations when Siebel or SAP Web is specified.

 

 

​

Folders

​

There are three folders that the DoxRunner operations need to know about. They tell them where to find certain files. The illustration below shows how to configure them. It also shows them located on the C: drive, however they can all be located on a network drive if that is more appropriate for team access, so long as the drive is configured with sufficient capacity (especially throughput).

​

The three paragraphs below the illustration describe them in more detail.

 

 

Support folder

​

The Solution document and the Test Case Template documents must be placed in this folder.

​

A Test Case will be placed here when it's checked out. To check-in a test case, it must be placed here beforehand.

​

Although not essential, the DoxRunner.docm file can also be placed here too, especially for a single solution.

​

 

Script folder

 

This folder contains all scripts that the DoxRunner Script operations need to support.

​

 

Included Files folder

​

This folder contains all files that the DoxRunner Script operations need to include in a script. Although the illustration below shows this folder to be a sub-folder within the scripts folder, this is not necessary - it can be anywhere.

​

Any file in this folder that has .c as the extension is inserted into the Actions section of the script (examples include mySQL.c, SessionManagement.c and Libs.c). 

 

Any file that has a .dat or .txt extension is simply copied into the script's folder if there is a Text Data File parameter in the script referencing it.

​​

All other file types are added under the Extra Files section (examples include mySQL.dll and pcre3.dll).

​

 

Example folders

 

The example folder structure shown here was manually created. DoxRunner's operations do not create them.

 

Although the structure is shown on the C: drive, it could be located on a network drive for team access and operation.

​

 

        Support folder

 

        Script folder

​

        Included Files folder

​

 

​

Timer Name Template CI

 

​

 

This CI guides the Process Raw operation to reformat timer names from the ID-only format (as recommended during recording) to a proper name.

 

Different organisations use different formats for the names of their timers. The most common examples are:

     <Timer ID> <Timer Name>

     <Timer Case ID> <Timer No> <Timer Name>

     <Timer Case ID> <Test Case Name> <Timer No> <Timer Name>

 

Use one of the above or make up your own from one or more of the following, in any combination:

     <Timer No>

     <Timer Name>

     <Test Case Name>

     <Test Case ID>

 

Use whatever you want as the delimiter (space, underscore, dash, anything). Although absurd, the following templates are valid:

     <Test Case ID> amy <Timer No>???<Timer Name>

    <Test Case Name>@#$ <Timer Name>

    <Timer ID> 444<Timer ID><Test Case Name>

​​

Examples:

 

​

Default Think Time CI

 

 

If there is no entry in a Transaction Timer's Think Time column, then the value set by the Default Think Time CI is used.

 

Also, there is an option in the Process Raw operation is to replace the recorded think times with a constant value.

The Default Think Time value is used in that case too.

​

 

​

Validation Template CIs

 

 

These two CIs are optional and are used to assist in the preparation of web_reg_find() functions by the Process Raw operation. They can be used to supplement those that are defined in your instance of VUGen, which is restricted to <title> </title>. One difference is that the LB and RB specified here in the Configuration section are included in the web_reg_find() function, whereas the one defined in VUGen excludes them. Including them enhances page verification.

​

When processing a script, the Process Raw operation prepares one web_reg_find() function per Timer. The first request in a step is special. If the Validation column in the Timers table is not empty, it uses that. However, if it is empty, it searches the appropriate response in the snapshot file(s) for text bounded by the above two Validation Template CIs. If found, it uses that text.

​​

​web_reg_find("Text=<script type='text/javascript' src='/ui/general.js'></script>",LAST);

​

​

Validation Template

​

The LB and RB can be specified as CIs in the Configuration section of the document. The Process Raw operation will search all responses  and, if the LB and RB are identified, a web_reg_find() function is placed immediately prior to the relevant request. The LB and RB text is included in the web_reg_find() function.

​

Example:

The illustration below shows the boundaries to be <ins and </ins>.

If this text is found in the response: <ins>Create Purchase Order</ins> ...

    ...then web_reg_find() this function is inserted immediately prior to the appropriate request:

web_reg_find("Text=<ins>Create Purchase Order</ins>", LAST);

Advantages:

1. The boundaries can be different to the VUGen default;

2. The tags are included.

​

Disadvantages: 

1. May not apply to all responses.

​​​

Validation2.gif
​

Validation template examples

 

Example 1 - Standard VUGen

​

1. VUGen Recording Options configured as shown on the right;

2. Both LB and RB DoxRunner Validation Template CIs are deleted;

3. The Validation column of the DoxRunner Timer is empty;

4. The response to the first request in the step contains:

       <title>Available Sugar Content</title>

 

 

 

       Outcome:

ValidationCI04.gif
ValidationCI01.gif

 

​

Example 2 - Validation Template CI only

​

1. VUGen Recording Options are disabled as shown on the right;

2. Both LB and RB DoxRunner Validation Template CIs are in place:

         LB = <title 

         RB = </title>

3. The Validation column of the DoxRunner Timer is empty;

4. The response to the first request in the step contains:

       <title>Available Sugar Content</title>

 

 

 

 

 

 

 

 

       Outcome:

ValidationCI02.gif
ValidationCI07.gif

 

 

Example 3 - Validation Template CIs exist and the DoxRunner Timer contains text in the Validation column

 

1. VUGen Recording Options are disabled as shown in the previous example above;

2. Both LB and RB DoxRunner Validation Template CIs are in place:

         LB = <title 

         RB = </title>

3. The Validation column of the Tmers table contains:

         Unploughed fields are difficult.

 

 

 

 

4. The response to the first request in the step contains these two items of text:

       <title>Available Sugar Content</title>

       Unploughed fields are difficult.

 

       Outcome:

​

ValidationCI09.jpg
ValidationCI07.jpg

 

​

Correlation Option CI

 

This simple Yes/No CI tells the DoxRunner operations whether to process Correlation Rules using the DoxRunner Process Raw operation, or leave it up to the native VUGen process.

​

Yes: Process the Correlation rules in accordance with the Correlation Rules in the Solution document and/or the Test Case;

No:  Leave it up to the native VUGen process, or correlate manually.

​

 

​

VTS CIs

 

 

The VTS CIs are used by the DoxRunner Process Raw operation to configure the VTS connect statement in vuser_init.c as shown in the illustration below. 

​

If the CTOPT_KEEP_ALIVE argument is not appropriate, it will need to be manually changed.

 

VTSCI02.gif

 

​

LoadTest Database CIs

 

 

If you do not intend to use the LoadTest Database for data management, then feel free to delete these CIs and ignore this section.

 

A MySQL database installation can consist of multiple databases. These can be used for several purposes such as one database per project, or one per release or one for everything. If a MySQL database is used as the LoadTest Database, only the database name and database server name are required here. However it is expected that all elements of the LoadTest Database are set up properly in mySQL.c.

 

The DoxRunner Process Raw operation will assign the Database Name CI to a parameter in vuser_init.c as shown in the illustration below.

​

The parameter is used when theDoxRunner Process Raw operation prepares the DatabaseOperations.c action file also as shown in the illustration below.

 

 

​

Test Case Operations

​​​​

Add Configuration Section

Delete Configuration Section

​​​​

​The Test Case Operations option is used to manage a Configuration section, but only in the unlikely situation whereif it's needed in a Test Case.

​

​​

​

Add Configuration Section

​

If a Configuration section needs to be added to a Test Case, then use the Add Section function within the Test Case Operations suite.​

 

 

​        Select the Test Case;

 

        Press Test Case Operations;

 

        Select Manage Sections;

 

        The Configuration option should                            be empty. If so, select it. It should

        change to Add;

​

        Press Apply. Check that it added OK;

 

        Add CIs as required.

        Make sure the CI name matches the                      corresponding one in the Solution                         Document.​​

​

​​​​​​​​

​​

Delete Configuration Section

​

If a Configuration section was added to a Test Case but needs to be deleted,  then use the Delete Section function within the Test Case Operations suite.​

 

 

​        Select the Test Case;

 

        Press Test Case Operations;

 

        Select Manage Sections;

 

        The Configuration option should                  show Exists. If so, select it. 

       It should  change to Delete;

 

        Press Apply.

 

Check that it deleted OK.

​​​​​​​​​​​​​

 

 

Script Operations

​​​​

​Configuration Items is used in the Process Raw operation.

​​

bottom of page