Create QTP Test Scripts – QTP Tutorial 1

Share This Post -

You can create tests using the keyword-driven methodology, step recording, or a combination of both. The keyword-driven methodology enables you to select keywords to indicate the operations you want to perform on your application. Step recording enables you to record the operations you perform on your application.

After you create your tests, you can enhance them using checkpoints and other special testing options.

This section includes:

  • About Creating Tests
  • Deciding Which Methodology to Use - Keyword-Driven or Recording
  • Enhancing Your Test
  • Using Relative Paths in QTP

About Creating Tests

You can create tests using the keyword-driven methodology, step recording, or a combination of both.

Creating tests using the keyword-driven methodology requires an infrastructure for all of the required resources. Resources include shared object repositories, function libraries, and recovery scenarios. Setting up the infrastructure requires in-depth knowledge of your application and a high level of QTP expertise.

Although setting up the infrastructure may initially require a longer time-investment in comparison to recording tests, using the keyword-driven methodology enables you to create tests at a more application-specific level and with a more structured design. This enables you to maintain your tests more efficiently and provides you with more flexibility than a recorded test.

In some cases, you may want to let QTP generate test steps by recording the typical processes that you perform on your application. As you navigate through your application, QTP graphically displays each step you perform as a row in the Keyword View. A step is anything a user does that changes the content of a page or object in your application, for example, clicking a link or typing data into an edit box. Recording may be easier for new QTP users or when beginning to design tests for a new application or a new feature.

While creating your test, you can insert checkpoints. A checkpoint compares the value of an element captured when the object was saved in the object repository, with the value of the same element captured during the run session. This helps you determine whether or not your application is functioning correctly.

When you test your application, you may want to check how it performs the same operations with different data. This is called parameterizing your test. You can supply data in the Data Table, define environment variables, instruct QuickTest to generate random numbers, and so on.

Deciding Which Methodology to Use - Keyword-Driven or Recording

You can create the steps in your tests using the keyword-driven methodology, recording, or a combination of both.

Recording Tests
Recording can be useful in the following situations:

  • Recording helps novice QTP users learn how QTP interprets the operations you perform on your application, and how it converts them to QTP objects and built-in operations.
  • Recording can be useful for more advanced QTP users when working with a new application or major new features of an existing application (for the same reasons described above). Recording is also helpful while developing functions that incorporate built-in QTP keywords.
  • Recording can be useful when you need to quickly create a test that tests the basic functionality of an application or feature, but does not require long-term maintenance.

Creating Tests Using Keyword-Driven Testing

Keyword-driven testing advantages include the following:

  • Keyword-driven testing enables you to design your tests at a business level rather than at the object level. For example, QTP may recognize a single option selection in your application as several steps: a click on a button object, a mouse operation on a list object, and then a keyboard operation on a list sub-item. You can create an appropriately-named function to represent all of these lower-level operations in a single, business-level keyword.
  • By incorporating technical operations, such as a synchronization statement that waits for client-server communications to finish, into higher level keywords, tests are easier to read and easier for less technical application testers to maintain when the application changes.
  • Keyword-driven testing naturally leads to a more efficient separation between resource maintenance and test maintenance. This enables the automation experts to focus on maintaining objects and functions while application testers focus on maintaining the test structure and design.
  • When you record tests, you may not notice that new objects are being added to the local object repository. This may result in many testers maintaining local object repositories with copies of the same objects. When using a keyword-driven methodology, you select the objects for your steps from the existing object repository. When you need a new object, you can add it to your local object repository temporarily, but you are also aware that you need to add it to the shared object repository for future use.
  • When you record a test, QTP enters the correct objects, methods, and argument values for you. Therefore, it is possible to create a test with little preparation or planning. Although this makes it easier to create tests quickly, such tests are harder to maintain when the application changes and often require re-recording large parts of the test.
  • When you use a keyword-driven methodology, you select from existing objects and operation keywords. Therefore, you must be familiar with both the object repositories and the function libraries that are available. You must also have a good idea of what you want your test to look like before you begin inserting steps. This usually results in well-planned and better-structured tests, which also results in easier long-term maintenance.
  • Automation experts can add objects and functions based on detailed product specifications even before a feature has been added to a product. Using keyword-driven testing, you can begin to develop tests for a new product or feature earlier in the development cycle.
  • Enhancing Your Test

    You can use a variety of options to enhance your existing tests. This section describes some of the ways in which you can enhance your existing tests.

    You can add checkpoints to your test. A checkpoint is a step in your test that compares the a specified item during a run session with the values stored for the same item within the test. This enables you to identify whether or not your application is functioning correctly. There are several different checkpoint types.

    Tip: You can also use the CheckProperty method, which enables you to verify the property value of an object without using the checkpoint interface.

You can parameterize your test to replace fixed values with values from an external source during your run session. The values can come from a Data Table, environment variables you define, or values that QTP generates during the run session.

Output Values
You can retrieve values from your test and store them in the Data Table as output values. You can subsequently use these values as an input parameter in your test. This enables you to use data retrieved during a test in other parts of the test.

You can divide your test into actions to streamline the testing process of your application.

Programming Statements

You can use special QTP options to enhance your test with programming statements. The Step Generator guides you step-by-step through the process of adding recordable and non-recordable operations (methods and properties) to your test. You can also synchronize your test to ensure that your application is ready for QTP to perform the next step in your test, and you can measure the amount of time it takes for your application to perform steps in a test by defining and measuring transactions.

You can also manually enter standard VBScript statements, as well as statements using QTP test objects and operations, in the Expert View

Using Relative Paths in QTP

QTP enables you to define the path to a resource that you are adding to the file system or to Quality Center, as a relative or an absolute path.

Note: If you are working with the Resources and Dependencies model with Quality Center 10.00, specify an absolute Quality Center path.

When you specify a path to a function library, shared object repository, recovery scenario, or environment variable file, QTP checks if the path, or the initial part of the path, exists in the Folders pane of the Options dialog box (Tools > Options > Folders node). The Folders pane contains a search list in which you can define where QTP searches for tests, actions, or files.

QTP then opens one of the following two dialog boxes, depending on whether the path you specified, or a part of the path, exists in the Folders pane.

Note: If you are connected to QualityCenter 10.00, these dialog boxes are displayed only if you select a path in the file system or in a QualityCenter 9.x project.


You can choose not to show one or both of these dialog boxes when you enter a path to a resource by selecting the Do not show this message again check box. To show these dialog boxes again, select the Remind me to use relative paths when specifying a path to a resource check box in the Folders pane of the Options dialog box. This check box is selected by default when you first start QTP.

Go Back to-> QTP Tutorial Learn QTP – Design QTP Scripts