How to use Transactions in QTP/UFT

By : Thomas Hamilton Thomas Hamilton
Hours Updated

⚡ Smart Summary

Transactions in UFT One measure how long a chosen section of a test takes to run, by wrapping those steps between a start statement and an end statement that reports the duration in the run results.

  • 🔘 Purpose: A transaction times one business flow, such as booking a flight, rather than the whole test.
  • ☑️ Insertion: The Insert menu adds Start Transaction and End Transaction statements around the selected steps.
  • ✅ Statements: Services.StartTransaction and Services.EndTransaction do the same job directly in the Editor.
  • 🧪 Results: The end statement reports name, status, total duration and wasted time.
  • 🛠️ Nesting: Transactions can be nested, but two open transactions must never share one name.
  • ⚠️ Integration: LoadRunner and Business Process Monitor read only data recorded inside a transaction.
Read More

How to use Transactions in QTP UFT

In UFT One/QTP, You can measure how long it takes to run a section of your test by defining Transactions. You define transactions within your test by enclosing the appropriate sections of the test with start and end transaction statements.

Transactions can be inserted anywhere in the script, and there is no limit to the number of transactions that can be added to a test.

⚠️ Product naming: the tool shipped as HP QuickTest Professional (QTP), became HP and then Micro Focus Unified Functional Testing, and is sold today by OpenText, whose current help pages call it OpenText Functional Testing. Transactions work the same way in every one of those releases.

How to insert transactions in QTP?

You can also insert a transaction within a transaction

Following video takes you through the steps to insert a Transaction in UFT One.

Click here if the video is not accessible

For example, you may want to note the time taken to book a flight.

  1. In QTP, select the appropriate state where you want to start your transaction.
  2. Select Insert Start Transaction. Start Transaction Dialog Box opens
  3. Give the transaction a suitable name, say “Booking Time”
  4. A start transaction statement is added in the test
  5. Select the state where you want to end the transaction
  6. Click Insert > End Transaction
  7. End Transaction Dialog Box Opens with the list of all available transactions
  8. Click Okay. An end transaction statement is added
  9. Let’s run the test
  10. In results, the end transaction statement gives the time taken to insert the order

Note: the same dialog boxes are reached from the Keyword View, and the Step Generator inserts the identical statements without opening the Insert menu.

Transaction Statements in the Editor

The dialog boxes above write two VBScript lines into the test. Typing them yourself in the Editor is faster once the pattern is familiar, and it is the only option when the steps are generated by code.

Services.StartTransaction "Booking Time"

' the steps that book the flight go here

Services.EndTransaction "Booking Time"

Both methods belong to the Services object. The start statement takes one argument, the end statement takes an optional second one.

Statement Arguments What it does
Services.StartTransaction Name Begins the time measurement at that point in the run
Services.EndTransaction Name, [Status] Stops the measurement and records the result

The optional status decides how the transaction is graded. Leaving it out is the same as passing Auto.

  • Auto — passes unless an error occurred between the two statements. This is the default.
  • Pass — always ends with a Pass status.
  • Fail — always ends with a Fail status.
Services.StartTransaction "Booking Time"
Wait 1
Services.EndTransaction "Booking Time", Pass

Reading Transaction Results

Once the test finishes, the End Transaction step in the run results carries four values that explain the measurement.

Result field Meaning
Transaction name The name supplied in the start statement
End status Pass or Fail, decided by the status argument or by Auto
Total duration Elapsed time between the start and end statements
Wasted time Time inside the duration that UFT One itself added

Wasted time matters because the tool runs background processes while the transaction is open. Subtract it from the total duration to estimate what the application alone would have taken, which is the number worth comparing between builds.

A single-user duration is a functional benchmark, not a load figure. Concurrency is measured by a performance testing tool, and a transaction that is fine for one user can still collapse under a hundred.

RELATED ARTICLES

Nested and Distributed Transactions

The source step list notes that a transaction can sit inside another one, which is how a slow sub-step is isolated without losing the timing of the whole flow. The outer transaction keeps running while the inner one opens and closes.

Two rules keep nesting safe.

  • Every name needs a matching pair, and the start statement must appear before its end statement.
  • Only one transaction with a given name may be open at a time. Opening a second one with the same name ends the first with a Fail status.

A distributed transaction goes further and spans two tests: Services.StartDistributedTransaction opens it in the first test and Services.EndDistributedTransaction closes it in the second, matched by a unique ID rather than by name. It exists for Business Process Monitor and LoadRunner scenarios, which read only the data recorded inside a transaction and ignore everything outside one.

When a step inside a transaction can legitimately fail, pair the transaction with a recovery scenario so the run reaches the end statement instead of stopping halfway.

FAQs

A transaction reports a named result with a status into the run results and into LoadRunner. A MercuryTimer only measures elapsed milliseconds inside the script, which you then report or convert yourself.

Time the unrelated operation with a MercuryTimer, then pass the value to Services.AddWastedTime. The wasted time is deducted from every open transaction, so the reported duration reflects only the flow under test.

An error before the end statement halts the run by default. In the Run pane of Test Settings, set the error option to proceed to the next step so the end statement is still reached and the transaction is recorded.

In the LoadRunner Controller rather than the Run Results window. Only steps enclosed in a transaction are sent, so anything outside a start and end pair never reaches the performance report.

Yes. Services.SetTransaction takes a name, a duration in seconds and a status, which lets a script log a measurement it calculated itself instead of one the tool timed.

Machine learning models baseline each named transaction across builds and raise an alert when a duration drifts beyond its normal range, catching a slow regression that a pass or fail status alone would hide.

Yes. GitHub Copilot completes the Services.StartTransaction and Services.EndTransaction pair from a comment, though the transaction name and the status constant still need checking against the naming convention in use.

There is no technical limit, but one transaction per business flow keeps the report readable. Dozens of tiny transactions bury the number that matters under measurement noise.

Summarize this post with: