background image
<< Chapter 8 Adding Features to Scripts | Why Use Timers >>
<< Chapter 8 Adding Features to Scripts | Why Use Timers >>
How Timers Work
Adding Features to Scripts
8-2
Timers
Individual emulation commands (such as
sqlprepare
and
sqlexec
) are timed
automatically. By default, these times are included in TestManager report output.
However, if you want to measure the time it takes a virtual tester to perform an
activity--for example, sending a query to the server and displaying the results--you
insert a timer or a block in the script.
How Timers Work
Think of a timer as a stopwatch that you click on just before you begin to perform
the timed activity, and that you click off when you complete the activity.
For example, suppose you want to time how long it takes to submit a query to a
database server and receive the results. During recording, you would:
1. Start the timer (click Insert



Start Timer) just before you click the button to
send the query. This action inserts the VU emulation command
start_time
into the script.
2. Stop the timer (click Insert



Stop Timer) as soon as the results appear. This
action inserts the VU emulation command
stop_time
into the script.
When you stop a timer, you can reuse that timer's name in another timer. There is
no practical limit to the number of timers that you can add to a script.
You can nest timers within other timers (by starting and stopping the second timer
before stopping the first timer), and you can overlap timers (by stopping the second
timer after stopping the first timer).
If you do not explicitly stop a timer, no response time is reported for that activity.
You cannot extend a timer over multiple scripts.
The following illustration shows the
start_time
and
stop_time
emulation
commands for a timer named query1: