Why Postman supports non-functional testing - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to set a timeout for a Postman request.

Postman

pm.test('Response time is acceptable', function () {
    pm.expect(pm.response.responseTime).to.be.below([1]);
});

Drag options to blanks, or click blank then click option'

A'2000ms'

B2000

Ctimeout

DresponseTime

Attempts:

3 left

💡 Hint

Common Mistakes

Using a string with units like '2000ms' instead of a number.

Using variable names instead of a numeric value.

The responseTime is a number in milliseconds, so we compare it to a number like 2000 (2 seconds).

2fill in blank

medium

Complete the code to check if the response size is less than a limit.

Postman

pm.test('Response size is within limit', function () {
    pm.expect(pm.response.responseSize.[1]).to.be.below(5000);
});

Drag options to blanks, or click blank then click option'

Asize

Blength

Clength()

Dlengths

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'length()' instead of 'size'.

Using 'size' on wrong object.

The responseSize property returns an object, so we use size to get the total size in bytes.

3fill in blank

hard

Fix the error in the code that checks if the response time is less than 1000 ms.

Postman

pm.test('Response time check', function () {
    pm.expect(pm.response.responseTime [1] 1000).to.be.true;
});

Drag options to blanks, or click blank then click option'

A<

B==

C>

D=

Attempts:

3 left

💡 Hint

Common Mistakes

Using assignment operator '=' instead of comparison.

Using equality '==' which checks exact match.

To check if response time is less than 1000, use the less than operator <.

4fill in blank

hard

Fill both blanks to check if the response status is 200 and response time is below 1500 ms.

Postman

pm.test('Status and performance check', function () {
    pm.expect(pm.response.code).to.be.[1](200);
    pm.expect(pm.response.responseTime).to.be.[2](1500);
});

Drag options to blanks, or click blank then click option'

Aequal

Bbelow

Cabove

DnotEqual

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'above' for response time when we want below.

Using 'notEqual' for status code when expecting 200.

Use equal to check status code equals 200, and below to check response time is less than 1500.

5fill in blank

hard

Fill all three blanks to create a test that checks response time below 1000, status code 200, and response body contains 'success'.

Postman

pm.test('Complete non-functional test', function () {
    pm.expect(pm.response.responseTime).to.be.[1](1000);
    pm.expect(pm.response.code).to.[2](200);
    pm.expect(pm.response.text()).to.include('[3]');
});

Drag options to blanks, or click blank then click option'

Abelow

Bequal

Csuccess

DnotEqual

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'notEqual' instead of 'equal' for status code.

Checking response time with 'above' instead of 'below'.

Missing quotes around the string 'success'.

We check response time is below 1000, status code equals 200, and response text includes 'success'.

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