Document a Performance Test Case

Performance Test Case

In the context of this site, a test case is the English description of a LoadRunner script in the form of a Microsoft Word document. Test cases normally reside within the solution document, but can be checked out into their own standalone document.

From a DoxRunner perspective it contains all rules needed to convert a raw script into a one that is parameterised with those rules, saving the scripter lots of time, especially when re-scripting.

It may define a single business process such as creating an invoice, or it may be a subset of one, or it may consist of more than one business process. Regardless of that relationship, there is only one script per test case (although there can be multiple versions of that script).

Getting started

Test case structure

A checked out test case can be sent to individual team members, including offshore teams. It can then be checked back in if it was updated while checked out.

Because they form the heart of DoxRunner's Test Case and Script operations, test cases must be semi-structured, using bookmarks and tables to balance the advantages of DoxRunner's Test Case and Script operations versus documentation flexibility. It is key to improving the efficiency of performance analysts by saving time during re-scripting.

Getting Started

The solution document, when downloaded from this site has no embedded test cases, only the structure ready to embed new ones.

The only thing to do is review the Test Case Template.docx when that is downloaded from this site so that when it is used to create a test case, that test case is close to your requirements.

Test case structure

Test case names have a specific structure, as discussed below.

Since test cases normally reside within the Solution document, the Word styles used are identical. These styles remain the same when a test case is checked out into a separate document.

Like the solution document, bookmarks are used extensively, as discussed below also.

Similarly, test case sections are structured in a manner similar to the Solution document.

Test case naming

Test case names are structured to enhance DoxRunner's Test Case and Script operations. As a side-effect, test case names across all solutions in an organisation become consistent.

All names are made up of a Test Case ID plus a Test Case Name, separated by a mandatory space.

Example: TC001 My Test Case Name, where TC001 is the Test Case ID.

Test Case ID

The Test Case ID is designed to be short for unique reference to a test case and to any script related to that test case.

It is structured with leading letters and trailing integers.

It cannot be shorter than 2 characters - one letter and one integer. eg. G6.

It cannot be longer than 7 characters - three letters and four integers. eg. YUP9987.

Spaces and other characters are not allowed. This is because it forms a critical component of the bookmarks used in all test cases, and bookmarks cannot contain spaces.

The name of all versions of the script that relate to the test case must also begin with the same ID. See Script Naming below.

Test Case Name

The test case name can be any alphanumeric text up to 30 characters, including spaces.

Script naming

One test case can describe one script or multiple versions of the same script.

The script names relating to a Test Case must begin with the Test Case ID, followed by an underscore, then followed by up to 30 alphanumeric characters. Underscores should be used instead of spaces because some versions of LoadRunner won't accept spaces.

The component of the script name following the Test Case ID does not need to match the Test Case Name - only the IDs need to match.

For example, the following script names all relate to test case TC001 My Test Case Name:

TC001_My_Test_Case_Name

TC001_My_Test_Case_Name_Version_4

TC001_Fred_2020-10-05

Test case bookmarks

Bookmarks are essential to DoxRunner's Test Case and Script operations. Unless they are faulty, or point to the wrong place, or you are deleting an optional section, there is no need to change them. Feel free to add more for internal documentation references once you have finished tailoring the document.

Because the test cases are normally embedded in the Solution document, the Solution document contains many bookmarks that aren't related to test cases. Refer to the Solution document itself for more details on these.

All test case-related bookmarks are prefixed by P_ followed by the Test Case ID, then followed by an underscore, then followed by text relevant to the purpose of the bookmark. This text cannot be changed because DoxRunner operations depend on it.

Examples and brief descriptions are listed below (Test Case ID TC001 is used for illustration):

P_TC001 - Critical - points to the title of the test case - do not delete (unless you're deleting the test case manually);
P_TC001_AdditionalAttributes - Optional - points to the Additional Attributes section if it exists;
P_TC001_CorrelationRules - Optional - points to the Correlation Rules section if it exists;
P_TC001_BriefDescription - Optional - points to the Brief Description section if it exists;
P_TC001_Configuration - Optional - points to DoxRunner's Configuration Items section if it exists;
P_TC001_CustomParameters - Optional - points to the Custom Parameters section if it exists;
P_TC001_DateTimeRules - Optional - points to the Date / Time section if it exists;
P_TC001_Headers - Optional - points to the Headers section if it exists;
P_TC001_Purpose - Optional - points to the Purpose section if it exists;
P_TC001_LoadTestDatabase - Optional - points to the LoadTest Database section if it exists;
P_TC001_NFRs - Optional - points to the Non-Functional Requirements section if it exists;
P_TC001_RandomNumbers - Optional - points to the Random Numbers section if it exists;
P_TC001_ReleaseNotes - Optional - points to the Release Notes section if it exists;
P_TC001_SAPGUI - Optional - points to the SAP GUI section if it exists;
P_TC001_ScriptHistory - Optional - points to the Script History section if it exists;
P_TC001_Timers - Critical - points to the heading of the Transaction Timers section - do not delete

(unless you intend to delete the test case manually);

P_TC001_SuccessCriteria - Optional - points to the Success Criteria section if it exists;
P_TC001_TextDataFile - Optional - points to the Text Data File section if it exists
P_TC001_VTS - Optional - points to the VTS section if it exists.

More details

Test case sections

More details

Descriptive sections

Managed items

Follow the link to understand the structure of DoxRunner sections.

The sections in a Test Case can be divided into descriptive and managed items.

Test case sections

All Microsoft Word documents are divided into sections. DoxRunner also uses the concept of sections, but there is a difference between Microsoft Word sections and DoxRunner sections. Refer to the page that describes this difference.

The below is a summary of the managed sections that can be found in a test case.

These are semi-structured so that DoxRunner's Test Case and Script operations can manage them.

Other sections can be added if they contribute to understanding the test case, but the DoxRunner's Test Case and Script operations will ignore them.

This site divides the section descriptions into how they are documented and how the documentation is used by DoxRunner's Test Case and Script operations:

Follow the link to understand the structure of DoxRunner sections.

The sections in a test case can be divided into descriptive and managed items.

Test Case Section Documentation

The links below lead to instructions on the specific way that DoxRunner documents each rule.

Complex screens may be better with a screenshot, but they should be in the minority. Where a screenshot is necessary, it should be included in the Scripting Notes section of the test case, not in the Steps section.