Đa số ứng viên QA chỉ chuẩn bị functional testing — performance testing ít được chuẩn bị kỹ nên trở thành cơ hội tốt để tạo ấn tượng khác biệt nếu bạn nắm vững, đặc biệt với các vị trí QA senior hoặc SDET.
"Kết quả load test cho thấy response time tăng dần theo thời gian dù tải không đổi, vấn đề có thể là gì?" — Đây là dấu hiệu điển hình của memory leak hoặc connection pool bị cạn kiệt dần (connection không được release đúng cách) — cần soak testing dài hơn để xác nhận và kết hợp với giám sát tài nguyên hệ thống (memory, CPU, số connection) trong suốt quá trình test.
"Bạn thiết kế kịch bản load test cho 1 API thế nào?" — Cần xác định rõ: số user đồng thời thực tế (dựa trên dữ liệu thật, không đoán), pattern tăng tải (ramp-up từ từ hay tăng đột ngột), và metric cần theo dõi (response time percentile — p95/p99 quan trọng hơn trung bình vì phản ánh trải nghiệm của phần lớn user, error rate, throughput).
"Tại sao nên nhìn p95/p99 thay vì response time trung bình?" — Trung bình dễ bị "che giấu" bởi đa số request nhanh, trong khi 1 nhóm nhỏ user gặp trải nghiệm rất tệ (p99 cao) không được phản ánh rõ qua số trung bình — với hệ thống lớn, ngay cả 1% user gặp trải nghiệm tệ cũng là con số tuyệt đối lớn cần quan tâm.
k6, JMeter, Gatling — hiểu được cách viết kịch bản test cơ bản với ít nhất 1 công cụ, và biết cách đọc/phân tích báo cáo kết quả (không chỉ chạy xong nhìn số tổng quan) là điểm cộng thực chất.
Nếu từng thực hiện performance test thật, kể rõ: mục tiêu test (SLA cần đạt), kịch bản thiết kế, và vấn đề phát hiện được — số liệu cụ thể (hệ thống chịu được tối đa bao nhiêu request/giây trước khi degrade) luôn thuyết phục hơn "đã làm performance test".