Using Macro Scheduler For Load Testing
By: MJT Net Ltd
Using Macro Scheduler for Automated Load Testing
This document describes how Macro Scheduler can be used for load testing other
1. Simulating a Multi-User Environment
2. Synchronising Scripts
3. Measuring Elapsed Time
4. Responding to Events
5. Recording and Analysing the Results
6. Logging to a Database
Simulating a Multi-User Environment
This has been done a number of ways. The most common approaches are to use
Windows Terminal Server or Microsoft Virtual PC. Using these solutions one
physical machine can be divided into several virtual PCs. Using a number of physical
machines multiplexed into several virtual PCs it is easy to build an environment of
multiple virtual workstations.
Each virtual workstation must have access to the software that is being tested and a
copy of Macro Scheduler running on it.
It is often necessary to ensure that all workstations begin testing at the same time.
This can be done a number of ways and a couple of methods will be described here.
Method 1: The Controlling Script Semaphore Method
The simplest approach is simply to have a controlling script, running on a master
workstation, which sets a flag to indicate that the testing scripts should start. This flag
is usually just a value in an INI file, which is stored on a network share available to all
A very simple start script might simply look like this:
The INI file would look like this:
When the start script is run it sets the run flag in the INI file to 1.
The test scripts will be set to wait for this flag to be 1 before performing the test:
// Wait for run flag
// run the test
Each test script would be set to run on start up so that when the test stations are
booted (or Macro Scheduler is started on those machines) they immediately start and
wait to be told to perform the test. This avoids any manual process on the test
If we add different tests we can add appropriate flags to the INI flag and add a
corresponding control script:
Now we can start different types of test by running the appropriate control script.
We will also want to add a control script to reset the run flag for later tests.
Method 2: msNet Server Add-in
Method 2 utilises the msNet server add in which allows macros to be started across
the network. msNet adds a small server component to each Macro Scheduler
workstation so that a request can be made remotely to run a script. Scripts can be
started from a web browser, command line tool, or GUI.
A broadcast request can be made so that the same script is run on all msNet enabled
machines at once.
For more information on msNet see:
Measuring Elapsed Time
Of most importance during load testing is the ability to measure elapsed time to
determine how long certain processes take. There are a number of ways to do this
with Macro Scheduler.
The TimeStamp command outputs an accurate time, with milliseconds, and a
message, to a log file. This can be used to log events during the test script. When the
test is finished the log file can be imported into Excel and analysed.
Sometimes it may be preferable to calculate elapsed time in the script directly and
output the actual elapsed time. This cuts down on the analysis needed later.
Often we ll use a combination of these two techniques. The following script code
determines how long a logon took to complete and outputs the results to the log file:
// Need these lines at start of script
// Wait s for logon window
WaitWindowOpen>OneWorld Sign On*
// Perform logon
SetFocus>OneWorld Sign On*
Press Tab * 5
// Output timestamp and message
TimeStamp>%logfile%,About to Log on
// Get Start Time
// Hit log on button
// Wait for login to complete
WaitWindowOpen>J.D. Edwards OneWorld Explorer*
// Calculate elapsed time
// Output elapsed time
So here we have used TimeStamp and Timer to output critical time information about
how long the log on process took. The log file can be imported into Excel and
For more control over the format of the output use the WriteLn command. We can
create a CSV file by separating key data with semi-colons:
WriteLn>logfile,r,Start Log on;%ElapsedTime%
WriteLn>logfile,r,Done Log on;%ElapsedTime%
Responding to Events
Most of the time we want to determine how long a process took. The majority of the
time this is as simple as waiting for a window to appear. E.g. in the log in example
above we enter the log in information, send alt-o to ok the log in and then wait for the
main application window to appear. We then know the log in has been successful and
we can calculate the elapsed time and log the results.
Sometimes it is not possible to determine progress by looking at windows and we
need to use other approaches. Amongst other things Macro Scheduler has functions
to wait for the cursor to change; get object text; wait for pixels to change colour; get a
checksum for a rectangular portion of the screen and wait for that checksum to
appear; wait for windows to change; check for the existence of files. Check out the
command reference that comes with Macro Scheduler for a full list of commands.
There is always a way that one or other of these commands can be used to determine a
For example, the following script snippet waits for the status bar to say Done :
//complete - output elapsed time
This example waits for the first status bar in Internet Explorer to say Done. In fact if
we were really automating Internet Explorer we d probably use it s Busy property
directly rather than look for the status bar text. But the example demonstrates a
method which can be used in any application and any control. It doesn t have to be a
status bar object we could be waiting for a button to change text for example.
Version 8.0 of Macro Scheduler also includes OnEvent event handlers. These allow
us to respond to events that may happen at indeterminable times. These could be
error messages for example. We can define an OnEvent handler for an error message
and log when that appears.
Another approach is to use OnEvent to log performance data and therefore not have to
add logging and time calculations to the body of the actual script. This makes it easy
to add performance logging to existing automation scripts easily.
Recording and Analysing the Results
We ve already discussed how we can record the performance data in the previous
section. TimeStamp is designed specifically for outputting script performance data.
Alternatively we can calculate elapsed time and output it using WriteLn. Or we can
use a combination of TimeStamp and elapsed time to provide an output file with
millisecond accurate time and elapsed time. The output file(s) can then be imported
into Excel and analysed.
It is often preferable to output performance data directly to a database. This is faster
and ensures all performance data is in one place and allows more advanced analysis
using SQL and graphical query and reporting tools.
Logging to a Database
A better alternative to outputting to a CSV or text file is to output performance data
directly to a database. This can speed up the process and make analysis easier. We
can easily write to a database using VBScript. E.g.:
//Add to start of script this opens a DB connection
//and contains the function to output performance data
'open the database connection
set DB = CreateObject("ADODB.Connection")
'next line can be a data source name or connection string
Sub LogOutput(scriptId,elapsed, message)
SQLString = "INSERT INTO tblResults (scriptId, elapsed, msg)
VALUES ('" & scriptId & "', '" & elapsed & "','" & message & "')"
//we would log data like so:
VBRun>LogOutput,1,%elapsed%,Done Logon Screen 1
This example simply outputs three fields a script ID, elapsed time and a message.
This can easily be modified to output any amount of information to suit the needs in
hand and the structure of the database.
... to read more articles, visit http://sqa.fyicenter.com/art/