7 Tips for Load Testing an E-Commerce Site

You may have heard that the holiday season is approaching.

If you’re working for a B2C company, there’s a good chance this is a busy time of year for you, and you’re expecting more web traffic than usual.

Creating realistic tests that mirror your the checkout process is absolutely imperative when preparing your websites, apps, APIs and infrastructure for load testing.

So, here are a checklist for ecommerce performance testing that will help you get the most actionable data from your tests. And that leads to better optimizations, which leads to better performance, which leads to happier customers and more revenue.

If you are new on the topic, we recommend starting with our guide to load test a website.

Test data

Load tests consume data very quickly. You definitely want to make sure your test data have plenty of information for the Virtual Users in your load test.

Let’s outline a quick breakdown to show what we mean. Let’s say you’re running a test with this configuration:

• Ramping up to 5,000 concurrent Virtual Users
• Test duration of four minutes
• Testing process of user logging in with a username and password, searching the product listing, adding an item to a cart and checking out
• Various user flows take around two minutes each to complete

So, if you want every scenario to be executed with a unique username and password, you’re going to need to have data for 10,000 users.

In order to include randomized data to make your load tests realistic, you’ll need to utilize different data for each user. Read more about Data Parameterization from the documentation.

const data = JSON.parse(open('./data.json'));

export default function () {
  const user = data.users[0];
  console.log(data.users[0].username);
}

Additionally, you could populate your database at the beginning of your load test with the test setup hook.

export function setup() {
  // called once at the beginning of the test
}
export default function (data) {
  // VU code
}
export function teardown(data) {
  // called once at the end of a test
}

Tokens: CSRF Tokens, VIEWSTATE, etc.

This can be an unforeseen wrinkle for the average engineer who hasn’t been working specifically in QA and performance testing throughout their career.

For many of our users who utilize the Browser Recorder to easily create testing scripts, the hiccup starts when our scenario recorder captures their specific CSRF token.

In order to properly test unique CSRF tokens for each of your Virtual Users in your test, you’ll need to extract the values, save it to a variable and concatenate it into the future relevant requests.

There’s a bit of scripting involved in that, but here’s an easy reference for correlating dynamic data (CSRF tokens, VIEWSTATE...) in a load test.

Try Less Common Scripted Behaviors

One scenario that covers most common behaviors is a good start, but average user behavior isn’t what might cause the biggest surprises during peak traffic times.

Create some scripts that test less common behaviors. Those less-common behaviors might include removing items from the cart repeatedly, using the browser "back” button during the checkout process, backing out of a cart or checkout, adding a discount code at checkout and then backing out, and so on.

Don’t overlook testing for failed API calls, slow or non-existent service responses, and so forth - those third-party integrations can trip you up when you least expect them.

Payments

You’re selling something, and there’s a good chance you use a payment provider to collect information (credit card info, etc.)

These solutions typically provide some kind of QA/test environment with a number of possible payment methods, but it’s important to know that many payment providers don’t want you to include their service in your load tests.

Simply put, payment providers don’t want you to run a stress test and crash their product. (Seems like a reasonable request from them)

If you think it’s absolutely imperative to test the actual payment-transaction process in your load test, you should probably notify your payment provider first.

In some cases, creating simulated requests against your payment provider’s system could violate your terms of service, as these companies are trying to protect themselves from performance issues.

So, take a look at your TOS or just send an email to your payment provider’s support team to make sure you’re in the clear.

Email or other Communication

People usually expect to receive some kind of email confirmation after making a purchase, and many of our customers have asked about including that in their load tests.

Our advice is to set up a catch-all mailbox to receive all those test emails.

A load test can generate thousands of emails (depending on the number of Virtual Users you’re testing), and sending all of those in a short time frame without configuring your email settings could cause you to be blacklisted or flagged as spam by an email provider.

Also, if your purchase confirmation is sent via SMS, then you’ll probably want to just disable that when running your load tests. Depending on how you pay for that, sending thousands of test messages could be a waste of money.

Inventory

This is a big one for our e-commerce friends working with a supply chain.

If you’re including real items in your test, Virtual Users running in your test scenario can cycle through the scenario several times, which means they’ll just keep "ordering” an item until the test finishes.

Depending on the level of automation you’re using in your logistics, this could lead to your system automatically re-ordering items you don’t need.

So, make sure you’re either testing something with plenty of inventory, or go ahead and configure some items specifically for your load tests that won’t "run out” of inventory or trigger an auto-reorder.

Most of our e-commerce users will create a few fake SKUs to only be included in load tests to accomplish this.

Backend Integrations (Logistics, etc.)

In the same vein as inventory, you’re probably using other integrations — invoicing, logistics providers, printing, CRM, financials, etc. — that could be affected by hundreds or thousands of Virtual Users accessing your website and "ordering” things.

Keep all of those in mind when creating your user scenarios and tests. It could save you from a massive (and unnecessary) headache down the line.

And there you have it. Hopefully some of those tips can help you testing the performance of your e-commerce sites this season.