Thursday, January 21, 2010

Learn QTP Yourself

Test Automation is the use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions[1]. Commonly, test automation involves automating a manual process already in place that uses a formalized testing process.
Although manual tests may find many defects in a software application, it is a laborious and time consuming process. In addition it may not be effective in finding certain classes of defects. Test automation is a process of writing a computer program to do testing that would otherwise need to be done manually. Once tests have been automated, they can be run quickly. This is often the most cost effective method for software products that have a long maintenance life, because even minor patches over the lifetime of the application can cause features to break which were working at an earlier point in time
Software Test Automation is the process of automating the steps of manual test cases using an automation tool Or utility to shorten the testing life cycle with respect to time…When application undergoes regression, some of the steps might be missed out or skipped which can be avoided in Automation…Automation helps to avoid human errors and also expedite the testing process…To implement the Test Automation detailed planning and effort is requiredAutomation saves time and effort which results in reduction of the Test life cycle…
What to test
Testing tools can help automate tasks such as product installation, test data creation, GUI interaction, problem detection (consider parsing or polling agents equipped with oracles), defect logging, etc., without necessarily automating tests in an end-to-end fashion.
One must keep following points when thinking of test automation:
Platform and OS independence
Data driven capability (Input Data, Output Data, Meta Data)
Customizable Reporting (DB Access, crystal reports)
Email Notifications (Automated notification on failure or threshold levels)
Easy debugging and logging
Version control friendly – minimum or zero binary files
Extensible & Customizable (Open APIs to be able to integrate with other tools)
Common Driver (Ant or Maven)
Headless execution for unattended runs (For integration with build process or batch runs)
Support distributed execution environment (distributed test bed)
Distributed application support (distributed SUT)
Benefits of Automation- Consistency of Test Execution- Reducing cycle time of regression test cycles- Data driven testing- Repeatability- Coverage- Reliability- Reusability of test waresAutomation life cycle is a subset of the entire test life cycle…Automation planning can be initiated in parallel to the test planning phase…Factors to be considered in automation planning,Stability of AUT (Application under test)No of regression cycles to be performedCompatibility of App platform with testing toolsCost benefit analysis (ROI)Availability of skilled resourcesRegression Testing & Automation When Automation is applicable?Regression Testing Cycles are long and iterative.If the application is planned to have multiple releases / buildsIf it’s a long running application where in small enhancements / Bug Fixes keeps happeningTest Repeatability is required
Automation Testing Process Automation Testing involves 3 main stages:
Creating Test scripts Running TestsAnalyzing Test ResultsCreating Tests Create a test script by recording a manual test scenario on the AUT (Application Under Test) using QTP. Quick Test Pro graphically displays each step users perform in the form of a collapsible, icon based tree view in QTP’s Keyword View.Running Tests & Analyzing Test ResultsRunning Tests:Once the test scripts are recorded / created, next step is to execute them…While running (executing) the tests Quick Test Pro connects to the web site or AUT and performs each operation in the test as performed manually while recording / creating tests (test scripts)…Debugging Test : To identify and eliminate the defects in the test scripts. Analyzing Test Results: Once the test scripts are executed, test results and the summary can be viewed for result analysis.
Why Automated Testing?
Every software development group tests its products, yet delivered software always has defects. Test engineers strive to catch them before the product is released but they always creep in and they often reappear, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of your software testing.
Manual software testing is performed by a human sitting in front of a computer carefully going through application screens, trying various usage and input combinations, comparing the results to the expected behavior and recording their observations. Manual tests are repeated often during development cycles for source code changes and other situations like multiple operating environments and hardware configurations. An automated software testing tool is able to playback pre-recorded and predefined actions, compare the results to the expected behavior and report the success or failure of these manual tests to a test engineer. Once automated tests are created they can easily be repeated and they can be extended to perform tasks impossible with manual testing. Because of this, savvy managers have found that automated software testing is an essential component of successful development projects.
Automated software testing has long been considered critical for big software development organizations but is often thought to be too expensive or difficult for smaller companies to implement. AutomatedQA’s TestComplete is affordable enough for single developer shops and yet powerful enough that our customer list includes some of the largest and most respected companies in the world.
Companies like Corel, Intel, Adobe, Autodesk, Intuit, McDonalds, Motorola, Symantec and Sony all use TestComplete.
What makes automated software testing so important to these successful companies?
Automated Software Testing Saves Time and Money
Software tests have to be repeated often during development cycles to ensure quality. Every time source code is modified software tests should be repeated. For each release of the software it may be tested on all supported operating systems and hardware configurations. Manually repeating these tests is costly and time consuming. Once created, automated tests can be run over and over again at no additional cost and they are much faster than manual tests. Automated software testing can reduce the time to run repetitive tests from days to hours. A time savings that translates directly into cost savings.
Automated Software Testing Improves Accuracy
Even the most conscientious tester will make mistakes during monotonous manual testing. Automated tests perform the same steps precisely every time they are executed and never forget to record detailed results.
Automated Software Testing Increases Test Coverage
Automated software testing can increase the depth and scope of tests to help improve software quality. Lengthy tests that are often avoided during manual testing can be run unattended. They can even be run on multiple computers with different configurations. Automated software testing can look inside an application and see memory contents, data tables, file contents, and internal program states to determine if the product is behaving as expected. Automated software tests can easily execute thousands of different complex test cases during every test run providing coverage that is impossible with manual tests. Testers freed from repetitive manual tests have more time to create new automated software tests and deal with complex features.
Automated Software Testing Does What Manual Testing Cannot
Even the largest software departments cannot perform a controlled web application test with thousands of users. Automated testing can simulate tens, hundreds or thousands of virtual users interacting with network or web software and applications.
Automated Software Testing Helps Developers and Testers
Shared automated tests can be used by developers to catch problems quickly before sending to QA. Tests can run automatically whenever source code changes are checked in and notify the team or the developer if they fail. Features like these save developers time and increase their confidence.
Automated Software Testing Improves Team Morale
This is hard to measure but we’ve experienced it first hand, automated software testing can improve team morale. Automating repetitive tasks with automated software testing gives your team time to spend on more challenging and rewarding projects. Team members improve their skill sets and confidence and, in turn, pass those gains on to their organization.
More often than not, I have seen people going for test automation just because they want to go for this exciting buzzword. It is generally realized in the very end that automation has not given intended returns.I would suggest that before even thinking of Automation a thorough study of your application/system/module should be performed.The following types of test cases are preferred (but not limited to) choice for automation:
Tests that need to run for every build.
Tests that use multiple data values for same action.
Identical tests that need to be executed using different browsers
The following types are not considered to be the good candidates for automation:
Test Cases that will only be executed once.
Test Cases used for Ad-hoc/random Testing.
Test Cases that are infrequently selected for execution.
Test Cases that will require manual intervention ie a task not possible to automate.
The most imp. one--based on the intuition and knowledge of application. Eg. if you find that you cannot escape from manual intervention.
Above all the effort required to develop and maintain the automated scripts should be weighed against the resources (no of hours, budget) that task would take while manual execution. The amount of changes the application undergoes from one build to another should also be taken into account while choosing for test automation.If an app undergoes drastic changes that means most time will be exhausted in maintaining the scripts. These apps are then considered bad choice for automation.Considering the above points Return On Investment (ROI) should be calculated and this should be the single most important criterion while going for Test Automation.
QuickTest 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 and desktop 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.
QTP is UI automation software designed for testing Web-based and Windows based applications running on Microsoft Windows. Like other test automation tools, it works by identifying the objects in the application UI or a web page and performing the desired operations on them (like mouse clicks or keyboard events); it can also be used to capture object properties like name or handler ID etc. To perform these actions, 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. To perform sophisticated actions, users may need to manipulate the underlying VBScript.
Though QTP is usually used for "UI Based" Test Case Automation, it can automate some "Non-UI" based Test Cases. (e.g. API (Certification testing), Database Testing, etc.)
“The Mercury advanced keyword-driven testing solution”Technologies SupportedDefault Support 1. Standard Windows applications2. Web objects / Applications3. ActiveX controls4. Visual Basic applicationsAdditional QuickTest add-ins Support,1. Java 2. Oracle 3. SAP Solutions,4. .NET Windows5. Web Forms, 6. Siebel, 7. PeopleSoft, 8. Web services, and terminal emulator applications.
QTP’s Add-in Manager facilitates the users to select the technology / environment from variety of environments suitable for the AUT (Application Under Test)Once an add-in is loaded, users can record that application in its supported environment and thus QTP recognizes the objects specific to the application under test (AUT) as loaded through Add-in Manager.It is critical for the users to know the development technologies / environment of AUT, and load right Add-Ins while invoking Quick Test Pro.
Learning Recording
Lets start recording with the mercury sample application FLIGHT.
We will begin with a simple test like the "Hello World" program with which we start learning any programming language.
1) First of all Click on Record toolbar button ( or Automation menu --> Record or press F3). when we click on Record, "Record and Run Settings" window opens up. Go to "Windows Applications" tab and choose first option "Record and run test on any open windows based application." and click on ok.
2) Open Flight application (Start -->All programs -->QuickTest Professional--> Sample Applications --> Flight)
3) Type Agent name as "duke" (You can enter any, but must be 4 characters or more) and enter password as "mercury".
4) In the flight reservation window that opens up:
a) In the Flight Schedule area, in Date of Flight enter tomorrow's date in mm/dd/yyyy format.( I used tabs to move to next fields)b)In Fly From enter Denverc)In Fly To enter Londond) Click on Flights button which is on the right hand side of "Fly To".Let the default option be selected in the Flights Table.e) Click okf)In the name field enter your name. It will fill rest of the required information by itself.g) Click on insert order and after the order is insertedh) Click on File --> exit.
5) Now you have recorded your first script. You can click on the expert view tab to see the script which QTP has recorded for you automatically.
6) Click on run from Automation Menu (or press F5) to open up run dialog box.
7) Go to the "Results Location" tab, and below "write run results to", in "new run results folder" radio button- let it be the default option --C:\Program Files\Mercury Interactive\QuickTest Professional\Tests\Test1\Res1(you can also change it)
8) click on ok.
This will run you earlier recorded test and show you the results.
But we have to go a long way. This is just the beginning.
Choosing the QTP Recording Mode
Normal recording mode records the objects in your application and the operations performed on them. This mode is the default and takes full advantage of the QTP test object model, recognizing the objects in your application regardless of their location on the screen.
When working with specific types of objects or operations, however, you may want to choose from the following, alternative recording modes:
Analog Recording. Enables you to record the exact mouse and keyboard operations you perform in relation to either the screen or the application window. In this recording mode, QTP records and tracks every movement of the mouse as you drag the mouse around a screen or window.
This mode is useful for recording operations that cannot be recorded at the level of an object, for example, recording a signature produced by dragging the mouse.
Note: You cannot edit Analog Recording steps from within QTP.
Low Level Recording. Enables you to record on any object in your application, whether or not QTP recognizes the specific object or the specific operation. This mode records at the object level and records all run-time objects as Window or WinObject test objects. Use low-level recording for recording in an environment or on an object not recognized by QTP. You can also use low-level recording if the exact coordinates of the object are important for your test.
Note: Steps recorded using Low Level Recording mode may not run correctly on all objects.
QTP Analog Recording
You can switch to Analog Recording mode only while recording. The option is not available while editing.
To record in Analog Recording mode:
If you are not already recording, click the Record button to begin a recording session.
Click the Analog Recording button or select Automation > Analog Recording. The Analog Recording Settings dialog box opens.
Select from the following options:
Record relative to the screen. QTP records any mouse movement or keyboard input relative to the coordinates of your screen, regardless of which application(s) are open or which application(s) you specified in the Record and Run Settings dialog box.
Select Record relative to the screen if you perform your analog operations on objects located within more than one window or if the window itself may move while you are recording your analog operations.
Note: When you record in Analog Recording mode relative to the screen, the run session will fail if your screen resolution or the screen location on which you recorded your analog steps has changed from the time you recorded. The analog tracking continues to record the movement of the mouse until the mouse reaches the QTP screen to turn off Analog Recording or to stop recording. Clicking on the QTP icon in the Windows taskbar is also recorded. This should not affect your test. The mouse movements and clicks on the QTP screen itself are not recorded.
Record relative to the following window. QTP records any mouse movement or keyboard input relative to the coordinates of the specified window.
Select Record relative to the following window if all your operations are performed on objects within the same window and that window does not move during analog recording. This guarantees that the test will run the analog steps in the correct position within the window even if the window's screen location changes after recording.

