eValid™ -- Automated Web Quality Solution Browser-Based, Client-Side, Functional Testing & Validation, Load & Performance Tuning, Page Timing, Website Analysis, and Rich Internet Application Monitoring.

eValid can run a test scenario made up of repeated playbacks of multiple script files at varying delay multiplier values. Each script file is executed in a sub-browser that is launched from the top browser, according to instructions contained in a single master script file (see example given below).

Important Facts

Here are some important facts about the LoadTest capability of eValid:

• You need to have the LOAD license key for eValid.
• The master script (see example below) runs each specified script in a separate eValid sub-browser.
• Each eValid sub-browser runs the script the specified number of times at the specified delay multiplier, and then closes itself.
• Each script runs without cache to assure that each page is actually downloaded, not just read from local storage.
• Playback of each script sequence begins as soon as its sub-browser is fully launched. The sub-browsers are launched in the sequence specified in the master script
• The load test scenario expressed in the master script can be made up of a set of pre-recorded script files and with:
  • Any delay multiplier value, e.g. 0.9 or 1.25 or ??
  • Any repetition count value, e.g. 1 or 5 or 100 or ??
• Timing data on each complete playback is written to a single consolidated timing logfile, the default name of which is LoadTest.log.

Shown below is a sample master LoadTest script that invokes the eValid LoadTest engine. The scenario refers to a total of 6 different pre-recorded script files that will be run independently of each other in 10 parallel executing sub-browers, with each script run a total of between 40 and 1200 times according to the indicated repetition counts and delay multipliers. The assumption is that each of these script files exercises features on the website of interest.

 void Scenario_01()
  {
    /*
       Sample scenario script for eValid
    */
    ProjectID "Test"
    GroupID "Load"
    TestID "Scenario_01"

    _eValid "script1.evs" "Simplest"      60   "-pm 0.9" "$LOGIN=jones $PASSWD=bill"
    _eValid "script2.evs" "Not So Simple" 90   ""        "$ACCT=Smith $PASSWD=Any"
    _eValid "script3.evs" "Type A User"   50   ""        "$USERID=Andrew"
    _eValid "script3.evs" "Fast Type A"   1200 "-pm 0.5" "$USERID=Jane"
    _eValid "script3.evs" "Type A User"   80   ""        "$USERID=Eddy"

    _eValid "script3.evs" "Slow Type A"   40   "-pm 2.25"
    _eValid "script4.evs" "Type B User"   70   "-pm 1.0"
    _eValid "script5.evs" "Type C Buyer"  100  "-pm 1.0" "$ACCT=smith"
    _eValid "script5.evs" "Type C Buyer"  150  "-pm 0.2" "$ACCT=jones"
    _eValid "script6.evs" "Background"    300  ""
  }

Master Script Parameter Definitions

Each line in the above script launches one eValid sub-browser and specifies (in order):

• The name of the script file [a string] to play back.
• The sub-session title of that test [a string]; this title will appear in records written to the LoadTest.log file. Graphing of the results from a LoadTest scenario are always expressed in terms of the user-specified titles. These titles do not need to be unique in each scenario, although they could be. If this field is left blank an internal sequence number is generated automatically.
• The repetition count [an integer] specifies how many times the named script is to be played.
• Additional parameters that control playback [a string], following the format for Batch Mode operation. In the example above, "-pm M.N" specifies a playback multiplier of M.N.

In example loading scenario seen above:

• #1: The script script1.evs is called "Simplest", is repeated 60 times (by the first line of the scenario), and is played back in every case with a delay multiplier of 0.9. The script is parametric with $LOGIN as "jones" and $PASSWD as "bill".
• #2: The script script2.evs is called "Not So Simple", is repeated 90 times, and is played back with the default delay multiplier of 1.0. The script is parametric with $ACCT as "Smith" and $PASSWD as "Any".
• #8: The script script5.evs is called "Type C Session", is repeated 100 times, and is played back with a delay multiplier of 1.0. The script is parametric with $ACCT as "Smith".
• #10: The script script6.evs is called "Background", is repeated 300 times, and is played back with a delay multiplier of 1.0. It has no parametric expansion.

Additional Notes

• If the specified script file is empty that command will fail.
• If the sub-session title field is empty an assigned sequence number is be used.
• A repeat count of < 1 defaults to 1.
• A repeat count of > 10000 is capped to 10000.
• Chaining [playback scripts that contain _eValid.references to other playback scripts] is allowed, and encouraged.
• Recursion [playback scripts that somehow contain _eValid.references to themselves] is allowed, is not explicitly detected, and is strongly discouraged for the obvious reason.
• The total number of sub-browsers launched from the master script is not checked. The maximum depends only on your machine's capacity (see estimates below).
• Parametric string substitutions before playback are made as indicated for any $STRING found in the script.
• Playbacks run from the _eValid command are always run without cache and with all logfiles (except the LoadTest.log file) suppressed.
• We assume a Windows 2000 environment. Some adjustments of internal machine parameters are generally required to achieve optimum load testing performance.

How Many Parallel Copies of eValid Can Be Running At One Time?

These are estimates for the total number of parallel executing eValid browser sessions as a function of typical machine capacity.

With a large number of simultaneous playback sessions the connection between the driver machine and the Web may saturate, thus slowing down all playbacks. Even though running slower, all launched sub-browsers will complete execution eventually -- unless interrupted. However, on a 10 Mbps LAN [or faster] for an IntraNet test, or with a T1 or T3 connection [or faster] for a live test, this may not be an issue.

If a typical user session lasts 10 minutes including "think time", but takes only one minute of actual playback time when the playback delay multiplier is set to 0.0, we say that the duty cycle for that test is 10%. This is a fairly common value for test duty cycles. This means that, as shown below, full-rate (delay multiplier = 0.0) playback of tests can simulate the load imposed by a large number of users. You may need to make some adjustments to system parameters to achive the below stated performances.