aaike wrote:Just can you please explain again to me why I have to have a browser rather than just capture the input/output traffic from the browser?
It seems to be a lot more efficient to simulate HTTP traffic than it is to run a complete browser, so there has to be some difference that using a browser gives you that you can't get with HTTP, right? What is that?
-Aaike
This is an old question but it comes up time and time again.
Yes, Aaike, a browser really *IS* necessary for testing a web application, compared with using the HTTP protocol trace, unless you are willing to:
(1) Accept an inaccurate solution, because the serial sequence of HTTP requests doesn't capture the partially parallel behavior of the browser, which gets page components in multiple threads;
(2) Don't have any browser-context issues at all, so that your test is really not more than a series of simple navigations;
(3) Don't need to have dynamically variables entries in the query strings, such as are often generated when there is active JavaScript (or other active elements) in the page making dynamic adjustments;
(4) Don't have a secure login with a session cookie which is kept inside the browser and is not visible in the sequence of URLs exchanged with the browser;
(5) Don't have any JavaScript that does processing of inputs local to the browser before submitting data to the server; or
(6) Don't have an AJAX application in which the sequence of HTTP requests is a function of what the user has done on the screen.
There are SO many reasons why having the work of testing done with the brower is superior to the old-hat way of trapping the HTTP traffic that it is hard to enumerate them all.
The bottom line of the argument FOR using a browser is that it is simpler, more realistic, more reliable, more compact, and more adaptable than any other recording and playback method.
(Let's not even TALK about what is wrong with using JavaScript playbacks...that's an entirely different story...)
The eValid Team
