Transaction Timers

LoadRunner measures the response time of each step in a business process via the use of lr_start_transaction() and lr_end_transaction() Timers, which are inserted into a script immediately prior to the first request of a business process step.

Through documentation, DoxRunner's Process Raw operation adds value to the development of a LoadRunner raw script.

Because the steps in a business process are executed sequentially, the name of each timer is prefixed by a sequential integer so that the LoadRunner analysis report also lists them sequentially, facilitating the understanding of the test by the analysis report recipients.

This page consists of four major sections related to Transaction Timers:

How timers are documented in a DoxRunner Test Case;
How timers are documented in the DoxRunner Test Case Template;
How a legacy script can be used to document timers (the Reverse Engineer operation).

Process Raw Operation

Initiating Process Raw Operation

lr_start_transaction()

Transfer Timers using Phase

Error Recovery

One File Per Timer

The DoxRunner Process Raw operation uses the DoxRunner documentation to convert a raw script to one that meets the desired final script, or close to it.

The illustration below summarises what happens with timers when you initiate that Process Raw operation.

Refer to the Timer Section further down this page for details on how the timers are documented.

The recorded Timer IDs are replaced by the Timer Long Name.

The Notes are not used by the Process Raw operation - refer to the Recording Aid section above.

The Expected Results are inserted into the script as comments.

The lr_think_time() function is either untouched, or inserted into the script using the documented Think Time, or a static value is used, depending on the option set. Refer to points xxx to yyy in the Process Raw Options section below;

The text from the Response Time NFR column is assessed. If it references an NFR ID from the NFR Section, then the text from the NFR Requirement column is inserted into the script as comments. Otherwise the text from the Response Time NFR column is inserted into the script as-is.

Although it is normal to record transactions into at least three files (vuser_init.c, Action.c, and vuser_end.c), recording

the DoxRunner way means that all transactions are recorded only into Action.c. Using the Phase column in the timers

table, the DoxRunner Process Raw operation will automatically move Timers from Action.c to vuser_init.c and vuser_end.c.

If the Validation column has a value, a web_reg_find() function is created just before the lr_start_transaction() function using that value.

lr_end_transaction() Function

Once the Timer Long Name is created and applied to the lr_start_transaction() function as shown above, the process raw operation will add the lr_end_transaction() function just after the last request associated with that business process step.

There is no documentation or configuration required - it is all done automatically.

Think Time

When recording a raw script, the think time that LoadRunner records is not necessarily valid in a production environment. The scripter may be interrupted, or paused while figuring out the next step, or may go faster than a typical user. It is often more valid to look at each step and assess a reasonable time, then document that in the think time column of the timer table.

Default operation

The process raw operation only focuses on those lr_think_time() functions that were recorded before the first request in a transaction. That is, if there are multiple requests following the lr_start_transaction() function, DoxRunner does not touch any lr_think_time() functions that may be located between them.

When initiating the process raw operation, you have the option of:

