By using QTP recovery scenario, we can handle errors.
The other way around handling Errors is using "On Error" statements.
Following code throws an Exception at Line 6, and the execution cannot proceed further.
msgbox "hello"
call funcOne
msgbox "after function call"
function funcOne()
msgbox 1/0
end function
Here the output is "hello", the script never reaches to the second output statement
To proceed further after the exception occured, use "On Error Resume Next" statement, which just ignores the Exception and proceeds.
msgbox "hello"
call funcOne
msgbox "after function call"
function funcOne()
On Error Resume Next
msgbox 1/0
end function
Here the output contains both the messages
To customize the error message displayed, use the Err Object
msgbox "hello"
call funcOne
msgbox "after function call"
function funcOne()
On Error Resume Next
msgbox 1/0
msgbox "Error Message: "&Err.Description&" and Error code: "&Err.Number
end function
Here the output is 3 msgs, including the Error description.
To disable Error Handling mechanism use "On Error Goto 0" statement.
msgbox "hello"
call funcOne
msgbox "after function call"
On Error Goto 0
call funTwo ' here the Error occues as we disabled Error Handling
function funcOne()
On Error Resume Next
msgbox 1/0
msgbox "Error Message: "&Err.Description&" and Error code: "&Err.Number
end function
You can also clear the Error object using Err.clear().
Tuesday, May 17, 2011
Monday, May 16, 2011
Difference between Driver and Stub
Driver:
1. A software module or application used to invoke a test item and, often, provide test inputs (data), control and monitor execution. A test driver automates the execution of test procedures.
2. Bottom-up testing still requires that test drivers be constructed
Stub:
1. A dummy software component or object used (during development and testing) to simulate the behavior of a real component that was not yet constructed. The stub typically provides test output
2. Top-down testing requires that stubs be created to simulate the actions of called functions that have not yet been incorporated into the system
1. A software module or application used to invoke a test item and, often, provide test inputs (data), control and monitor execution. A test driver automates the execution of test procedures.
2. Bottom-up testing still requires that test drivers be constructed
Stub:
1. A dummy software component or object used (during development and testing) to simulate the behavior of a real component that was not yet constructed. The stub typically provides test output
2. Top-down testing requires that stubs be created to simulate the actions of called functions that have not yet been incorporated into the system
Difference between Test Strategy and Test Plan
Test Strategy describes about the overall "testing appraoch" of our testing.
Generally prepared by Project Manager or his delegate.
It provides a roadmap that describes the steps to be conducted as part of testing, when these steps are planned and under taken, and how much effort, time and resources will be required. Therefore, any test Strategy must incorporate test planning, test design, test execution, and resultant data collection and evaluation.
This document generally derived from BRD(Business Requirement document)
It is static document, meaning updation of this document is almost minimal.
This document can be organization specific or project specific.
Test plan describes about "how & what we are going to test, who will do what, when to test".
Generally prepared by Test Lead or Test Manager.
It prescibes the scope, appraoch, resources and schedules of our testing activities.
This document is generally derived from Business Requirement Document, Functional Specification Document, Technical Specification Document and any use case document.
It is dynamic document, and needs to be updated as per the needs.
This document is project specific, and based on the project size, some projects have master test plan and individual test plans will be derived from this test plan.
The content of the Test Plan includes:
1. Introduction
a. Overview of the project
b. Purpose of this document
c. Objectives of the testing
2. Scope of testing
a. Features to be tested
b. Out of scope items
3. Test Strategy: Different types of testing
4. Test and System schedules
5. Roles and Responsibilities
6. Environment requirements
7. Resources(H/w,S/w, human)
8. Risks and contingencies
9. Deliverable
10. Approvals
Generally prepared by Project Manager or his delegate.
It provides a roadmap that describes the steps to be conducted as part of testing, when these steps are planned and under taken, and how much effort, time and resources will be required. Therefore, any test Strategy must incorporate test planning, test design, test execution, and resultant data collection and evaluation.
This document generally derived from BRD(Business Requirement document)
It is static document, meaning updation of this document is almost minimal.
This document can be organization specific or project specific.
Test plan describes about "how & what we are going to test, who will do what, when to test".
Generally prepared by Test Lead or Test Manager.
It prescibes the scope, appraoch, resources and schedules of our testing activities.
This document is generally derived from Business Requirement Document, Functional Specification Document, Technical Specification Document and any use case document.
It is dynamic document, and needs to be updated as per the needs.
This document is project specific, and based on the project size, some projects have master test plan and individual test plans will be derived from this test plan.
The content of the Test Plan includes:
1. Introduction
a. Overview of the project
b. Purpose of this document
c. Objectives of the testing
2. Scope of testing
a. Features to be tested
b. Out of scope items
3. Test Strategy: Different types of testing
4. Test and System schedules
5. Roles and Responsibilities
6. Environment requirements
7. Resources(H/w,S/w, human)
8. Risks and contingencies
9. Deliverable
10. Approvals
Subscribe to:
Posts (Atom)