|
|
The general rule is is this: for eValid to successfully modifiy the browser state to validate operation of a website, it MUST start in a known state. |
Introduction
During test script creation using the real-time recording mode inserts
"Wait nnnn" commands
to account for user think time.
eValid has a built-in HTML page synchronization based on sensing
of the "document complete event" within the eValid browser.
In addition to this synchronizing mode any available
inter-command times also serve to help synchronize playback.
This page describes how to assure synchronized playback
when the usual methods do not work perfectly.
Need for Synchronization
It is a good practice to make sure that a recording maintains synchronization
with the pages that the server is delivering to the browser.
If playback is not synchronized subsequent actions on a page
usually are not meaningful.
When scripts are intended to be used with multiple browsers, e.g. in eValid LoadTest operations, the need for synchronization is acute. This is because the response time from the server can be very much longer than when the recording was made. (This is often the point of a LoadTest experiment!)
A fully synchronized (or self-synchronized) test can be lifted from singleton playback to LoadTest operation without modification.
Solution Outline
The basic solution is to synchronize playback of slow-loading
or slow-availability pages using one of eValid's playback synchronization commands.
These commands include the
Validate and Synchronize on Text String
and
Validate and Synchronize on Screen Rectangle
capabilities.
These commands can both be recorded into the script during the script creation process. During recording you reach them with the Record > Validate > & Synchronize >... pulldown. It is generally not a good idea to try to edit these commands into script manually.
In effect use of these synchronization commands is a kind of "recording protocol" which forces creation of a fully self-synchronized script. As mentioned, such a script is essential for testing of websites for which the normal HTML page synchronization may fail.
The protocol used is simple: sync > action > sync > action, etc. Every activity first synchronizes on the screen to which it applies and then takes the action after the page is known to be ready for it.
Identifying Fail-to-Sync Problems
The acid test for self-synchronizing scripts is to observe
that the script fails when the Wait Time Multiplier is set to zero
and/or when the script "plays ahead" of the response it is intended
to produce from the server.
You can tell if a script has played ahead if the test runs to completion but the browser screen shows an intermediate page. Usually what happens is that a page arrives too late, timeouts take over, and the script playback proceeds -- without coherent meaning -- to the end.
How to Confirm Self-Synchronized Script
The best test for the self-synchronized property is to run the script
with the wait time multiplier to zero.
You know that the script is self-synchronizing if it always succeeds even when
the load on the server (the delivery time of the pages) varies.
It is good practice, before promoting a script into LoadTest scenarios, to confirm that it is self-synchronizing.
Pages Where Fail-To-Sync Often Occurs
Pages can be slow to be ready for access and/or use for a variety of reasons.
Some of the more common reasons are:
Minor Warnings
We have seen a number of cases where synchronization fails because of a bad interaction
between the Draw Visible Outline option and the images on which the
synchronization is supposed to occur.
This option is normally intended to inform the user that "something is happening".
To show the blinking outline eValid has to read from the current image, save the pixels where the outline is going to go, draw in the pixels for the outline, wait for the blink interval to elapse, and restore the original content saved from above.
In case the screen image is changing dynamically there is a slight chance that synchronization will fail when this option is turned on. If you notice this -- and it is quite evident because your syncs will fail! -- simply turn this option off.
Another problem occurs when a page has an unpredictable up/down scroll possition. The solution is simple: position the cursor in the scroll aread and record a HOME or END to force the scroll bar into a known position during playback. You may also follow a HOME by a number of Down-Arrow clicks, or a END by a number of Up-Arrow clicks.
AJAX Synchronization
In AJAX applications synchronization probably needs to be done using
detailed information about the page and how it was implemented.
See the list of available commands in the
Synchronization Mode Summary.
