Testing Fundamentals
Performance Testing Interview Questions & Answers
Performance testing interview questions on load, stress, spike and soak testing, key metrics, JMeter, k6 and Gatling, workload modelling and bottleneck analysis.
Interview Questions
Showing 15 of 40 questions
Performance testing checks how fast, stable and scalable a system is under a given workload. It finds bottlenecks and capacity limits before real users do, protecting revenue and user experience.
Load testing runs expected peak traffic, say 2,000 concurrent users, to verify SLAs. Stress testing pushes beyond that until the system breaks to find the limit and how it fails; spike testing applies a sudden jump, like a flash sale; soak testing holds normal load for hours to reveal memory leaks; scalability testing checks how performance changes as resources or load grow.
Response time percentiles (p50, p90, p95, p99), throughput in requests or transactions per second, error rate, and concurrent users, alongside server metrics like CPU, memory, GC, DB connections and network. Percentiles matter more than averages.
Averages hide outliers: a few very slow requests barely move the mean while many users suffer. p95 means 95% of requests were at or below that time, so it reflects the experience of almost all users.
Latency is the time until the first byte of the response arrives, response time is the total time until the full response is received, and throughput is how many requests the system completes per unit of time. In JMeter, Latency and Elapsed time are reported separately.
Little's Law says concurrency equals throughput times the time each user spends in the system: N = X × (R + Z), where R is response time and Z is think time. It converts business targets like 100 transactions per second into the number of virtual users needed.
I analyse production logs or analytics to find the busiest hour, key user journeys, their mix percentage, transaction rates and think times. Then I translate that into scripts, user counts, pacing and ramp-up that reproduce realistic peak traffic plus a growth factor.
In a closed model a fixed number of virtual users loop, so when the system slows, the arrival rate drops too. In an open model new requests arrive at a set rate regardless of response time, which matches public websites and exposes queuing better.
Think time is the pause a real user takes between actions, like reading a page. Pacing controls the time between the start of iterations so each user runs at a fixed rate. Both are needed to make load realistic.
A test plan contains thread groups (virtual users), samplers like HTTP Request, config elements such as HTTP Request Defaults, CSV Data Set Config and Cookie Manager, plus timers, assertions, pre/post-processors and listeners for results.
Number of threads is the virtual users, ramp-up period is how long JMeter takes to start all of them, and loop count is how many times each thread runs the samplers. For example, 100 threads with 50 seconds ramp-up starts 2 users per second.
Correlation captures dynamic values from a response, like session IDs, CSRF tokens or order IDs, and reuses them in later requests. In JMeter I use post-processors such as the JSON Extractor, Regular Expression Extractor or Boundary Extractor, then reference the variable as ${name}.
I use CSV Data Set Config to read rows such as usernames and passwords from a file into variables, so each thread uses different data. Functions like ${__Random} or ${__UUID} generate unique values on the fly.
Response Assertion for status codes or text, JSON Assertion for JSON paths, Duration Assertion for SLA times and Size Assertion for payloads. Assertions use CPU on the load generator, so I keep them lightweight and targeted.
Listeners like View Results Tree keep results in memory and render them, which consumes heavy CPU and RAM on the load generator and skews results. For real runs I use non-GUI mode, write a JTL file and generate the HTML dashboard afterwards.