This Article has been contributed by Prarthana Agwania who has been working in Siebel QA for past 1 year.

This Article gives you introduction of two very common tools used to automate Siebel testing.

• Quick Test Professional (QTP)
• Load Runner

Quick Test Professional (QTP):

“Quick Test Professional (QTP) is an automated functional Graphical User Interface (GUI) testing tool created by the HP subsidiary Mercury Interactive that allows the automation of user actions on a web or client based computer application. It is primarily used for functional regression test automation. QTP uses a scripting language built on top of VBScript to specify the test procedure, and to manipulate the objects and controls of the application under test.”

It comes with several Add-ins in order to support the record and playback on specific applications like for example, Siebel Add-ins need to be installed in order to perform the automation of a Siebel application. Similarly SAP add-ins, Java add-ins, PeopleSoft add-ins are required to record the operations done on the application built in these technologies.

Load Runner :
LoadRunner is a performance and load testing product by HP for examining system behavior and performance, while generating actual load. LoadRunner can emulate hundreds or thousands of concurrent users to put the application through the rigors of real-life user loads( for which it uses Virtual User Generator), while collecting information from key infrastructure components (Web servers, database servers etc).

The LoadRunner Scripts are run via Controller, and after the results can then be analyzed in detail (using Analyzer), to explore the reasons for particular behavior. Load runner scripts are prepared with the help of Click Stream documents and WebEx Recording.

Click stream Documents:
Click stream documents are prepared for documenting the flow of a transaction so as to help in the preparation of Load Runner scripts. It consists of the screenshot of the various screens involved to complete the transaction, input data to be given, and indications to start and stop the timer.

WebEx Recording:
WebEx recordings are prepared using WebEx recorder which can be easily downloaded from internet. In this we start the recorder and open the application in the recorder. The recorder records every action we perform. There are no indications to start or stop the timer and intelligence is demanded from the coder itslef.

In next few posts we will discuss some advanced concept related to these tools.

This article has been submitted by Prarthana Agwania. This is an Article dealing with advance concepts of Load Runner and QTP. This Article assumes that you have working knowledge of both QTP and Load Runner.

Many of you might be aware of the automation testing which requires some automation tool. For Siebel applications, we mostly use HP (formerly Mercury) Quick Test Professional (QTP) for Functional Testing and HP LoadRunner(LR) for Performance Testing.

Though for Performance Testing, LR scripts are prepared from scratch. In our project we provide Click stream documents or Webex recording in order to provide the flow for the functionality.
But the efforts can be saved by converting QTP scripts to LR scripts or rather to be very precise invoking QTP scripts from LR and then capturing the replay of QTP scripts through LR thus resulting in LR scripts.

There can be two approaches to make this possible:

• Using QTP Script directly to run the Load Test using LoadRunner
• Using QTP Script to generate LR Script and then using the same to run a Load Test.

Follow the steps given below to Run QTP Scripts directly using Load Runner

1. Prepare a QTP script.
2. Install QTP on a Load Generator machine.
3. Setup the Load Generator machine for Terminal sessions.
4. Create a controller scenario using QTP script.
5. In the Load Generator details, choose the Virtual User ( vuser) limits tab and increase the GUI limit.

Now you are all set to start the test. But the method has its own constraints.

Since Load Test requires to have a large amount of load in the form of no. of virtual users performing a certain task, QTP has its limitation of taking the full control on GUI desktop of a computer. So that means only one QTP script can be run per computer which implies that we will require that many physical computers in order to run multiple QTP scripts.

The problem can be overcome by using Terminal Server or Citrix Server or VMWare which will generate number of virtual desktops on a single machine. But here comes another issue of licenses. LoadRunner requires a GUI vuser license to run QTP scripts in the controller. Running each vuser requires a separate GUI vuser license.

Readers please note: Some of you might be thinking that we need to have QTP licenses as well in order to open that many instances of QTP. This is not the case. You only have to have GUI vuser licenses.

Now coming to the second method. But before we start, certain preparations need to be made.

In the QTP script, we need to manually insert lines of code to represent the Transaction boundaries and Action definitions. These are the terms used in Load Runner.

Transaction: represent units of actions for which performance characteristics is measured, monitored, and analyzed.
Action: is comprised of one or more transactions and represents a unit of iteration during a load test.

To start with second approach you need to:

• Add a second browser(other than in which the application will be running) to the QTP object repository.
• Declare two variables named ‘Server‘ and ‘Application‘ with values initialized to the name of the web server and the application that you will be recording against, respectively.
• Place a call to the Init subroutine by inserting a line with the text Init ( ). To alter the HTTP traffic to capture transaction boundaries and action definitions, ping commands are sent to the server, and an OK response is received for each such ping request.

The ping command has to be sent from a separate browser than the one running the Siebel application. The Init subroutine handles the task of creating the separate browser window to send the ping commands and capturing the resulting OK responses so that the main browser running the Siebel application is not affected.

The subroutine calls manually inserted into the QTP script result in ping commands being sent to the server that represent:

• The start of an action with the action name.
• Beginning of a transaction with the transaction name.
• End of a transaction with the transaction name.
• The ping commands appear in the HTTP traffic which gets captured by LoadRunner.

The AutoGenerate utility (Autogenerate.exe) then performs post-processing on the LR script to identify and replace the ping commands with lr_start_transaction and lr_end_transaction calls that identify a transaction. The AutoGenerate utility also splits up the LoadRunner script into different .c files based on the action definitions in the QTP script.

To represent the beginning and end of an action, insert the following lines of code:

• CreateNewAction “vuser_init”: To represent the start of an action.
• CreateNewAction “vuser_end”: To represent the end of a action.
• To represent the beginning and end of a transaction, insert the following lines of code:
• StartTransaction “<Transaction_Name>”: To represent the start of a transaction.
• EndTransaction “<Transaction_Name>”: To represent the end of a transaction.

Save the edited QTP script (the script now contains transaction and action definitions). Start the Virtual User (VU) Generator module of LoadRunner in the Record mode.

After you are finished with the steps mentioned above, you need to do the following things:

1. Firstly, QTP needs to be installed in the machine where LoadRunner is also installed. This is because LoadRunner will be recording the same flow that the QTP script will be executing.
2. Secondly, this is how the process goes: Both individual instances of QTP as well as LoadRunner has to be open. Start the recording in LoadRunner keeping the application URL- “about: blank”. What this will ensure is that even though the Internet Explorer will start, it will not be accessing any application since it was ensured that there is “about: blank” in the address bar.
3. Once this is done, start executing the QTP script. What QTP will do is invoke its own Internet Explorer window and the flow recorded in the QTP script will be executed.
4. When the QTP script starts executing, the LoadRunner will start recording the communication between the client and the server of the Internet Explorer which was invoked by QTP.
5. Once the execution is stopped. LoadRunner will generate the same flow executed by QTP but in its own form, the form LoadRunner recognizes i.e, in the form of C and its functions.
6. Now, ensure that the AutoGenerate tool is available on the same machine. Also make sure that AutoGenerate.exe is in the system path.
7. Open a command window and navigate to the directory where the LoadRunner script is saved. Execute AutoGenerate.exe. The results should indicate that the post processing was completed successfully to insert the transaction boundaries and rearrange the script into different actions as specified in the QTP script.

Once the script gets generated and after the Autogenerate utility (Autogenerate.exe) has been run, we still have to do a few things: Correlation and Parameterization.

Even though, before starting the recording, we have the Auto Correlation option checked, then also LoadRunner doesn’t always correlate everything automatically. There are many values which need to be correlated manually, which don’t get correlated automatically by LoadRunner since rules are not defined to correlate these values in the .cor file used for the very purpose of automatic correlation for Siebel.

We require correlation because of certain values which change dynamically. For this express reason we have options in LoadRunner by which we can capture these dynamic values and use it so that the scripts don’t fail.

Parameterization: There are values which don’t change dynamically but are required to be parameterized, i.e. certain known values which are present in a table from beforehand and LoadRunner uses them one by one for the express purpose of the script doing exactly the flow which has been recorded otherwise the script will fail. The values are taken from the table and used in the script.

Like for example, PO numbers parameterized in a script which tries to approve a PO. Once a PO gets approved, it cannot be approved again unless and until some revisions are made. But if the script which has been recorded to approve a PO and then do nothing further, we will require a good amount of PO numbers to be parameterized so that LoadRunner, while executing the script, can take a different PO each time otherwise the script will fail since it will try to Approve a PO number which is already Approved.

After reading this though the grass seems to be quite green. But the reality is totally different. Since to set up the entire infrastructure, is not cost effective. But if you have it in place then you can go ahead with it. Also there are some transactions which cannot be recorded using LoadRunner so they can use this approach.