using the value recorded (ie. DoxRunner doesn't touch any of them);
using the value you documented in the timer table (as explained below);
using a fixed value as documented in the configuration section.

These three values are specified at xxx in the illustration below.

In the example in the illustration below:

The documented Think Time is 20 seconds;

The process raw operation option is to use this value;

The script is configured accordingly.

If the value in the think time column is empty, or there is no think time column, then the default value that is documented in the configuration section is used.

Think Time Runtime Settings

Although not related to timers, the think time range in the LoadRunner runtime settings can be specified when the process raw options form is displayed, as shown in the illustration below.

Note also that the runtime settings in the illustration below is set to ignore Think Time. This is set using the assumption that the scripter will want to shake out the script before including it in a test, and think times are irrelevant and slow down the shakeout. It must be changed manually prior to any test.

web_reg_find() Function

Overview

This section refers to the web_reg_find() function and how it is related to the timers.

There are three levels of validation covered here. DoxRunner supports two of them.

Validation

Standard VUGen Validation

This is not a DoxRunner function - it is standard VUGen. When recording, the VUGen setting in the illustration below allows VUGen to identify text between the title tags in the response to a request, and configure the script with web_reg_find()

functions accordingly. If a transaction contains many requests, any resulting web_reg_find() functions may appear before any of them, not just the first one.

Advantages:

All responses are examined and the web_reg_find() function is placed prior to the relevant request;
It's easy to set up and seamless when recording and replaying.

Disadvantages:

The LB and RB tags are not flexible - they are always <title> and </title>;
The tags aren't included in the web_reg_find() function.

For example, if <title>Create Purchase Order</title> is detected in a response, then the following is placed just prior to the relevant request:

web_reg_find("Text=Create Purchase Order", LAST);

DoxRunner Template Validation

As explained in the previous section, standard VUGen searches for text in all responses using <title> and </title> as the LB and RB and prepares the relevant web_reg_find() function.

DoxRunner offers a more flexible method of specifying the LB and RB.

The Configuration section contains two CIs specifying the LB and an RB of a Validation Template. These are used by the Process Raw operation to extract values from the responses in addition to the Standard LoadRunner method.

Also, the LB and RB are included in the web_reg_find() function.

Timer Validation

DoxRunner can prepare additional web_reg_find() functions using the timer's Validation column.

If there is a value in the Validation column, then the Process Raw operation will use it to prepare a web_reg_find() function and place it before the first request in a transaction - just before the relevant lr_start_transaction() function.

Timer Types

DoxRunner supports three types of timer:

Standard - normal LoadRunner start/end transaction functions wrapped around all requests associated with one business process step;
Common - also wrapped around one business process step, but with any context such as the Test Case ID and Timer ID removed - only the Timer Name remains, and the first character is an underscore;
End-to-End - wrapped around -all- requests in Action.c.

Standard Timers

This is the standard timer type, and is the target of the one documented in the Timers section. It is designed to time steps in a business process, and It is the one that all performance test analysts use.

How DoxRunner handles them is discussed at lr_start_transaction() and lr_end_transaction() above.

Common Timer Type

This Timer Type is one that DoxRunner invented.

The more occurrences of a transaction during a test, the better and more reliable the statistics in the analysis report are. However, often the number of transactions during a test, especially within vuser_init.c, are far fewer than ideal. Often some of these transactions are present in more than one Test Case, but are still of interest from a performance perspective. The Standard Timer Type discussed above will report these transactions separately, so the statistical count for each may be relatively low. A typical example is the login step.

The Common Timer Type is designed to improve the statistical reporting in the analysis report of these low-count transactions by naming them with the Timer Name only. They are then collected across all test cases in a test and appear in the analysis report as one line item, containing all occurrences of each within that test.

If selected, the Process Raw operation simply wraps the Common Timer around the Standard Timer, so it essentially duplicates the Standard Timer within one script, but with the effect described in the previous paragraph.

Common timer names begin with an underscore so that when the analysis report is prepared, they appear altogether at the top. In this way you can decide whether to delete them all, or delete all except a sub-set that may be of interest. For example, if a Timer Name of "Press Cane Estimate Button" appears in several scripts, their response times appear in the analysis report in two places

under each Test Case in which they are configured;
in one line as "_Press Cane Estimate Button", representing the statistics of all those that appear in all Test Cases in the test.

If the Timer Name appears in only one test case, then the common type in the analysis report is irrelevant - they will be identical. It's best practice to manually delete these from the analysis report.

Wrapping Common Timers

Select the Add common timers option when presented with the process raw options, as shown below.

The resulting common timers are highlighted in yellow. They only contain the Timer Name, preceded by an underscore.

No other configuration options or documentation is required - it all happens automatically.

End to End Timer

Often a business is interested in the time it takes for all transactions in an iteration. This can be achieved in the analysis report by wrapping a special timer around all transactions in Action.c.

DoxRunner uses a specific name for this timer. For example, if the Test Case ID is "CEP001", and the Test Case Name is "Cane Volume Estimation Process", then the Timer will be configured in the script as:

lr_start_transaction("CEP001 Cane Volume Estimation Process_End_To_End");

It is not necessary to document the end-to-end timer - it is generated automatically if selected when executing the Process Raw operation.

Wrapping End_to_End Timer

If the Add 'End to End' timer option was selected, the process raw operation wraps all requests in Action.c with an 'End to End' Timer.

The illustration below assumes that the Phase column for timers 5 to 14 shows the letter I, short for Iteration.

Select the Add 'End to End' timer option when presented with the process raw options, as shown below.

The End-to-End lr_start_transaction() function is added just before the first timer cluster in Action.c.

It will add the End-to-End lr_end_transaction() function just after the last end timer cluster in Action.c.

No other configuration options or documentation is required - it all happens automatically.

Readability Comment

The Process Raw operation will make all functions associated with each timer easier to visually identify by inserting an easy to see line appended by the Timer ID / Timer Name at the beginning of those requests related to that timer.

This is automatic - there is no documentation or configuration required.

Expected Result

The Process Raw operation inserts the contents of the Expected Result column just below the Readability comment.

This is automatic - there is no documentation or configuration required.

Non-Functional Requirements (NFRs)

The Process Raw operation simply converts the NFR column in the timer table to a comment and inserts it into the script just below the Expected Result comment.

This is automatic - there is no documentation or configuration required.

NFRs are usually solution-wide and are documented in their own NFR Section, with the NFRs having an NFR ID each.

Timers have an NFR associated with each. These are listed under the Response Time NFR column, where they can be documented as a single figure such as 3 secs, or as an NFR ID, referencing the NFR Section.

In the example in the illustration below, the timer is configured with L in the Response Time NFR column. L references an NFR in the NFR Section with Category of Long. The Requirement with NFR ID of L has a summary of the requirement. The Process Raw operation inserts this text as a comment just after the Expected Results comment.

Transfer Timers using Phase

When recording a raw script the DoxRunner way, all transactions will reside in Action.c. They need to be moved - some to vuser_init.c, and others to vuser_end.c. This is done automatically by DoxRunner from the contents of the Phase column.

There are four phases recognized by the Process Raw operation, and they must appear in the same order as the description of each here:

LI - Log In - optional - the step(s) needed to log in.

These are normally moved to vuser_init.c, or a function that is called from vuser_init.c

TI - To Iteration - optional - the step(s) needed to move the session from the login or home page to the first step of the iteration.

These are normally moved tovuser_init.c, or a function that is called from vuser_init.c.

I - Iteration - mandatory - the steps executed during each iteration. These are normally left in Action.c.

LO - Log Out - optional - the step(s) used after all iterations are complete.

These are normally moved to vuser_end.c, or a function that is called from vuser_end.c.

Default operation

Referencing the illustration below, DoxRunner has the following default operation:

Timers 1 and 2 show LI in the Phase column. This is short for Log In. They are transferred to vuser_init.c.

Timers 3 and 4 show TI in the Phase column. This is short for To Iteration. They are transferred to vuser_init.c also.

Timers 5 to 14 show I in the Phase column. This is short for Iteration. They remain in Action.c.

Timers 15 to 99 show LO in the Phase column. This is short for Log Out. They are transferred to vuser_end.c.

The Process Raw operation will:

Transfer Timers 1 to 4 from Action.c to vuser_init.c;
Transfer Timers 14 to 99 from Action.c to vuser_end.c;
Timers 5 to 14 will remain in Action.c.

Note that DoxRunner makes no distinction between LI and TI - these are separate for documentation reasons only.

Error Recovery

If LoadRunner encounters an error while processing the transactions in Action.c, and it is configured to continue processing after error, then the transactions following that error often doesn't make sense to LoadRunner, and the script will continue to fail until it encounters a request that makes sense.

DoxRunner has the ability to configure a script so that if LoadRunner encounters an error in the Iteration phase, it returns to a known point in the application by logging the Vuser off, then back on again. Then the transactions in Action.c will start at the first one, and LoadRunner will continue either without error, or until another error is encountered.

By default, when recording a raw script the DoxRunner way, all transactions are placed into Action.c. The default option of the Process Raw operation described above uses the Phase column to transfer timers from Action.c to vuser_init.c and vuser_end.c.

However the Phase column can also be used to configure the script for error recovery. It looks complicated, and it isn't simple, but it is easy to set up and, once set up, requires no further action.

If LoadRunner encounters an error while processing the transactions in Action.c, and it is configured to continue processing after error, then the transactions following that error often doesn't make sense to LoadRunner, and the script will continue to fail until it encounters a request that makes sense.

DoxRunner has the ability to configure a script so that if LoadRunner encounters an error in the Iteration phase, it returns to a known point in the application by logging the Vuser off, then back on again. Then the transactions in Action.c will start at the first one, and LoadRunner will continue either without error, or until another error is encountered.

By default, when recording a raw script the DoxRunner way, all transactions are placed into Action.c. The default option of the Process Raw operation described above uses the Phase column to transfer timers from Action.c to vuser_init.c and vuser_end.c.

However the Phase column can also be used to configure the script for error recovery. It looks complicated, and it isn't simple, but it is easy to set up and, once set up, requires no further action.

Getting Started

Use the illustration below and the following steps to configure the DoxRunner environment to achieve this behaviour:

Ensure that the Included Folders CI is set and that the folder it references exists;

Create a text file with the following structure and place it into the Included files folder;

The text file must contain these three valid C functions:

Login()
ToIteration();
LogOut().

Each function must contain one of the following

three comments:

// <Transfer phase LI to here>;
// <Transfer phase TI to here>;
// <Transfer phase LO to here>;

How it works

Yes, this is a little complicated, but it is described in detail here for your understanding only. If the simple steps in the Getting Started paragraphs above are done, then there is no further action needed by the scripter - it all happens automatically!!

In the illustration below, one of the files in the Included Files Folder is SessionManagement.c. That file needs to be configured as shown. That is, with three C functions named Login(), ToIteration(), and LogOut(). Each function needs to contain one of the three template comments exactly as shown.

The Process Raw operation copies all files from the Included Files Folder to the script's folder, including SessionManagement.c.

DoxRunner adds any of these files that have extension .c to the .usr file of the script, including SessionManagement.c.

DoxRunner trawls through all Action files looking for text structured as "// <Transfer phase xx to here>;" where xx is one of LI, TI, or LO.

If the text is "// <Transfer phase LI to here>;", then it is replaced by all

timers with Phase LI.

If the text is "// <Transfer phase TI to here>;", then it is replaced by all

timers with Phase TI.

If the text is "// <Transfer phase LO to here>;", then it is replaced by all

timers with Phase LO.

DoxRunner defines iIterationStatus in globals.h

DoxRunner adds the code shown to the top of vuser_init.c.

That is, unlike the default operation of the Phase timer

transfers, timers with Phase LI and TI are not transferred

from Action.c to vuser_init.c.

Instead, vuser_init.c contains calls to

Login() and ToIteration(), which is

where these timers should now be.

In addition, two #define statements

create two variables.

Also, iIterationStatus is initially set to

ITERATION_SUCCEEDED to ensure

that the first iteration is executed.

DoxRunner adds the code shown to

the top of Action.c. If the iteration

succeeded, then the Login() and

ToIteration() functions are not

executed. However, iIterationStatus

is always set to ITERATION_FAILED

at the beginning of each iteration,

anticipating failure which, hopefully,

won't happen.

DoxRunner adds the code shown to

the bottom of Action.c, where it is

assumed that the iteration

succeeded, so iIterationStatus is set

to ITERATION_SUCCEEDED.

If, however, this code is not reached,

then it is assumed that the iteration

failed, so when LoadRunner

attempts to continue on error,

the Login() and ToIteration() functions

are executed, ensuring the iteration

restarts at known point.

DoxRunner adds the code shown

to the bottom of vuser_end.c so that

the timers with Phase LO are

executed.

One File per Timer

Some performance test analysts like to configure their LoadRunner scripts so that there is one file per Timer.

DoxRunner has an option that supports this behaviour.

Select the One file per timer option when presented with the Process Raw options, as shown below.

The Process Raw operation creates a separate action file per Timer containing all requests for that Timer, plus the ancillary functions like lr_start_transaction(), lr_think_time(), web_reg_find() etc. The illustration below shows the first request for Timer 5.

The new action files are called from the relevant vuses_init(), Action.c(), or vuser_end() functions. The illustration below shows Timers 5, 6, and 7.

A list of all action files showing one per Timer for Test Case CEP001.

No other configuration options or documentation is required - it all happens automatically.

Documenting Test Case Transaction Timers

Getting Started

Test Case

Test Case Template

It is mandatory in DoxRunner to include at least one transaction timer per test case, so the timer section in all test cases and the test case Template is mandatory.

Timers are not relevant outside of the test cases, so they do not appear anywhere else in the solution document.

If the script doesn't require a timer (it may be a part of background load, where measuring response times may not be relevant), a dummy timer must be documented.

A timer can only be added to a test case manually, using the guidelines in the following paragraphs.

As with most DoxRunner sections, the timer section has four major components:

Bookmark;
Section title;
Section description
Table.

Getting Started

Items 1 and 2 below are typically only done once, with the occasional review and tweaking if necessary.

Item 3 is where all the action takes place.

1. Test Case Template

When the Test Case Template is downloaded from this site, tailor the Transaction Timer section using the guidelines in the Test Case Template instructions below.

2. When the Solution Document is downloaded:

tailor the Configuration Section for:
- the default Timer Long Name template;
- the default Validation template;
review the NFR Section and update it with any NFRs that the business may require.

3. Create the Test Case(s).

For each Test Case:

Assess the Timer section and update it necessary:
- The Section Title;
- Make sure its bookmark is visible and located immediately before the first character of the Section Title;
- Make sure the table has the two mandatory columns (ID and Configuration), each with the specified heading text.;
- Assess the table to see whether more columns are appropriate.;
- Assess the Description between the Section Title and the Table and update it if necessary.;
Manually step through the business process that the Test Case is meant to simulate;
Add Timer rows in the table of the Transaction Timer Section - one Timer per Business Process step;
Review the following components of each Timer:
- the Notes;
- the Expected Results;
- the Think Time;
- the NFR;
- the Phase;
- the Validation.

Do not change the bookmark.

If all ideal columns are included, then the section looks better when on a page with landscape orientation.

Test Case Template

Document Test Case Template

Create Test Case

A timer section is present in the test case template that is downloaded from the DoxRunner site.

The illustration below shows it when the Test Case Template is initially downloaded.

There is no need to change it. However, if there are timers that are common to most test cases, then those Timers can be added, saving typing when a new test case is created.

The illustration below is an example.

Columns can be added at this stage, and non-mandatory columns can be deleted (not recommended).

Test Case

The transaction timer section is the most important section in a test case. The illustration below is an example.

Test Case

Timer Section

A Timer section is mandatory in all test cases. It is semi-structured, and always appears as the last section in all Test Cases and the Test Case Template document.

As with all managed items, timers are documented within a Microsoft Word section.

Each instance of the timer section consists of:

a section title;
a Bookmark;
a Description;
a Table with, ideally, eight columns:
- ID, Notes, Timer Name, Expected Results, Think Time, Response Time NFR, Phase, and Validation;
Only the ID and Timer Name columns are mandatory, but the remaining six are highly recommended;
More columns can be added.

Section Title

Timer Section Description

Timer Table

Timer Table Column Headings

Due to the number of columns in the timer table, the timer section is best be on a page that is oriented as landscape. Since it is, typically, the only section requiring the page to be oriented as landscape, for document simplicity it is usually the last section in a test case.

An example of a timer section is reproduced in the illustration abone and described in following paragraphs.

Timer Section Title

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

Test Case Section Title

The example in the illustration on the right shows the Section

Title and its three components as it may appear in 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 the Process Raw operation;
Structure: P_AUT6_Timers (where AUT6 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 200 characters;
Style: I_Heading n or I_Appendix n, where n can be an integer from 1 to 5.

Note that the Title Text in the example above includes the Test Case ID and the Test Case Name. This is derived from the structure of the Test Case Template as explained in the paragraphs below. It is an optional feature.

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 in a typical 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 the Process Raw operation;
Structure: P_Timers;
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.

Note the "<IDx> <Namex>" text at the end of the Title Text. This is optional. It is code for the Process Raw operation to insert the Test Case ID and Test Case Name into the Title Text (refer to the example in the Test Case Section Title above). Sometimes it's useful to know which Test Case the Timers apply to, so it's handy when dealing with many Test Cases.

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.

Timer Section Description

When the Test Case is created, DoxRunner uses the Timer Section Description from the Test Case Template.

It's optional;
Location: between the Timer Title and the Timer Table;
Structure: free-format text;
Length: Cannot be longer than 1,000 characters;
Style: I_BodyText;
DoxRunner operations do not use this text.

Timer Table

The Timer Table is the heart of Test Case documentation and many DoxRunner operations.

It's mandatory;
Located: immediately below the Timer Section Description (or Timer Title if there is no Timer Section Description):
A minimum of two rows:
- A heading row and a data row (one data row per Timer);
Ideally eight columns:
- ID, Notes, Timer Name, Expected Results, Think Time, Response Time NFR, Phase, and Validation;
- More columns can be added;
Do not change the column heading text - DoxRunner operations use them;
All cells must conform to specific rules, as described in the Column Headings below.

Timer Table Column Headings

Timer ID

Notes

Timer Name

Expected Result

Think Time

Response Time NFR

Phase

Validation

The illustration below shows the relationship between the eight columns of the Timer table and the LoadRunner script as prepared by the Process Raw operation. Note that there is some interaction with the NFRs documented in the NFR section.

Timer ID Column

Refer to xxx in the illustration above.

DoxRunner identifies transaction timers by a numeric ID followed by the timer name.

The ID is mandatory and is designed to ensure that timers are listed sequentially in the analysis report.

The underlying assumption is that the steps in a business process are executed sequentially, hence the name of each timer is prefixed by a sequential integer so that the LoadRunner Analysis report also lists them sequentially, facilitating the understanding of test results by the report recipients.

The integer must be sequential but there is some flexibility. It can have gaps which allows steps to increment by, say, 10 (ie. 10, 20, 30,...) or if a script has more than one stream, a longer gap can be utilized (ie. 1, 2, 3, 25, 26...etc).

When recording a script, use this number and only this number, as described in the recording section at the beginning of this page. That is, don't use the Timer Name when recording.

Do not leave the Timer ID blank, and use no more than three digits.

Notes Column

Refer to xxx in the illustration above.

This column is designed purely to assist the scripter when recording a raw script. It does not appear in any script or report and is optional.

Use this column to enter notes that are useful to the person recording and debugging the script. When recording a raw script, keep these notes visible to ensure you record correctly and/or update the notes if it's helpful.

Although some notes can be written when defining the test case, it is expected that most updates will occur when recording the first script. Update this column so that future scripters will find it easier to re-record it (including yourself). Include any gotchas, preparation, etc that is relevant to recording the step. Consider it a supplement to screenshots.

If the cell is insufficient to describe what is required, add a paragraph to the Scripting Notes section of the test case, and provide a link to it in the Notes cell. This is particularly useful if a screenshot is necessary.

Timer Name Column

Refer to xxx in the illustration above.

The Timer Name forms a part of the Full Timer Name. It is mandatory and should be a very brief alphanumeric description of the business process step so that it can be better identified by anybody who is the recipient of the Analysis Report. For example, "Press Next", when reported in the Analysis Report, is meaningless. Consider "Accept Details Of Cane Estimate".

Make the Timer Name consistent across all scripts that use the same business process step. This way the Common Timer will represent all instances across all scripts in the Analysis Report.

When all components of the full timer name are combined, it must conform to LoadRunner rules for the lr_start_transaction().

When recording a script, do not use it - use the Timer ID only, as described in the Recording section.

Expected Results Column

Refer to xxx in the illustration above.

This is optional text describing what is expected when the step is executed in a LoadRunner test. The Process Raw operation includes it in the script as documentation.

Think Time Column

Refer to xxx in the illustration above.

Although Think Time is entered by VUGen during recording, it is often unrealistic.

By including it in the Transaction Timer table, the scripter has the opportunity to tailor it based on a more appropriate value that represents how long it would take for a competent user to execute that step.

For example, if a tab or button is to be pressed, the Think Time would be short, whereas if text such as a description or a name is required, then the think time should be much longer

The Process Raw operation will (optionally) replace all think time functions that LoadRunner may have inserted, with the value from the Timer table, and places them immediately prior to the relevant start transaction timer.

Response Time NFR Column

Refer to xxx in the illustration above.

This column is optional and documents the Response Time NFR in two possible ways:

As a value in seconds (example: 5.9 secs);
As a link to the NFR section when the NFR is more complex.

Since NFRs can be more complex than just pinning it down to a single response time, the latter option is recommended. It is easier when liaising with a Business Analyst - each step can then be categorized depending on its task, and each category can then be placed into the NFRs section and described at length.

Phase Column

Refer to xxx in the illustration above.

The Phase is useful if you choose the easy way of recording a raw script. That is, if you choose to record ALL actions in Action.c rather than attempting to record the log-in sequence in vuser_init.c and the log-out sequence in vuser_end.c.

The Phase tells the Process Raw operation to move the appropriate steps from Action.c into the appropriate file.

There are four phases recognized by the Process Raw operation, and they must appear in the same order as the description of each here:

LI - Log In - optional - the step(s) needed to log in.

These are normally moved to vuser_init.c, or a function that is called from vuser_init.c

TI - To Iteration - optional - the step(s) needed to move the session from the login or home page to the first step of the iteration.

These are normally moved tovuser_init.c, or a function that is called from vuser_init.c.

I - Iteration - mandatory - the steps executed during each iteration. These are normally left in Action.c.

LO - Log Out - optional - the step(s) used after all iterations are complete.

These are normally moved to vuser_end.c, or a function that is called from vuser_end.c.

By default, when recording a script, VUGen will place all steps into Action.c (unless you configured it otherwise, which is not recommended here). Also by default, the Process Raw operation automatically moves steps from Action.c into another script file. Intuitively the LI and TI steps would be moved to vuser_init.c and LO steps moved to vuser_end.c, but it is more flexible than that. It actually moves the steps into any file that has the following signature(s):

// <Transfer phase LI to here>;

// <Transfer phase TI to here>;

// <Transfer phase LO to here>;

This allows one or more files to be placed in the _Included Files folder that allows better management of the session. Refer to <TBA> for more details.

Validation Column

Refer to xxx in the illustration above.

There are several options when choosing how the web_reg_find() functions are configured.

When recording a script, VUGen provides the option of entering a value used by web_reg_find(), but it limits the LB and RB to <title> and </title> respectively, and some applications do not include these tags in some responses. In addition, the web_reg_find() function prepared by VUGen does not include the tags, so there is a risk that the page is wrong but the text is still in the response.

The options described here are more flexible. If you enter text into the Validation column, the Process Raw operation will automatically prepare web_reg_find() functions using that text, and place it immediately prior to the first request of the step. Note that if the Transaction Timer includes multiple requests, the Process Raw operation only applies the web_reg_find() function to the first one. If any others are required, then they must be manually configured.

If the Validation cell is left empty for one or more steps, the Process Raw operation will attempt to determine a value using the Validation Template LB and Validation Template RB CIs defined in the Configuration section, if they are found in the appropriate response. By choosing appropriate LB and RB values, more cells in the Validation column will be empty and typing is reduced, enhancing the efficiency of re-recording the script. Even if you just emulate VUGen's rule and use <title> and </title>, these tags will be included in the web_reg_find() function, improving accuracy.

Refer also to the Validation Template CIs in the Configuration section.

Reverse Engineer

The Reverse Engineer operation is designed to update the documentation for a test case from a legacy script.

Transaction timer 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.