API Testing USING QTP/UFT: Complete Tutorial

By : Thomas Hamilton Thomas Hamilton
Hours Updated

⚡ Smart Summary

API testing in QTP/UFT One validates a service directly, with no user interface involved. An API test is built as a flow of activities on a canvas, and checkpoints decide whether each response passes.

  • 🔘 No GUI involved: Inputs are sent straight to the service and the recorded response is compared with expectations.
  • ☑️ Five supported types: Web service, REST, object-oriented language, database and proprietary APIs.
  • ✅ Activity flow, not objects: Drag an HTTP Request from the Toolbox onto the test flow and set its properties.
  • 🧪 Checkpoints decide the verdict: A status code checkpoint of 200 marks the call successful without manual inspection.
  • 🛠️ Results in one place: The Run Results Viewer reports every activity, its response and each checkpoint outcome.
  • 📌 Current naming: QTP plus HP Service Test became UFT, now sold as OpenText Functional Testing (UFT One).
Read More

Building and running an API test in QTP and UFT One

Before testing an API, we need to know what an API is. An API (Application Programming Interface) is a collection of software functions and procedures that can be executed by other software applications.

What is API Testing?

API Testing is a software testing method for validating Application Programming Interfaces (APIs). The goal of API testing is to test the API in terms of functionality, reliability, security and performance. In API testing, software is used to send inputs to the API, and the output is recorded in order to test the API.

So API Testing is:

  • Testing without GUI
  • Programmatically simulating data or control-flow scenarios.
  • Focus on functionality, not on behavior or customer experience.

The diagram below places API testing between the client that calls the service and the data it reaches.

Scope of API testing between the client layer and the database layer

Why is API Testing important?

API Testing has four significant advantages

1. API testing is the trend

As the following figure shows, API testing has grown very fast over the last ten years. It has become far more popular than other testing types.

Chart showing growth in API testing adoption over ten years

2. Time efficient

With API Testing we can use parallel execution to reduce test execution time. You can save up to 5 times compared to other testing types.

3. Language independent

In API Testing, data is exchanged via XML or JSON, so any language can be used to test the response. For example, if you have a service whose response is in JSON format, you can easily parse the data with Java, C# or any other language.

4. Easy GUI integration

Because UFT One holds GUI tests and API tests in the same solution, an API call can set up data for a user interface test and both kinds of test report into the same run results. That keeps a service check and the screen that consumes it in one project instead of two toolchains.

API Testing with UFT (Unified Functional Testing)

There are many tools available, both open-source and commercial. UFT is a strong choice for executing API tests, because the flow is built visually and the configuration is kept in one properties pane.

The last version of QTP, called HP Unified Functional Testing (UFT), is a combination of HP QTP (a GUI testing tool) and HP Service Test (an API testing tool). UFT supports Web, Java, .NET, Oracle, Siebel, web services and many other major languages and platforms that older versions did not support.

⚠️ Product naming: the tool described here as HP UFT is now sold as OpenText Functional Testing (UFT One), having passed from HP to Micro Focus and then to OpenText. The screens below come from the HP-era release, so menu wording differs from current builds, but the API test flow, activities and checkpoints work the same way.

Type of API test support by HP UFT

  1. Web service
  2. REST
  3. Object-Oriented Language
  4. Database
  5. Proprietary API

RELATED ARTICLES

Start your first API testing with QTP

In this API testing in UFT tutorial, we will cover UFT API testing examples. We are going to test the Graph API of Facebook. We will test the API as the Test Case below

  1. Get a profile of the specified user on Facebook.
  2. Verify that the profile is as per expectation

Here is a step to build a test flow for this API.

Planned UFT test flow for the Facebook Graph API test case

⚠️ About this example: Facebook retired Graph API v2.3 years ago and the access token shown below has long since expired, so the exact call no longer returns data. The original request is kept unchanged as the worked example; point the same steps at any current REST endpoint to follow along.

Step 1) Open HP UFT and create new project API Testing

  1. Choose Start > (All) Programs > HP Software > HP Unified Functional Testing > Unified Functional Testing. In current releases this is simply the UFT One shortcut.

    Windows Start menu path to the HP Unified Functional Testing shortcut

  2. Click File > New > Test. Select the API Test type

    UFT Add New Test dialog with the API Test type selected

  3. When a dialog box opens, input the name of the API test: API_Facebook, and select a location to save this project. Click Create to create the API test project.

    Naming the new API test API_Facebook and choosing its save location

Step 2) Adding HTTP Request to Test Flow

We will use the HTTP Request to make a request to the Facebook API.

  1. Select Toolbox > Network

    Network group expanded in the UFT Toolbox pane

  2. Drag element HTTP Request to Test Flow.

    HTTP Request activity dropped onto the UFT API test flow canvas

Step 3) Configure and pass parameters into an HTTP request

  1. Right-click on the HTTP Request object to edit it.

    Right-click menu on the HTTP Request object in the test flow

  2. In the Properties part, enter the URL

    Properties pane of the HTTP Request activity with the URL field

    https://graph.facebook.com/v2.3/me?access_token=CAACEdEose0cBANJsDnbZC92mNAghaM6xxZCZBZAvKlMXS98VYvKy%20OlrfAdsUWR8x5aw9Kqc0grscs9zb9IYED4VC3FwapIZBj%20dsuxy%20HdLcff38gYUBFNeRQlH%20fN7eXKoVZBNl0bR233ZAZCw8fLF1QLh98ry2ZBeYBhXLabtTDkFPZA1IqhaMG0mQp30zO1%20QxQ19nVCxZArJA6XRoB1o5FMepII5cn3DgbBmTgZD
  3. You can also pass a parameter into the API by setting values in the Request Header grid.

    Request Header grid used to pass extra parameters into the API call

    Use the Graph API Explorer of Facebook to obtain the value of access_token.

  4. Set the HTTP method to GET.

    HTTP method list of the HTTP Request activity set to GET

    GET selected as the HTTP method for the request

  5. Configure Checkpoints of the HTTP Request. Set the Status code to 200 in the Checkpoints part. Checkpoints let you see whether the action was successful without having to check the result manually, and the pass or fail verdict of the test is determined by them. A status code of 200 means the test case has passed.

    Checkpoints pane with the expected status code set to 200

Step 4) Run the test

Click the Run button, or press F5, to open the Run Test dialog box. Click Run to compile and run the test.

UFT Run Test dialog opened from the Run button

Step 5) View the result

The Run Results Viewer opens. In this API testing using UFT example, a failed test case is reported like the following figure.

Run Results Viewer showing a failed API test case

When the test case passes, the result is reported as below.

Run Results Viewer showing the API test case passing

Your first API test in UFT is now complete.

Where to go from here

Now that you have learned to create a test with an API test in UFT, you can create your own test for your GUI-less application. Adding a checkpoint per response and grouping calls into transactions are the usual next steps.

FAQs

A GUI test drives controls on screen and stores them as test objects. An API test is a flow of activities on a canvas that sends requests directly to a service, so nothing is recorded from the interface.

No. An API test has activities, input and output properties and data sources instead of test objects, so no object repository is involved. Only GUI tests learn objects and store their descriptions.

Import the service WSDL into the test. UFT reads the document, creates an activity for each operation the service exposes, and adds them to the Toolbox pane so they can be dragged onto the test flow like any other activity.

Link the activity input properties to a data source such as an Excel sheet or XML file instead of typing literal values. Each row then produces one iteration, and the Run Results Viewer reports the outcome per iteration.

AI-assisted tooling compares responses across runs to flag schema drift and newly failing fields, and it can group repeated failures by likely root cause. That shortens triage, but the expected values in each checkpoint still need a human decision.

Copilot is useful for the code around the test: custom activity logic, response parsing and helper functions. It cannot build the visual test flow or read your service contract, so every request and checkpoint it suggests needs verification.

SoapUI and Postman are lighter and free to start with. UFT earns its place where the same project must also cover the user interface, since one licence and one result set span both layers.

Beyond the HTTP status code, an API test can check response body content, individual header values and returned data compared with an expected source. Every checkpoint result appears alongside the request in the Run Results Viewer.

Summarize this post with: