Tutorial on recording in LoadRunner

http://www.whatwg.org/

Here is my "recipe" of step-by-step instructions I typical use to create scripts using LoadRunner.

I would welcome your ideas on improving this for the benefit of all.

Rather than working with a new script from scratch, I prefer saving an existing script as the new name so that I can call utility functions from within custom scripts. This is a big time saver for me.

--- Begin by making a list of every move and number each step.

We usually need to run through an application several times over several cycles of recording. If the same exact user moves are not performed every time, it would be more difficult to compare the recordings.

Identify the URL [2-10]

Create a new VuGen step with the step name you plan on executing.

If you change a step name in VuGen's tree view, VuGen will change the function identifier in the script code.

I prefer pasting into that file script code captured into another file. This approach provides me a place to store comments and allows me to add lr_start_transaction and lr_end_transaction statements before I record. [04]

Write a change note every time you change the file.

"02 JAN 06 WML - Added ... "

As you investigate the app by going through each recording cycle (listed below), make a note of the programming and runtime settings appropriate for your script and application.

VuGen does not allow changes to any script while it's recording.

--- Cycle 1. As your record, take screen images and save html source after each user move.

Name each file with your assigned step numbers and cycle number so that files associated with the same screen have the same file name prefix.

Note the data values you input.

Note what text is unique to each screen. This text is used later in code to verify that the correct screen returned by the app.

Note what is needed to return the system to the same initial state.

Note error message text to listen for.

Time-outs that occur in the application need to be recognized by script content checks (ch 13).

--- Cycle 2. Record in HTML "GUI" mode.

Create a new step file to record into. Name it with a recording cycle number.

Go into Runtime Settings, Logic and delete step names used for recording.

In Recording Options, set to always generate a think time statement regardless of the pause time during recording.

During recording, before each user action (such as clicking), add a comment. Precede and end each comment with a space. This makes them easier to edit later.

Save the script file.

For each file identified in the generated script (under "EXTRARES"), note their byte count by using Windows Explorer to view folder "Temporary Internet" folder.

After recording, save VuGen's Recording log with a name containing the cycle number, such as "Recording Log.C01.txt".

If the .html and .js files downloaded to the client is "compressed", praise the programmer because this is a very good best practice because time is not wasted downloading comments and "white space" such as spaces and tabs to format code. After that, get the uncompressed code so you can read it.

--- Cycle 3. Record in HTTP "concurrent" mode.

This is needed if the app uses framesets or issues GET/POST requests from Javascript.

A script can contain code generated both ways, but beware of duplicating requests.

Add code to define transaction timing -- lr_start_transaction and lr_end_transaction around each user move. Sometimes several statements are created with each user move.

I copy over cookie statements generated by VuGen, but comment them out because LR will automatically emulate client cookie manipulation during playback.

add_cookie statements are needed only if Javascript on the client explicitly creates them.

--- Cycle 4. Record for correlation.

Auto correlation can be "dumb". Sometimes correlation is created only for "Referrer" text which most apps do not use.

Add web_reg_save_param [see help, 10-6, Appendix A] to capture text passed from one screen to the next:

--- Cycle 5. Record for error detection

Debug one transaction at a time. Temporarily place a stop statement such as lr_abort(); [see 10-4] After you make sure each block of code works properly, cut and paste that statement to the end of the next block you are debugging.

Rather than being innudated with log entries, set runtime settings to show logs only on error, but add statements in the script to display advanced settings only where needed, such as before entering the block of code you are currently debugging.

In Miscellaneous Runtime Settings, have LoadRunner create a "snapshot" on each error. They are in the script's "Result1" folder.

Add web_reg_find commands [10-14] to recognize error message text.

--- Cycle 6. Add parameters [5].

Temporarily set the runtime settings logic to run the same section 3 times a minute after each other. If the first iteration measurement is higher than results from subsequent measurements is usually due to the server retrieving its data from memory rather than from disk.

This is an important observation to report.

Multiple values work around the effect of caching on the database, on the web server, etc.

In the script init section, add a lr_save_string command [see help] to define a LoadRunner parameter of the URL host {pURLHost}.

The press Ctrl+H or pull Edit, Replace of the URL ("http://...") with the {pURLHost} parameter.

This needs to be done with all generated code every time you record again.

To see if you obtain the correct parameter values, in Runtime Log Settings, check Advanced checkbox.

Also add a lr_report_msg command [see help] to display to the log all run parameters.

LoadRunner parameters need to be converted using lr_eval_string commands [10-10].

--- Cycle 7. Add random execution.

Add a randomizer statement.

Specify a date time for an random seed.

If statement.

The time for each transaction is the first result metric you can report.

--- END ---