beqa108 wrote:Sorry, please explain again why you think eVaid is so much better than a JavaScript based playback engine like Selenium?
The problem with JavaScript-based playback is twofold: Performance and
Contention.
First, Performance...
If you use the JavaScript engine to run the playback you are using the browser resources to help test the browser, and our measurements have shown that this can skew the timings significantly. If you want accurate data you can't use some feature of the browser (the JavaScript engine) to get the work done if doing that will mess up the data you're trying to collect.
By comparison, eValid uses direct execution to run commands -- this is possible because eValid is immplemented as a full browser, where the playback commands operate at the PC level, not at the JavaScript level.
Second, Contention...
AJAX applications typically use JavaScript programs that run in the browser and interact with the server to deliver information to and from the browser, and (as the name implies) they do this asynchronously. It is really cool programming and a very, very powerful way to implement a complex application.
But when testing such an application you run agains the problem that your tests need to synchronize somehow against what is by nature an asynchronoous activity in the browser. But if you try to run a JavaScript passage that performs the synchronization then you are actually are interfering with the JavaScript engine in order to attain synchronization. That is "contention" -- two requirements competing for the same result.
The eValid method of synchronizing avoids contention because the DOM-based synchronization commands are run directly in the browser. They don't interfere at all with the actions of the JavaScript...
The result is that you get accurate timings because you have avoided interfering with the very mechanism you're trying to analyze. That is a good thing.
The eValid Team
Why do you think eValid is so much better...?
by beqa108 » Tue Aug 25, 2009 9:44 am