Master Performance Testing: 10 Key Questions Every Test Manager Should Know

Introduction

Test engineers often lack insight into the specific work, progress, and outcomes of performance testing, making it difficult to assist and control the overall testing process. This article aims to help test managers deeply understand performance testing progress and quality, and provides practical guidance.

The objectives are to grasp the execution process of performance testing, ensure its quality, clarify when and what type of performance testing should intervene, understand how to measure system performance, and learn how to verify the quality of performance testing.

Q1. When should performance testing be introduced?

Performance testing should be inserted at appropriate stages of the development lifecycle: unit testing (code‑level efficiency and resource usage), component/service/interface testing (functional verification), and system testing (full‑scale user behavior simulation). Ideally, it is engaged before a stable build is released, guided by the user model defined in the performance plan.

Q2. What does the performance testing process look like?

Regardless of traditional or agile models, performance testing includes clear documentation, execution phases, and iterative verification and correction. Transparency can be improved by standardising the workflow and establishing checkpoint reviews.

Q3. Is performance testing necessary?

New projects or versions that experience increased user load, data volume, or architectural changes typically require performance testing. Even minor feature additions can alter the user model, necessitating retesting to guarantee system performance. Shifting testing toward component/service levels and enhancing enterprise‑level virtualisation can improve reusability and reduce cost.

Q4. What types of performance testing exist?

Benchmark testing – establishing a baseline for future comparison.

Load testing – applying moderate pressure to confirm normal operation.

Stress testing – evaluating behaviour under maximum expected load.

Capacity testing – identifying bottlenecks for future planning.

Stability (endurance) testing – long‑run execution to assess stability.

Combining multiple types usually yields the most accurate results, and stability test duration depends on data that demonstrates long‑term reliability.

Q5. How to analyse performance requirements?

Test leads should assess requirements for completeness, feasibility, measurability, and flexibility, considering user experience, business impact, and technical constraints, and ensure performance indicators are clear and representative.

Q6. How to measure performance?

Performance is evaluated using user‑perceived metrics such as response time, page load time, throughput, and TPS, with indicators that are technically measurable and defined during test design.

Q7. What can performance testing achieve?

By simulating real user behaviour through a user model, performance testing evaluates web system performance. Its goal is to uncover system bottlenecks rather than functional defects.

Q8. How to verify the quality of performance testing?

Establish execution standards and key checkpoints, assigning responsibility for verification.

Record complete execution details and parameter adjustments, maintaining continuous interaction and confirmation.

Ensure output data robustly supports conclusions; reports must be data‑driven, avoiding subjective judgement.

Q9. What skills should a performance testing engineer possess?

Solid understanding of software testing theory, methods, and techniques.

Proficiency with tools such as LoadRunner, JMeter, Locust.

Knowledge of databases (Oracle, MySQL) and basic SQL tuning.

Experience with Unix/Linux systems and basic OS tuning.

Familiarity with application servers (WebLogic, WebSphere) and their tuning strategies.

Understanding of web application architecture principles.

Ability to analyse and locate performance bottlenecks, especially for web or mobile applications.

Practical experience diagnosing and resolving performance issues.

Q10. What are common performance‑testing terms?

Concurrent users – number of users performing similar actions simultaneously.

Concurrent user count – online users interacting with the server at a given moment, directly affecting load.

Response time – time from client request to receipt of the final response byte.

Transaction response time – macro‑level response covering a series of requests.

Throughput – total data transferred during a test.

Throughput rate (TPS) – requests or data processed per unit time.

Click rate – number of HTTP requests per second from client to server.

Resource utilisation – degree to which server, OS, DB, network resources are used, crucial for bottleneck analysis.

Q11. What is the general performance‑testing workflow?

Collect and analyse performance testing requirements.

Develop a performance testing plan.

Design the performance testing strategy.

Create and design performance test scripts.

Build workload models.

Execute performance tests using appropriate tools.

Analyse test results.

Write performance test reports.

Provide performance improvement recommendations.

Q12. What specific performance‑testing types are there?

Concurrency testing – checks system behaviour under simultaneous user access.

Load testing – evaluates performance under expected load.

Stress testing – validates stability beyond normal load, identifying break points.

Endurance testing – long‑duration load to detect memory leaks and ensure stability.

Strength testing – assesses minimum performance under extreme conditions.

Spike testing – simulates sudden load spikes to verify rapid recovery.

Volume testing – tests performance with large data volumes.

Q13. How to understand “concurrency” in performance testing?

Concurrency has distinct meanings for client‑side and server‑side. Client concurrency simulates many users, while server concurrency reflects the number of simultaneous requests the server handles. Effective concurrency is determined by resource utilisation (network, bandwidth, memory, CPU, I/O). During stress testing, rising response times as concurrency increases indicate the system’s concurrency limit.