This page provides some basic technical notes about eValid support for validating images of various kinds. This material is important because there is increasing need for functional testing (and performance analysis) of websites that deliver graphical information.
With some care, images can be validated very effectively so that the systems that rely on them can have automated regression tests that are effective at discovering errors. Examples of success in the mapping area include map-generated engines such as Google Maps, MapQuest, and include applications that are built on them such as NextBus.
Here are recommendations that concern applying eValid to validating images of all kinds.
VSSR saves a checksum extracted from the image at record time and saves the checksum in the script file. On playback eValid continually recalculates the checksum present within the saved image coordinates (in the part of the desktop you selected at record time) until a match against the saved checksum is found or until the synchronization timeout time is reached.
Caution: In some cases the "blinking outline" feature causes the synchronization to fail, so the safest method is to leave this feature disabled. (Think of the blinking image as a crowd pleasing heuristic.)
However, if an images has a fixed number of repetitions you may achieve VSSR-type synchronization, but not necessarily on the first instance of the correct image being displayed (due to the client side time delays involved).
You should be able to get good reproducibility with Google Maps, assuming the database from which the images are taken has not been updated.
In the most common case, you need to VSSR, but one problem is: how do you get the popup to occur repeatedly. The answer is to do an absolute xyClick type command at the spot on the display that causes the popup. Then you can VSSR the popup without difficulty assuming it is persistent enough.
What will appear to be a failure of the validation is in fact due to a problem with the initial state.
The starting frame and the ending frame usually are stable/static and given that the control buttons on most players are objects in the DOM there is some hope for start/end movie confirmation. Sadly, however, there is almost no hope for any kind of "in the middle of the movie" validation of images or movie-frames within the sequence unless you have the capability to stop the move playback at a specific movie-frame number.