Devops for Growth

This is a repository of code snippets. Please send me any useful sections of code that you have written.

Note that this repository does not contain trivial examples (i.e. something you could learn by looking at the example code in the LoadRunner Online Function Reference - accessed by pressing F1 in VuGen).

Code snippets that have been written as separate Tech Tips:

• Adding try/catch blocks to Java-based BPM scripts
• How to query a MySQL database
• How to calculate the difference between two dates or timestamps
• Writing a polling loop to check that something has finished
• How to parameterising Unix/Posix timestamps
• How to handle HTTP POSTs with a changing number of name-value pairs
• Scripting Web Services
• Custom character encoding (SAP Web Dynpro)

It's wrong to assume that VuGen scripts are always written in C. Some virtual user types are only available in other languages, and some give you an option of generating a recorded script in a variety of languages. At current count, LoadRunner supports 8 languages (or 6, if you consider VBA, VBScript and VB to be the same language).

This post shows the list of languages available for LoadRunner/VuGen 9.10, and which vuser types they are available for.

To generate your script in a different language (if available), change the "scripting language" setting under Recording Options.

The VuGen Script File Development Process

These steps are part of an overall corporate

Approach to Managing Performance

1. Define the test project's objectives, environment, scripts, data, hardware, etc. The assumptions for the script should reference coding standards/conventions.
   I code HTML to create a web page that I can link to in my status reports.

1. Create a versioned folder to store the various assets associated with the application under test, such as .png/.gif image files of pictures that will be captured, html file saved from the recording, the full source html file from the recording, and the VuGen recording log.

1. List (in a table) for each business processes the manual actions needed to walk though the actual application steps needed to 1) capture each screen image for documentation, 2) assign a unique transaction name to each screen, and 3) note the technical component (URL or method and function) handling each step.

    

   So that transaction names are listed in the sequence of manual steps, I assign transaction names using zero-filled zeros (such as "09", etc.).

   I capture the image of each screen into an MS-Word file or a separate .gif file referenced from an icon on a webpage.

   As needed, I note for each screen/step its testability status (such as not available for use, script having errors, is being ignored, data parameterization, variations in values, etc.)

1. Create a versioned folder.
   I prefer not to use the default location, but to store all files associated with a script together in the same folder. Unfortunately, this means that if I switch between different tests, I have to remember to change the default settings every time.

    

   When working with a new script, I select "Multi-protocol" rather than "Single protocol because the UI is better. I can sort actions only within the multi-protocol UI. Protocols

    

2. Use VuGen to generate a sequence of script code by Recording the application according to the sequence of screens and user steps specified in your business processes list. In the "Start Recording" dialog:

    

    

   • select application type "Win32 Application" to use the COM/DCOM protocol
   • select application type "Internet Application" to use the "Web(HTTP/HTML)" protocol.

    

3. Edit the script based on the Ways to script list at right and following script language rules

    

    

   • Comment out cookie code (because they will be performed again when the script is run).

    

    

4. Debug and Adjust script (for a single user) by running it within VuGen with Runtime Settings Logs set to display all messages:

    

    

   • Identify and fix script editing errors.
   • Determine timings
   • Set initial Runtime Settings Scenarios

    

    

5. Run in Controller using full test Runtime Settings