If you search for a load testing tool to test your AJAX application, you will surely find many vendors pretending that their tool support AJAX applications. If you look a bit more carefully in the detailed features, you’ll quickly find that it is done by recording the http traffic.
HTTP traffic recording limits
Capturing should always be considered very carefully for functional testing as well as for load testing. In the case of AJAX applications, it can simply lead you to generate a load testing scenario that may work… but that has nothing to do with the traffic that would really occur for the number of simulated users.
A small example
An example is worth 1000 words, let’s look at the code of this minimal AJAX application
<html><head><title>Welcome</title><body> <script> var xhr = window.XMLHttpRequest ? new XMLHttpRequest() : new ActiveXObject('Microsoft.XMLHTTP'); xhr.open('GET', 'numberOfVisitors.txt', false); xhr.send( "" ) var nbConnectedVisitors = parseInt(xhr.responseText) var nextPage; if (nbConnectedVisitors < 100) nextPage = "fullFeaturedSite.html" else if (nbConnectedVisitors < 1000) nextPage = "limitedSite.html" else nextPage = "temporarilyUnavailable.html" window.location = nextPage </script> </body></html>
fullFeaturedSite.html” if less than 100 users are connected, “
limitedSite.html” for 100 until 1000 connected users and “
temporarilyUnavailable.html” when over 1000 users are connected.
If you use a recorder to create a test for this application, you’ll probably be the single connected user while recording. When you’ll run the recorded tests to simulate the last of a large number of users, you’ll perform charge on your server of course (here requesting “
fullFeaturedSite.html“), but this charge is something that would never occur when over 100 users are connected, what means that your test results have nearly no signification.
Client side JS evaluation needed
It wouldn’t be really complicated here to adapt the load script to parse the content of the response from “
numberOfVisitors.txt” in order to perform the adequate next request. The downside of such a strategy is naturally the duplication of the logic of the application in the load test scripts which cause high maintenance costs and is not necessarily always as easy as in this oversimplified example.
A place for HtmlUnit as load testing tool?