Load testing of WebSphere Commerce software is a critical component to the success of the project. It ensures the functionality of all facets of the eCommerce site as well as all related interfaces and back-end systems. Load testing allows the project team to subject the WebSphere Commerce software to the highest levels of anticipated traffic, allowing the team to identify and resolve any potential bottlenecks in the system. This can all be accomplished prior to launching the application, allowing all issues to be resolved before the go-live date.
What is Load Testing and Why is it Important?
Load testing is exactly what it sounds like: putting artificial load onto any browser-based system, in our case an eCommerce site, to try to simulate the load that site will handle once it has launched.
There are two main benefits to load testing. One is that it allows you to configure a site to better handle more load. There are a number of variables that can be adjusted to allow the site to run more efficiently.
The other benefit is that it validates the configuration of your site and the expected load. By putting more load on the site than the anticipated amount, you can prove how well your site will perform.
Types of Load Testing for WebSphere Commerce
Generally, the load testing of WebSphere Commerce is conducted in two scenarios based on time and workload. The first is short-running tests with a heavy workload. These tests are typically run for 30 minutes to a full hour. Shorter tests are used to evaluate page response times, system interfaces and hardware performance.
The second is longer-running tests with a constant, moderate workload. These tests are generally run for four to eight hours, but can be run for as long as 24 hours. Longer tests are used to evaluate caching strategies and check for memory leaks, as well as validate memory performance.
Load testing can provide the project team with a general idea of how many users can access the system simultaneously while maintaining the desired level of performance.
When to Perform Load Testing
There are a number of situations that call for load testing, but we always suggest load testing under the following circumstances:
- When launching a brand new site: Load testing before the launch of a new site will validate the configuration and make sure that the site is ready for go-live.
- After a major site upgrade: Similarly to launching a new site, testing the load before implementing a major upgrade will ensure that the upgrade is ready to go live.
- Before every major holiday rush: This is especially applicable for larger sites. Whether the rush hits on Cyber Monday or Valentine’s Day, load testing beforehand is a good idea.
- Before a major code push: Also recommended for larger sites, load testing in the staging environment is recommended to make sure that the new code is not negatively affecting anything else on the site.
Load Testing vs Regression testing
While similar, load testing and regression testing accomplish different tasks. Regression testing tools simulate specific clicks on a screen and work at the GUI object level. However, load testing simulates the user clicking the ‘Submit’ button on the page, sending data to the Web Server. This can then be done for a high volume of users simultaneously. Both types of testing are important, however, and it is critical to use the right tool for the job at hand.
Our Approach to WebSphere Commerce Load Testing
Our standard approach to load testing WebSphere Commerce is to use a load testing tool to simulate site traffic, which also tests the various areas of the application. We use data from the back-end systems to create load testing scripts that simulate browsing traffic. This traffic is designed to access all portions of the website. Wherever possible, we also develop scripts that generate a completed customer order within commerce applications.
Then, using a collection of reporting tools, we capture the results of these tests for evaluation. The data in these reports typically point to areas of contention within the site or the related interfaces.