Response time benchmarking in Postman - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Response Time Assertion in Postman Test Script

Given the following Postman test script snippet, what will be the result of the assertion if the response time is 350 ms?

Postman

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

A Test throws a syntax error due to incorrect function syntax

B Test is skipped because responseTime is undefined

C Test fails because 350 is greater than 300

D Test passes because 350 is less than 300

💡 Hint

Check the comparison operator and the actual response time value.

The assertion checks if the response time is below 300 ms. Since 350 ms is greater than 300 ms, the test fails.

🧠 Conceptual

intermediate

Understanding Response Time Metrics in Postman

Which Postman property correctly represents the total time taken for the server to send the full response?

A pm.response.responseTime

B pm.response.responseCode

C pm.response.responseSize

D pm.response.responseHeaders

💡 Hint

Look for the property that measures time duration.

pm.response.responseTime gives the total time in milliseconds taken to receive the full response from the server.

🔧 Debug

advanced

Debugging a Failing Response Time Test in Postman

A Postman test script intended to check if response time is under 500 ms is failing with a ReferenceError: pm is not defined. What is the most likely cause?

Postman

test('Response time under 500ms', function () {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

A pm.response.responseTime is not a valid property in Postman

B Response time cannot be tested in Postman scripts

C The assertion syntax is incorrect; 'to.be.below' should be 'to.be.lessThan'

D The test script uses 'test' instead of 'pm.test', causing pm to be undefined

💡 Hint

Check the function used to define the test in Postman scripts.

In Postman scripts, tests must be defined using pm.test, not test. Using test causes pm to be undefined, leading to ReferenceError.

❓ framework

advanced

Best Practice for Benchmarking Response Time in Postman Collections

Which approach is best to benchmark average response time across multiple requests in a Postman collection?

A Use a collection-level pre-request script to start a timer and a test script to calculate and store each request's response time, then compute average after all requests

B Manually check each request's response time in the Postman console and calculate average externally

C Add a fixed delay in each request to simulate response time and compare delays

D Use pm.response.responseSize to estimate response time indirectly

💡 Hint

Think about automating timing and aggregation within Postman scripts.

Using collection-level scripts to track and store response times for each request allows automated calculation of average response time within Postman.

❓ assertion

expert

Complex Assertion for Response Time with Conditional Logging

In a Postman test script, which option correctly asserts that response time is below 400 ms and logs a warning if it is between 300 ms and 400 ms?

A

pm.test('Response time check', () => {
  const time = pm.response.responseTime;
  pm.expect(time).to.be.below(400);
  if (time > 300 && time <= 400) {
    console.warn('Warning: Response time is high but acceptable');
  }
});

B

pm.test('Response time check', () => {
  const time = pm.response.responseTime;
  pm.expect(time).to.be.below(400);
  if (time >= 300 && time < 400) {
    console.warn('Warning: Response time is high but acceptable');
  }
});

C

pm.test('Response time check', () => {
  const time = pm.response.responseTime;
  pm.expect(time).to.be.below(400);
  if (time > 300 && time < 400) {
    console.error('Warning: Response time is high but acceptable');
  }
});

D

pm.test('Response time check', () => {
  const time = pm.response.responseTime;
  pm.expect(time).to.be.below(300);
  if (time > 300 && time < 400) {
    console.warn('Warning: Response time is high but acceptable');
  }
});

💡 Hint

Check the assertion boundary and the logging method used for warnings.

Option B correctly asserts response time below 400 ms and logs a warning if time is between 300 (inclusive) and 400 (exclusive) ms using console.warn, which is appropriate for warnings.

Practice

1. What does pm.response.responseTime measure in Postman?

easy

A. The time taken by the server to respond to a request

B. The size of the response body

C. The number of requests sent

D. The status code of the response

Solution

1. Step 1: Understand the purpose of pm.response.responseTime

   This property records how long the server takes to send back a response after a request is made.

2. Step 2: Differentiate from other response properties

   It does not measure response size, count requests, or check status codes; it only measures response speed.

3. Final Answer:

   The time taken by the server to respond to a request -> Option A

4. Quick Check:

   Response time = server speed [OK]

Hint: Response time means how fast server replies [OK]

Common Mistakes:

• Confusing response time with response size
• Thinking it counts requests instead of timing
• Mixing it up with status code checks

2. Which of the following is the correct way to assert that response time is less than 500 milliseconds in Postman test script?

easy

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

B. pm.test('Response time is less than 500ms', () => pm.response.responseTime < 500);

C. pm.test('Response time is less than 500ms', () => pm.response.responseTime > 500);

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

Solution

1. Step 1: Identify correct assertion syntax in Postman

   Postman uses Chai assertion library syntax: pm.expect(value).to.be.below(limit) to check if value is less than limit.

2. Step 2: Check each option's logic and syntax

   pm.test('Response time is less than 500ms', () => pm.expect(pm.response.responseTime).to.be.below(500)); correctly uses pm.expect(pm.response.responseTime).to.be.below(500). pm.test('Response time is less than 500ms', () => pm.response.responseTime < 500); lacks assertion method. The version checking greater than 500 reverses the logic, and the version checking equality to 500 uses the wrong matcher.

3. Final Answer:

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

4. Quick Check:

   Use pm.expect(...).to.be.below(...) for less than checks [OK]

Hint: Use pm.expect(...).to.be.below(value) for less than checks [OK]

Common Mistakes:

• Using comparison operators without pm.expect
• Checking for equality instead of less than
• Reversing comparison logic

3. Given this Postman test script snippet:

pm.test('Check response time', () => {
  pm.expect(pm.response.responseTime).to.be.below(300);
});

If the actual response time is 350 ms, what will be the test result?

medium

A. Test fails because 350 is not below 300

B. Test passes because 350 is below 300

C. Test passes because response time is ignored

D. Test throws a syntax error

Solution

1. Step 1: Understand the assertion condition

   The test expects response time to be less than 300 ms using to.be.below(300).

2. Step 2: Compare actual response time with expected limit

   The actual response time is 350 ms, which is greater than 300 ms, so the assertion fails.

3. Final Answer:

   Test fails because 350 is not below 300 -> Option A

4. Quick Check:

   350 > 300 means assertion fails [OK]

Hint: If actual > limit, test fails for 'to.be.below' [OK]

Common Mistakes:

• Thinking 350 is less than 300
• Assuming test passes without checking values
• Confusing syntax error with assertion failure

4. You wrote this Postman test to check response time:

pm.test('Response time under 200ms', () => {
  pm.expect(pm.response.responseTime).below(200);
});

But the test always passes even when response time is 500 ms. What is the error?

medium

A. Response time property is misspelled

B. Using pm.expect incorrectly without parentheses

C. Missing to.be before below(200)

D. Test name is incorrect

Solution

1. Step 1: Check assertion syntax correctness

   The correct Chai syntax requires chaining to.be.below(200). The code uses pm.expect(...).below(200) missing to.be.

2. Step 2: Understand effect of missing chain

   Without to.be, the assertion does not execute properly and silently passes, ignoring the actual response time.

3. Final Answer:

   Missing to.be before below(200) -> Option C

4. Quick Check:

   Use full chain pm.expect(...).to.be.below(...) [OK]

Hint: Always use pm.expect(...).to.be.below(...) chain [OK]

Common Mistakes:

• Omitting 'to.be' in assertion chain
• Misspelling responseTime property
• Ignoring test failure due to syntax

5. You want to benchmark response times for multiple API endpoints in Postman and fail the test if any response time exceeds 400 ms. Which approach is best?

hard

A. Write a test script in each request using pm.expect(pm.response.responseTime).to.be.below(400)

B. Use a collection-level test script that checks pm.response.responseTime after each request

C. Manually check response times in Postman console after running all requests

D. Set a global variable with response time and compare after all requests finish

Solution

1. Step 1: Understand scope of test scripts in Postman

   Collection-level scripts run after every request in the collection, allowing centralized checks for all endpoints.

2. Step 2: Compare options for efficiency and automation

   Use a collection-level test script that checks pm.response.responseTime after each request automates response time checks for all requests without repeating code. Writing a test script in each request using pm.expect(pm.response.responseTime).to.be.below(400) duplicates code, manually checking response times in Postman console after running all requests is error-prone, and setting a global variable with response time and comparing after all requests finish complicates logic unnecessarily.

3. Final Answer:

   Use a collection-level test script that checks pm.response.responseTime after each request -> Option B

4. Quick Check:

   Collection-level scripts automate checks for all requests [OK]

Hint: Use collection-level tests to check all response times automatically [OK]

Common Mistakes:

• Repeating same test in every request script
• Relying on manual checking instead of automation
• Overcomplicating with global variables