Giới thiệu

Trong quy trình phát triển và triển khai phần mềm, kiểm thử hiệu năng đóng vai trò thiết yếu để đảm bảo ứng dụng hoạt động ổn định trong môi trường thực tế. Trong số các loại hình kiểm thử, Stress Test là phương pháp giúp kiểm tra hệ thống khi bị đặt dưới điều kiện tải trọng vượt ngưỡng, mô phỏng các tình huống xấu nhất có thể xảy ra về mặt lưu lượng người dùng hoặc xử lý giao dịch.

Stress Test là gì?

Stress Test (kiểm thử quá tải) là kỹ thuật kiểm thử phi chức năng nhằm:

• Xác minh khả năng xử lý tải cao bất thường.
• Phát hiện các giới hạn về phần mềm, phần cứng và hạ tầng.
• Đánh giá khả năng phục hồi của hệ thống sau khi gặp sự cố.

Trong thực tế, tải trọng được thiết lập trong bài kiểm thử stress thường vượt xa mức tải trung bình, với mục tiêu kiểm tra giới hạn chịu đựng và các điểm yếu tiềm ẩn trong hệ thống.

Cách tính tải trọng tương lai

Xác định tải trọng cho Stress Test không thể dựa vào cảm tính. Thay vào đó, cần kết hợp giữa dữ liệu lịch sử và kế hoạch tăng trưởng kinh doanh.

Ví dụ: Nếu hệ thống hiện tại phục vụ tối đa ~239 VUs, và tốc độ tăng trưởng là 20%/năm, ta có thể tính các mức tải kiểm thử như:

• 125% → ~ 300 VUs.
• 150% → ~ 360 VUs.
• 200% → ~ 480 VUs.

Hoặc đôi lúc chúng ta cũng cần thực hiện với mức tải dựa trên peak time: hệ số có thể là 2X; 4X; 6X; 8X (Có nghĩa kiểm tra với gấp 2,4,6,8 lần peak time – thông số được đo đếm trong điều kiện thực tế)

Kinh nghiệm thực tế: Với các ứng dụng mới hoặc chưa có số liệu đầy đủ, nên bắt đầu bằng cách xác định Break-point và trao đổi với BA, DevOps để xác lập ngưỡng kiểm thử phù hợp.

Mục đích của Stress Test

• Xác minh khả năng đáp ứng tải tăng trưởng trong tương lai.
• Kiểm tra thời gian phản hồi của hệ thống khi bị quá tải.
• Đo lường mức tiêu thụ tài nguyên (CPU, RAM, I/O).
• Phát hiện bottleneck, lỗi logic và sự cố hiệu năng.
• Kiểm tra hệ thống có thể tự phục hồi sau crash hay không.

Phương pháp thực hiện với JMeter

• Công cụ: Apache JMeter.
• Plugin: Concurrency Thread Group (cài đặt từ Plugin Manager, hoặc download tại đây); ngoài ra bạn cũng có thể sử dụng Ultimate Thread Group như dưới.
• Cấu hình đề xuất
  • Target Concurrency: Tổng số lượng người dùng ảo ~ VU
  • Ramp-up Time: Thời gian khởi tạo để đạt số lượng VU
  • Ramp-up Steps: Count Số bước tăng tải
  • Hold Target Rate Time: Thời gian duy trì mức tải sau khi khởi tạo đủ VU

Lưu ý kinh nghiệm thực chiến:

• Kịch bản nên chạy ít nhất từ 01h – 04h.
• Thời gian ramp-up nên giới hạn trong ≤ 1/3 tổng thời gian test.
  • Ví dụ: Test 01h → Ramp-up: tối đa 20 phút, Hold time: 40 phút (Nếu hạ tầng test mạnh, bạn có thể rút ngắn ramp-up để tập trung phân tích giai đoạn ổn định).
• Thông tin config như sau: Giả sử hệ thống đang hoạt động ổn định ở mức 210 CCUs. Theo chiến lược tăng trưởng, mức tải stress nên được đẩy lên 125%, tức khoảng 260 CCUs.

Sử dụng Ultimate Thread Group:

Kinh nghiệm triển khai thực tế

• Chuẩn hóa dữ liệu đầu vào: Dữ liệu test phải phản ánh hành vi thật của người dùng, tránh dùng dữ liệu “rác” gây sai lệch kết quả.
• Giám sát toàn diện: Sử dụng các công cụ như Grafana, Prometheus… để theo dõi hiệu năng hệ thống theo thời gian thực.
• Lặp lại và tinh chỉnh kịch bản: Một bài test không đủ., hãy chạy nhiều lần, điều chỉnh từng tham số và so sánh kết quả để đưa ra nhận định chính xác.
• Đừng chỉ nhìn vào response time: Phải đánh giá cả: throughput, lỗi HTTP, log backend, memory leak, CPU spike, disk IO…

Kết luận

Stress Test không đơn thuần là “ép tải cao” mà là một chiến lược để nhìn thấy trước những điểm gãy của hệ thống. Nếu thực hiện bài bản, bạn có thể chủ động xử lý bottleneck, tối ưu chi phí hạ tầng, và đặc biệt là ngăn ngừa downtime khi hệ thống thật sự gặp áp lực lớn từ người dùng.

Bạn đã từng gặp sự cố trong khi làm Stress Test chưa? Hãy chia sẻ kinh nghiệm thực chiến của bạn để cộng đồng cùng học hỏi và cải thiện kỹ năng kiểm thử hiệu năng!