Why Postman supports non-functional testing - Framework Benefits

Framework Mode - Why Postman supports non-functional testing

Folder Structure

Postman Collection Project/
├── collections/
│   ├── api_endpoints.postman_collection.json
│   └── performance_tests.postman_collection.json
├── environments/
│   ├── dev_environment.postman_environment.json
│   └── prod_environment.postman_environment.json
├── scripts/
│   ├── pre_request_scripts.js
│   └── test_scripts.js
├── reports/
│   └── test_run_reports/
│       ├── functional_report.html
│       └── performance_report.html
└── postman_config.json

Test Framework Layers

• Collections: Group API requests logically, including functional and non-functional tests.
• Environments: Manage variables for different setups like dev, test, and production.
• Scripts: Use pre-request and test scripts to set up data and validate responses.
• Reports: Store test run results, including performance and load testing reports.
• Configuration: Define global settings such as base URLs, authentication, and test parameters.

Configuration Patterns

• Environment Variables: Use environment files to switch between servers and credentials easily.
• Global Variables: Store reusable data like tokens or common headers.
• Collection Variables: Define variables specific to a collection for scoped testing.
• Data Files: Use CSV or JSON files to run data-driven tests for load or stress scenarios.
• Postman Settings: Configure request timeouts and retries to simulate non-functional conditions.

Test Reporting and CI/CD Integration

• Newman CLI: Run Postman collections from command line and generate JSON, HTML, or JUnit reports.
• CI/CD Pipelines: Integrate Newman runs in Jenkins, GitHub Actions, or GitLab to automate tests on code changes.
• Performance Metrics: Capture response times and error rates in reports to analyze non-functional behavior.
• Alerts: Configure notifications on test failures or performance degradation.

Best Practices

• Separate Functional and Non-Functional Tests: Organize collections to clearly distinguish test types.
• Use Environment Variables: Avoid hardcoding URLs or credentials to enable flexible testing.
• Leverage Data-Driven Testing: Use data files to simulate multiple users or load scenarios.
• Automate with Newman: Run tests automatically in CI/CD for continuous feedback.
• Monitor Performance Metrics: Track response times and failures to detect issues early.

Self-Check Question

Where in this Postman project structure would you add a new collection for stress testing the API?

Key Result

Postman supports non-functional testing by organizing collections, environments, and scripts to simulate load, measure performance, and integrate automated reporting.

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