Performance Testing – P4

Performance Testing – P4: Các loại kiểm thử hiệu năng và khi nào nên dùng

Nếu Performance Testing là một môn võ, thì mỗi loại kiểm thử là một “chiêu thức”.
Dùng đúng chiêu thì thắng nhanh, dùng sai chiêu thì… tự đánh mình.

Sau khi đã hiểu khái niệm (P1), lập kế hoạch (P2) và thực thi – phân tích – tinh chỉnh (P3), câu hỏi tiếp theo là:

“Rốt cuộc thì có những loại Performance Testing nào, và dùng chúng khi nào?”

Đây chính là nội dung của Phần 4.

Vì sao phải chia Performance Testing thành nhiều loại?

Một sai lầm phổ biến của người mới học là nghĩ rằng:

“Chỉ cần chạy test cho nhiều user là đủ.”

Không hẳn.

Mỗi loại Performance Testing được thiết kế để trả lời một câu hỏi khác nhau:

Hệ thống có chịu được tải bình thường không?
Khi quá tải thì sập thế nào?
Sập rồi có hồi phục không?
Chạy lâu có bị yếu dần không?
Dữ liệu lớn thì có còn ổn không?

Nếu không phân biệt rõ, bạn có thể test rất nhiều nhưng lại không trả lời được câu hỏi nào cho đúng.

1. Load Testing – Kiểm thử tải (quan trọng nhất)

Load Testing trả lời câu hỏi gì?

“Hệ thống có hoạt động đúng và ổn định dưới tải dự kiến không?”

Đây là loại kiểm thử cơ bản, phổ biến và bắt buộc trong hầu hết dự án.

Đặc điểm:

Số lượng người dùng = tải thực tế mong đợi.
Thời gian chạy đủ dài để quan sát hành vi ổn định.
Dùng để kiểm tra:
- Response time
- Throughput
- Error rate

Ví dụ:

Một hệ thống đăng ký học phần dự kiến có:

5.000 sinh viên truy cập cùng lúc
→ Load test với 5.000 virtual users.

Nếu hệ thống chạy mượt → đạt yêu cầu.
Nếu chậm hoặc lỗi → cần tối ưu trước khi go-live.

Kết luận:

Load Testing là “bài thi giữa kỳ” của hệ thống.

2. Stress Testing – Kiểm thử quá tải

Stress Testing trả lời câu hỏi gì?

“Khi vượt quá giới hạn, hệ thống sẽ sập ở đâu và sập như thế nào?”

Ở đây, mục tiêu không phải chạy mượt — mà là đẩy hệ thống đến điểm gãy.

Đặc điểm:

Tăng tải vượt mức thiết kế.
Quan sát:
- Điểm sập (breakpoint).
- Cách hệ thống phản ứng khi quá tải.
- Có tự phục hồi hay không.

Ví dụ:

Hệ thống thiết kế cho 5.000 user.
→ Stress test lên 8.000 – 10.000 user.

Kết quả có thể là:

Server từ chối request mới (tốt).
Server treo toàn bộ (xấu).
Database lock và crash (rất xấu).

Kết luận:

Stress Testing giống như hỏi: “Hệ thống chịu đòn mạnh đến mức nào trước khi gục?”

3. Spike Testing – Kiểm thử tăng tải đột ngột

Spike Testing trả lời câu hỏi gì?

“Nếu lượng người dùng tăng vọt trong thời gian rất ngắn, hệ thống có chịu nổi không?”

Khác với Stress Test tăng từ từ, Spike Test tăng đột ngột.

Đặc điểm:

Tải tăng mạnh trong vài giây hoặc vài phút.
Sau đó có thể giảm nhanh.
Kiểm tra khả năng phản ứng tức thời của hệ thống.

Ví dụ:

Công bố điểm thi.
Mở cổng đăng ký học phần.
Flash sale 0h.

Hệ thống có thể:

Chậm vài giây rồi ổn định (chấp nhận được).
Timeout hàng loạt (không ổn).
Crash hoàn toàn (thất bại).

Kết luận:

Spike Testing mô phỏng những khoảnh khắc “cao trào” nhất của hệ thống.

4. Endurance / Soak Testing – Kiểm thử độ bền

Endurance Testing trả lời câu hỏi gì?

“Hệ thống có chạy ổn trong thời gian dài không?”

Có những hệ thống:

Chạy 1 giờ rất tốt.
Nhưng chạy 8 tiếng thì bắt đầu chậm dần.
Chạy 24 tiếng thì… chết.

Đặc điểm:

Chạy với tải ổn định.
Thời gian dài (nhiều giờ, thậm chí nhiều ngày).
Mục tiêu là phát hiện:
- Memory leak.
- Connection leak.
- Hiệu năng suy giảm theo thời gian.

Ví dụ:

Một hệ thống thanh toán online:
→ Soak test 12–24 giờ liên tục với tải trung bình.

Nếu RAM tăng đều và không giảm → có rò rỉ bộ nhớ.

Kết luận:

Endurance Testing kiểm tra “sức bền”, không phải sức mạnh tức thời.

5. Volume Testing – Kiểm thử dữ liệu lớn

Volume Testing trả lời câu hỏi gì?

“Hệ thống có xử lý khối lượng dữ liệu lớn tốt không?”

Ở đây, trọng tâm không phải số user, mà là dữ liệu.

Đặc điểm:

Database chứa lượng dữ liệu lớn.
Kiểm tra:
- Truy vấn có còn nhanh không?
- Backup/restore có ổn không?
- Báo cáo có bị chậm?

Ví dụ:

Hệ thống quản lý sinh viên có 10 năm dữ liệu.
Một bảng chứa hàng triệu bản ghi.

Nhiều hệ thống chạy tốt với dữ liệu nhỏ, nhưng sụp đổ khi dữ liệu phình to.

Kết luận:

Volume Testing trả lời câu hỏi: “Hệ thống có chịu nổi sự già đi theo thời gian không?”

6. Scalability Testing – Kiểm thử khả năng mở rộng

Scalability Testing trả lời câu hỏi gì?

“Nếu thêm tài nguyên, hệ thống có tăng hiệu năng tương ứng không?”

Đặc điểm:

Tăng số server, CPU, RAM.
Quan sát xem throughput có tăng theo không.
Phát hiện thiết kế không scale được.

Ví dụ:

Thêm 1 server → throughput tăng 80% (tốt).
Thêm 1 server → throughput tăng 5% (thiết kế có vấn đề).

Kết luận:

Scalability Testing kiểm tra tính “đầu tư có lời” của hệ thống.

Chọn sai loại test = kết luận sai

Một bảng tóm tắt nhanh:

Mục tiêu	Loại Test Phù hợp
Kiểm tra tải thực tế	Load Testing
Tìm điểm sập	Stress Testing
Mô phỏng gia tăng đột ngột	Spike Testing
Chạy lâu dài	Endurance Testing
Dữ liệu lớn/nhiều	Volume Testing
Mở rộng hệ thống	Scalability Testing

Bài học quan trọng:

Không có loại Performance Testing nào là “tốt nhất”.
Chỉ có loại phù hợp nhất với câu hỏi bạn đang cần trả lời.

Tổng kết Phần 4 – Và cũng là tổng kết series

Performance Testing không phải một bài test duy nhất, mà là một tập hợp chiến lược kiểm thử.
Hiểu rõ từng loại test giúp bạn:

Đặt đúng câu hỏi.
Chạy đúng bài test.
Và đưa ra kết luận có giá trị thật sự.

Tin khác: