Bird
Raised Fist0
Postmantesting~8 mins

Response time in Postman - Framework Patterns

Choose your learning style10 modes available
Framework Mode - Response time
Folder Structure
postman-project/
├── collections/
│   └── api-tests.postman_collection.json
├── environments/
│   ├── dev.postman_environment.json
│   ├── staging.postman_environment.json
│   └── prod.postman_environment.json
├── tests/
│   └── response-time-tests.js
├── reports/
│   └── response-time-report.html
├── scripts/
│   └── test-scripts.js
└── postman.config.json
    
Test Framework Layers
  • Collections: Group of API requests organized by feature or endpoint.
  • Environments: Variables for different setups like dev, staging, prod.
  • Tests: Scripts that check response time and other API behaviors.
  • Scripts: Reusable JavaScript functions for assertions and helpers.
  • Reports: Generated test run reports showing pass/fail and response times.
  • Config: Settings for Postman CLI or Newman runs, including environment selection.
Configuration Patterns
  • Environment Files: Store base URLs, API keys, and thresholds for response time per environment.
  • Global Variables: Define max acceptable response time (e.g., 500 ms) to reuse in tests.
  • Postman Config: Use postman.config.json to set default environment and collection paths for automation.
  • Newman CLI: Pass environment and collection files as parameters for CI/CD integration.
Test Reporting and CI/CD Integration
  • Use Newman to run Postman collections from command line.
  • Generate HTML or JSON reports showing response times and assertion results.
  • Integrate Newman runs into CI/CD pipelines (Jenkins, GitHub Actions) to automate tests on each build.
  • Fail builds if response time exceeds defined threshold.
  • Use reports to track performance trends over time.
Best Practices
  1. Set clear response time thresholds based on realistic user expectations.
  2. Use environment variables to easily adjust thresholds per environment.
  3. Write assertions in test scripts to fail tests if response time is too high.
  4. Keep test scripts simple and reusable by extracting common logic into helper scripts.
  5. Run response time tests regularly in CI/CD to catch performance regressions early.
Self Check

Where would you add a new test script that checks if the API response time is under 300 ms?

Key Result
Organize Postman tests with collections, environments, and scripts to measure and assert API response times effectively.

Practice

(1/5)
1. What does pm.response.responseTime represent in Postman?
easy
A. The time taken by the server to respond to a request
B. The size of the response body in bytes
C. The HTTP status code of the response
D. The number of requests sent in a collection

Solution

  1. Step 1: Understand the meaning of response time

    Response time measures how fast a system replies to a request.
  2. Step 2: Identify what pm.response.responseTime returns

    In Postman, pm.response.responseTime gives the time in milliseconds the server took to respond.
  3. Final Answer:

    The time taken by the server to respond to a request -> Option A
  4. Quick Check:

    Response time = server reply speed [OK]
Hint: Remember responseTime measures speed, not size or status [OK]
Common Mistakes:
  • Confusing response time with response size
  • Thinking it returns HTTP status code
  • Assuming it counts number of requests
2. Which of the following is the correct syntax to assert that response time is less than 500ms in Postman test script?
easy
A. pm.test('Response time is less than 500ms', () => pm.response.responseTime < 500);
B. pm.test('Response time is less than 500ms', () => pm.expect(pm.response.responseTime).to.equal(500));
C. pm.test('Response time is less than 500ms', () => pm.expect(pm.response.responseTime).to.be.below(500));
D. pm.test('Response time is less than 500ms', () => pm.response.responseTime > 500);

Solution

  1. Step 1: Recall Postman assertion syntax

    Postman uses pm.test with a callback and pm.expect for assertions.
  2. Step 2: Check correct assertion for less than 500ms

    The correct way to check if response time is below 500 is pm.expect(pm.response.responseTime).to.be.below(500).
  3. Final Answer:

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

    Use pm.expect(...).to.be.below(value) for less than [OK]
Hint: Use pm.expect(...).to.be.below(value) for less than checks [OK]
Common Mistakes:
  • Using direct comparison without pm.expect
  • Using > instead of < for less than
  • Using to.equal instead of to.be.below
