by serverloading » Thu Aug 28, 2008 4:58 pm
The goals of test automation tools have not changed over the
years, but the growing dominance of web applications was a
primary architectural push for the eValid solution, which by
design was optimized for web applications. By putting the
entire test engine inside a full-featured browser we succeeded
in leapfrogging the older client/server solutions (like the
ones you mention).
eValid records web tests simply and reliably using data about
the web page taken from within the browser -- from the DOM.
This approach lets non-programmers be effective test creators.
The recordings contain enough object-mode DOM-based detail so
that test playback is not "brittle": tests play correctly
with minor page variations, e.g. objects moving around. The
adaptive playback feature takes advantage of having full DOM
access to "do the right thing" (insofar as that can be
determined automatically by analyzing the current DOM).
It's possible to generate the corresponding URL sequence from
an eValid script but that throws out the hard-won stateful
browser based simulation. The URL sequence is useful for
generating "load," but not as practical as simply running
multiple eValid browsers in parallel to impose real load.
Recorded scripts are simple to read and easily edited, run
reliably, and can even synchronize AJAX applications with
built-in DOM polling. Even so, there's a programmatic
interface available separately if you really need to construct
additional code around such tests.
eValid Tech Support Team
