Question

A similar question was already asked ( Performing a Stress Test on Web Application?), but I'd like to test a web application that prevents double-submits and takes some counter-XSRF actions and therefore REQUIRES JavaScripts to be evaluated.

Has anybody done stress tests with web apps that require (and use) JS and any experience to share?

jMeter wouldn't work I guess...

Thanks!

Was it helpful?

Solution

Watir?

Watir is a simple open-source library for automating web browsers. Watir drives browsers the same way people do. It clicks links, fills in forms, presses buttons. Watir also checks results, such as whether expected text appears on the page.

It drives Internet Explorer, but is also functional with Firefox (and Safari to some extent).

OTHER TIPS

The problem with Watir and Selenium RC or any other full browser solution is that they need a full browser :P

Browsers are very expensive to run, often requiring 300MB or more of RAM. Multiply those requirements by even 100 and you need massive hardware. Fortunately, there is a solution: I recently started a company that does exactly what you're looking for.

Check out http://browsermob.com and you can run a limited test (up to 25 users) to get a feel for the app. Feel free to contact us if you have any questions at all!

One solution that may be worth pursuing is to run Selenium on Amazon EC2 to provide the scalability you need. There is a tutorial over at Selenium using a sample that ships with Selenium grid. Windows machines are 12.5 cents an hour for a small machine meaning that a 500 machine test is going to cost $62.50 an hour.

PROS:

  • Selenium runs in a real browser meaning that your Javascript is executing as it would on a client
  • Low cost - trying to do this on your own hardware would cost significantly more

CONS:

  • You would have to establish network connectivity from Amazon to your application

The testers I work with use Bad Boy for load testing. I'm fairly certain you can test interactions that use javascript, so you should be able to test stuff like double-submits.

As far as your backend is concerned, it doesn't matter what triggers a request whether it's from JavaScript or a load testing tool as long as the request is valid.

You can create a bunch of fake requests that do lots of different things (hopefully representative of actual usage patterns) and slam your webserver with a load testing tool.

There's a bunch out there:

  • jMeter
  • http_load
  • Grinder
  • httpperf

Because JMeter is not a browser, it won't interpret the JavaScript code on the page you GETting:

JMeter does not process Javascript or applets embedded in HTML pages. [JMeter Wiki]

So, what can you do? You can add WebDriver to JMeter test and by this, evaluate the web pages.

Web Driver Sampler automates the execution and collection of Performance metrics on the Browser (client-side). A large part of performance testing, up to this point, has been on the server side of things. However, with the advancement of technology, HTML5, JS and CSS improvements, more and more logic and behaviour have been pushed down to the client. This adds to the overall perceived performance of website/webapp, but this metric is not available in JMeter. Things that add to the overall browser execution time may include:

  1. Client-side Javascript execution - eg. AJAX, JS templates
  2. CSS transforms - eg. 3D matrix transforms, animations
  3. 3rd party plugins - eg. Facebook like, Double click ads, site analytics, etc

All these things add to the overall browser execution time, and this project aims to measure the time it takes to complete rendering all this content.

Official guide: https://jmeter-plugins.org/wiki/WebDriverTutorial/

I've tried Badboy which is OK. The big, fat, heavy tool is SilkTest. It requires a lot of programming to get up and running, but you can get something very solid done!

If you only need to stress test request from e.g. IIS log files, I have a custom build tool. I will publish it at CodePlex very soon.

Selenium RC is another alternative.

Also related, check out my recent article on Ajaxian. I think it does a good job of explaining why real browsers do matter and why executing JavaScript is becoming more important for load testing.

http://ajaxian.com/archives/why-load-testing-ajax-is-hard

There's a new tool in this area called k6

it has a way to access the DOM, and I'm planning to try it in a project.

background story:

You can visit this and this blog.

maybe it will help.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top