3. Consider 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 350ms, what will be the test result?
medium
A. Test will pass because 350 is below 300
B. Test will be skipped automatically
C. Test will error due to syntax mistake
D. Test will fail because 350 is not below 300

Solution

  1. Step 1: Understand the assertion condition

    The test expects response time to be below 300ms.
  2. Step 2: Compare actual response time with condition

    Actual response time is 350ms, which is greater than 300ms, so the condition fails.
  3. Final Answer:

    Test will fail because 350 is not below 300 -> Option D
  4. Quick Check:

    350 > 300 means test fails [OK]
Hint: Compare actual value with assertion condition carefully [OK]
Common Mistakes:
  • Assuming test passes if value is greater
  • Confusing below with above
  • Thinking syntax error causes failure
4. You wrote this Postman test:
pm.test('Response time test', () => {
  pm.expect(pm.response.responseTime).to.be.lessThan(400);
});

But the test always errors out. What is the likely problem?
medium
A. You should use pm.response.time instead of pm.response.responseTime
B. The method lessThan is not valid in Postman assertions
C. The test needs to be inside a pm.response.to block
D. The response time cannot be tested in Postman

Solution

  1. Step 1: Check Postman assertion methods

    Postman uses Chai assertion library where the correct method is below, not lessThan.
  2. Step 2: Identify the invalid method causing error

    Using lessThan causes a syntax error because it is not recognized.
  3. Final Answer:

    The method lessThan is not valid in Postman assertions -> Option B
  4. Quick Check:

    Use .to.be.below() not .lessThan() [OK]
Hint: Use .to.be.below() for less than, not .lessThan() [OK]
Common Mistakes:
  • Using unsupported assertion methods
  • Confusing property names for response time
  • Thinking response time tests are unsupported
5. You want to fail a Postman test if the response time is more than 200ms but allow up to 300ms with a warning message. Which test script correctly implements this?
hard
A. pm.test('Response time check', () => { if(pm.response.responseTime > 300) { pm.expect.fail('Response time too high'); } else if(pm.response.responseTime > 200) { console.warn('Warning: Response time above 200ms'); } else { pm.expect(pm.response.responseTime).to.be.below(201); } });
B. pm.test('Response time check', () => { pm.expect(pm.response.responseTime).to.be.below(200); if(pm.response.responseTime > 300) { console.warn('Warning: Response time above 300ms'); } });
C. pm.test('Response time check', () => { if(pm.response.responseTime > 200) { pm.expect.fail('Response time too high'); } else { pm.expect(pm.response.responseTime).to.be.below(300); } });
D. pm.test('Response time check', () => { pm.expect(pm.response.responseTime).to.be.below(300); if(pm.response.responseTime > 200) { pm.expect.fail('Response time warning'); } });

Solution

  1. Step 1: Understand the requirement

    Fail test if response time > 300ms, warn if > 200ms but ≤ 300ms, pass otherwise.
  2. Step 2: Analyze each option logic

    pm.test('Response time check', () => { if(pm.response.responseTime > 300) { pm.expect.fail('Response time too high'); } else if(pm.response.responseTime > 200) { console.warn('Warning: Response time above 200ms'); } else { pm.expect(pm.response.responseTime).to.be.below(201); } }); correctly fails if > 300, warns if between 201 and 300, and passes if ≤ 200. Others either fail incorrectly or misuse warnings.
  3. Final Answer:

    pm.test('Response time check', () => { if(pm.response.responseTime > 300) { pm.expect.fail('Response time too high'); } else if(pm.response.responseTime > 200) { console.warn('Warning: Response time above 200ms'); } else { pm.expect(pm.response.responseTime).to.be.below(201); } }); -> Option A
  4. Quick Check:

    Fail above 300, warn above 200, else pass [OK]
Hint: Use if-else to separate fail, warn, and pass conditions [OK]
Common Mistakes:
  • Failing test on warning condition
  • Using console.warn without fail for errors
  • Incorrect order of conditions causing wrong results
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard