Automated Web Test

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.

This blog post from myloadtest.com gives an illustration of using the Logparser tool to determine the more often used functionalities of the site allowing the performance tests to be focussed on the areas that add the most value to the users.

If you are in a hurry to get started, the steps are as follows:

1. Get a copy of the log files for a peak day.
2. Extract the top page requests from the file.
3. Determine which page requests map to which business processes.
4. Query the log file for the relevant page request that identifies each business process. Pick the busiest hour.

Everyone else, read on…

Sometimes when creating performance testing scripts, you will stumble upon vulnerabilities in the application under test.

Maybe you will miss a value you should have correlated before sending to the server, and when you go back and check your script you will find that (hypothetically) the web store is allowing you to purchase every item in their inventory for $9.95.

WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols.

WebScarab is designed to be a tool for anyone who needs to expose the workings of an HTTP(S) based application, whether to allow the developer to debug otherwise difficult problems, or to allow a security specialist to identify vulnerabilities in the way that the application has been designed or implemented.

You can download WebScarab from the OWASP Source Code Center at Sourceforge.

Source: MyLoadTest

technorati tags:Tools, Security, SQLInjection

Blogged with Flock