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.
Postman’s load testing features
As a tool to test APIs, Postman 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. Postman Collections, in particular, 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. While this test scenario is still valid and useful, the team at Postman realized that many users were interested in a different use case: Postman performance testing. Because of this, some key features have been introduced, 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 the Postman Collection Runner, which allows you to run requests from a Collection in a specified order.
Creating Mock Servers
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 and one of those microservices is the
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.
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 using Postman for load testing
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 insufficient stress tests, 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 load test scenario 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.
How to load test using 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, open source API that can be used to get random test data.
1. Create and save 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.
Now you can rename the collection to “Postman Load Test Tutorial” by clicking the pen to the right of the collection name.
Create a new HTTP Request by clicking the
+ button to the right of the Collection tab.
Now enter the URL
https://randomuser.me/api/?gender=female&nat=US and click “Send” to execute 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.”
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.”
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.”
2. Verifying Response
var data = JSON.parse(responseBody); var user = data.results; 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.
3. Use the Postman Collection Runner to Run 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.
With the collection view open, click the “Run” button in the upper right-hand corner.
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.”
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, along with results and statistics, like duration and average response times.
4. Configure 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.
Now that the response body is filled out, you can save the request as an example.
Now you can mock the collection by clicking on the kebab menu next to the collection name, then clicking “Mock collection.”
Give the mock server a name and click “Create Mock Server.”
You should now see a screen from where you can copy the URL of the mock server.
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.
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.
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.
Jeff Kwan, Principal Software Engineer, Cimpress
Load testing with Speedscale
Due to this limitation, it might be worth looking into what other testing tools are available. If you run 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 key features in Speedscale allow you to push your services right to the edge, giving you confidence that your services will perform as expected in production. One Speedscale customer, Cimpress, not only got better insight, but reduced their load testing time from 4 weeks to 4 days.