(Page 2)
The capacity module is a little tricky, to be honest. I'm going to explain how the module implements the timeslicing method, and hopefully this will help anyone who's implementing the module.
Fundamentally, the module works in a way similar to the stress module, by constantly cycling through the windows, and executing an action for each of the window. However, the module will have to keep track of which actions belong to which window, and what action is to be performed for a particular window at a particular time. This is the tricky part.
The module uses several variables that are shared by all of the WinFrame sessions
under control. These always start with the "t_
" prefix.
However, the most important one that you should be aware of is: t_win_ra[]
,
which is the array of WinFrame window names. Unlike the stress module, you have
to use this array to store the WinFrame session's window names, which should
correspond to the entries in the WinFrame manager. Also, the content of the
t_win_ra[]
array must be numerically indexed starting from 0.
The other variables (the purposes of which can be found by reading through the notes in the t2 module), are mainly multidimensional arrays. If you're interested in writing additional functions, then you will need to read through these notes. These arrays are shared to keep track of timeouts, goto markers, actions to be performed, and the pointers as to which line of action to perform for each window.
In executing the actions, the module executes the action one line at a time. You will notice this limitation when writing the script, and this is what makes the script writing a little tricky. As a result, conditional statements will have to be contained on one line of code; but remember that you can use goto statements to break the commands up.
In writing the scripts using the module's functions, you will not be able to
specify the window to act on (most of the time, anyway). This is because the
module should be the one to determine the window to perform the action on, since
the window's name might change in different hosts. However, if you need to specify
the window's name, you can use the t_def_win()
function to get
the default window as the module sees it.
Here are the overview of some of the more useful functions:
t_def_win ();
t_win_wait_text (text_to_wait, timeout, x1, y1, x2, y2);
t_win_wait_text_t (text_to_wait, timeout, x1, y1, x2, y2, transaction);
t_win_wait_text()
, plus ending the transaction when
the text appears (pass transaction), or the timeout has been reached (failed
transaction).t_win_type (text);
t_win_mouse_click (x, y);
t_win_mouse_dbl_click (x, y);
t_win_mouse_drag (x1, y1, x2, y2);
t_start_transaction (transaction);
t_end_transaction (transaction[, {PASS|FAIL}]);
t_start_transaction()
function, the module will append an index to uniquely identify each "virtual
user."t_wait (seconds);
wait()
, because this function will not hold off the
other "virtual users" from performing. The regular wait()
will force all of the other "virtual users" to wait, which you do
not want to do.t_rendezvous_add (rendezvous);
t_rendezvous_set_timeout (rendezvous, timeout_value);
t_rendezvous (rendezvous);
rendezvous()
call to the LoadRunner controller. This is the only way that you can synchronize
rendezvous across different hosts.