| Article Index |
|---|
| IBM Rational adding Features to Scripts |
| Page 2 |
| All Pages |
Adding Features to Scripts
This article describes the features that you can add to a script while recording the session with Robot. The chapter includes the following topics:
-
Blocks
-
Timers
-
Synchronization points
-
Comments
-
Using the Insert menu
Toolbars for Adding Features
Use the Session Insert toolbar to add features like timers, blocks, synchronization points, and comments.
To access the Session Insert toolbar, click Display Session Insert toolbar in the Session Record toolbar:
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-
insert a timer or a block in the script.
How Timers Work
Think of a timer as a stopwatch that you use to begin a timed 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:
Why Use Timers?
Use timers in the following cases:
-
To time an overlapping sequence of events. Insert a start_time command followed by several stop_time commands. You cannot overlap blocks, although you can nest them.
-
To time a specific portion of the script. Insert the start_time and stop_time commands exactly where you want when you edit the script. You
can insert a block, however, only during recording.
In other cases, you may want to use blocks rather than timers. Blocks not only add timers to a script but also add a prefix to each command ID in the block. This prefix
enables you to easily identify emulation commands associated with a block both in the script and in the report output. For more information, refer to the section in this
chapter on blocks.
Adding a Timer During Recording
You can add a timer to a script during recording follows:
1. If the Session Insert floating toolbar is not already displayed, click the Display Session Insert Toolbar button on the Session Record floating toolbar.
2. Click the Start Timer button.
3. In the Start Timer dialog box, type the timer's name (40 characters maximum) and click OK.
4. Perform the timed activity.
5. Immediately after receiving the results generated by the activity, click the Stop Timer button on the Session Insert floating toolbar.
6. In the Stop Timer dialog box, select the name of the timer you typed in step 3 and click OK.
When you start and stop a timer during recording, you can view these commands in the Annotations window.
Adding a Timer During Editing
The Session Insert toolbar adds timers during recording. To add a timer during editing, type the timer commands into the script.
The following are the timer commands for VU scripts:
-
start_time - Starts timing the activity. Insert this command immediately before the first emulation command for the activity that you are timing. The
start_time measurement includes the think time (if any) for the next emulation command in the script.
To exclude the think time for an emulation command, insert start_time after the emulation command and use the _fs_ts read-only variable. For
example:
http_request ["test1.001"] ...
start_time ["timerid"] _fs_ts;
stop_time ["timerid"];
-
stop_time - Stops timing the activity. Insert this command immediately after the last emulation command for the activity that you are timing.
For information on using timers in VU scripts, see the start_time command in the VU Language Reference.
For information on using timers in Visual Basic scripts, see the TimerStart method in Rational Test Script Services for Visual Basic.
For information on using timers in SQABasic scripts, see the StartTimer command in SQABasic Language Reference.
Blocks
A block is a set of contiguous lines of code that you want to make distinct from the rest of the script. Typically, you use a block to identify a transaction within a script.
A block has the following characteristics:
-
A block begins with the comment. In the VU language, a block begins like this:
/* Start_Block "BlockName" */
-
Robot automatically starts a timer at the start of the block. In the VU language, the timer looks like this:
start_time ["BlockName"] _fs_ts;
-
Typically, the start_time emulation command is inserted after the first action but with an argument to use a read-only variable that refers to the start of the first action.
The ID of every emulation command in a block is constructed the same way- that is, by the block name followed by a unique, three-digit autonumber.
For example, in the VU language:
http_header_recv ["BlockName002"] 200;
When you end a block, command IDs are constructed as they were before you started the block. For example, if the last command ID before the block was
Script025, the next command ID after the block is Script026.
¾
-
A block ends with a stop_time command plus a comment. For example, in the VU language:
stop_time ["BlockName"]; /* Stop_Block */
A script can have up to 50 blocks.
When you end a block, Robot automatically ends the current block. In other words, blocks can be nested, but they cannot be overlapped. For example:
You cannot extend a block over multiple scripts. If you attempt to split a script in the middle of a block, Robot ends the block when it ends the initial script.
Why Use Blocks?
You might use blocks for the following reasons:
-
To associate the block and timer names with the emulation command that performs the transaction.
-
To include the block name in TestManager reports, thus enabling you to filter the reports with the block name.
-
To make the script easier to read.
-
To provide an immediate context for a line within the block through command IDs.
Adding a Block
To insert a block into a script:
1. If the Session Insert floating toolbar is not already displayed, click the Insertbutton on the Session Record floating toolbar.
2. Click the Start Block button at that point in the script where you want the block to begin-for example, just before you start to record a transaction.
3. Type the block name.
Robot uses this name as the prefix for all command IDs in the block. The maximum number of characters for a command ID prefix is seven.
4. Click OK.
5. Record all of the client requests in the block.
6. Click the Stop Block button to end the current block and click OK.
NOTE: When you end a block, you always end the current block. If you are nesting blocks, you cannot specify which block you want to end-the Stop Block
command always applies to the innermost block. For more information, seeNesting Blocks on page 8-6.
When you start and stop a block during recording, the commands are reported as annotations in the Annotations window.
NOTE: You can add a block during recording only, not during editing.
Nesting Blocks
To nest blocks, click Start Block on the Session Insert floating toolbar to start a new block without explicitly ending the current block.
When you nest blocks:
Robot automatically starts a timer at or near the beginning of the second block.
Timing continues on the first block (in other words, a stop timer command is not inserted for the first block).
The second block's name replaces the first block's name as the prefix for emulation commands.
If you have nested blocks and you click Stop Block:
Robot inserts a stop timer command to stop timing the current block.
The next block up in the hierarchy becomes the current block (that is, its name is used as the prefix for emulation commands). Timing continues on this block
plus other blocks that may be above it in the nesting hierarchy.
continues in page 2
| < Prev | Next > |
|---|