Note: If you have selected to record in Analog Recording mode relative to a window, any operation performed outside the specified window is not recorded while in Analog Recording mode.
If you choose to Record relative to the following window, click the pointing hand and click anywhere in the window on which you want to record in Analog Recording mode. The title of the window you clicked is displayed in the window title box.

Click Start Analog Record.
Perform the operations you want to record in Analog Recording mode.
All of your keyboard input, mouse movements, and clicks are recorded and saved in an external file. When QTP runs the test, the external data file is called. It tracks every movement and click of the mouse to replicate exactly the operations you recorded.
When you are finished and want to return to normal recording mode, click the Analog Recording button or select Automation > Analog Recording to turn off the option.
If you chose to Record relative to the screen, QuickTest inserts the RunAnalog step for a Desktop item. For example:

The track file called by the RunAnalog method contains all your analog data and is stored with the current action.
You can use this track file in more than one action in your test, and also in other tests, by saving the action containing the RunAnalog step as a reusable action. A reusable action can be called by other tests or actions.

Note: When entering the RunAnalog method, you must use a valid and existing track file as the method argument.
Tip: To stop an analog step in the middle of a run session, press Ctrl + Esc, then click Stop in the Testing toolbar.

Tips for Using the Pointing Hand
You can hold the left Ctrl key to change the pointing hand to a standard pointer. You can then change the window focus or perform operations in QTP or in your application, such as right-clicking, using the scroll bars, or moving the pointer over an object to display a context menu.
If the window containing the object you want to select is partially hidden by another window, hold the pointing hand over the partially hidden window for a few seconds until it comes to the foreground. Then point to and click the required object. You can configure the length of time required to bring a window into the foreground using the General pane of the Options dialog box.
If the window containing the object you want to select is fully hidden by another window, or if a dialog box is hidden behind a window, press the left Ctrl key and arrange the windows as needed.
If the window containing the object you want to select is minimized, you can display it by holding the left Ctrl key, right-clicking the application in the Windows task bar, and choosing Restore from the context menu.
If the object you want to select can be displayed only by performing an event (such as right-clicking or moving the pointer over an object to display a context menu), hold the left Ctrl key. The pointing hand temporarily turns into a standard pointer and you can perform the event. When the object you want to select is displayed, release the left Ctrl key. The pointer becomes a pointing hand again.
QTP Low Level Recording
You can switch to Low Level Recording mode only while recording a test. The option is not available while editing a test.
To record in Low Level Recording mode:
If you are not already recording, click the Record button to begin a recording session.
Click the Low Level Recording button or select Automation > Low Level Recording.
The record mode changes to Low Level Recording and all of your keyboard input and mouse clicks are recorded based on mouse coordinates. When QTP runs the test, the cursor retraces the recorded clicks.
When you are finished and want to return to normal recording mode, click the Low Level Recording button or select Automation > Low Level Recording to turn off the option.
The following examples illustrate the difference between the same operations recorded using normal mode and Low Level Recording mode.
Suppose you type the word tutorial into a user name edit box and then press the Tab key while in normal recording mode. Your test is displayed as follows in the Keyword View and Expert View:

Using Data Table
Lets use data table:
There are two types of data tables Design time and Run time:
Design time data table is what you see in the main QTP window and run time data table you can see only in the test results window. Design time data table is always created before running the test while run time data table is generated after execution of the test.
1) Open new test (Ctrl+N)
2) We will Click on record toolbar button ( or Automation menu --> record or press F3). when we click on record, "Record and Run Settings" window opens up. Go to "Windows Applications" tab and choose first option "Record and run test on any open windows based application." and click on ok.
3) Open Flight application (Start-->All programs-->QuickTest Professional->Sample Applications-->Flight)
4) Type Agent name as "Niyati" (you can enter any, but must be 4 characters or more) and enter password as "mercury".
5) In the flight reservation window that opens up:
6) Click on File-->exit. Click Stop to stop the recording.
7) In the keyword view you will see four headings- Item, Operation, Value, Documentation. Under Value click on Kumar and on the right hand side of Kumar you will see a small icon, just click on that (or press ctrl + F11), The "Value Configuration Options" dialog box opens. In that dialog box click on parameter Radio button and select Data Table from there. In Name field enter any variable name (I entered 'username'). Let all other be the default options in this dialog box and click on ok.
8) QTP will add username column in the data table (bottom, left hand side) with 'Niyati' as the first value.
9) Now enter more values in the username column, manually. I entered 'Varun' and 'Tanya' in 2nd and 3rd column respectively.
10) Save the test. (File-->Save).
11) Now run the test. (follow same steps as we did earlier).
12) If the test ran successfully, in the Results summary window on the left hand side you will see three iterations (because we added 3 variables in the 3 rows of a data table). Expand 1st iteration, it will show action summary for that iteration, expand the action summary, it will show Login, Expand the login. Click on the first option under it "Agent Name: SetText". On the right hand side it will show 1st variable name under details.
13) Similarly you can look for 2nd and 3rd.
Accessing Data Table values through Script
What if we want to write a short script that accesses values from the data Table.
1) Make sure that QTP (with a new blank test) and a blank notepad is open.
2) In the Data Table below write a, b, c in the first column A.
3) Click on Record. When we click on Record, "Record and Run Settings" window opens up. Go to "Windows Applications" tab and choose first option "Record and run test on any open windows based application." and click on ok.
4) Just highlight the notepad and write 'a' on it.
5) Click on Stop so as to stop recording.
6) In the expert view your script will look like this:
Window("Notepad").WinEditor("Edit").SetCaretPos 0,0
Window("Notepad").WinEditor("Edit").Type "a"
7) We have to make it look like this:
rc = DataTable.Value("A", dtGlobalSheet)
msgbox rc
Window("Notepad").WinEditor("Edit").SetCaretPos 0,0
Window("Notepad").WinEditor("Edit").Type rc
8) Save the Test.
9) Run the Test again with a blank Notepad open. It will enter all the three values from Data Table into the Notepad.
Using Global and Action Data Sheets in QTP
When you output a value to the Data Table or add a Data Table parameter to your test, you can specify whether to store the data in the Global data sheet or in the action data sheet.
Choosing Global sheet enables you to create a new column or select an existing column in the Global sheet in the Data Table. When you run your test, QTP inserts or outputs a value from or to the current row of the Global data sheet during each global iteration. You can use the columns in the Global data sheet for Data Table output values or Data Table parameters in any action. This enables you to pass information between actions.
Each action also has its own sheet in the Data Table so that you can insert data that applies only to that action. Choosing Current action sheet (local) enables you to create a new column or select an existing column in the corresponding action sheet in the Data Table. Note that the name of the action sheet is the same as the name of the relevant action. When you run your test, QTP inserts or outputs a value from or to the current row of the current action (local) data sheet during each action iteration.
When there are parameters or output value steps in the current action's sheet, you can set QTP to run one or more iterations on that action before continuing with the current global iteration of the test. When you set your action call properties to run iterations on all rows, QTP inserts the next value from or to the corresponding action parameter or output value during each action iteration, while the values of the global parameters stay constant.
Note: If you create Data Table parameters or output value steps in your action and select to use the Current action sheet (local) option, be sure that the run settings for your action are set correctly in the Run tab of the Action Call Properties dialog box. You can set your action to run without iterations, to run iterations on all rows in the action's data sheet, or to run iterations only on the rows you specify.
For example, suppose you want to test how a flight reservation system handles multiple bookings. You may want to parameterize the test to check how your site responds to multiple sets of customer flight itineraries. When you plan your test, you plan the following procedures:
The travel agent logs into the flight reservation system.
The travel agent books five sets of customer flight itineraries.
The travel agent logs out of the flight reservation site.
When you consider these procedures, you realize that it is necessary to parameterize only the second step—the travel agent logs into the flight reservation system only once, at the beginning, and logs out of the system only once, at the end. Therefore, it is not necessary to parameterize the login and logout procedures in your test.
By creating three separate actions within your test—one for logging in, another for booking a flight, and a third for logging out—you can parameterize the second action in your test without parameterizing the others.
Understanding the QTP Object Hierarchy
The QuickTest Professional test object hierarchy comprises one or more levels of test objects. The top level object may represent a window, dialog box, or browser type object, depending on the environment. The actual object on which you perform an operation may be learned as a top level object, a second level object, for example, Window.WinToolbar, or a third level object, for example, Browser.Page.WebButton.
In some cases, even though the object in your application may be embedded in several levels of objects, the hierarchy does not include these objects. For example, if a WebButton object in your application is actually contained in several nested WebTable objects, which are all contained within a Browser and Page, the learned object hierarchy is only Browser.Page.WebButton.
An object that can potentially contain a lower-level object is called a container object. All top-level objects in the object hierarchy are container objects. If a second-level object contains third-level objects according to the QuickTest Professional object hierarchy, then that object is also considered a container object.
For example, in the step Browser.Page.Edit.Set "David", Browser and Page are both container objects.
When you add a step to your test in the Keyword View, the step is added as a sibling step or sub-step of the currently selected step, according to the QuickTest Professional object hierarchy, as follows:

QTP Object Repository automation object model
Manipulate QTP Object Repositories Using the Object Repository Automation Objects and Methods.The QTP Repository automation object model enables you to manipulate QTP shared object repositories and their contents from outside of QTP. The automation object model enables you to use a scripting tool to access QTP shared object repositories via automation.Automation programs are especially useful for performing the same tasks multiple times or on multiple shared object repositories. You can write your automation programs in any language and development environment that supports automation. For example, you can use VBScript, JavaScript, Visual Basic, Visual C++, or Visual Studio.NET.Just as you use the QTP object model to automate your QTP operations, you can use the objects and methods of the Object Repository automation object model to write programs that manipulate shared object repositories, instead of performing these operations manually using the Object Repository Manager. For example, you can add, remove, and rename objects; import from and export to XML; retrieve and copy objects; and so forth.After you have retrieved an object, you can manipulate it using the methods and properties available for that test object class. For example, you can use the GetTOProperty or SetTOProperty methods to retrieve and modify its properties.Note: You can use the Object Repository automation object model to manipulate shared object repositories saved in the file system. If you want to manipulate a shared object repository stored in Quality Center, you must download the shared object repository and save it to the file system, before using the Object Repository automation object model to manipulate it.
ObjectRepositoryUtil Object
Description: ObjectRepositoryUtil Object enables you to manipulate object repository files (shared and local) from outside of QTP.Methods:AddObject - Adds the specified object to the object repository under the specified parent object.You can use this method to add a copy of an object that you retrieved from a different object repository.Tip: Before adding an object to the object repository, you can modify its description properties using the SetTOProperty method.Syntax: object.AddObject (Object, Parent, [Name])Convert - Converts the specified object repository file (version 8.2.1 or earlier) to the current format.You must convert object repository files from QuickTest Professional 8.2.1 or earlier to the current format before you can use them in QuickTest Professional 9.0 or later.Note: You do not need to use the Load method to load the object repository before converting it.Syntax: object.Convert (OldFile, NewFile)CopyObject - Creates a copy of the specified object in the object repository.To copy an object from one object repository to another, first create a copy of the object using this method. Then load another object repository, and use the AddObject method to add the returned (copied) object to the other repository.Syntax: object.CopyObject (Object)ExportToXML - Exports the specified object repository to the specified XML file.- Only test objects are exported to the XML file. If your object repository contains checkpoint or output objects, they are not exported to the XML file.- This method can be used only to export shared object repositories (*.tsr files). Local object repositories cannot be exported.- The object repository you want to export must be in QuickTest version 9.0 or later format. If the object repository is in an earlier format, you can use the Convert method to convert it before exporting it.Syntax: object.ExportToXML (SourceFile, TargetFile)GetAllObjects - Retrieves all objects under the specified parent object.You can use this method to enumerate the objects in an object repository and retrieve a collection of objects, even if you do not have any information about any of the objects in the object repository.Syntax: object.GetAllObjects ([Parent])GetAllObjectsBy- Class Retrieves all objects of the specified class under the specified parent object.You can use this method to enumerate the objects in an object repository and retrieve a collection of objects, even if you do not have any information about any of the objects in the object repository.Syntax: object.GetAllObjectsByClass (Class, [Parent])GetChildren - Retrieves all direct children of the specified parent object.You can use this method to enumerate the objects in an object repository and retrieve a collection of objects, even if you do not have any information about any of the objects in the object repository.Syntax: object.GetChildren ([Parent])GetChildrenByClass- Retrieves all direct children of the specified class under a specified parent.You can use this method to enumerate the objects in an object repository and retrieve a collection of objects, even if you do not have any information about any of the objects in the object repository.Syntax: object.GetChildrenByClass (Class, [Parent])GetLogicalName - Retrieves the name of the specified object.Retrieves the name of the specified object.Syntax: object.GetLogicalName (Object)GetObject - Retrieves the object according to the specified path.This method is similar to the GetObjectByParent method, but it enables you to supply the entire object path (including the parent object information) as a string. This is useful when you do not have access to an object containing the parent.If you do have access to the parent as an object (rather than a string), it is recommended to use the GetObjectByParent method for better performance.Syntax: object.GetObject (ObjectPath)GetObjectByParent- Retrieves the object according to the specified parent object and object name.This method is similar to the GetObject method, but enables you to supply an object for the parent argument (if available) rather than a string.Supplying an object results in better performance.Syntax: object.GetObjectByParent (Parent, Object)ImportFromXML - Imports the specified XML file to the specified object repository.This method can be used only to import XML files into new shared object repositories (*.tsr files). It cannot be used with local object repositories.Object repository XML files contain only test objects. They do not contain checkpoint or output objects.Syntax: object.ImportFromXML (SourceFile, TargetFile)Load - Loads the specified object repository file.You must load an object repository file before performing any other object repository automation steps.All object repository automation steps in your script that follow a load statement, perform the operations on the loaded object repository file.If your script contains more than one Load statement on the same RepositoryUtil object, the second Load statement effectively unloads the first repository.To load more than one repository at once, create multiple RepositoryUtil objects and load the repositories using different objects.Syntax: object.Load FileNameRemoveObject - Removes the specified object from the object repository.You can remove objects from an object repository if they are no longer needed. Removing unnecessary objects helps to simplify maintenance and improves object repository performance.Syntax: object.RemoveObject Parent, ObjectRenameObject - Renames the specified object in the object repository.You can rename an object to provide a more descriptive name, which makes it easier to read your test or component steps.Syntax: object.RenameObject (Object, Name)Save - Saves any changes made while running an object repository automation script.Saves any changes made while running an object repository automation script.Syntax: object.SaveUpdateObject - Updates the object repository with any changes made to the specified object.You should call this method after any object change (for example, rename, copy, and so forth).Syntax: object.UpdateObject ObjectTOCollection Object A collection of object repository objects, returned by methods of the ObjectRepositoryUtil object.Example: Manipulate Object Repositories Using the Object Repository Automation Objects and Methods.The following example retrieves an object repository's objects and properties, looks for specific test objects using several methods, and copies a test object to another object repository.
Standard Checkpoint
Checkpoints cannot be added manually, they are inserted using QTP's interface. Results of the checkpoint can be viewed in the Test Results Window.
Checkpoint information is stored in the Local Object Repository. It is in the Resource.mtr file which is in the action folder (if you created checkpoint in action1 then it will be action 1 folder under the folder in which you are saving the test/script, if you created checkpoint in action 2 then it will be action 2 folder and so on) .
In the expert view, on any blank line type Checkpoint and put "(". As soon as you put the starting bracket it will show all the checkpoints you have used in the test.
Now we will start with checkpoints. I will try to show easy to understand example of each and every checkpoint.
Lets start with simple example of standard checkpoint which checks a variety of objects such as buttons, radio buttons, combo boxes etc. Standard checkpoints are supported for all add-in environments
1. Open a blank test.
2. Make sure that Flight application is open.(Now only QTP with blank test and Flight application should be open).
3. Click on Record. When we click on Record, "Record and Run Settings" window opens up. Go to "Windows Applications" tab and choose first option "Record and run test on any open Windows based application." and click ok.
4. Go to Insert (menu)->Checkpoint->Standard Checkpoint (or press F12).The mouse pointer will become hand and QTP will be minimized.
5. Click on the "Flights..." button which is on the Right Hand Side of the "Fly To" combo box in the Flight application.
6. It will open "Object Selection - Checkpoint Properties" window (with WinButton:FLIGHT highlighted). Click ok.
7. It will open checkpoint properties window. (only one property will be checked in it i.e. 'enabled' with a value of False.)
8. Click ok. Click on Stop in order to stop the Recording.
9. Save the test.
This is a small test in which we have used standard checkpoint and captured the disabled button on the Flight application. Now we can run the test in two ways to see how it fails and passes the results of the checkpoint.
To see a pass test result:
Make sure that this test and Flight application is open. Click on run.
It will Run the test and show you the result as pass.
To see a Fail test result:
Make sure that this test and Flight application is open.
In the Flight application enter the Date of Flight, Fly From and Fly To fields and nothing else. (The reason for doing this is that it will enable the 'Flight...' button)
Click on run in order to run the test.
It will Run the test and show you the result as Fail. This is because QTP was looking for a disabled 'Flight...' button for which it recorded the information at the record time, but now since the button was enabled at run time, so it failed.
This will help you in understanding the standard checkpoint in QTP more deeply
Page Checkpoint

Page checkpoint:It is for web applications only.Common things to check with this are load time, broken links etc.
1. Open a blank test.
2. Make sure that http://www.google.co.in/ is open.(Now only QTP with blank test and www.google.co.in should be open.)
3. Click on Record. When we click on Record, "Record and Run Settings" window opens up. Go to "Web" tab and choose first option "Record and run test on any open browser." and click ok.
4. Go to Insert (menu)->Checkpoint->Standard Checkpoint (or press F12).
5. The mouse pointer will become hand and QTP will be minimized.
6. Click anywhere on the white space on the Google.co.in page.
7. It will Open "Object Selection - Checkpoint Properties" window. Click on 'Page : Google' option which has a page icon on left of it with right corner of the page slightly folded.
8. Click ok.
9. A 'Page Checkpoint Properties' window opens up. Let all the options be default. Click ok.
10. Click on Stop in order to stop the Recording.
In the Expert view it will add just one line:

Browser("Google").Page("Google").Check CheckPoint("Google")

We will explore this line later on.

I ran this test by opening www.google.co.in in offline mode (not on internet). It recorded the following properties:

Property Name
Property Value
load time
"0"
number of images
"2"
number of links
"20"
Here it shows the load time as 0 because I did not open Google at the time of running the test, it was already open.
When you run it, in the results window, on left hand side, it will show (when every option is expanded):
Test Checkpoint-page Summary (where Checkpoint-page is the name with which I saved the test
Run-Time Data Table
Checkpoint-page Iteration 1 (Row 1)
Action1 Summary
Google (This will be the browser)
Google (This will be the Page)
Checkpoint "Google"
If you run this test on www.google.com it may fail.
Bitmap Checkpoint
Now we will look at the bitmap checkpoint which is different from the image checkpoint.
Make sure that QTP and the Flight application are open.
STYLE A
1. Open a blank test.
2. Click on Record. When we click on Record, "Record and Run Settings" windowopens up. Go to "Windows Applications" tab and choose first option "Record andrun test on any open windows based application." and click Ok.
3. Go to Insert (menu)->Checkpoint->Bitmap Checkpoint
4. Click on the "Fly To" combo box.
5. "Object Selection- Bitmap Checkpoint Properties" window opens up. I will have "WinComboBox:Fly To" highlighted. Click ok
6. It will open "Bitmap Checkpoint Properties" window.
7. Change the "Checkpoint timeout" at the bottom of the window to 0 seconds, so that we will have no wait time while running the test.
8. Click ok.
9. Click stop to stop recording the test.
STYLE B
Above, after 3rd point, instead of clicking on the "Fly To" combo box, click somewhere in the empty space above the "Fly From" Combo box but below the line, i.e. in the "Flight Schedule" Area.
"Object Selection- Bitmap Checkpoint Properties" window opens up. It will have "WinObject:Flight Schedule" highlighted. Click ok
It will open "Bitmap Checkpoint Properties" winodow. This time it will have "Flight schedule" area instead of just the "Fly To" combo box.
Now click on the "Select Area..." button. Mouse pointer will change so that you can select any area by dragging. Just select "Fly From" combo box by dragging.
Change the "Checkpoint timeout" at the bottom of the window to 0 seconds. so that we will have no wait time while running the test.
Click ok.
Click stop to stop recording the test.
Now you can run the test it will pass. To see how it stores the results, just fail the test. If you have recorded in the style A then just select any value in the "Fly To" combo box and then run the test. In the result window on the left hand side when you click on Checkpoint "Fly To:", it will show you the expected bitmap and actual bitmap on the right hand side.
(note: it will show that only in case of Failed result)
Image Checkpoint
Lets see the Image checkpoint.
Open a blank test.
On your system under My Documents, there will be a folder named My Pictures,Sample Pictures( containing 4 pictures - Blue Hills, Sunset, Winter, Water lilies) under this you will will find a folder-
We will run this test with one of the image there- Sunset.
Go to My Documents->My Pictures-> Sample Pictures and right click on imagenamed 'Sunset' and open it with internet explorer.
Now only a new blank test and internet explorer with this image should be open.
Click on Record. When we click on Record, "Record and Run Settings" window opens up. Go to "Web" tab and choose first option "Record and run test on any open browser." and click on Ok.
Go to Insert (menu)->Checkpoint->Standard Checkpoint(or press F12).The mouse pointer will become hand and QTP will be minimized.
Click on the image which is opened in the explorer.
It will open 'Object Selection Checkpoint Properties' window with Image: Sunset highlighted. Click Ok.
It will Open 'Image Checkpoint Properties' Window. In this window just uncheck all the property values like href, html tag etc and only check last property which is src.
Rest every thing will be default. Click OK.
Click stop to stop recording the test.
In the expert view it will just add one line Browser("file:///C:/Documents%20and%20S").Page("file:///C:/Documents%20and%20S").Image("Sunset").Check CheckPoint("Sunset")
If you run it with that image open in internet explorer it will pass. This test is not intelligent enough. It is just checking that the image in the explorer is in the same location in which it was when the test was recorded and its name is Sunset. If you change the name of some other picture in that folder to Sunset and run the test with that it will also pass.
In this way you can test for some or all the properties of the image which it showed in the 'Image Checkpoint Properties' Window.
Text Checkpoint
Now we will look at the Text Checkpoint
Open a blank test and a web page in offline mode like this below:

Click on Record. When we click on Record, "Record and Run Settings" window opens up. Go to "Web" tab and choose first option "Record and run test on any open browser." and click on ok.
Go to Insert (menu)->Checkpoint->Text Checkpoint.The mouse pointer will become hand and QTP will be minimized.Click on the first paragraph (which starts with-The page you are looking..) of that web page.
"Text Checkpoint Properties" window opens up. It will show the text to be checked in "Checkpoint Summary" are in red color and also show in blue color the text which is displayed before and after the selected text.
Click on Configure -here you can change your selected text, change before and after text and so on, but for now just click ok. At the bottom of the "Text Checkpoint Properties" window change 'Checkpoint timeout' to 0 seconds. Again Click ok to come out of "Text Checkpoint Properties" window.
Click on stop in order to stop recording.
Run the test and when it is passed just go to the results window and on the left hand side just expand every option and click on last option Checkpoint "Cannot find server". On the right hand side it will show you the details. Try to understand those
Table Checkpoint
In this tutorial we will look at a table Checkpoint just to get familiar with it.
Open a blank test and also open a website http://www.editorial.co.in/software/software-testing-life-cycle.php" in offline mode
This website has a table at the bottom of the page.
Click on Record. When we click on Record, "Record and Run Settings" window opens up. Go to "Web" tab and choose first option "Record and run test on any open browser." and click on ok.
Go to Insert (menu)->Checkpoint->Standard Checkpoint (or press F12).
The mouse pointer will become hand and QTP will be minimized.
Click somewhere inside the table.
"Object Selection - Checkpoint properties" window opens.
Select "WebTable: Software Testing Life Cycle" which has a table icon on its left, where "Software Testing Life Cycle" is the name of the table.
Click ok.
'Table Checkpoint properties' window opens. It will show all the rows and columns of the selected table. This time we will not do any extra setting. Just change the Checkpoint timeout at the bottom of this window to 0 seconds and click ok .
Click stop in order to stop recording.
Run the test and analyze the results in the result window, mainly the checkpoint results to see how QTP verifies the result. We will manipulate test results in later tutorials.
Checkpoint Return Value
We will use the Standard Checkpoint which we did in tutorial 4.
Open that test that contains the standard Checkpoint.In the expert view of the test you will see only one line i.e.
Window("Flight Reservation").WinButton("FLIGHT").Check CheckPoint("FLIGHT")
Now we will make some changes in this one line so that it can return some value.
NOTE: Checkpoint always returns a value, it depends on us whether we capture it or not.
Lets now capture it.Declare a variable and catch the return value in that variable:
Dim returnreturn = Window("Flight Reservation").WinButton("FLIGHT").Check CheckPoint("FLIGHT")msgbox (return)
One thing more we need to do here is that we have to enclose Checkpoint ("FLIGHT") in brackets. So the final version looks like this:
Dim return
return = Window("Flight Reservation").WinButton("FLIGHT").Check (CheckPoint("FLIGHT"))msgbox (return)
It can return either true or false i.e. a boolean value. If it passes, it will return true else it will return false

Actions
In this tutorial we will see how to use more than one action in a test and how to call one action from another with in the same test.
Open a blank test. By default it will have Action1 in it (make sure you are in the keyboard view).
Make sure that Action1 is selected/highlighted and Click on the Expert View tab.
In the Expert View type:msgbox ("my action 1")
Again when you go to keyword View and expand Action1 it will show you function call under it.
In that keyword View itself go to Insert (Menu) ->Call to New Action. 'Insert Call to New Action' Dialog box opens with Action2 as a default name of a new action. By default it will be added at the end of the test as this radio button is selected in the location area.
Click ok.
It will add Action2 to your test.
Make sure that Action2 is selected and click on the Expert View tab.
In the Expert View type:msgbox ("my action 2")
Similarly insert a third Action.
After third action is added, select Action1(keyword view), right click on it and choose 'Action Properties'.
In the Action properties window that opens, check the 'Reusable action' checkbox at the bottom.
Click ok.
Now again highlight Action3 right click on it and choose 'Insert Call to Existing action'.
'Select action' dialog box appears. In this dialog box in the 'action' dropdown box it will have Action1 by default since we made only that action as reusable.
Just click ok.
In the keyword View where you can see all the three actions, make sure against Action3 it shows "Call to Action1 action" under Documentation.
Run the test. Three message boxes appear in succession showing 'my action 1', 'my action 2', and again 'my action 1'.
Insert Multiple Actions in a QTP Script
When you create a QTP Script, it includes one action. All the steps you add and all the modifications you make while editing your test are part of a single action.
You can divide your test into multiple actions by creating new actions and inserting calls to them, by inserting calls to existing actions, or by splitting existing actions. The actions used in the test, and the order in which they are run, are displayed in the Test Flow pane.
There are three kinds of actions:
Reusable action. An action that can be called multiple times by the test with which it is stored (the local test), as well as by other tests.
Non-reusable action. An action that can be called only in the test with which it is stored, and can be called only once.
External action. A reusable action stored with another test. External actions are read-only in the calling test, but you can choose to use a local, editable copy of the Data Table information for the external action. By default, new actions are reusable. You can mark each action you create in a test as reusable or non-reusable. Only reusable actions can be called multiple times from the current test or from another test. You can store a copy of a non-reusable action with your test and then insert a call to the copy, but you cannot directly insert a call to a non-reusable action saved with another test. Inserting calls to reusable actions makes it easier to maintain your tests, because when an object or procedure in your application changes, it needs to be updated only one time, in the original action.
Two or more tests can call the same action and one action can call another action (this is known as nesting an action). Complex tests may have many actions and may share actions with other tests.
When you run a test with multiple actions, the test results are divided by actions within each test iteration so that you can see the outcome of each action, and you can view the detailed results for each action individually.
Create Actions in QTP
You can create new actions and add calls to them, as needed.
You can call the new action from your test flow as a top-level action, or you can call the new action from within another action in your test as a sub-action (or nested action).
You can also split an existing action into two actions.
To create a new action in your test:
If you want to insert a call to the new action from an existing action in your test, click the step after which you want to insert the new action. To insert a call to the new action from the test flow as a top-level action, click any step.
Select Insert > Call to New Action or click the Insert Call to New Action button on the Insert toolbar. The Insert Call to New Action dialog box opens.
In the Name box, type a new action name or accept the default name. If you rename the action, make sure that the action name is unique (within the test), does not exceed 1023 characters, does not begin or end with a space, and does not contain the following characters: \ / : * ? " < > | % ' ! { }
In the Description box, add a description of the action. You can also add an action description at a later time using the Action Properties dialog box.
Tip: Descriptions of actions are displayed in the Select Action dialog box. The description makes it easier for you to choose an existing action you want to call.
Ensure Reusable Action is selected if you want to be able to call the action from other tests or multiple times from within this test. By default, this option is selected. You can also set or modify this setting at a later time using the Action Properties dialog box.

Decide where to insert the call to the action by selecting At the end of the test or After the current step. Choosing At the end of the test creates a call from the test flow to a top-level action. Choosing After the current step inserts the call to the action from within the current action (nests the action).
Note: If the currently selected step is a reusable action from another test, the new action is added automatically to the end of the test (the location options are disabled).
Click OK. A new action is stored with your test and the call to it is displayed at the bottom of the test or after the current step. You can move your action call to another location at a parallel (sibling) level within your test by dragging it to the desired location. For more information on moving actions, see Using the Test Flow Pane.
If you inserted the call to the new action while editing your test, make sure your new action is selected before adding steps to it.

Call Existing Actions in QTP Scripts
When you plan a suite of QuickTest Professional test scripts, you may realize that each test requires some identical activities, such as logging in. Rather than inserting all of the login steps three times in three separate tests and enhancing this part of the script (with checkpoints, parameterization, and programming statements) separately for each test, you can create an action that logs into a flight reservation system and store it with one test. After you are satisfied with the action you created, you can insert calls to the existing action into other tests.
You can insert calls to an existing action by inserting a call to a copy of the action, or by inserting a call to the original action.
For example, suppose you want to create the following three tests for the Mercury Tours site—booking a flight, modifying a reservation, and deleting a reservation. While planning your tests, you realize that for each test, you need to log in and log out of the site, giving a total of five actions for all three tests.
You would initially create three tests with five actions. Test 1 would contain two reusable actions (Logging In and Logging Out). These actions can later be called by Test 2 and Test 3.

You would then finish creating Test 2 and Test 3 by inserting calls to the reusable actions you created in Test 1

Calls to Copies of Actions in QTP test scripts

When you insert a call to a copy of an action into a test, the original action is copied in its entirety, including checkpoints, parameterization, the corresponding action tab in the Data Table, plus any defined action parameters. If the test you are copying has objects in the local object repository, the copied action's local object repository is also copied together with the action.
The action is inserted into the test as an independent, non-reusable action (even if the original action was reusable). After the action is copied into your test, you can add to, delete from, or modify the action just as you would with any other non-reusable action. Any changes you make to this action after you insert it affect only this action, and changes you make to the original action do not affect the copied action.
To create a copy of an action and call the copy in your test:
In your test, select Insert > Call to Copy of Action, right-click an action icon and select Insert Call to Copy of Action, or right-click any step and select Action > Insert Call to Copy. The Select Action dialog box opens.
Use the From test browse button to find the test containing the action you want to copy. The Action box displays all local actions (actions that are stored with the test you selected).
Note: You can enter a Quality Center folder or a relative path in the From test box.
If you enter a relative path, QuickTest Professional searches for the test in the folders listed in the Folders pane of the Options dialog box. For more information, see Setting Folder Testing Options and Using Relative Paths in QuickTest. (Refer Last Section)
If you are working with the Resources and Dependencies model with Quality Center 10.00, specify an absolute Quality Center path.
In the Action list, select the action you want to insert. When you select an action, its type (Non-reusable Action or Reusable Action) and description, if one exists, are displayed. This helps you identify the action you want to copy. For more information on action descriptions see Setting General Action Properties.
If you want to modify the copied action's properties, select the Edit new action properties check box. If you select this option, the Action Properties dialog box is displayed when you click OK. You can then modify the action properties.
Note: If you do not select this option, you can modify the action's properties later by right-clicking the action icon in the Keyword View and selecting Action Properties.
Decide where to insert the call to the copy of the action and select At the end of the test or After the current step.
Note: If the currently selected step is a reusable action from another test, the call to the copy of the action is added automatically to the end of the test (the After the current step option is disabled).
Click OK. The action is inserted into the test as a call to an independent, non-reusable action. You can move your action call to another location in your test by dragging it to the desired location.
Specify Action's Input Parameters in QTP
You can specify input parameters for an action so that steps in the action can use values supplied from elsewhere in the test. Input values for an action parameter can be retrieved from the test (for a top-level action) or from the parameters of the parent action that calls it (for a nested action), or from the output of a previous action call (for a sibling action).
You can specify output parameters for an action, so that it can return values for use later in the test. For example, you can output a parameter value to a parent action so that a later nested action can use the value.
For each input or output action parameter, you define a name (case sensitive), a type, and optionally, a description. You can also specify a default value for each action input parameter, or you can use the default value that QTP provides for the parameter value type that you choose. The default value is saved with the action and is used by the action if a value is not defined for a parameter in the action call. You can define, modify, and delete input and output parameters in the Parameters tab of the Action Properties dialog box (Edit > Action > Action Properties or right-click an action and select Action Properties).

To add a new input or output action parameter:
Click the Add button above the Input parameters or Output parameters lists to add a new parameter to the appropriate list. A row for the new parameter is added to the relevant list.
Click in the Name box and enter a name for the parameter. (Action parameter names are case sensitive.)
Select the value type for the parameter in the Type box. You can select one of the following types:
String. A character string enclosed within a pair of quotation marks, for example, "New York". If you enter a value and do not include the quotation marks, QTP adds them automatically when the value is inserted in the script during the test run. The default value is an empty string.
Boolean. A true or false value. If you select a Boolean value type, you can click in the Default Value column and click the arrow to select a True or False value. The default value is True.
Date. A date string, for example, 3/2/2005. If you select a Date value type, you can click in the Default Value column and click the arrow to open a calendar from which you can select a date. The default value is today's date.
Number. Any number. The default value is 0.
Password. An encrypted password value. If you select a Password value type, the password characters are masked when you enter the password in the Default Value field. In the action, however, the value appears encrypted. The default value is an empty string, which also appears as an encrypted value in the actual action.
Any. A variant value type, which accepts any of the above value types. Note that if you select the Any value type, you must specify the value in the format that is required in the location where you intend to use the value. For example, if you intend to use the value later as a string, you must enclose it in quotation marks. When you specify a value of Any type, QTP checks whether it is a number. If the value is not a number, QTP automatically encloses it in quotation marks. If you are editing an existing value, QTP automatically encloses it in quotation marks if the previous value had quotation marks. The default value is an empty string.
If you are defining an input action parameter, click in the Default Value box and enter a default value for the parameter. Alternatively, you can leave the default value provided by QTP for the parameter value type. The default value is required so that you can run the action without receiving parameter values from elsewhere in the test.
(Optional) Click in the Description box and enter a description of the parameter, for example, the purpose of the parameter in the action. QTP displays this description together with the name of the parameter in any dialog box in which you can choose an action parameter, including the Output Options, Parameter Options, and Value Configuration Options dialog boxes. To modify an existing action parameter:
Select the parameter you want to modify from the Input parameters or Output parameters list.
Modify the values as necessary in the edit boxes of the parameter row. To delete an existing action parameter:
Select the parameter you want to delete from the Input parameters or Output parameters list.
Click the Delete button. The parameter is removed from the list.
Note: When you delete an action parameter, make sure that you also delete any steps that use the action parameter.
Rename QTP Actions
To rename an action in the Rename Action dialog box:
In the Keyword View, select the call to the action you want to rename and select Edit > Action > Rename Action. In the Expert View, display the action that you want to rename and select Edit > Action > Rename Action. The Rename Action dialog box opens.

Enter a new name for the action in the New name box. Make sure that action name is unique within the test, does not begin or end with a space, does not exceed 1023 characters, and does not contain the following characters: \ / : * ? " < > | % ' ! { }
Click OK to save the change.
Tip: You can also press Shift + F2 to open the Rename Action dialog box.
To rename an action in the Action Properties dialog box:
In the Test Flow pane or in the Keyword View, right-click the action and select Action Properties. Alternatively, in the Keyword View or in the Expert View, select an action and select Edit > Action > Action Properties. The Action Properties dialog box opens.
Enter a new action name in the Name box of the General tab. Each action name within a test must be unique. Make sure that action name is unique within the test, does not begin or end with a space, does not exceed 1023 characters, and does not contain the following characters: \ / : * ? " < > | % ' ! { }
Click OK to save the change
Splitting Actions in QTP
You can split an action that is stored with your test into two sibling actions or into parent-child nested actions. When you split an action, the second action starts with the step that is selected when you perform the split action operation.
You cannot split an action, and the option is disabled when:
an external action is selected
the first step of an action is selected
you are working with a read-only test
recording a test
running a test
When you split an action in your test that uses a local object repository:
QTP makes a copy of the local object repository.
The two actions have identical local object repositories containing all of the objects that were in the original local object repository.
If you add objects to one of the split actions, the new objects are added only to the corresponding local object repository.
To split an action:
Select the step before which you want the new (second) action to begin.
Select Edit > Action > Split Action, click the Split Action button, or right-click the step and select Action > Split. The Split Action dialog box opens.
Select one of the following options:
Independent of each other. Splits the selected action into two sibling actions.
Nested (the second action is called by the first). Splits the selected action into a parent action whose last step calls the second, child action.
If you want, modify the name and description of the two actions in the Name and Description boxes.
Note: If a reusable action is called more than once in a test and you split the action into two independent actions, each call to the action within the test will be followed by a call to the new (reusable) action. If a reusable action is called from another test, however, splitting it may cause the calling test to fail.
Nesting Actions in QTP
Sometimes you may want to call an action from within an action. This is called nesting. By nesting actions, you can:
Maintain the modularity of your test.
Run one or more actions based on the results of a conditional statement.
For example, suppose you have parameterized a step where a user selects one of three membership types as part of a registration process. When the user selects a membership type, the page that opens depends on the membership type selected in the previous page. You can create one action for each type of membership. Then you can use If statements to determine which membership type was selected in a particular iteration of the test and run the appropriate action for that selection.
In the Keyword View, your test might look something like this:

In the Expert View, your test might look something like this:
Browser("Membership Preference").Page("Membership Preference").WebRadioGroup("MemType").Select DataTable("memtype", dtGlobalSheet)
Mem_Type=Browser("Membership Preference").Page("Membership Preference").WebRadioGroup("MemType").GetROProperty ("value")
If Mem_Type="paid" Then
RunAction "Paid_Mem", oneIteration
ElseIf Mem_Type = "free" Then
RunAction "Free_Mem", oneIteration
Else
RunAction "Preferred", oneIteration
End If
To nest an action within an existing action:
Highlight the step after which you would like to insert the call to the action.
Follow the instructions for inserting a call to a new action as described in Creating New Actions.

Advanced Action Features in QTP
You can divide your QTP Test Scrits into actions to streamline the process of testing your application. This section covers the advanced use of actions in your test. Using basic action-related features is described in Working with Actions.
This section includes:
About Working with Advanced Action Features
Inserting Calls to Existing Actions
Setting Action Parameters
Using Action Parameters
Setting Action Call Properties
Sharing Action Information
Understanding Action Syntax in the Expert View
Exiting an Action
Section 1:
About Working with Advanced Action Features:
Actions help divide your test into logical units, such as the main sections of a Web site, or specific activities that you perform in your application.
A test is comprised of calls to actions. When you create a new test, it contains a call to a single action. By creating tests that call multiple actions, you can design tests that are more modular and efficient.
You can pass information between actions in several ways. You can also specify input parameters for actions, so that steps in an action can use values supplied from elsewhere in the test. You can also output values from actions to be used in steps later in the test, or to be passed back to the application that ran the test. For more information, see Using Action Parameters.
Configuring Actions in QTP
The Action Properties dialog box enables you to define options for the stored action. These settings apply each time the action is called. You can modify an action name, add or modify an action description, and set an action as reusable or non-reusable. For an external action, you can set the Data Table definitions.
The Action Properties dialog box also enables you to define input and output parameters to be used by the action, and specify the object repositories that are associated with the action. For more information, see Associating Object Repositories with Actions.
Note: The following sections describe how to define action properties using the Action Properties dialog box. You can also define actions and action parameters in the Expert View.
You can open the Action Properties dialog box while working with your test by:
Right-clicking an action node in the Test Flow pane and selecting Action Properties.
Choosing Edit > Action > Action Properties when an action node is highlighted in the Keyword View or displayed in the Expert View.
Right-clicking an action node in the Keyword View and selecting Action Properties.
The Action Properties dialog box always contains the General tab, the Parameters tab, the Associated Repositories tab, and the Used By tab:


Note: In addition to the tabs shown above, the Action Properties dialog box for a called external action also contains an External Action tab, and the other tabs are read-only.

Setting General Action Properties
You can use the General tab of the Action Properties dialog box to modify the name of an action, add or edit an action's description, or change the reusability status of the action.
To open the Action Properties dialog box, right-click an action in the Test Flow pane and select Action Properties, or select Edit > Action > Action Properties.
Note: The name of the action and its path are displayed in the tab. If it was defined with a relative path in QTP, then the path is displayed as .\. If the action is a reusable action or an external action, then Reusable action or External Action is displayed next to the action name.
The General tab includes the following options:
Option
Description
Name
The name of the action. By default, the action name is the internal name provided by QTP, such as Action 1. This number is incremented by 1 for each new action that is added to the test.
You can rename the action, as needed. The action name must be unique (within the test), cannot begin or end with a space, cannot exceed 1023 characters, and cannot contain the following characters: \ / : * ? " < > | % ' ! { }
Location
The folder or Quality Center path where the action is stored.
Description
You can insert comments about the action. An action description helps you and other testers know what a specific action does without reviewing all the steps in the action. The description is also displayed in the description area of the Select Action dialog box. This enables you and other testers to determine which action you want to call or copy from another test without having to open it.

Note: You can also add a description when inserting a call to a new action.
Reusable action
Indicates whether the action is a reusable action. By default, this check box is selected. A reusable action can be called multiple times within a test and can be called from other tests. Non-reusable actions can be copied and inserted as independent actions, but cannot be inserted as calls to the original action.
When you change this setting, the action icon changes to a non-reusable action icon or reusable action icon as appropriate. If the steps of the action were expanded, they collapse after changing a non-reusable action to a reusable action. You can view the steps of the reusable action by selecting the action name in the Test Flow pane.
Notes:
 If the action is called more than once within the test flow or if the action is called by a reusable action, the Reusable action option is read-only. If you want to make the action non-reusable, remove the additional calls to the action from the test.
 You cannot expand reusable actions from the test flow view. You can view details of a reusable action by double-clicking the action in the Keyword View, or selecting the action from the Action List. For more information on the test flow and action views, see Using the Action Toolbar in the Keyword View.
Setting Properties for an External Action
When you insert a call to an external action, you can choose where you want QTP to store the Data Table data. You can specify this in the External Action tab of the Action Properties dialog box.
To open the Action Properties dialog box, right-click an action in the Test Flow pane and select Action Properties, or select Edit > Action > Action Properties.

The External Action tab includes the following options:
Option
Description
Data Table parameters
Indicates where to store the action's Data Table data:
To use the original action's data, select Use data stored with the original action (read-only). If you select this option, the data is read-only when viewed from the calling test, and all changes to the original action's data sheet apply when the action runs in the calling test.
To use an editable copy of the data in the test's Data Table, select Use a local, editable copy. If you select this option, a copy of the called action's data sheet is added to the calling test's Data Table and is independent of the original action.
Changes to the original action's data sheet do not affect the calling test even if you insert another call to this action after the action's data sheet is modified.
If the called action has parameterized steps that rely on new information in the original action's data sheet, enter the relevant column names and required data to the action sheet in the calling test manually.
Note: When you call an external action, the global data sheet columns and data from the called action's test are always imported as a local, editable copy in the calling test's global data sheet.
Changes to the original action's global data sheet do not affect the calling test even if you insert another call to this action after the called action's global data sheet is modified.
If the called action has parameterized steps that rely on new information in the global data sheet, enter the relevant column names and required data to the calling test's global data sheet manually.
Viewing a List of the Tests and Actions Using this Action
If your tests are stored in Quality Center and are using the resources and dependencies model, the Action Properties dialog box displays the Used By tab. This enables you to view a list of the tests and actions that contain calls to this particular action. This is the same list that is displayed in the Dependencies tab of the Test Plan module in Quality Center.
To open the Action Properties dialog box, right-click an action in the Test Flow pane and select Action Properties, or select Edit > Action > Action Properties.

The Used By tab includes the following options:
Option
Description
Test
Indicates the Quality Center path of the test containing a call to this action.
Action
Indicates the internal name of the action containing a call to this action. The internal name is the name that QTP applies to an action by default when the action is created, for example, Action 1. The internal name of the action calling this action is displayed even if the calling action was renamed.

Script to create file

Now lets do some kind of processing with file system e.g. working with text, excel, word etc files from within the QTP.
For this tutorial you need to know VBScript FSO (File System Object).
The main purpose of the FSO is to access the file system of the computer.
File System Object model is:
Drive|Folder|File|Textstream
or some people make it like this:Drive|Folder|Folders|File|Files|Textstream
These above objects have methods and properties. With these above objects you can obtain and work with the information about drives, folders, files etc like creating a new file, opening a file, writing into a file and much more.
Here we will see a very simple example how to create a text file from within QTP.
Dim fso, new_fileSet fso = createobject("scripting.filesystemobject") // an instance of filesystemobject is being created here. After an instance (fso) is created then we can use the methods (like createtextfile, CreateFolder etc) with that objects instance.Set new_file = fso.createtextfile("c:\testfile.txt", True) //createtextfile is amethod to create a file and after creating a file it returns a TextStream objectthat can be used to read from or write to the file.new_file.writeline("hello world!")new_file.close
Just write the above text in the expert view of a new blank test and run it. A new text file (testfile.txt) will be created with "hello world!" written in it.
Try to change the extention of testfile.txt to testfile.doc and see what happens
Regular Expression

Objects and text strings with varying (changeable) values or we can say dynamic values can be identified by QuickTest using Regular expressions.
Regular expressions can be used:
§ To define property values of an object.
§ To parameterize a step.
§ To create a checkpoint with changeable values.
Important points regarding Regular expressions:
You can use regular expressions only for values of type string.
When any special character in a regular expression is preceded by a backslash (\), QuickTest searches for the literal character.
You can define a regular expression for a constant value, a Data Table parameter value, an Environment parameter value, or a property value in a programmatic description.
For more common options to create Regular Expressions, see QTP User Guide.
Instead of writing more about QTP regular expressions, lets quickly jump to examples.
Below you will find examples.
QTP Regular Expression Example 1
[This is just an example using Yahoo mail inbox. Your inbox unread mails may differ from the one shown in this example][This is just an example using Yahoo mail inbox. Your inbox unread mails may differ from the one shown in this example]1. Launch QTP and open a new test.2. Open Internet Explorer.[Now we have QTP with a blank test and Google open.]3. Click on Record in order to start recording.4. Copy and paste this URL (https://login.yahoo.com/config/login_verify2?&.src=ym) in the browser's address bar to open Yahoo mail login.5. Type your user name and password to login to Yahoo mail.6. When Yahoo mail is open, click on the Inbox link as shown in the screenshot below.7. Click on Stop in order to stop recording.My recorded code looks like this:
Code:
Browser("Browser").Page("Page").SyncBrowser("Browser").Navigate "https://login.yahoo.com/config/login_verify2?&.src=ym"Browser("Browser").Page("Yahoo! Mail: The best").WebEdit("login").Set "sach2n"Browser("Browser").Page("Yahoo! Mail: The best").WebEdit("passwd").SetSecure "4801a2cbf793b46aad67194b5cbc961c071f"Browser("Browser").Page("Yahoo! Mail: The best").WebButton("Sign In").ClickBrowser("Browser").Page("Yahoo! Mail - sach2n@yahoo.com").Link("Inbox (6)").Click
Now if you don't check any mail in your inbox and log out and then again run this code it will work fine.But if you check any mail like if I check one mail in my inbox then it will be Inbox(5) in the above screen shot, then if I run this code it will fail and show the below error.Now we will change the above code with the help of regular expression so that it will work even if there is only one unread mail.In QTP go to Resources (menu) ->Object Repository.Object Repository window will open. Now follow the screen shots below.When you click on the button as in above screen shot it will open 'Value Configuration Options' window. On this window click on Regular Expression check box. When you click on checkbox it will show warning as in the screen shot below. Just click on Yes.Now in the Constant text box (above screenshot) enter what I have entered "Inbox \([5-6]\)" and click Ok and close Object Repository window.This Regular Expression setting which we have done works for inbox unread mails between 5 and 6 e.g. if your inbox says inbox(5) or inbox(6).Run the test. It passes for me because I had 5 unread mails in my inbox (inbox(5)).You can do this setting according to your convenience e.g. [1-5] for unread mails between 1 and 5 and so on.
Let us take yahoo! site as an example. Then the script will be something like:===========================================================Browser("Yahoo! Mail - The best").Page("Yahoo! Mail - The best").WebEdit("login").Set "TestUser"Browser("Yahoo! Mail - The best").Page("Yahoo! Mail - The best").WebEdit("passwd").SetSecure "460205b87f0543"Browser("Yahoo! Mail - The best").Page("Yahoo! Mail - The best").WebButton("Sign In").ClickBrowser("Yahoo! Mail - The best").Page("Yahoo! Mail - TestUser@").Link("Addresses").ClickBrowser("Yahoo! Mail - The best").Page("Yahoo! Address Book -").Link("Mail").ClickBrowser("Yahoo! Mail - The best").Page("Yahoo! Mail - TestUser").Sync===========================================================Here the page title is continuously changing. but, all titles contain "Yahoo!"When ever, you click on any tabs, i.e. (mail, compose, addresses, etc), the page title changes. but, still contains "Yahoo!" as part of the string. in this case, we can use regular expression (while using descriptive programming):================================================================Browser("Yahoo! Mail - The best").Page("ClassName:=Page", "title:=Yahoo.*").WebEdit("ClassName:=WebEdit", "Name:=login").Set "TestUser"================================================================

No comments: