Các loại kiểm thử hiệu năng

Cùng một câu "hệ thống cần được kiểm thử hiệu năng", nhưng người thì dựng kịch bản 5 phút, người lại chạy liên tục 32 giờ. Không ai sai — họ chỉ đang nói về những loại kiểm thử khác nhau. Và nếu bạn chọn nhầm loại, bạn sẽ trả lời sai câu hỏi mà doanh nghiệp thật sự đang hỏi.

Kiểm thử hiệu năng (Performance Testing) là quá trình đo lường và đánh giá hoạt động của một hệ thống phần mềm dưới các điều kiện tải khác nhau, để xác định hệ thống có đáp ứng yêu cầu về tốc độ, độ tin cậy, khả năng mở rộng và tính ổn định hay không. Nhưng "kiểm thử hiệu năng" không phải một bài test duy nhất — nó là cả một họ các loại kiểm thử, mỗi loại có hình dạng tải, thời lượng và mục tiêu riêng. Hiểu sai sự khác biệt này là lý do nhiều đội chạy test rất chăm nhưng vẫn bỏ lọt đúng rủi ro nguy hiểm nhất.

Trong bài viết này, bạn sẽ nắm được:

• Sáu loại kiểm thử hiệu năng phổ biến nhất và mục tiêu cốt lõi của từng loại.
• Cấu hình tham khảo cho mỗi loại: số người dùng ảo (VUs) và thời lượng kiểm thử.
• Cách phân biệt nhanh để chọn đúng loại test cho đúng câu hỏi.
• Bảng tổng hợp tra cứu một-lần và những lưu ý thực chiến khi áp dụng.

Smoke Test — kiểm tra script trước khi chạy thật

Smoke Test là bài chạy đầu tiên, mục đích là kiểm tra độ chính xác của script dùng để đánh giá hiệu năng — chứ chưa phải để đo sức chịu tải. Nó xác nhận kịch bản chạy thông suốt, request đúng, dữ liệu đầu vào hợp lệ trước khi bạn đổ tải lớn vào.

Khi nào dùng

Chạy ngay sau khi viết hoặc chỉnh sửa script, trước mọi bài test nặng. Đây là bước "khởi động" bắt buộc để tránh lãng phí một lần chạy tải lớn chỉ vì lỗi cấu hình tầm thường.

• Số người dùng ảo (VUs): thấp — khoảng 3 – 5 VUs.
• Thời gian kiểm thử: ngắn — vài phút (< 3 phút).

Load Test — duy trì hiệu năng ở tải trung bình

Load Test kiểm tra việc duy trì hiệu năng của hệ thống ở mức sử dụng trung bình — tức tải mà hệ thống dự kiến gặp trong vận hành bình thường. Đây là phép xác nhận: ở tải kỳ vọng, hệ thống có giữ được tốc độ và độ ổn định hay không.

Khi nào dùng

Khi bạn cần chứng minh hệ thống đáp ứng được lưu lượng thực tế hằng ngày, hoặc kiểm chứng SLA ở mức tải dự kiến trước khi phát hành.

• Số người dùng ảo (VUs): trung bình — phụ thuộc lượng tải thực tế, hoặc ước tính 50 – 70% ngưỡng.
• Thời gian kiểm thử: nên (should) 01 – 04 giờ; tối thiểu có thể 5 – 60 phút.

Stress Test — đẩy hệ thống trên mức trung bình và cao

Stress Test kiểm tra hệ thống khi tải vượt mức trung bình, lên mức cao. Mục tiêu không phải để chứng minh hệ thống "chịu được", mà để xem nó suy giảm và gãy như thế nào khi bị đẩy quá ngưỡng vận hành bình thường.

Khi nào dùng

Khi cần đánh giá hành vi hệ thống ở giờ cao điểm hoặc các đợt tăng tải mạnh có kế hoạch — ví dụ chiến dịch khuyến mãi, mở bán, cao điểm mùa vụ.

• Số người dùng ảo (VUs): cao / vượt ngưỡng — tham khảo peak time (số lượng request/user được xử lý cao nhất trong khoảng thời gian) hoặc đặt theo 100 – 125% ngưỡng.
• Thời gian kiểm thử: nên (should) 01 – 04 giờ; tối thiểu có thể 5 – 60 phút.

Endurance (Soak) Test — chạy liên tục trong thời gian dài

Endurance Test, còn gọi là Soak Test, kiểm tra hệ thống khi sử dụng liên tục trong thời gian dài. Đây là loại test bộc lộ những vấn đề tích lũy mà các bài ngắn không thấy được: rò rỉ bộ nhớ (memory leak), đầy connection pool, log phình to, hiệu năng tụt dần theo giờ.

Khi nào dùng

Khi hệ thống phải chạy 24/7 hoặc xử lý tải ổn định trong nhiều giờ liền, và bạn cần chắc chắn nó không "xuống sức" sau một thời gian vận hành.

• Số người dùng ảo (VUs): trung bình — phụ thuộc lượng tải thực tế, hoặc ước tính 50 – 70% ngưỡng.
• Thời gian kiểm thử: nên (should) 08 – 32 giờ.

Spike Test — cú sốc tải đột ngột

Spike Test kiểm tra hệ thống khi số lượng người dùng tăng vọt hoặc khi hệ thống thường xuyên nhận lưu lượng truy cập cao đột biến. Khác với Stress Test (tải cao nhưng tăng dần), Spike Test mô phỏng cú sốc tức thời — tải nhảy vọt rồi giảm nhanh.

Khi nào dùng

Khi hệ thống có thể hứng các đợt traffic bùng nổ bất ngờ: flash sale, mở vé, viral, thông báo đẩy gửi đồng loạt tới hàng loạt người dùng cùng lúc.

• Số người dùng ảo (VUs): cao / vượt ngưỡng — tham khảo peak time hoặc đặt theo 100 – 125% ngưỡng.
• Thời gian kiểm thử: nên (should) 01 – 04 giờ; tối thiểu có thể 5 – 60 phút.

Breakpoint Test — đi tìm giới hạn trên của hệ thống

Breakpoint Test có mục tiêu tìm giới hạn trên của hệ thống (bottleneck) — tức điểm mà hệ thống bắt đầu gãy. Tải được tăng theo từng bước nhảy đều đặn cho đến khi chạm ngưỡng, từ đó bạn biết chính xác hệ thống chịu được tới đâu và nút thắt nằm ở đâu.

Khi nào dùng

Khi bạn chưa có dữ liệu lịch sử để chốt mức tải mục tiêu, hoặc cần xác định năng lực tối đa thật của hạ tầng trước khi thiết kế các bài Load/Stress.

• Số người dùng ảo (VUs): tăng theo bước nhảy tới ngưỡng.
• Thời gian kiểm thử: mỗi bước nhảy khoảng 5 – 10 VUs/CCUs, duy trì mỗi bước 4 – 10 phút.

Bảng tổng hợp: chọn đúng loại cho đúng câu hỏi

Sáu loại trên dễ bị dùng lẫn lộn. Cách phân biệt nhanh nhất là nhìn vào mục tiêu và hình dạng tải — mỗi loại sinh ra để trả lời một câu hỏi khác nhau:

Loại kiểm thử	Mục tiêu	Mức tải (VUs) & thời lượng	Câu hỏi cần trả lời
Smoke	Kiểm tra độ chính xác của script	3 – 5 VUs · < 3 phút	Script có chạy đúng trước khi đổ tải lớn không?
Load	Duy trì hiệu năng ở tải trung bình	50 – 70% ngưỡng · 01 – 04 giờ	Hệ thống có ổn định ở tải dự kiến không?
Stress	Đẩy tải trên trung bình → cao	100 – 125% ngưỡng / peak · 01 – 04 giờ	Hệ thống suy giảm và gãy ở mức nào?
Endurance (Soak)	Chạy liên tục thời gian dài	50 – 70% ngưỡng · 08 – 32 giờ	Có vấn đề tích lũy (memory leak…) không?
Spike	Cú sốc tải tăng vọt đột ngột	100 – 125% ngưỡng / peak · 01 – 04 giờ	Hệ thống xử lý cú sốc tức thời ra sao?
Breakpoint	Tìm giới hạn trên (bottleneck)	Tăng bước 5 – 10 VUs, giữ 4 – 10 phút/bước	Giới hạn tối đa của hệ thống ở đâu?

Mô hình trực quan để dễ hình dung

Sự khác biệt giữa các loại kiểm thử thể hiện rõ nhất qua hình dạng đường tải theo thời gian — tải phẳng, tải tăng dần, cú sốc nhọn hay đường chạy dài. Mô hình dưới đây minh họa trực quan sự khác nhau đó:

Kinh nghiệm thực chiến. Đừng coi sáu loại này là các lựa chọn loại trừ nhau. Trong một dự án thật, chúng nối tiếp nhau theo trình tự: Smoke để chốt script, Breakpoint để tìm ngưỡng khi chưa có số liệu, rồi mới đến Load / Stress / Spike / Endurance dựng trên ngưỡng đã biết. Chọn loại trước khi chọn công cụ — vì cùng một công cụ (như JMeter hay k6) đều chạy được tất cả, nhưng kịch bản và kết luận thì hoàn toàn khác nhau.

Kết luận

"Kiểm thử hiệu năng" không phải một bài test, mà là một họ các loại test — mỗi loại có hình dạng tải, thời lượng và mục tiêu riêng. Smoke kiểm script, Load xác nhận tải bình thường, Stress đẩy quá ngưỡng, Endurance phơi bày lỗi tích lũy, Spike mô phỏng cú sốc, Breakpoint đi tìm giới hạn. Nắm vững bản đồ này, bạn sẽ chọn đúng loại test cho đúng câu hỏi — thay vì chạy thật nhiều mà vẫn bỏ lọt rủi ro nguy hiểm nhất.

Bạn thường dùng loại kiểm thử hiệu năng nào nhất trong dự án của mình, và đã từng "vỡ ra" điều gì khi áp dụng? Hãy chia sẻ để cộng đồng cùng học hỏi nhé. Hẹn gặp bạn ở bài tiếp theo: "Cách thức thực hiện kiểm thử hiệu năng cho Breakpoint / Load / Endurance".

Tham khảo: Grafana k6 — Test types.