Bird
Raised Fist0
Testing Fundamentalstesting~15 mins

Performance test reporting in Testing Fundamentals - Build an Automation Script

Choose your learning style10 modes available
Generate and verify performance test report after load test
Preconditions (3)
Step 1: Run the load test script with 100 virtual users for 5 minutes
Step 2: Wait for the test to complete
Step 3: Generate the performance test report in HTML format
Step 4: Open the generated report
Step 5: Verify the report contains average response time, throughput, error rate, and test duration
Step 6: Check that the report summary shows no errors above 1%
✅ Expected Result: Performance test report is generated successfully and contains all key metrics with error rate below 1%
Automation Requirements - Python with Locust and pytest
Assertions Needed:
Report file exists after test run
Report contains average response time metric
Report contains throughput metric
Report contains error rate metric
Error rate is below 1%
Best Practices:
Use explicit waits for test completion
Use file existence checks for report generation
Parse report content to verify metrics
Use pytest assertions for validation
Keep test modular and readable
Automated Solution
Testing Fundamentals
import os
import time
import pytest

REPORT_PATH = 'performance_report.html'

# Simulate running load test and generating report
# In real scenario, this would trigger Locust or other tool

def run_load_test():
    # Simulate test duration
    time.sleep(5)  # wait 5 seconds to simulate test
    # Simulate report generation
    with open(REPORT_PATH, 'w') as f:
        f.write('<html><body>')
        f.write('<h1>Performance Test Report</h1>')
        f.write('<p>Average Response Time: 200ms</p>')
        f.write('<p>Throughput: 50 requests/sec</p>')
        f.write('<p>Error Rate: 0.5%</p>')
        f.write('<p>Test Duration: 5 minutes</p>')
        f.write('</body></html>')


def test_performance_report_generation():
    # Run the load test simulation
    run_load_test()

    # Wait for report file to exist (explicit wait)
    timeout = 10
    poll_interval = 1
    waited = 0
    while not os.path.exists(REPORT_PATH) and waited < timeout:
        time.sleep(poll_interval)
        waited += poll_interval

    # Assert report file exists
    assert os.path.exists(REPORT_PATH), 'Report file was not generated'

    # Read report content
    with open(REPORT_PATH, 'r') as f:
        content = f.read()

    # Assert key metrics present
    assert 'Average Response Time' in content, 'Average Response Time metric missing'
    assert 'Throughput' in content, 'Throughput metric missing'
    assert 'Error Rate' in content, 'Error Rate metric missing'
    assert 'Test Duration' in content, 'Test Duration metric missing'

    # Extract error rate value
    import re
    match = re.search(r'Error Rate: ([0-9.]+)%', content)
    assert match is not None, 'Error Rate value not found'
    error_rate = float(match.group(1))

    # Assert error rate below 1%
    assert error_rate < 1.0, f'Error rate too high: {error_rate}%'

    # Cleanup
    os.remove(REPORT_PATH)

This test script simulates running a performance load test and generating an HTML report.

The run_load_test() function waits 5 seconds to mimic test duration and creates a simple HTML report file with key metrics.

The test test_performance_report_generation() waits explicitly for the report file to appear, then reads its content.

It asserts the presence of average response time, throughput, error rate, and test duration in the report.

Using a regular expression, it extracts the error rate value and asserts it is below 1%.

Finally, it cleans up by deleting the report file.

This approach uses explicit waits, file checks, content parsing, and pytest assertions to verify performance test reporting.

Common Mistakes - 3 Pitfalls
{'mistake': 'Not waiting for the report file to be generated before reading it', 'why_bad': 'The test may fail because the report file does not exist yet, causing false negatives', 'correct_approach': "Use explicit waits or polling to check for the report file's existence before reading"}
Hardcoding metric values in assertions without parsing the report
Ignoring cleanup of generated report files
Bonus Challenge

Now add data-driven testing with 3 different load levels: 50, 100, and 200 virtual users

Show Hint

Practice

(1/5)
1. What is the main purpose of a performance test report?
easy
A. To list all the bugs found during testing
B. To explain the software installation steps
C. To describe the user interface design
D. To show how software behaves under different loads

