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

Summary
This page describes some common problems encountered with eValid when applied to Rich Internet Application Monitoring. The below-described situations are taken from our actual experience with unattended monitoring and/or with customers experience with eValid in the same mode.

• Hidden, Unexpected Modal Pop-Up
  The playback script arrived at a page that caused a modal pop-up to occur that was not evident during recording (so clicking on it was not part of the script.

  eValid will wait forever for action to dismiss a modal dialog. What you'll see appears to be a hangup, but if you move the eValid browser aside you'll see the modal that is awaiting action.

• Dangling Thread
  End of script playback, timeout on page loading time, but the page has a thread running to get a last element.

  eValid MAY be in a deadly embrace...from which it may be impossible to escape. If the -RT switch in the batch command line doesn't do it, you have to use the kill mechanism in the Scheduler. If all else fails you can use "pskill" to remove all eValid copies.

• Dynamically Variable Frame Paths
  In this scenario, the page's frame paths change over time. They don't have names (labels), so they are viewed by eValid as "numbered (ordinal)" frames. The script will have eValid looking for "X" in frame n1 but now it is in frame n2, and eValid will not find "X" where it is expected to be.

  Non-deterministic behavior cannot be monitored. However, if you can change the script to refer to named frames this problem is unlikely.

• ScreenSaver Interference
  The screensaver often is set to log you out and present you with a login screen after a certain number of minutes. If this occurs, the next eValid playback attemped will fail, because you are not logged in.

  Disable the screensaver feature, or disable the requirement that you log in to regain screen focus.

• Focus
  Window focus is not instantaneous. Even if you run a Focus command it takes a few seconds to bring the target window into actual, active, focus.

  Add Wait 100's after a Focus command to allow the operating system to catch up.

• Non-eValid Pop-ps
  Often times a page will pop-up a page that is NOT an eValid sub-window -- and as a result eValid's ability to suppress child pop-ups won't work. You can tell if a pop-up is a child of eValid because all such child windows have the eValid logo in the upper left hand corner of the window.

  Close non-IE child windows manually prior to playback.

• Non-Desktop-Safe Playbacks
  If two or more scripts are non-desktop-safe they may step on each other unless ALL scripts on the desktop make use of the Lock/Unlock MUTEX operator.

  Add Lock/Unlock to every script that needs to share the one available desktop resource.

• Idempotency
  Tests ought to start at a known state and at the end return to the same state. Otherwise, results are not predictable.

  Make sure each test has a known and reproducible starting state.

• Timeout Limits, Wait Ceilings, Retry Rates
  All of these parameters are adjustable and often they can have very unusual interactions. Many times a page really isn't fully downloaded when the Maximum Download Time is exceeded.

  Also, when you are doing synchronization polling the Retry interval affects performance (so make the interval as long as you can), and in the case of screen images synchronization there often is a small performance penalty as eValid scrapes the screen and generates a checksum.

  Be aware of the interaction of all of the time limits, ceilings, and timeout limits and choose the values for your situation that are appripriate.

• Multiple Logins
  Some websites allow mutiple logins; but some either prohibit the second login from the same IP address, or they log out the first logged in person when the second one signs in. In either case, you have a "unitary resource" -- the number of logins.

  Treat this the same as for desktop-limited tests, where the Lock/Unlock MUTEX may be an effective solution.

• Cookie Management
  If session A logs in and places a cookie, and needs the cookie to log out successfully, and session B comes along and does a DeleteCookies, that will be an unhappy outcome for session A when it tries to finish up.

  Manage cookies that may be shared between runs very carefully, and DeleteCookies only when necessary.