LoadRunner - Parameterize and increase iteratively a value from database

/* Initialize variables and character buffer */

int i;

int j;

char ssbuf[12];

/* Extract the value of database parameter and convert it into int by using atoi */

i = atoi(lr_eval_string("{UPLOADID}"));

/* Output the value */

lr_output_message("Integer Value of Parameter: %d", i);

/* Extract the iteration number from NewParam which is configured to extract iteration number

j = atoi(lr_eval_string("{NewParam}"));

i = i+j;

/*  Add integer to character stream */

sprintf(ssbuf,"%d", i);

/* save the parameter value */

lr_save_string(ssbuf,"UPLOADID");

lr_output_message("Integer Value of Parameter: %d", i);

QTP - Test Parameter

Test Parameters can be used to pass values to the test and retrieve values when the test completes. They are global parameters and can be accessed in any action or rather any scope. They are of two type - Input and output. Input Parameters are used to pass values to the test while Output Parameters are used to retrieve values from the Test.

1. Open a New Test.

2. Go to File->Settings->Parameters Tab

3. Click on '+' sign which is on the top right.

4. Enter the Name of the parameter as 'vartest' and its Default Value as 'hello'. Click Apply and then Ok. The Type of this parameter is string.

5. Above we have created a Test Parameter.

6. Now in the Keyword View right click on Action1 and select 'Action Properties'. 'Action Properties' window opens.

7. Go to 'Parameters' Tab. Click on '+' sign which is on the top right.

8. Enter the Name of the parameter as 'varaction' and its Type as string and no default value. Click Ok to come out of that window.

9. Again in the Keyword View right click on Action1 and select 'Action Call Properties'. 'Action Call Properties' window opens.

10. Go to 'Parameter Values' Tab. There you will see the 'varaction' action parameter we created earlier. Make a single click under 'Value' heading, it will show a button like this <#>. Just click on this button to open 'Value Configuration Options' window.

11. Click on 'Parameter' radio button and select 'Test/action Parameter' from that dropdown.

12. 'Test Parameters' radio button will be selected by default and under 'Test Parameters' radio button select 'vartest' from Parameter dropdown.[ remember this vartest is a test parameter we created at the beginning]

13. When you click on ok to come out of 'Value Configuration Options' window, in the 'Action Call Properties' window, under 'Value' it will show . Click Ok.

14. Go to Expert View and type: msgbox(parameter("varaction"))

15. Now run the test. While running it will show 'hello' in the msgbox.

QTP - Action Parameter

1. In the Keyword View right click on Action1 and select 'Action Properties'. 'Action Properties' window opens.

2. Go to 'Parameters' Tab. Click on '+' sign which is on the top right.

3. Enter the Name of the parameter as 'a' and its Type as Number. In the same way create another Number parameter 'b'.

4. Click Ok.

5. In the Keyword View right click on Action1 and select 'Action Properties'. 'Action Properties' window opens. In the general tab, click on 'Reusable Action' checkbox at the bottom to make the action reusable.

6. In the Expert View of Action1 type:

s1=parameter("a")

s2=parameter("b")

msgbox(s1+s2)

7. Go to Insert (menu)-> Call to New Action. 'Insert Call to New Action' window opens. Just click ok to insert a new action.

8. Make action2 reusable as we did for action1.

9. In the Expert View of action2 type:

RunAction "Action1", oneIteration, 2,2

10. In the keyword View right click on action2 and select 'Run from Step', it will show you the sum 4 in msgbox.

QTP - Environment Variables

User-Defined Internal, User-Defined External, Built-in are the types of environment variables available in QTP.

Built-in variables as the name suggests are predefined by QTP. Examples of such variables are OS, OSVersion, ActionName which are for Operating System, Operating System Version and name of the action which is currently running, respectively.

Example: In the Expert View type and Run the test:

a = environment("ActionName") & " is running on " & environment("OS")

msgbox (a)

User Defined Internal variables are the variables defined by you (the user) within the test and which are saved within the test and also accessible from within the test.

Example: You may add internal enviornment variable in File (Menu)->Settings-> Environment tab.Add New Internal  Environment Parameter by selecting 'User defined' ion dropdown box. Go to expert view and type:

msgbox(environment("a"))

User-Defined external variables are the variables which are defined in the file outside of test. These act as read only for the test. You can create as many files for environment variables as you want and choose them for your test.

Open a new text file and type the following lines in it and save it with .xml extension. 

<Environment>

<Variable>
<Name> a </Name>
<Value> hello </Value>
</Variable>
</Environment>

You may attach external enviornment variable file in File (Menu)->Settings-> Environment tab. It would load Environment Parameter in XML file. Go to expert view and type:

msgbox(environment("Address"))

Parameterizing Tests in QTP

