Gatling requires Scala code to run high-quality scenarios. The recorder helps, but does not provide an immediately usable path. In the results, it is difficult to analyse the errors encountered during a load test. We can identify when errors occur, but it is challenging to pinpoint the cause at a given moment.
WebLOAD is an imperative tool for our web manager and developers team. We rely heavily on this in our daily activities, mainly to run script testing (in record time) of new code prior to our build releases. This product helps us identify potential gaps and issues with the user flow and allows us to make adjustments and fix problems before they make it into the live production site. Our team also depends on this software to run multiple load testing of each server in preparation for heavy timeframes of the year, such as Cyber Monday, Black Friday, etc. Our team members brought up that they would love to see more scripting examples of how to use WebLOAD, which would make their job easier.
Our tests are only run via an integration platform (Jenkins), and only the results are analysed using Gatling reports. The difficulty lies in maintaining the Scala scripts, which must keep pace with changes in the application over time. New use cases must be thoroughly documented for testers who are not directly involved in development.
Gatling can only be used for high-load tests with a paid license and only for tests with a reduced graphical user interface (GUI). Unlike OctoPerf, NeoLoad, or LoadRunner, we are not limited to a fixed number of users per license. Compared with JMeter, Gatling is less resource-intensive and therefore does not require an extensive test infrastructure.
There are many similar comparable products on the market, but with WebLOAD, the price point was reasonable. Their sales and engineering teams and very friendly and helpful and make our implementation a breeze. I would definitely renew our contract and recommend this to anyone out there looking for the best load-testing tool!
