共用方式為

Web Test Recording

  • 發行項

Our Web Test Recorder works differently than recorders in some other web/load testing products. We actually hook IE navigation events while others use a small proxy server to intercept and record requests. There are advantages and disadvantages to both approaches.

A proxy recorder's main advantage is that it can see all HTTP traffic no matter where it's coming from (any active browser, smart client app, etc). Seeing everything can also be a disadvantage because your recording may be filled with lots of extraneous requests such as images and CSS files. Also, proxy recorders can be difficult (or impossible) to use through other proxy servers, with Windows authentication, and with SSL.

A browser recorder sees only navigation events in IE. One advantage is that your test looks logically like what you clicked on during recording. Redirects, images, CSS, and javascript files all get handled at runtime and don't clutter up your test. Perhaps the main advantage of a browser recorder (and the reason we decided on this path) is that SSL, other proxy servers, and authentication have all already been handled by the browser before any events are raised. That is, the browser recorder works exactly the same no matter what's going on at the network level.

I originally went down the proxy recorder path before we eventually opted for a browser recorder. In our next release, we're looking at using a hybrid browser-proxy recorder that could fuse the best of both worlds. In the meantime, we're working with Eric Lawrence, the creator of Fiddler, to be able to convert Fiddler recordings into web tests for those cases that aren't handled well by a browser recorder.

Comments