Automated Web Test

LoadRunner 9.1’s Flex protocol includes both AMF3 and Http protocols in its options. For testing applications using Flex and AMF3 protocols, these options need to be explicitly added in the recording options. To do this:

1. Click on options in the recording window.

2. Check the AMF and Http protocols in the Recording Options window under the subhead - Protocols.

3. Check the “Try to encode externizable object” option in the “Code Generation” Subhead of Recording Options window.

Recording after these options are checked would give more readable code as XML rather than Binary.

The Vugen uses *.dat files to store data used for parameterizing for user-supplied values in a script. But when there are multiple data tables, vugen gets confused as to which data set we are referring to when we run the script.

For example:

In our script if we have two different data tables of login ids names UserId.dat and UID.dat. When we refer to the data column in the table by the column number the data file that is used may not be the one you are intending to use. It is always a better idea to refer to the column by the column name.

Source : MyLoadTest.com

A LoadRunner feature that has made my life a lot easier has been ContentCheck rules, which are available in the script runtime settings.
If you are using a web-based vuser type, you can configure your
LoadRunner script to search through all returned pages for strings that
match known error messages.

Using web_reg_find functions is fine, but when you get an error
LoadRunner reports it as “failed to find text” instead of
something more descriptive.

I will always create rules for
any error messages I find during scripting and, if I receive an error
while running a scenario, I will add the error message from the
snapshot in the scenario results directory (the snapshot on error
feature is very useful).

All this is pretty obvious if you
have taken the time to explore LoadRunner’s features or you have
attended a Mercury training session, but I recommend taking things a
step further.

• Ask your developers for a list of all
  the error messages that the application can throw. This should be easy
  for them to provide if the application is well designed and stores all
  the message in some kind of message repository instead of sprinkling
  them throughout the source code.
• Include error message for
  functional errors that you are likely to encourner. Creating a rule for
  “incorrect username or password” may save someone 20
  minutes of investigation when they first run the script after the
  database has been refreshed.

If you prefer to have
error message you are checking for in the script (where you can add
comments to them) instead of the runtime settings, you can use the
web_global_verification function instead. The only difference between
the two is the error message that LoadRunner will include in its log:

Action.c(737):
Error -26368: “Text=A runtime error occurred” found for
web_global_verification (”ARuntimeErrorOccurred”)
(count=1), Snapshot Info [MSH 0 21]

…compared to:

Action.c(737):
Error -26372: ContentCheck Rule “ARuntimeErrorOccurred” in
Application “Webshop” triggered. Text “A runtime
error occurred” matched (count=1), Snapshot Info [MSH 0 21]

And finally, ContentCheck rules can be easily exported and shared between scripts, which can be a nice time-saver.