Monitor results analysis in Postman - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to check if the monitor run was successful.

Postman

pm.test('Monitor run status is successful', function () {
    pm.expect(pm.response.code).to.equal([1]);
});

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

A200

B404

C500

D301

Attempts:

3 left

💡 Hint

Common Mistakes

Using 404 or 500 which indicate errors instead of success.

Checking for redirect codes like 301 which are not success for this test.

The HTTP status code 200 means the request was successful, so the test checks for this code.

2fill in blank

medium

Complete the code to assert the response time is less than 500 milliseconds.

Postman

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

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

Abelow

Babove

ClessThan

DgreaterThan

Attempts:

3 left

💡 Hint

Common Mistakes

Using above or greaterThan which check the opposite.

Using below which is not a valid Chai assertion method.

The method lessThan checks if the response time is less than the given value.

3fill in blank

hard

Fix the error in the assertion to check if the JSON response has a 'success' property set to true.

Postman

pm.test('Response has success property true', function () {
    pm.expect(pm.response.json().[1]).to.eql(true);
});

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

Asuccess

Bstatus

Cresult

Dmessage

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'status' or 'result' which may not be boolean true.

Using 'message' which is usually a string, not a boolean.

The JSON response should have a property named success that is true for this test.

4fill in blank

hard

Fill both blanks to create a test that checks if the response body contains the word 'monitor' and the status code is 200.

Postman

pm.test('Response contains monitor and status is 200', function () {
    pm.expect(pm.response.text().[1]('monitor')).to.be.[2];
    pm.expect(pm.response.code).to.equal(200);
});

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

Aincludes

Btrue

Cfalse

DindexOf

Attempts:

3 left

💡 Hint

Common Mistakes

Using indexOf without comparing to -1.

Expecting false instead of true.

The includes method returns true if the string contains the substring. The test expects this to be true.

5fill in blank

hard

Fill all three blanks to write a test that checks if the JSON response has a 'data' object, the 'id' inside 'data' is greater than 0, and the status code is 200.

Postman

pm.test('Data object and valid id present', function () {
    const jsonData = pm.response.json();
    pm.expect(jsonData.[1]).to.be.an('object');
    pm.expect(jsonData.data.[2]).to.be.[3](0);
    pm.expect(pm.response.code).to.equal(200);
});

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

Adata

Bid

Cabove

Dlength

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'length' instead of 'above' for numeric comparison.

Checking wrong property names or types.

The test checks that jsonData.data is an object, jsonData.data.id is greater than 0 using above, and the status code is 200.

Practice

1. What is the main purpose of analyzing Postman monitor results?

easy

A. To create user interface designs

B. To write new API requests

C. To track API health and detect failures over time

D. To deploy applications to servers

Solution

1. Step 1: Understand monitor results role

   Monitor results show how API tests perform over time, highlighting issues.

2. Step 2: Identify main goal of analysis

   Analyzing results helps track API health and find failures quickly.

3. Final Answer:

   To track API health and detect failures over time -> Option C

4. Quick Check:

   Monitor results = API health tracking [OK]

Hint: Monitor results show API health trends over time [OK]

Common Mistakes:

• Confusing monitor results with request creation
• Thinking monitor results are for UI design
• Assuming monitor results deploy apps

2. Which filter option in Postman Monitor results helps you quickly find failed test runs?

easy

A. Sort by request name

B. Sort by creation date

C. Filter by response time

D. Filter by status: Failed

Solution

1. Step 1: Identify filter purpose

   Filtering by status narrows results to specific outcomes like failures.

2. Step 2: Choose filter to find failures

   Filtering by status: Failed shows only failed test runs quickly.

3. Final Answer:

   Filter by status: Failed -> Option D

4. Quick Check:

   Status filter = find failures fast [OK]

Hint: Use status filter to isolate failures fast [OK]

Common Mistakes:

• Sorting by request name does not isolate failures
• Filtering by response time shows speed, not failures
• Sorting by creation date orders runs but doesn't filter failures

3. Given this Postman monitor result snippet:

{"runId":123, "status":"failed", "tests": {"responseCodeCheck": false, "bodyCheck": true}}

Which test failed in this run?

medium

A. bodyCheck

B. responseCodeCheck

C. Both tests passed

D. No tests were run

Solution

1. Step 1: Read test results in JSON

   The tests object shows responseCodeCheck: false and bodyCheck: true.

2. Step 2: Interpret boolean test results

   false means test failed, true means test passed.

3. Final Answer:

   responseCodeCheck -> Option B

4. Quick Check:

   False test = failure [OK]

Hint: False test result means failure [OK]

Common Mistakes:

• Assuming true means failure
• Ignoring test result booleans
• Confusing test names

4. You notice your Postman monitor shows all runs as "passed" but your API is down. What is the most likely cause?

medium

A. Test scripts do not check API response status codes

B. Monitor is not scheduled to run

C. API is running but returning errors

D. Monitor results are delayed by 24 hours

Solution

1. Step 1: Analyze monitor showing all passes

   If monitor shows all passes but API is down, tests likely miss failure detection.

2. Step 2: Identify missing test checks

   Not checking response status codes means failures go unnoticed.

3. Final Answer:

   Test scripts do not check API response status codes -> Option A

4. Quick Check:

   Missing status checks = false passes [OK]

Hint: Check if tests verify response status codes [OK]

Common Mistakes:

• Assuming monitor is not running without checking
• Thinking API is up despite errors
• Believing monitor results delay causes issue

5. You want to create a Postman monitor report that highlights only failed tests with response times over 2 seconds. Which approach best achieves this?

hard

A. Filter monitor results by status: Failed and response time > 2000ms

B. Sort monitor results by response time ascending

C. Filter monitor results by status: Passed only

D. Export results and manually check response times

Solution

1. Step 1: Understand filtering needs

   You want to see only failed tests with slow response times.

2. Step 2: Apply combined filters

   Filtering by status: Failed and response time > 2000ms shows exactly those runs.

3. Final Answer:

   Filter monitor results by status: Failed and response time > 2000ms -> Option A

4. Quick Check:

   Combined filters = precise failure + slow tests [OK]

Hint: Use combined filters for precise monitor analysis [OK]

Common Mistakes:

• Sorting alone does not filter failures
• Filtering by passed misses failures
• Manual checks waste time and risk errors