Solution

  1. Step 1: Understand the role of performance testing

    Performance testing checks how software works when many users or tasks run at once.
  2. Step 2: Identify what the report shows

    The report summarizes results like speed, response time, and stability under load.
  3. Final Answer:

    To show how software behaves under different loads -> Option D
  4. Quick Check:

    Performance test report = software behavior under load [OK]
Hint: Performance reports focus on load behavior, not bugs or UI [OK]
Common Mistakes:
  • Confusing performance reports with bug reports
  • Thinking reports describe UI or installation
  • Ignoring load and speed details
2. Which element is NOT typically included in a performance test report?
easy
A. Steps to reproduce a UI bug
B. Number of concurrent users tested
C. Graphs showing response times
D. Summary of test conclusions

Solution

  1. Step 1: Review common report contents

    Performance reports usually have graphs, user counts, and conclusions about performance.
  2. Step 2: Identify unrelated content

    Steps to reproduce UI bugs belong in functional or bug reports, not performance reports.
  3. Final Answer:

    Steps to reproduce a UI bug -> Option A
  4. Quick Check:

    UI bug steps ≠ performance report content [OK]
Hint: Performance reports focus on load data, not UI bugs [OK]
Common Mistakes:
  • Including bug reproduction steps in performance reports
  • Confusing test conclusion with bug details
  • Ignoring graphs and user counts
3. Given this snippet from a performance test report:
Average response time: 2.5 seconds
Peak users: 1000
Error rate: 0.5%

What does the error rate tell us?
easy
A. The percentage of requests that failed during the test
B. The average time users waited for a response
C. The total number of users tested
D. The maximum response time recorded

Solution

  1. Step 1: Understand error rate meaning

    Error rate shows how many requests or actions failed compared to total attempts.
  2. Step 2: Match error rate to options

    It is a percentage of failures, not time or user count.
  3. Final Answer:

    The percentage of requests that failed during the test -> Option A
  4. Quick Check:

    Error rate = % of failed requests [OK]
Hint: Error rate means failed requests percentage [OK]
Common Mistakes:
  • Confusing error rate with response time
  • Mixing error rate with user count
  • Thinking error rate is max response time
4. A performance test report shows response times increasing steadily, but the test script mistakenly used only 10 users instead of 1000. What is the main issue?
medium
A. Graphs should not show response times
B. Response times are always expected to increase
C. Test load is too low to reflect real performance
D. Error rate must be zero for valid results

Solution

  1. Step 1: Analyze test load impact

    Using only 10 users instead of 1000 means the load is too small to simulate real conditions.
  2. Step 2: Understand effect on results

    Low load can hide performance problems or give misleading response times.
  3. Final Answer:

    Test load is too low to reflect real performance -> Option C
  4. Quick Check:

    Low user load = unreliable performance data [OK]
Hint: Check user count matches test plan for valid results [OK]
Common Mistakes:
  • Assuming response times always increase
  • Ignoring incorrect user load
  • Expecting zero error rate always
5. You have a performance test report with these results:
Average response time: 1.2s
Peak response time: 5.0s
Error rate: 3%
Concurrent users: 500

Which action should you recommend to improve the system?
hard
A. Reduce the number of concurrent users to 100 to lower errors
B. Investigate causes of high peak response times and errors under load
C. Ignore errors since average response time is low
D. Increase test duration without changing load

Solution

  1. Step 1: Analyze report data

    Peak response time is much higher than average, and error rate is 3%, which is significant under 500 users.
  2. Step 2: Decide best improvement action

    Investigating causes of spikes and errors helps fix real problems rather than just lowering load or ignoring issues.
  3. Final Answer:

    Investigate causes of high peak response times and errors under load -> Option B
  4. Quick Check:

    High peaks and errors = investigate and fix [OK]
Hint: Focus on fixing spikes and errors, not just lowering load [OK]
Common Mistakes:
  • Ignoring error rate because average looks good
  • Reducing users instead of fixing root causes
  • Extending test time without addressing issues
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