Beginner’s Guide to Performance Testing: A Complete Tutorial from Load Testing to Stress Testing
A Complete Guide to Getting Started with Performance Testing - Covers load testing, stress testing, and soak testing, introduces the practical usage of the three major tools JMeter, k6, and Locust, and learns to identify system bottlenecks from scratch to ensure online stability.
Last Updated:2026-03-16
This article provides an introductory guide to performance testing. Actual tool selection and testing strategies need to be adjusted based on project needs.
Table of Contents
1. Why performance testing is needed
Correct functionality does not mean that the system can handle real traffic. During e-commerce promotions, the website hangs up, the event page opens very slowly, and the API response times out. These are all performance issues. The goal of performance testing is to find the limits and bottlenecks of the system before going online to avoid overturning in front of real users. Common performance issues include: slow database queries, memory leaks, connection pool exhaustion, low cache hit rates, and slow third-party API responses that drag down overall performance.
2. Four Types of Performance Testing
Simulate expected normal and peak traffic to verify that the system can operate properly under target loads. For example: The system is expected to have 1,000 users at the same time, and the test scenario is 1,000 virtual users. Gradually increase the load beyond the system capacity and observe how the system behaves when overloaded. The focus is not on "whether it can withstand it", but on "whether it degrades gracefully instead of crashing directly when overloaded". Run for hours or even days under normal load to detect long-term problems such as memory leaks and connection pool exhaustion. Simulate a sudden surge in traffic, such as when a marketing campaign starts to influx a large number of users instantly. Test whether the system can scale quickly and return to normal after traffic decreases.
3. Key indicators for performance testing
When performing performance testing, you need to focus on these core metrics:
-
Response Time
P50 (median), P95, P99 quantile. P99 reflects real user experience better than average
-
Throughput
Requests per second (RPS). Represents the processing power of the system
-
Error Rate
The proportion of failed requests. Error rates should not increase rapidly when load increases
-
Concurrent Users
Number of users online at the same time
-
Resource usage
CPU, memory, disk I/O, network bandwidth usage
4. Comparison of three major performance testing tools
The open source tool of the Apache Foundation, with the oldest history and the largest community: Modern performance testing tool maintained by Grafana Labs, using JavaScript to write test scripts: Performance testing framework written in Python, using Python to define user behavior:
-
advantage
GUI operation is intuitive, rich in plug-ins, and supports multiple protocols (HTTP, FTP, JDBC, SOAP)
-
shortcoming
Writing in Java consumes resources, has high script maintenance costs, and is not suitable for version control.
-
Suitable
Introductory learning, GUI operation required, QA with non-engineering background
-
advantage
The script is written in JS, easy to read and maintain, CLI execution is suitable for CI/CD, and the resource consumption is low.
-
shortcoming
Only supports HTTP/WebSocket/gRPC, does not support GUI recording
-
Suitable
Modern Web API testing, CI/CD integration, QA with programming background
-
advantage
Rich Python ecosystem, easy distributed execution, and real-time monitoring via Web UI
-
shortcoming
Python GIL limits stand-alone performance and requires Python knowledge
-
Suitable
Python technology stack team needs complex user behavior simulation
5. Practical process of performance testing
Before starting testing, confirm performance goals with the team: Performance testing should be performed in an environment that is as similar as possible to the production environment. Key considerations: Design test scenarios based on real user behavior: Synchronously monitor system resources when executing tests: After the test is completed, analyze the results and generate a report:
-
Home page loading time must be within 2 seconds (P95)
Home page loading time must be within 2 seconds (P95)
-
API response time must be within 200ms (P99)
API response time must be within 200ms (P99)
-
The system must support 5000 simultaneous users
The system must support 5000 simultaneous users
-
Error rate must be less than 0.1%
Error rate must be less than 0.1%
-
Hardware specifications should be consistent with the production environment (or scaled down and converted)
Hardware specifications should be consistent with the production environment (or scaled down and converted)
-
The database should have test data close to the real level
The database should have test data close to the real level
-
Turn off unnecessary monitoring and logs to avoid interfering with results
Turn off unnecessary monitoring and logs to avoid interfering with results
-
Analyze traffic patterns in production (which APIs are called most often)
Analyze traffic patterns in production (which APIs are called most often)
-
Define user behavior path (browse home page → search → view products → add to shopping cart)
Define user behavior path (browse home page → search → view products → add to shopping cart)
-
Set a reasonable thinking time (the time the user stays on the page)
Set a reasonable thinking time (the time the user stays on the page)
-
Prepare test data (different accounts, different products)
Prepare test data (different accounts, different products)
-
Monitor server metrics using Grafana + Prometheus
Monitor server metrics using Grafana + Prometheus
-
Observe database slow query logs
Observe database slow query logs
-
Log errors in the application log
Log errors in the application log
-
Pay attention to garbage collection (GC) frequency and pause time
Pay attention to garbage collection (GC) frequency and pause time
-
Compare actual data to performance goals
Compare actual data to performance goals
-
Find the bottleneck (is it CPU, memory, database or network)
Find the bottleneck (is it CPU, memory, database or network)
-
Provide specific optimization suggestions and priorities
Provide specific optimization suggestions and priorities
-
Record baseline data as the basis for subsequent regression comparisons
Record baseline data as the basis for subsequent regression comparisons
6. Common performance bottlenecks and solutions
The following are the most commonly encountered bottlenecks and corresponding solutions in performance testing:
-
Database query is slow
Add indexes, optimize queries, and use cache
-
memory leak
Use profiler to find leaks and check for unreleased resources
-
Connection pool exhausted
Adjust the size of the connection pool and check whether the connection is returned correctly
-
CPU fully loaded
Identify CPU-intensive operations and consider asynchronous processing or horizontal scaling
7. FAQ
It is recommended to conduct a complete performance test after the function is stable and before going online. But a better approach is to add lightweight performance tests (such as API response time thresholds) to CI/CD and automatically check for performance degradation with each deployment. Can. Both k6 and Locust can perform basic load testing on a single machine. The key is to start small, learn to analyze the results, and then gradually increase the complexity of the test. Variation in performance test results is normal. It is recommended to run each scene at least 3 times and take the average value to exclude the influence of the first warm-up. Also make sure no other programs are competing for resources during testing.
Related Quick Guides
2026 QA 趨勢：AI 測試、Shift-Left 與職涯新方向
探索 QA 領域的最新趨勢，包含 AI 輔助測試、Shift-Left 策略、以及 QA 工程師的職涯轉型方向。
API 測試入門：用 Postman 和 pytest 打造你的第一個 API 測試
API 測試是現代 QA 必備技能。從 HTTP 基礎概念到實際用 Postman 和 pytest 寫測試，帶你踏出 API 測試的第一步。
Bug 回報的藝術：讓開發者秒懂的 Bug Report 寫法
一份好的 Bug Report 能大幅加速修復速度。分享 Bug 回報的最佳實踐，包含模板、嚴重度分級、以及如何與開發有效溝通。
General Disclaimer
The information provided on this site is for reference only. We do not guarantee its completeness or accuracy. Users should determine the applicability of the information on their own.