Why Postman supports non-functional testing - Automation Benefits in Action

Verify API response time and status code using Postman

Preconditions (2)

Step 1: Open Postman and create a new GET request

Step 2: Enter the API endpoint URL in the request URL field

Step 3: Click the Send button to send the request

Step 4: Observe the response status code and response time displayed in Postman

✅ Expected Result: The response status code should be 200 OK and the response time should be less than 2000 milliseconds

Automation Requirements - Postman Test Scripts (JavaScript)

Assertions Needed:

Verify response status code is 200

Verify response time is less than 2000 ms

Best Practices:

Use pm.response.to.have.status() for status code assertion

Use pm.response.responseTime to check response time

Write clear and simple test scripts inside the Tests tab

Avoid hardcoding values; use environment variables if needed

Automated Solution

Postman

pm.test('Status code is 200', () => {
    pm.response.to.have.status(200);
});

pm.test('Response time is less than 2000ms', () => {
    pm.expect(pm.response.responseTime).to.be.below(2000);
});

The first test checks if the API response status code is exactly 200, which means the request was successful.

The second test checks if the response time is less than 2000 milliseconds, ensuring the API is fast enough.

Both tests use Postman's built-in pm object and assertion methods for clarity and reliability.

Common Mistakes - 3 Pitfalls

Not checking the response time in tests

Hardcoding API URLs and values directly in test scripts

Using incorrect assertion syntax like pm.response.status instead of pm.response.to.have.status()

Bonus Challenge

Now add tests to verify the API response contains a specific JSON field with expected value for 3 different endpoints

Show Hint

Practice

1. Why does Postman support non-functional testing like checking API speed and stability?

easy

A. To write complex backend code

B. To only test the API's user interface design

C. To replace functional testing completely

D. To ensure APIs work well under different conditions and meet quality standards

Solution

1. Step 1: Understand non-functional testing purpose

   Non-functional testing checks qualities like speed, stability, and security, not just if the API works.

2. Step 2: Relate to Postman's role

   Postman helps test these qualities to ensure APIs perform well and are reliable before users use them.

3. Final Answer:

   To ensure APIs work well under different conditions and meet quality standards -> Option D

4. Quick Check:

   Non-functional testing = Quality checks [OK]

Hint: Non-functional means quality, not just function [OK]

Common Mistakes:

• Confusing non-functional with functional testing
• Thinking Postman only tests UI
• Believing Postman replaces all testing

2. Which JavaScript code snippet correctly measures API response time in Postman tests?

easy

A. pm.test('Response time is less than 200ms', () => pm.expect(pm.response.responseTime).to.be.below(200));

B. pm.test('Response time check', () => pm.response.responseTime < 200);

C. pm.expect(pm.response.time).to.be.above(200);

D. pm.test('Check time', () => pm.responseTime < 200);

Solution

1. Step 1: Identify correct Postman test syntax

   Postman tests use pm.test with a description and a function containing assertions using pm.expect.

2. Step 2: Check property and assertion correctness

   The correct property for response time is pm.response.responseTime, and to check below 200ms use .to.be.below(200).

3. Final Answer:

   pm.test('Response time is less than 200ms', () => pm.expect(pm.response.responseTime).to.be.below(200)); -> Option A

4. Quick Check:

   Correct syntax + property = pm.test('Response time is less than 200ms', () => pm.expect(pm.response.responseTime).to.be.below(200)); [OK]

Hint: Use pm.test with pm.expect and correct property [OK]

Common Mistakes:

• Using wrong property names like pm.response.time
• Missing pm.test wrapper
• Incorrect assertion methods

3. Given this Postman test code, what will be the test result if responseTime is 150ms?

pm.test('API is fast', () => {
  pm.expect(pm.response.responseTime).to.be.below(200);
});

medium

A. Test fails because 150ms is not below 200ms

B. Test throws an error due to syntax

C. Test passes because 150ms is below 200ms

D. Test is skipped automatically

Solution

1. Step 1: Understand the assertion condition

   The test checks if responseTime is below 200ms using .to.be.below(200).

2. Step 2: Compare given responseTime value

   150ms is less than 200ms, so the condition is true and the test passes.

3. Final Answer:

   Test passes because 150ms is below 200ms -> Option C

4. Quick Check:

   150 < 200 = Pass [OK]

Hint: Check if value meets condition literally [OK]

Common Mistakes:

• Misreading 'below' as 'above'
• Assuming syntax error without checking code
• Thinking test skips automatically

4. Identify the error in this Postman test code for checking API security headers:

pm.test('Security headers present', () => {
  pm.expect(pm.response.headers.has('Content-Security-Policy')).to.equal(true
});

medium

A. Missing closing parenthesis in pm.expect statement

B. Incorrect header name used

C. pm.response.headers.has is not a function

D. pm.test requires a callback function

Solution

1. Step 1: Check syntax of pm.expect statement

   The pm.expect call is missing a closing parenthesis after .to.equal(true).

2. Step 2: Verify other parts

   Header name and pm.response.headers.has function are correct, and pm.test has a callback function.

3. Final Answer:

   Missing closing parenthesis in pm.expect statement -> Option A

4. Quick Check:

   Syntax error = Missing parenthesis [OK]

Hint: Count parentheses carefully in assertions [OK]

Common Mistakes:

• Assuming wrong header name
• Thinking pm.response.headers.has doesn't exist
• Ignoring missing parenthesis

5. You want to use Postman to check API stability by running a test multiple times and measuring if response times stay below 300ms consistently. Which approach best fits this non-functional testing goal?

hard

A. Manually send one request and check response time once

B. Use Postman Collection Runner to run the test repeatedly and write a test script to assert responseTime < 300ms each time

C. Write a test that only checks if status code is 200

D. Use Postman to test only API functionality, not response times

Solution

1. Step 1: Understand stability testing requirements

   Stability means consistent performance over multiple runs, so repeated tests are needed.

2. Step 2: Choose Postman feature and test script

   Collection Runner allows running tests multiple times; writing a script to check responseTime < 300ms each time fits the goal.

3. Final Answer:

   Use Postman Collection Runner to run the test repeatedly and write a test script to assert responseTime < 300ms each time -> Option B

4. Quick Check:

   Repeated tests + response time check = Use Postman Collection Runner to run the test repeatedly and write a test script to assert responseTime < 300ms each time [OK]

Hint: Use Collection Runner for repeated tests [OK]

Common Mistakes:

• Testing only once for stability
• Ignoring response time in tests
• Confusing functional with non-functional testing