Performance test reporting in Testing Fundamentals - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to print the total time taken for the performance test.

Testing Fundamentals

print('Total test time:', [1], 'seconds')

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

Aelapsed_time

Btotal_time

Ctest_duration

Drun_time

Attempts:

3 left

💡 Hint

Common Mistakes

Using a variable name that does not exist or is unrelated to time.

The variable elapsed_time holds the total time taken for the test, so it should be printed.

2fill in blank

medium

Complete the code to calculate the average response time from the list of response times.

Testing Fundamentals

average_time = sum(response_times) [1] len(response_times)

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

A/

B*

C+

D-

Attempts:

3 left

💡 Hint

Common Mistakes

Using multiplication or addition instead of division.

To find the average, sum all response times and divide by the number of responses.

3fill in blank

hard

Fix the error in the assertion that checks if the maximum response time is below the threshold.

Testing Fundamentals

assert max(response_times) [1] threshold, 'Response time too high!'

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

A>=

B<=

C>

D<

Attempts:

3 left

💡 Hint

Common Mistakes

Using greater than or equal operators which invert the logic.

The assertion should confirm the max response time is less than the threshold, so use <.

4fill in blank

hard

Fill both blanks to create a dictionary of response times for each user where times are greater than 100ms.

Testing Fundamentals

slow_responses = {user: [1] for user, [2] in responses.items() if max(times) > 100}

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

Atimes

Btime

Ctimes_list

Dtime_list

Attempts:

3 left

💡 Hint

Common Mistakes

Using inconsistent variable names causing errors.

The dictionary comprehension uses times as the value and times as the variable for each user's response times.

5fill in blank

hard

Fill all three blanks to create a report dictionary with user names in uppercase, their average response time, and only include users with average below 200ms.

Testing Fundamentals

report = {user[1]: sum(times)[2]len(times) for user, times in data.items() if (sum(times)[3]len(times)) < 200}

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

A.upper()

B/

D.lower()

Attempts:

3 left

💡 Hint

Common Mistakes

Using .lower() instead of .upper().

Using multiplication or addition instead of division for average.

User names are converted to uppercase with .upper(). Average is sum divided by length using /. The filter uses the same division to check average below 200.

Practice

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