Wednesday, May 26, 2010
http://www.sumitsharma.in/search/label/No%20Objection%20Certificate
http://www.sumitsharma.in/search/label/No%20Objection%20Certificate
Wednesday, April 29, 2009
Actions in QTP 9 (QuickTest Professional)
Actions break up the test into logical sections/units such as specific activities that we perform in our application.
When we create a new test, it contains a call to one action. By breaking up the tests into calls to multiple actions, we can design more modular and well organized and professional tests. An action has its own test script, containing all of the steps recorded in that action, and all objects in its local object repository. An action is stored with the test in which you created it.
If you create a test in which you log into the system (email), check inbox, and then log out of the system (email), your test might be structured as shown—one test calling three separate actions:
Test 1
Actions stored with Test 1
Call to action 1 ---> Action 1(Logging In)
Call to action 2 ---> Action 2(Checking Inbox Mails)
Call to action 3 ---> Action 3(Logging Out)
Actions make it possible to parameterize and iterate over specific elements of a test. They also make it easier to re-record steps in one action when part of your application changes. For every action called in the test, QuickTest creates a corresponding action sheet in the Data Table so that we can enter Data Table parameters that are specific to that action only.
Three types of actions are: Non-reusable action This non reusable action can be called only once and that too in the test with which it is stored.
Reusable action Reusable actions are like functions in any programming language. If there is a process that needs to be included in several tests, we can record, modify, and enhance the steps of the process and save them in a reusable action. Then we can call the action from other tests, rather than recording, modifying, and enhancing the same steps each time. It can be called several times by the test with which it is stored (the local test), as well as by other tests.
Deleting a reusable action that is called by other tests will cause those tests to fail.
External action is a reusable action stored with another test. External actions are read-only in the calling test, but we can choose to use a local, editable copy of the Data Table information for the external action. When a call to an external action is inserted, the action is inserted in read-only format
We can create an additional call to any reusable or external action in the test by pressing CTRL while we drag and drop the action to another location at a parallel (sibling) level within the test.
By default, new actions are non-reusable. Each action created in a test can be marked as reusable or non-reusable.
When we run a test with multiple actions, the test results are divided by actions within each test iteration so that we can see the outcome of each action, and can view the detailed results for each action individually.
If you expect other users to open your tests and all actions in your tests are stored in the same drive, you should use relative paths for your reusable actions so that other users will be able to open your tests even if they have mapped their network drives differently.
Actions break up the test into logical sections/units such as specific activities that we perform in our application.
When we create a new test, it contains a call to one action. By breaking up the tests into calls to multiple actions, we can design more modular and well organized and professional tests. An action has its own test script, containing all of the steps recorded in that action, and all objects in its local object repository. An action is stored with the test in which you created it.
If you create a test in which you log into the system (email), check inbox, and then log out of the system (email), your test might be structured as shown—one test calling three separate actions:
Test 1
Actions stored with Test 1
Call to action 1 ---> Action 1(Logging In)
Call to action 2 ---> Action 2(Checking Inbox Mails)
Call to action 3 ---> Action 3(Logging Out)
Actions make it possible to parameterize and iterate over specific elements of a test. They also make it easier to re-record steps in one action when part of your application changes. For every action called in the test, QuickTest creates a corresponding action sheet in the Data Table so that we can enter Data Table parameters that are specific to that action only.
Three types of actions are: Non-reusable action This non reusable action can be called only once and that too in the test with which it is stored.
Reusable action Reusable actions are like functions in any programming language. If there is a process that needs to be included in several tests, we can record, modify, and enhance the steps of the process and save them in a reusable action. Then we can call the action from other tests, rather than recording, modifying, and enhancing the same steps each time. It can be called several times by the test with which it is stored (the local test), as well as by other tests.
Deleting a reusable action that is called by other tests will cause those tests to fail.
External action is a reusable action stored with another test. External actions are read-only in the calling test, but we can choose to use a local, editable copy of the Data Table information for the external action. When a call to an external action is inserted, the action is inserted in read-only format
We can create an additional call to any reusable or external action in the test by pressing CTRL while we drag and drop the action to another location at a parallel (sibling) level within the test.
By default, new actions are non-reusable. Each action created in a test can be marked as reusable or non-reusable.
When we run a test with multiple actions, the test results are divided by actions within each test iteration so that we can see the outcome of each action, and can view the detailed results for each action individually.
If you expect other users to open your tests and all actions in your tests are stored in the same drive, you should use relative paths for your reusable actions so that other users will be able to open your tests even if they have mapped their network drives differently.
The default mode of recording is the Normal recording mode. There are other
recording modes also like
Analog Recording or Low Level Recording. Normal mode is the default and takes full advantage of the QuickTest test object model, as it recognizes the objects in the application regardless of their location on the screen. Analog Recording : Exact mouse and keyboard operations are recorded in relation to either the screen or the application window. In this QTP also records and tracks every movement of the mouse for example, recording a signature produced by dragging the mouse. Analog Recording steps are not editable from within QuickTest.
Low Level Recording : At any time, if an environment or on an object not recognized by QuickTest, use Low Level Recording. It records at object level and records all run-time objects as Window or WinObject test objects. QuickTest records all parent level objects as Window test objects and all other objects as WinObject test objects.
Each step recorded in Low Level Recording mode is shown in the Keyword View and Expert View. All the three modes of recording can be used in a single test e.g. we can switch to either Analog Recording or Low Level Recording in the middle of a recording session for specific steps and then return to normal recording mode.
Analog Recording and Low Level Recording require more disk space than normal recording mode.
Use Analog Recording when :
The actual movement of the mouse is what you want to record.
Recording in Analog mode can be relative to the screen or relative to a specific window
In Analog Recording a separate file is saved and stored with the action.
In Analog Recording mode, QuickTest adds to your test a RunAnalog statement that calls the recorded analog file.
Use Low Level Recording when :
Environments or objects not supported by QuickTest.
Exact location of the operation on your application screen is necessary. in normal mode QuickTest performs the step on an object even if it has moved to a new location on the screen.
If the location of the object is important to your test, switch to Low Level Recording.
recording modes also like
Analog Recording or Low Level Recording. Normal mode is the default and takes full advantage of the QuickTest test object model, as it recognizes the objects in the application regardless of their location on the screen. Analog Recording : Exact mouse and keyboard operations are recorded in relation to either the screen or the application window. In this QTP also records and tracks every movement of the mouse for example, recording a signature produced by dragging the mouse. Analog Recording steps are not editable from within QuickTest.
Low Level Recording : At any time, if an environment or on an object not recognized by QuickTest, use Low Level Recording. It records at object level and records all run-time objects as Window or WinObject test objects. QuickTest records all parent level objects as Window test objects and all other objects as WinObject test objects.
Each step recorded in Low Level Recording mode is shown in the Keyword View and Expert View. All the three modes of recording can be used in a single test e.g. we can switch to either Analog Recording or Low Level Recording in the middle of a recording session for specific steps and then return to normal recording mode.
Analog Recording and Low Level Recording require more disk space than normal recording mode.
Use Analog Recording when :
The actual movement of the mouse is what you want to record.
Recording in Analog mode can be relative to the screen or relative to a specific window
In Analog Recording a separate file is saved and stored with the action.
In Analog Recording mode, QuickTest adds to your test a RunAnalog statement that calls the recorded analog file.
Use Low Level Recording when :
Environments or objects not supported by QuickTest.
Exact location of the operation on your application screen is necessary. in normal mode QuickTest performs the step on an object even if it has moved to a new location on the screen.
If the location of the object is important to your test, switch to Low Level Recording.
QTP (QuickTest Professional) keyword view
In QTP (QuickTest Professional) we first of all record a test, then run a test and then analyze the results, but before running the test we can also enhance it with checkpoints and parameters.
First of all let's talk a little about keyword view in QTP and then we will talk about recording in QTP and then we will move on to other things. After recording all the operations, QuickTest displays them as steps in the Keyword View, and generates them in a script (in an Expert View).
In the keyword view there are 4 visible columns –
Item- The item on which we want to perform the step and it can be a test object, utility object, function call, or statement. This column shows a hierarchical icon-based tree. The highest level of the tree is actions, and all steps are contained within the relevant branch of the tree.
Operation- The operation (methods or functions) to be performed on the item selected in the Item column, for example, Click or Select.
Value- The argument values for the selected operation, for example, the mouse button to use when clicking the image.
Documentation- It is a Read-only auto-documentation of what the step does in an easy-to-understand sentence, for example, Click the "findFlights" image.
Assignment- The assignment of a value to or from a variable for example, Store in cCols would store the return value of the current step in a variable called cCols so you can use the value later in the test. This column is not visible by default.
Comment- Any textual information you want to add regarding the step. This column is also not visible by default.
First of all let's talk a little about keyword view in QTP and then we will talk about recording in QTP and then we will move on to other things. After recording all the operations, QuickTest displays them as steps in the Keyword View, and generates them in a script (in an Expert View).
In the keyword view there are 4 visible columns –
Item- The item on which we want to perform the step and it can be a test object, utility object, function call, or statement. This column shows a hierarchical icon-based tree. The highest level of the tree is actions, and all steps are contained within the relevant branch of the tree.
Operation- The operation (methods or functions) to be performed on the item selected in the Item column, for example, Click or Select.
Value- The argument values for the selected operation, for example, the mouse button to use when clicking the image.
Documentation- It is a Read-only auto-documentation of what the step does in an easy-to-understand sentence, for example, Click the "findFlights" image.
Assignment- The assignment of a value to or from a variable for example, Store in cCols would store the return value of the current step in a variable called cCols so you can use the value later in the test. This column is not visible by default.
Comment- Any textual information you want to add regarding the step. This column is also not visible by default.
Parameterizing Tests in QTP (QuickTest Professional)
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.
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.
QTP (QuickTest Professional) Recording
The default mode of recording is the Normal recording mode. There are other
recording modes also like
Analog Recording or Low Level Recording. Normal mode is the default and takes full advantage of the QuickTest test object model, as it recognizes the objects in the application regardless of their location on the screen. Analog Recording : Exact mouse and keyboard operations are recorded in relation to either the screen or the application window. In this QTP also records and tracks every movement of the mouse for example, recording a signature produced by dragging the mouse. Analog Recording steps are not editable from within QuickTest.
Low Level Recording : At any time, if an environment or on an object not recognized by QuickTest, use Low Level Recording. It records at object level and records all run-time objects as Window or WinObject test objects. QuickTest records all parent level objects as Window test objects and all other objects as WinObject test objects.
Each step recorded in Low Level Recording mode is shown in the Keyword View and Expert View. All the three modes of recording can be used in a single test e.g. we can switch to either Analog Recording or Low Level Recording in the middle of a recording session for specific steps and then return to normal recording mode.
Analog Recording and Low Level Recording require more disk space than normal recording mode.
Use Analog Recording when :
The actual movement of the mouse is what you want to record.
Recording in Analog mode can be relative to the screen or relative to a specific window
In Analog Recording a separate file is saved and stored with the action.
In Analog Recording mode, QuickTest adds to your test a RunAnalog statement that calls the recorded analog file.
Use Low Level Recording when :
Environments or objects not supported by QuickTest.
Exact location of the operation on your application screen is necessary. in normal mode QuickTest performs the step on an object even if it has moved to a new location on the screen.
If the location of the object is important to your test, switch to Low Level Recording.
recording modes also like
Analog Recording or Low Level Recording. Normal mode is the default and takes full advantage of the QuickTest test object model, as it recognizes the objects in the application regardless of their location on the screen. Analog Recording : Exact mouse and keyboard operations are recorded in relation to either the screen or the application window. In this QTP also records and tracks every movement of the mouse for example, recording a signature produced by dragging the mouse. Analog Recording steps are not editable from within QuickTest.
Low Level Recording : At any time, if an environment or on an object not recognized by QuickTest, use Low Level Recording. It records at object level and records all run-time objects as Window or WinObject test objects. QuickTest records all parent level objects as Window test objects and all other objects as WinObject test objects.
Each step recorded in Low Level Recording mode is shown in the Keyword View and Expert View. All the three modes of recording can be used in a single test e.g. we can switch to either Analog Recording or Low Level Recording in the middle of a recording session for specific steps and then return to normal recording mode.
Analog Recording and Low Level Recording require more disk space than normal recording mode.
Use Analog Recording when :
The actual movement of the mouse is what you want to record.
Recording in Analog mode can be relative to the screen or relative to a specific window
In Analog Recording a separate file is saved and stored with the action.
In Analog Recording mode, QuickTest adds to your test a RunAnalog statement that calls the recorded analog file.
Use Low Level Recording when :
Environments or objects not supported by QuickTest.
Exact location of the operation on your application screen is necessary. in normal mode QuickTest performs the step on an object even if it has moved to a new location on the screen.
If the location of the object is important to your test, switch to Low Level Recording.
Subscribe to:
Comments (Atom)