Why Postman supports non-functional testing - Test Execution Impact

Test Overview

This test checks if Postman can perform non-functional testing by measuring response time and validating server performance under load.

Test Code - Python requests with assertions (simulating Postman test)

Postman

import requests
import time

def test_response_time():
    url = "https://api.example.com/data"
    start_time = time.time()
    response = requests.get(url)
    end_time = time.time()
    response_time = end_time - start_time
    assert response.status_code == 200, f"Expected status 200 but got {response.status_code}"
    assert response_time < 0.5, f"Response time too high: {response_time}s"

if __name__ == "__main__":
    test_response_time()

Execution Trace - 5 Steps

Step	Action	System State	Assertion	Result
1	Test starts	Test environment ready, network available	—	PASS
2	Send GET request to https://api.example.com/data	Request sent, waiting for response	—	PASS
3	Receive response with status code 200	Response received with data payload	Check if status code == 200	PASS
4	Measure response time	Response time calculated as 0.3 seconds	Verify response time < 0.5 seconds	PASS
5	Test ends with all assertions passed	Test completed successfully	—	PASS

Failure Scenario

Failing Condition: Response time exceeds 0.5 seconds or status code is not 200

Execution Trace Quiz - 3 Questions

What does the test verify about the API response?

A Only response content correctness

B Response status code and response time

C Database connection status

D User interface layout

Key Result

Non-functional testing in Postman includes checking API performance metrics like response time, which helps ensure the API meets speed and reliability expectations.

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