Rk classes -7

qtp software free download 10.0 trial version

www8.hp.com/us/en/software/software-solution.html?compURI=tcm:245-937061#tab=3

Debugging anAction or a Function in QTP

Suppose you create an action or a function that defines variables that will be used in other parts of your test or function library. You can add breakpoints to the action or function to see how the value of the variables changes as the test or function library runs. To see how the test or function library handles the new value, you can also change the value of one of the variables during a breakpoint.

This can be done by following below simple steps:

Step 1: Create a New Action or Function: Open a test and insert a new action, or open a new function library and create a new function called SetVariables.

If you are working in the Expert View, then follow Step 4 directly. If you are working in a function library, continue with Step 2 and Step 3.

Step 2: (For Function Libraries Only) Associate the Function Library with a Test: Make sure the function library is in focus. Select File > Associate Library ‘<Function Library Name>’ with ‘<Test Name>’. QuickTest associates the function library with your test.

Step 3: (For Function Libraries Only) Add a Call to the Function in Your Test: Add a call to the function by inserting a new step and typing the following in the Expert View: SetVariables.

Step 4: Add Breakpoints: Add breakpoints at the appropriate lines.

Step 5: Begin Running the Test: Run the test. The test or function library stops at the first breakpoint, before executing that step (line of script).

Step 6: Check the Value of the Variables in the Debug Viewer Pane:

Step 7: Check the Value of the Variables at the Next Breakpoint: Click the Run button to continue running the test. The test stops at the next breakpoint.

Step 8: Modify the Value of a Variable Using the Variables Tab

Step 9: Modify the Value of a Variable Using the Command Tab

Step 10: Repeat a Command from the Command History

Using Breakpoints :
We can use breakpoints to instruct QuickTest to pause a run session at a predetermined place in a component or function library. QuickTest pauses the run when it reaches the breakpoint, before executing the step. we can then examine the effects of the run up to the breakpoint, make any necessary changes, and continue running the component or function library from the breakpoint.
You can use breakpoints to:
* suspend a run session and inspect the state of your site or application.
* Mark a point from which to begin stepping through a component or function library using the step commands
* We can set breakpoints, and we can temporarily enable and disable them. After we finish using them, we can remove them from your component or function library.
Note: Breakpoints are applicable only to the current QuickTest session and are not saved with your component or function library.

Operations we can perform on Breakpoints:
* Setting Breakpoints
* Enabling and Disabling Breakpoints
* Removing Breakpoints

* Setting Breakpoints:
By setting a breakpoint, we can pause a run session at a predetermined place in a component or function library. A breakpoint is indicated by a filled red circle icon in the left margin adjacent to the selected step.
To set a breakpoint:
Perform one of the following:
*Click in the left margin of a step in script/function library where you want the run to stop
*Click a step and then:
Click the Insert/Remove Breakpoint button
Choose Debug > Insert/Remove Breakpoint
The breakpoint symbol is displayed in the left margin of the script or function library.
Note: Breakpoints are applicable only to the current QuickTest session and are not saved with your component or function library.

* Enabling and Disabling Breakpoints :
We can instruct QuickTest to ignore an existing breakpoint during a debug session by temporarily disabling the breakpoint. Then, when you run our component or function library, QuickTest runs the step containing the breakpoint, instead of stopping at it. When we enable the breakpoint again, QuickTest pauses there during the next run. This is particularly useful if your component or function library contains many steps, and you want to debug a specific part of it.
We can enable or disable breakpoints individually or all at once. For example, suppose we add breakpoints to various steps throughout your component or function library, but for now you want to debug only a specific part of your document. We could disable all breakpoints in your script or function library, and then enable breakpoints only for specific steps. After you finish debugging that section of your document, you could disable the enabled breakpoints, and then enable the next set of breakpoints (in the section you want to debug). Because the breakpoints are disabled and not removed, we can find and enable any breakpoint, as needed.
An enabled breakpoint is indicated by a filled red circle icon in the left margin adjacent to the selected step.
A disabled breakpoint is indicated by an empty circle icon in the left margin adjacent to the selected step.
Note: Breakpoints are applicable only to the current QuickTest session and are not saved with your component or function library.

We can:
Enable/disable a specific breakpoint
Enable/disable all breakpoints
To enable/disable a specific breakpoint:
Click in the line containing the breakpoint you want to disable/enable.
Choose Debug > Enable/Disable Breakpoint or press Ctrl+F9. The breakpoint is either disabled or enabled (depending on its previous state).
To enable/disable all breakpoints:
Choose Debug > Enable/Disable All Breakpoints or click the Enable/Disable All Breakpoints button. If at least one breakpoint is enabled, QuickTest disables all breakpoints in the component or function library. Alternatively, if all breakpoints are disabled, QuickTest enables them.

* Removing Breakpoints:
You can remove a single breakpoint or all breakpoints defined for the current component or function library.
To remove a single breakpoint:
Perform one of the following:
Click the breakpoint.
Click the line in your component or function library with the breakpoint symbol and:
Click the Insert/Remove Breakpoint button.
Choose Debug > Insert/Remove Breakpoint.
The breakpoint symbol is removed from the left margin of the QuickTest window.
To remove all breakpoints:
Click the Clear All Breakpoints button, or choose Debug > Clear All Breakpoints. All breakpoint symbols are removed from the left margin of the QuickTest window

* Setting Breakpoints:

By setting a breakpoint, we can pause a run session at a predetermined place in a component or function library. A breakpoint is indicated by a filled red circle icon in the left margin adjacent to the selected step.
To set a breakpoint:
Perform one of the following:
*Click in the left margin of a step in script/function library where you want the run to stop
*Click a step and then:
Click the Insert/Remove Breakpoint button
Choose Debug > Insert/Remove Breakpoint
The breakpoint symbol is displayed in the left margin of the script or function library.
Note: Breakpoints are applicable only to the current QuickTest session and are not saved with your component or function library.

* Enabling and Disabling Breakpoints :
We can instruct QuickTest to ignore an existing breakpoint during a debug session by temporarily disabling the breakpoint. Then, when you run our component or function library, QuickTest runs the step containing the breakpoint, instead of stopping at it. When we enable the breakpoint again, QuickTest pauses there during the next run. This is particularly useful if your component or function library contains many steps, and you want to debug a specific part of it.
We can enable or disable breakpoints individually or all at once. For example, suppose we add breakpoints to various steps throughout your component or function library, but for now you want to debug only a specific part of your document. We could disable all breakpoints in your script or function 

Step Into, Step Out, and Step Over commands

Step Into:- Choose Debug > Step Into, click the Step Into button, or press F11 to run only the current line of the active test or function library. If the current line of the active test or function library calls another action or a function, the called action/function is displayed in the QuickTest window, and the test or function library pauses at the first line of the called action/function.

Step Out :- Choose Debug > Step Out, click the Step Out button, or press SHIFT+F11 only after using Step Into to enter an action or a user-defined function. Step Out runs to the end of the called action or user-defined function, then returns to the calling test or function library and pauses the run session.

Step Over:- Choose Debug > Step Over, click the Step Over button, or press F10 to run only the current step in the active test or function library. When the current step calls another action or a user-defined function, the called action or function is executed in its entirety, but the called action or function script is not displayed in the QuickTest window.

Interview Question:- What is difference b/w Step Into, Step Out, and Step Over commands ?

Recovery Scenarios

What are Recover Scenarios?
While executing your scripts you may get some UNEXPECTED/UNPREDICTABLE errors. (like printer out of paper). To "recover" the test (and continue running) from these unexpected errors you use Recovery Scenarios.
Next question arises,
When to use "on error resume next" or programmatic handling of errors VS Recovery Scenarios ?
If you can predict that a certain event may happen at a specific point in your test or component, it is recommended to handle that event directly within your test or component by adding steps such as If statements or optional steps or "on error resume next", rather than depending on a recovery scenario. Using Recovery Scenarios may result in unusually slow performance of your tests.They are designed to handle a more generic set of unpredictable events which CANNOT be handled programmatically.
For Example:
A recovery scenario can handle a printer error by clicking the default button in the Printer Error message box.
You cannot handle this error directly in your test or component, since you cannot know at what point the network will return the printer error. You could try to handle this event in your test or component by adding an If statement immediately after the step that sent a file to the printer, but if the network takes time to return the printer error, your test or component may have progressed several steps before the error is displayed. Therefore, for this type of event, only a recovery scenario can handle it.
I would not go into details of how to create files and how to define them since they are fully covered in QTP Documentation. Mercury QuickTest Professional User's Guide > Working with Advanced Testing Features > Defining and Using Recovery Scenarios >
What constitute Recovery Scenarios?
A recovery scenario consists of the following: 

• Trigger Event. The event that interrupts your run session. For example, a window that may pop up on screen, or a QTP run error.
  
• Recovery Operations. The operations to perform to enable QTP to continue running the test after the trigger event interrupts the run session. For example, clicking an OK button in a pop-up window, or restarting Microsoft Windows.
  
• Post-Recovery Test Run Option. The instructions on how QTP should proceed after the recovery operations have been performed, and from which point in the test QTP should continue, if at all. For example, you may want to restart a test from the beginning, or skip a step entirely and continue with the next step in the test.

Recovery scenarios are saved in recovery scenario files having the extension .rs. A recovery scenario file is a logical collection of recovery scenarios, grouped according to your own specific requirements. 
Is there a method to programmatically call them?
By default, QTP checks for recovery triggers when an error is returned during the run session. You can use the Recovery object's method to force QTP to check for triggers after a specific step in the run session. 
For a complete list go to QTP Documentation > Quick Test Advanced References > Quick Test Automation > Recovery Object

In this example, we will define a Function Call and use that Function Call to handle the error. The default syntax for the Recovery Scenario Function is:

