Postman Load Test Tutorial

Postman is a highly popular tool for testing and verifying API requests. But, while using Postman for general API testing has widespread adoption, many are still unsure of how to use it for load testing.

In this post, it’s assumed that you have at least some experience working with Postman and are familiar with the basics of creating and sending requests. If not, you can find many great resources in the Postman Learning Center.

Table of Contents

How Does Postman Relate to Load Testing?

Postman as a tool aims to test any type of API you might be working with and currently supports the three major protocols: REST, gRPC, and GraphQL. They also support SOAP, for those still working with that.

The most common use case for Postman is to simply test or verify individual API requests. With the introduction of Collections, in particular, Postman became one of the optimal tools for testing API requests during development, as Collections allow you to group requests together, such as all possible requests for a given API.

However, Postman was initially only meant to test API requests one at a time. This is still a very useful use case, as it allows you to manually verify the response from your API.

While that has been and still is a very valid use case, the team at Postman also realized that many users are interested in verifying the resilience of APIs, also known as load testing. Because of this, new features have been integrated into Postman, allowing users to verify performance and resilience as well.

Generating Requests Sequentially

Load testing is an entire subject in itself. However, there’s one feature you’ll find in every load testing tool: the ability to generate requests. For the load test to work, you need to run all the tests at once to create a significant load.

As you start working with load testing, you’ll find that the configurations can get very advanced and complex. But without being able to generate a given number of requests at a time, it’s impossible to perform a load test.

Postman decided to implement this functionality with their Collection Runners, a way of running requests from a Collection in a specified order.

Creating Mock Servers

As an example of more advanced features implemented by load testing tools, the use of mock servers can greatly enhance your load testing experience. In fact, mock APIs can enhance your development experience in general.

Combining load testing and mocks is the best way of ensuring that you’re only load testing a single service. Imagine you’re running an e-commerce site with a microservice architecture. One of those microservices is the cart service.

This service will, of course, need to handle payments, and in this imaginary case, your service is using Stripe. While Stripe does offer a sandbox API specifically for testing, you can still run into rate-limiting issues, which is very likely to happen during a load test.

Graphic showing testing with and without mocks

Later in this blog post, in the section about implementation, you’ll see how mocks are actually created in Postman.

Integrating with CI/CD

Being able to run a load test locally is a great first step, and allows teams to verify the resilience of a service at a moment’s notice. However, efficient teams may consider integrating load tests in their CI/CD pipelines directly, ensuring with every commit that the service still performs as expected.

Postman provides two ways of accomplishing this. They’ve developed integrations directly for a number of CI/CD providers. If your CI/CD provider isn’t on this list, it’s also possible to get started by using the Newman library.

Limitations of Postman

At this point, it should be apparent that performing load tests with Postman is by all means possible. However, there are certain limitations you need to consider before going through the effort of using Postman.

Checking Response Times

It can be argued that Postman doesn’t support "true" load testing, as it waits to check the response time for a request before sending the next one. This can result in not enough load or stress, as the requests are being sent in isolated instances.

Manually Managing Mocks

While Postman does support mocking functionality, it’s far from an automated experience. In essence, Postman will generate a URL that will return whatever response you’ve configured.

Using our previous example of a cart service, you’ll have to configure the service (either directly or via environment variables) to use the new URL when contacting the Stripe API. It’s much better than not using mocks, but it does add some cognitive load to your load tests.

Combine this with the fact that mocks often have to be updated, especially if you’re mocking internal APIs, it can quickly become quite the task to manage.

No Public Cloud Option

Perhaps the biggest limitation of Postman is the lack of a cloud option. With Newman, you can run it in your private cloud or internal data centers.

For one-off tests, this may not be the biggest issue, but when you want to integrate with CI/CD pipelines, this is additional infrastructure you will have to consider.

Load Testing with Postman

Whether you’ve made the decision to move forward with Postman load testing or just curious to see how it works, here’s an overview of what a simple load test in Postman can look like.

To showcase this functionality, you’ll be using the RandomUser API, which is a free API that can be used to get random test data.

Creating and Saving Requests to a Collection

First, you need to open up Postman and create a collection. Do this by clicking the + icon under the "Collections" tab.

Screenshot of the plus button

Now you can rename the collection to "Postman Load Test Tutorial" by clicking the pen to the right of the collection name.

Screenshot of the edit pen

Create a new HTTP Request by clicking the + button to the right of the Collection tab.

Screenshot of the plus button

Now enter the URL https://randomuser.me/api/?gender=female&nat=US and click "Send" to execute the request.

