But professional QA testers are generally dubious of the open source tools. Not because they aren't fans of open source (I've known some of these folks for years and trust their commitment) but because they believe the proprietary tools really are better. "I've used the commercial load testing tools (SilkPerformer, LoadRunner) and a cloud-based load testing tool (BrowserMob). I've spent a number of years looking for an open source tool that was as good as a commercial one and I've never found one I can recommend," said Ed Borasky (whom I also quoted in the original article). "The key differentiator is ease of script recording. If you're willing to use a conventional or custom programming language and write scripts and load test definitions by hand, there are plenty of open source tools. I guess the best I've encountered is JMeter. But easy capture of test scripts from users executing an application as far as I know can only be found in the commercial tools," Ed explained.
One contact dis-recommends all the open source load- and stress-test tools he's encountered because, he says, "Staff time is the 100-pound gorilla, not license cost (unless you have more people than you should)."
Also, these tools do rely on the developer's existing knowledge to interpret the results. It's important to understand what you're doing when you're stress testing, Sean said. "You want to find the breaking point of your application. You want to find out where your bottlenecks are in your code. Measuring response times isn't helpful here because a large component of that time is going to be the queuing delay, not the time the application processes information." Obviously, if you are going to turn to these tools, it behooves you to learn about the topic; there's plenty of options for a developer who wants to acquire that knowledge, but the tools won't give you a wizard-based "follow the bouncing ball" process that will assure you that yes, your e-commerce site can manage the holiday rush without breaking a digital sweat.
I suppose that dedicated open source developers should see this situation as an opportunity: a software domain in which the open source code quality cannot (yet) claim to be better. You up for the challenge?