By replacing fixed values with parameters QuickTest enables you to enlarge the scope of a basic test. It is known as parameterization, greatly increases the power and flexibility of a test. A parameter is a variable that is assigned a value from an external data source or generator. Values in steps and checkpoints and also the values of action parameters can be parameterize.

Parameters let us check how the application performs the same operations with multiple sets of data.

There are four types of parameters:

Test/action parameters: Test parameters make possible for us to use values passed from the test. Action parameters enable us to pass values from other actions in your test. To use a value within a specific action, the value must be passed down through the action hierarchy of the test to the required action. We can then use that parameter value to parameterize a step in the test. For example, suppose that we want to parameterize a step in Action3 using a value that is passed into the test from the external application that runs (calls) the test. We can pass the value from the test level to Action1 (atop-level action) to Action3 (a nested action of Action1), and then parameterize the required step using this action input parameter value (that was passed through from the external application). Alternatively, we can pass an output action parameter value from an action step to a later sibling action at the same hierarchical level. For example, suppose that Action2, Action3, and Action4 are sibling actions at the same hierarchical level, and that these are all nested actions of Action1. We can parameterize a call to Action4 based on an output value retrieved from Action2 or Action3. We can then use these parameters in the action step.

Data Table parameters allow us to create a data-driven test (or action) that runs several times using the data that we supply. In each repetition, or iteration, QuickTest uses a different value from the Data Table.

Environment variable parameters allow us to use variable values from other sources during the run session. These may be values that we supply, or values that QuickTest generates for us based on conditions and options we choose.

Random number parameters Enable us to insert random numbers as values in your test.

Values in steps and checkpoints can be parameterized while recording or editing the test. The values of object properties can be parameterized for a selected step. The values of the operation (method or function arguments) defined for the step can also be parameterized. When the value of an object property for a local object is parameterized, we are amending the test object description in the local object repository. Therefore, all occurrences of the specified object within the action are parameterized.

Parameterizing the value of a checkpoint property enables us to check how an application or Web site performs the same operation based on different data

Checkpoints in QTP - Quick Test Professional

A checkpoint enables you to identify whether the Web site or application under test is functioning correctly or not by comparing a current value for a particular property with the expected value for that property.

After we add a checkpoint, QuickTest adds a checkpoint to the current row in the Keyword View and adds a Check CheckPoint statement in the Expert View.

By default, the checkpoint name receives the name of the test object on which the checkpoint is being performed. We can change the name of the checkpoint if

needed.

Types of Checkpoints:

1. Standard checkpoint
   
2. Image checkpoints
   
3. Bitmap Checkpoint
   
4. Table checkpoints
   
5. Accessibility Checkpoint
   
6. Text Checkpoint
   
7. Page Checkpoint
   
8. Database Checkpoint
   
9. XML checkpoints
   

Standard checkpoints allow checking the object property values in the Web site or application under test. Standard checkpoints evaluate (compare) the expected values of object properties captured during recording to the object's current values during a run session. For

example we can check that a radio button is activated after it is selected. Standard checkpoints are supported for all add-in environments.

Standard checkpoints can be used to perform checks on

• Images,
  
• Tables,
  
• Web page properties, and
  
• Other objects within your application or Web site.
  

Standard checkpoints can be created for all supported testing environments (as long as the appropriate add-in(s) are loaded).

Image checkpoints allow you to check the properties of an image in the application or Web page. For example, you can check that a selected image's source file is correct or not. An image checkpoint can also be created by inserting a standard checkpoint on an image object. Image checkpoints are supported for the Web add-in environment

With Bitmap Checkpoint we can check an area of a Web page or application as a bitmap. While creating a test, we have to specify the area to check by selecting an object. An entire object or any area within an object can be checked. Bitmap checkpoints are supported for all add-in environments

By adding table checkpoints to the test, we can check the content of tables displayed in the application. For example, we can check that a specified value is displayed in a certain cell. Certain environments also support checking the properties of the table object. For example, a check that a table has the expected number of rows and columns. A table checkpoint can also be created by inserting a standard checkpoint on a table object.

Accessibility Checkpoint recognizes areas of your Web site that may not conform to the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines. For example, check if the images on a Web page include ALT properties, required by the W3C Web Content Accessibility Guidelines. Accessibility checkpoints are supported for the Web add-in environment

QuickTest can check that a text string is displayed in the appropriate place in an application or on a Web page with Text Checkpoint. Text checkpoints are supported for the Web add-in environment, plus some Web-based add-in environments

Page Checkpoint checks the features of a Web page. For example, you can check how long a Web page takes to load or whether a Web page contains broken links. A page checkpoint can also be created by inserting a standard checkpoint on page object. Page checkpoints are supported for the Web add-in environment

The contents of a database accessed by your application can be checked by Database Checkpoint. Database checkpoints are supported for all add-in environments

By adding XML checkpoints to your test, you can check the contents of individual XML data files or documents that are part of your Web application. The XML Checkpoint option is supported for all add-in environments.