Screenshot of sending the request

At this point, you should see that the request executes properly, and you’re ready to save it to the collection. Do this by clicking "Save."

Screenshot of the save button

In the modal window that pops up, name the request "Female US," click on "Postman Load Test Tutorial" to select the collection, and, finally, click "Save."

Screenshot of save modal

Let’s quickly add another request to the collection. Do this by changing the "gender" parameter to "Male," clicking the arrow next to the "Save" button, then clicking on the "Save As…" button. After this, change the request name to "Male US" and click "Save."

Screenshot of the Save As button

Verifying Response

Verifying request responses in Postman is done by writing tests in JavaScript. To implement these tests, go to the "Tests" tab on the request and enter the following code snippet:

var data = JSON.parse(responseBody);
var user = data.results[0];
tests["A single user was returned"] = data.results.length ===1;

// Gender Tests
tests["Gender is male"] = user.gender ==="male"; 

// Nationality Tests
tests["The user is from the United States"] = user.nat === "US";

The above snippet verifies that one user was returned, that they’re male, and that they’re from the US. After sending the request again, you should see in the "Test Results" tab at the bottom that all tests are passing.

Screenshot of tests passing

Running a Collection

At this point, you have a collection with a few requests and tests added to at least one request. Now it’s time to implement the actual point of this post: load testing.

To execute requests from a collection, you will first have to open the collection in the Postman UI. Do this by double-clicking the collection in the left-hand menu.

Screenshot of collection view

With the collection view open, click the "Run" button in the upper right-hand corner.

Screenshot of run button

On the next page, you can choose a variety of options for your run, like what requests to include, how many iterations, and how it should be run. For this post, leave all options to default and click "Run Postman Load Test Tutorial."

Screenshot of collection run

Given the low number of requests, the run should finish quickly. You can now see how Postman presents you with a view of the requests, any results that might be present from test runs, as well as a few statistics.

Screenshot of run results

Configuring a Mock Server

To configure a mock server with Postman, you first need to add an example to the requests saved in a collection. To do this with the "Female US" request, select and execute it, making sure it shows a response.

Screenshot of request sent

Now that the response body is filled out, you can save the request as an example.

Screenshot showing the add example button

Now you can mock the collection by clicking on the kebab menu next to the collection name, then clicking "Mock collection."

Screenshot showing the mock collection menu button

Give the mock server a name and click "Create Mock Server."

Screenshot showing the mock server creation dialog

You should now see a screen from where you can copy the URL of the mock server.

Screenshot of mock server URL

Now you can send a request to <mock-server-url>/api and see how it responds with the example response you’ve just saved as an example.

Screenshot showing the mock server in action

You might notice that this response is being returned even though no parameters have been added. Postman uses a matching algorithm to determine which response is most suitable for a given request.

If you go back and add an example for the "Male US" request as well, you’ll notice that you are able to get different responses by changing the "gender" parameter. It is important to be aware of this, in case you’re expecting your mock to return an error code in case query parameters are misconfigured.

Mitigating Postman’s Limitations

As you can see, getting Postman set up to send requests sequentially is fairly straightforward. However, it’s important to keep the previously mentioned limitations in mind, the biggest limitation being how Postman isn’t capable of performing "true" load tests.

You can see this more clearly in practice by adding a pre-request script to the "Female US" request then rerunning the collection.

Screenshot of pre-request script

Because Postman is waiting for one request to succeed before moving on, you’re unlikely to push your service to its limits and properly stress-test it.

Because of this, it might be worth looking into what other load-testing tools are available. If you happen to be running your services in Kubernetes, it might be worth checking out how to load test with Speedscale.

Speedscale takes care of:

  • Recording production traffic
  • Replaying traffic
  • Automatically creating mocks
  • Generating many simultaneous requests
  • Easy CI/CD integration

These points, combined with a few more, let Speedscale push your services right to the edge, giving you confidence that your services will perform as expected in production.

How Will You Implement Load Testing?

At this point, you should have a much clearer idea of how you can approach API load testing. Whether you go with Postman or a tool like Speedscale is completely up to you and will depend heavily on your use case.

In any case, you now have the knowledge of how Postman load testing works and the ability to make an informed decision.

Play Around With Speedscale

speedscale traffic viewer

Speedscale allows you to quickly replay past traffic and increase confidence in your changes as part of CI.  Autogenerate mocks that represent 3rd parties and dependencies based on real traffic in seconds.

Speedscale is a traffic replay framework for API testing in Kubernetes.

About The Author