Last updated: September 2026
If you are interested in performance testing, performance engineering, or improving your skills as a software tester, the ISTQB Certified Tester – Performance Testing (CT-PT) certification is a specialist qualification designed to develop your understanding of performance testing.
This guide explains what the ISTQB Performance Testing certification covers, who it is for, the main concepts you need to understand, how performance testing is planned and executed, and how to prepare for the exam.
Important: This is an independent study guide created by TestManagerHQ. It is based on the official ISTQB CT-PT syllabus and publicly available ISTQB information. TestManagerHQ is not affiliated with or endorsed by ISTQB.
View the official ISTQB CT-PT certification page
What is ISTQB Performance Testing?
The ISTQB Certified Tester Performance Testing (CT-PT) certification focuses on the principles, techniques and practices used to evaluate the performance of software systems.
Performance testing is concerned with how a system behaves under different workloads and conditions.
It can help answer questions such as:
- How quickly does the system respond?
- How many users can the system support?
- What happens when the system reaches its capacity?
- Does performance remain stable over several hours?
- How does the system behave when traffic suddenly increases?
- Which system resources are becoming bottlenecks?
- Can the system meet its performance requirements?
ISTQB describes performance testing as covering technical, method-based and organizational aspects of performance testing, including concepts, measurements, activities, tasks and tools.
Who is the CT-PT certification for?
The certification is intended for people who want to expand their knowledge of performance testing or develop a career specializing in performance testing.
It can also be useful for professionals working with performance engineering who want a stronger understanding of performance testing.
Typical candidates may include:
- Software testers
- Test analysts
- Test engineers
- Performance testers
- Performance engineers
- Test leads
- Test managers
- QA professionals
- Developers involved in performance testing
- Technical specialists involved in system performance
ISTQB currently states that candidates must hold the Certified Tester Foundation Level (CTFL) certificate before taking the CT-PT certification exam.
What does the ISTQB Performance Testing certification cover?
The official CT-PT syllabus is structured around five major areas:
- Basic Concepts
- Performance Measurement Fundamentals
- Performance Testing in the Software Lifecycle
- Performance Testing Tasks
- Tools
The official syllabus currently available from ISTQB is CT-PT Syllabus v1.0, 2018.
Let’s look at each area.
1. Performance Testing Basic Concepts
Before designing a performance test, it is important to understand what “performance” actually means.
ISTQB connects performance efficiency with three important areas:
Time behavior
Time behavior concerns how quickly a system or component responds to inputs.
For example:
A customer submits an order and expects confirmation within two seconds.
Response time can be measured at different levels, from an end-to-end user interaction to the execution time of a particular software operation.
Resource utilization
Performance testing can also investigate how efficiently system resources are being used.
Typical resources include:
- CPU
- Memory
- Disk
- Network
- Database connections
- Threads
- Connection pools
A system might have acceptable response times while using an excessive amount of CPU or memory. This can become a performance risk as the workload increases.
Capacity
Capacity concerns how much load a system can handle while still meeting its performance objectives.
For example:
The application must support 10,000 concurrent users while maintaining the agreed response-time target.
ISTQB identifies time behavior, resource utilization and capacity as important aspects of performance efficiency.
Types of Performance Testing
Performance testing is an umbrella term covering several different types of testing.
Understanding the differences is important for both practical performance testing and the CT-PT exam.
Load Testing
Load testing evaluates how a system behaves under expected or anticipated workloads.
Example:
A web application normally has approximately 5,000 concurrent users during peak business hours.
A load test can reproduce a representative workload and measure whether the system meets its performance requirements.
Stress Testing
Stress testing pushes a system toward or beyond its expected workload limits.
The objective can be to understand how the system behaves under extreme conditions.
Questions might include:
- When does performance become unacceptable?
- When does the system fail?
- Does the system recover after the stress is removed?
- What resources become bottlenecks?
Scalability Testing
Scalability testing examines how the system behaves as the workload or system size grows.
For example:
1,000 users → 5,000 users → 10,000 users → 20,000 users
The goal is to understand whether the system can grow without violating its performance objectives.
Spike Testing
Spike testing examines the system’s response to sudden changes in workload.
For example:
1,000 users → 20,000 users within a few seconds.
This can be particularly relevant for systems experiencing unpredictable traffic spikes.
Endurance Testing
Endurance testing evaluates system stability over an extended period.
It can reveal problems that may not appear during a short performance test, such as:
- Memory leaks
- Database connection problems
- Thread pool exhaustion
- Gradual resource degradation
- Increasing response times
Concurrency Testing
Concurrency testing examines situations where actions occur simultaneously.
For example:
5,000 users attempt to log in at approximately the same time.
Concurrency-related problems can be difficult to reproduce because timing and system state can affect the result.
Capacity Testing
Capacity testing determines how many users, transactions or data volumes a system can support while still meeting its performance objectives.
Static and Dynamic Performance Testing
Performance testing should not necessarily wait until the end of development.
The ISTQB syllabus distinguishes between static and dynamic performance testing.
Static Performance Testing
Static testing does not execute the software.
Instead, performance risks can be identified by reviewing things such as:
- Requirements
- Database design
- Architecture
- Network architecture
- Code
- Queries
- Stored procedures
This is particularly important because some performance problems originate in architecture and design decisions.
Finding such problems early can be significantly cheaper than discovering them after the system has been built.
Dynamic Performance Testing
Dynamic performance testing involves executing the system and measuring its behavior.
It can take place at different stages, including:
- Unit testing
- Component integration
- System testing
- System integration testing
- Acceptance testing
ISTQB emphasizes starting performance testing as early as practical rather than waiting until the final stages of a project.
2. Performance Measurement Fundamentals
You cannot perform meaningful performance testing without measurements.
A performance test should produce information that allows you to determine whether the system meets its objectives.
Common measurements include:
Response time
How long does an operation take?
Example:
Login response time = 1.2 seconds
Throughput
How much work does the system process over a period of time?
Examples:
- Transactions per second
- Requests per second
- Orders per minute
Resource utilization
How heavily are system resources being used?
Examples:
- CPU utilization
- Memory utilization
- Network utilization
- Disk utilization
Concurrency
How many users, processes or operations are active at the same time?
Capacity
What is the maximum sustainable workload while still meeting the defined objectives?
Why performance metrics matter
Performance metrics allow testers and stakeholders to move from:
“The system feels slow.”
to:
“The 95th percentile response time for checkout is 4.8 seconds at 8,000 concurrent users.”
The second statement provides something that can be measured, compared and investigated.
The official syllabus emphasizes that performance measurements should be connected to performance objectives and stakeholder expectations.
Percentiles in Performance Testing
Percentiles are particularly useful when analyzing response times.
Imagine the following simplified results:
Percentile | Response Time |
50th | 0.8 sec |
75th | 1.1 sec |
90th | 1.8 sec |
95th | 2.4 sec |
99th | 4.9 sec |
The 95th percentile of 2.4 seconds means that approximately 95% of the measured responses were at or below 2.4 seconds, while approximately 5% were slower.
This is often more informative than simply reporting the average.
Baselines
A baseline provides a reference point against which future performance measurements can be compared.
For example:
Version 1.0: average response time = 1.4 seconds
Version 1.1: average response time = 1.8 seconds
The baseline helps identify whether performance has improved or degraded.
ISTQB specifically discusses baselines as a way of comparing current and previous performance measurements and demonstrating improvements or verifying acceptance criteria.
3. Performance Testing in the Software Lifecycle
Performance testing should be connected to the entire software development lifecycle.
A common mistake is to treat performance testing as something that happens immediately before production.
A better approach is to identify performance risks early.
For example:
Requirements
Define:
- Expected response times
- Expected user volumes
- Throughput requirements
- Capacity requirements
- Resource constraints
Architecture
Evaluate whether the architecture can support the expected workload.
Development
Use profiling and other techniques to identify potential performance bottlenecks.
Integration
Evaluate performance across important integrations and workflows.
System Testing
Execute realistic end-to-end workloads.
Acceptance
Confirm that the system performs appropriately under realistic conditions.
The CT-PT syllabus explicitly addresses performance testing activities throughout the software lifecycle.
Performance Risks
Different architectures create different performance risks.
Examples include:
Database-heavy systems
Potential risks:
- Inefficient queries
- Database locking
- Connection pool exhaustion
- Poor indexing
- High database CPU usage
Distributed systems
Potential risks:
- Network latency
- Service dependencies
- Communication overhead
- Cascading failures
Web applications
Potential risks:
- High concurrent traffic
- Slow APIs
- Database bottlenecks
- Network bandwidth
- Infrastructure limitations
Cloud systems
Potential risks may include:
- Scaling delays
- Resource limits
- Configuration issues
- Dependency performance
- Cost-related constraints
The important point is that performance testing should be risk-driven, rather than simply generating as much load as possible.
4. Performance Testing Tasks
The largest section of the official CT-PT syllabus focuses on practical performance testing tasks.
These can broadly be divided into:
Planning → Analysis & Design → Implementation → Execution → Analysis & Reporting
Planning a Performance Test
Before creating scripts, you need to understand what you are trying to prove.
A performance test should have clear objectives.
For example:
Verify that the online banking application supports 5,000 concurrent users while maintaining a 95th percentile response time below three seconds.
This is much better than:
Test whether the application is fast.
Performance Test Plan
A performance test plan should describe how the performance test will be performed.
Depending on the project, it can include:
- Objectives
- Scope
- System under test
- Workload
- Performance requirements
- Acceptance criteria
- Test environment
- Test data
- Load profile
- Risks
- Schedule
- Responsibilities
- Monitoring
- Reporting approach
The official syllabus specifically covers deriving performance test objectives and developing a performance test plan.
Operational Profiles
An operational profile describes how users or external systems are expected to use the system.
For example, an e-commerce application might have:
Business Activity | Approximate Share |
Browse products | 50% |
Search | 20% |
Add to cart | 15% |
Checkout | 10% |
Account management | 5% |
The performance test can then reproduce a workload that more closely resembles real-world usage.
This is generally more useful than having every simulated user perform exactly the same operation.
Load Profiles
A load profile describes how the workload changes during the test.
For example:
Users
5000 | ███████████
4000 | ███████████████
3000 | ███████████████████
2000 | █████████████████████
1000 | ███████████████████████
+————————-
Time
A realistic test might include:
- Ramp-up
- Steady-state
- Peak workload
- Sustained load
- Ramp-down
The exact profile depends on the performance objectives.
Throughput and Concurrency
Two concepts that are often confused are throughput and concurrency.
Concurrency
How many activities are occurring simultaneously?
Example:
5,000 concurrent users
Throughput
How much work is being processed over time?
Example:
250 transactions per second
A system can have high concurrency without necessarily having high throughput, depending on how long individual operations take.
Understanding this distinction is important when designing performance tests.
Performance Test Scripts
Performance testing tools generally execute scripts that represent user or system interactions.
A basic script might represent:
Login
↓
Search product
↓
Open product
↓
Add to basket
↓
Checkout
↓
Logout
A realistic performance script may also need:
- Parameterization
- Correlation
- Dynamic data handling
- Authentication
- Session management
- Transactions
- Think time
- Synchronization
The objective is to reproduce a realistic workload rather than simply generate a large number of requests.
Test Data
Test data can have a significant impact on performance testing.
Examples include:
- User accounts
- Product data
- Customer data
- Database records
- Transaction data
The official syllabus discusses considerations such as extracting production data, creating data, restoring data between test cycles, and protecting sensitive information through masking or anonymization.
A performance test using an unrealistic database can produce misleading results.
For example:
Production database: 20 million records
Test database: 10,000 records
A query might perform well against the small test database but behave very differently in production.
Performance Test Execution
During execution, the test team should monitor both:
Application behavior
and
System behavior
For example:
Application
- Response time
- Throughput
- Error rate
- Transactions
Infrastructure
- CPU
- Memory
- Network
- Disk
- Database
- Application server
This allows the team to correlate performance symptoms with potential causes.
Analyzing Performance Test Results
A performance test does not end when the load generator stops.
The most important part is often the analysis.
Suppose you obtain:
Response time increased from 1.2 seconds to 7.5 seconds when concurrency exceeded 6,000 users.
You then need to investigate:
- What changed?
- Which component became saturated?
- Did CPU increase?
- Did database response time increase?
- Did network utilization increase?
- Did errors increase?
- Was throughput still increasing?
- Did the system recover?
The objective is to turn measurements into meaningful conclusions.
Performance Bottlenecks
A bottleneck is a component that limits the overall performance of the system.
Common bottlenecks include:
- CPU
- Memory
- Database
- Network
- Disk I/O
- Application code
- External services
- Connection pools
- Thread pools
A useful performance investigation therefore considers the entire system rather than looking only at response time.
Reporting Performance Test Results
A good performance test report should communicate more than raw graphs.
Stakeholders normally need to understand:
What was tested?
Under what workload?
What were the results?
Did the system meet its objectives?
What risks were identified?
What should happen next?
For example:
The system successfully supported 5,000 concurrent users and met the defined response-time objective. At approximately 7,500 users, database utilization reached saturation and response times increased significantly. Additional capacity or architectural optimization should therefore be evaluated before increasing the production workload.
This is much more useful to management than simply presenting a graph.
5. Performance Testing Tools
Tools play an important role in performance testing.
The ISTQB CT-PT syllabus covers categories of performance tools and factors that can be considered when selecting them.
A performance testing tool may provide capabilities such as:
- Load generation
- Script creation
- Parameterization
- Correlation
- Test execution
- Monitoring
- Result collection
- Reporting
Popular tools in the wider industry include tools such as JMeter, LoadRunner, Gatling and k6.
However, knowing a specific tool is not the same as understanding performance testing.
The most important question is:
Does the tool allow us to create a realistic, measurable and repeatable performance test?
The Performance Testing Process
A simple way to remember the overall process is:
Define Objectives
↓
Identify Risks
↓
Define Workload
↓
Create Performance Test Plan
↓
Design Test
↓
Prepare Environment & Data
↓
Implement Scripts
↓
Execute Test
↓
Collect Measurements
↓
Analyze Results
↓
Report Findings
↓
Optimize / Retest
Performance testing is often iterative.
A test can reveal a bottleneck, the bottleneck can be fixed, and the test can then be repeated to determine whether the change improved the system.
ISTQB CT-PT Exam
According to the current official ISTQB certification page, the CT-PT exam has:
Exam characteristic | CT-PT |
Questions | 40 |
Total points | 40 |
Passing score | 26 |
Standard exam time | 90 minutes |
Non-native language extension | +25% |
The official page also states that the Foundation Level Core certificate is required before taking the Performance Testing certification exam.
That means the passing score is 65% of the available points.
How to Prepare for the ISTQB Performance Testing Exam
The official ISTQB guidance recommends using the relevant syllabus and ISTQB Glossary as a minimum for self-study. Official sample exams are also available.
I recommend the following approach.
Step 1 — Read the syllabus
Start with the official CT-PT syllabus.
Don’t immediately try to memorize everything.
First understand the structure:
Basic Concepts → Measurement → Lifecycle → Tasks → Tools
Step 2 — Learn the terminology
Performance testing has many terms that are easy to confuse.
Make sure you understand:
- Load testing
- Stress testing
- Scalability testing
- Spike testing
- Endurance testing
- Concurrency testing
- Capacity testing
- Response time
- Throughput
- Resource utilization
- Workload
- Operational profile
- Load profile
- Baseline
- Bottleneck
The official ISTQB Glossary is the authoritative terminology reference for ISTQB certifications.
Step 3 — Understand the concepts, don’t just memorize definitions
The CT-PT syllabus contains learning objectives using different cognitive levels.
For example, some objectives require you to remember information, while others require you to understand, apply or analyze concepts.
Therefore, ask yourself questions such as:
Why would I use stress testing instead of load testing?
When would endurance testing be appropriate?
Why might throughput increase while response time gets worse?
What could cause a database bottleneck?
Why is realistic test data important?
These types of questions force you to understand the concepts rather than simply memorize terminology.
Step 4 — Use sample exams
Once you understand the syllabus, use the official sample exam.
Don’t just check whether your answer is correct.
For every incorrect answer ask:
Why is this wrong?
and:
Which concept from the syllabus does this question test?
The official ISTQB CT-PT certification page provides sample exam materials alongside the syllabus.
Step 5 — Think like a performance tester
When looking at a performance problem, develop the habit of asking:
What is the workload?
↓
What are the performance objectives?
↓
What measurements do I need?
↓
Where could the bottleneck be?
↓
What does the data actually tell me?
↓
What should we do next?
That mindset is more valuable than simply memorizing tool commands.
CT-PT Quick Revision Checklist
Before taking the exam, make sure you can explain:
Performance fundamentals
- What is performance testing?
- What is performance efficiency?
- Time behavior
- Resource utilization
- Capacity
Performance test types
- Load
- Stress
- Scalability
- Spike
- Endurance
- Concurrency
- Capacity
Measurements
- Response time
- Throughput
- Concurrency
- Resource utilization
- Percentiles
- Baselines
Lifecycle
- Requirements
- Architecture
- Development
- Integration
- System testing
- Acceptance testing
Planning
- Objectives
- Requirements
- Acceptance criteria
- Workload
- Operational profiles
- Load profiles
- Test data
- Environment
Execution
- Test scripts
- Parameterization
- Correlation
- Transactions
- Load generation
- Monitoring
Analysis
- Bottlenecks
- Performance degradation
- Resource utilization
- Throughput
- Response time
- Test results
- Reporting
Tools
- Tool categories
- Tool capabilities
- Tool suitability
- Load generation
- Monitoring
- Reporting
Final Thoughts
Performance testing is much more than putting thousands of virtual users against an application.
Effective performance testing starts with clear objectives and realistic workloads, uses appropriate measurements, and produces information that allows the team to make decisions.
A successful performance test should answer questions such as:
Can the system handle the expected workload?
Does it meet its performance requirements?
Where are the bottlenecks?
What happens when workload increases?
Can the system scale?
What risks should be addressed before production?
The ISTQB CT-PT certification provides a structured foundation for understanding these concepts and applying them to performance testing activities throughout the software lifecycle.
Official CT-PT resources
For exam preparation, always use the official ISTQB materials as the primary source:
ISTQB Certified Tester – Performance Testing (CT-PT)
Official CT-PT Syllabus v1.0 (2018)
URL slug:
/istqb-performance-testing/
Meta description:
Complete guide to the ISTQB Performance Testing (CT-PT) certification. Learn performance testing concepts, test types, metrics, planning, execution, analysis and exam preparation.
Primary keyword:
ISTQB Performance Testing
Secondary keywords:
- ISTQB CT-PT
- ISTQB Performance Testing certification
- CT-PT exam
- ISTQB Performance Tester
- Performance Testing certification
- ISTQB CT-PT exam
- Performance testing study guide