Function fnRecovery(Object, Method, Arguments, retVal)
        'Error Handling Code
End Function

Explanation of each argument to fnRecovery is given below:

Object as Object: The object of the current step.
Method as String: The method of the current step.
Arguments as Array: The actual method's arguments.
Result as Integer: The actual method's result.

To handle this scenario, we will use the function below:

Function Recovery_ListItemIsNotFound(Object, Method, Arguments, retVal)
     Dim sAllItems, arrAllItems, intItem
 
     With Object
          'Retrieve all items from the Listbox
          sAllItems = .GetROProperty("all items")
          'Split 'all items' using a delimiter ";" into an array
          arrAllItems = Split(sAllItems, ";")
 
          'Select a random number
          intItem = RandomNumber.Value(LBound(arrAllItems), UBound(arrAllItems))
          .Select "#" & intItem
 
          Reporter.ReportEvent micInfo, "ListItemIsNotFound", "Item: " & .GetROProperty("value")
     End With
End Function

Recovery_ListItemIsNotFound, as the same suggests, executes the Recovery Operation if the list item that we supplied to our target WebList does not exist. This is quite common in Web applications, and Items in a WebList can change depending upon the input(s) provided.

To start, Click Resources -> Recovery Scenario Manager. You should see a window like this:

Recovery Scenario Manager

To recover from unexpected events and errors that are occurred in the test environment during run session, we can use Recovery Scenario Manager. For good recovery, error must be known the occurrence is unknown.

There are (4) Types of events such as:

(i) Application Crash

An open application fails during Test Run.

Navigation:

Resources Menu -> Recovery Scenario Manager-> Click New-> Click Next ->

Select Application Crash as Trigger event->Next ->Select selected executable

application->Next ->Select Recovery Operation [Keyboard, Mouse Operation,

Close Application Process, function Call, Restart, Microsoft Windows] ->Next ->If

you want to check Add another operation else uncheck->Next ->Next ->Enter

Scenario Name ->Next->Select Option ->Finish ->Close ->Save the scenario in

specified location with ".qrs"

(qrs stands for QuickTest Recovery Scenario.)

(ii) Popup Window.

To handle unwanted popups.

Navigation:

Resources Menu ->Recovery Scenario Manager ->New ->Next ->Select "Popup

Window" as Trigger event ->Next ->Click on Hand Icon ->Show unwanted

window with Hand icon ->Next ->Next ->Select function call as Recovery

Operation ->Next [Open Notepad ->Save empty file with .vbs extension] ->Browse

the .vbs fie path ->Next ->Uncheck Add another Recovery Operation ->Next ->

Select Post-Recovery Test Run Option [Repeat current step and continue, Proceed to

Next step, Proceed to Next Action, Proceed to next test iteration, Restart current test

run, Stop the Test Run] ->Next ->Enter Scenario Name ->Next ->Select Option ->

Finish ->Save the scenario with ".qrs" ->Record required Recovery Operation [Click

ok, Click Cancel] take the script into function ->Save the library file ->Click Run

(iii) Test Run Error.

A step in your test does not run successfully then Test Run Error

can be raised.

Navigation :

Resources Menu ->Recovery Scenario Manager ->New ->Next ->Select "Testrunerror

Window" as Trigger event ->Next ->select any error o ->Next ->Next ->Select function call as Recovery

Operation ->Next [Open Notepad ->Save empty file with .vbs extension] ->Browse

the .vbs fie path ->Next ->Uncheck Add another Recovery Operation ->Next ->

Select Post-Recovery Test Run Option [Repeat current step and continue, Proceed to

Next step, Proceed to Next Action, Proceed to next test iteration, Restart current test

run, Stop the Test Run] ��Next ��Enter Scenario Name ��Next ��Select Option ��

Finish ��Save the scenario with ".qrs" ��Record required Recovery Operation [Click

ok, Click Cancel] take the script into function ��Save the library file ��Click Run

(iv) Object State

The property values of an object in your application match

specified values. You can specify property values for each object in the

hierarchy.

Navigation:

Resources Menu -> Recovery Scenario Manager -> New -> Next -> Select "Object state

Window" as Trigger event -> Next -> Click on Hand Icon -> Show object with hand icon

-> Next -> Next->select object property with value (enabled ,false)->click next -> Select function call as Recovery

Operation -> Next [Open Notepad -> Save empty file with .vbs extension] -> Browse

the .vbs fie path -> Next -> Uncheck Add another Recovery Operation -> Next ->

Select Post-Recovery Test Run Option [Repeat current step and continue, Proceed to

Next step, Proceed to Next Action, Proceed to next test iteration, Restart current test

run, Stop the Test Run] -> Next-> Enter Scenario Name -> Next -> Select Option ->

Finish -> Save the scenario with ".qrs" -> Record required Recovery Operation [Click

ok, Click Cancel] take the script into function -> Save the library file -> Click Run