Performance Testing Là Gì? Kiểm Thử Hiệu Năng A–Z

Performance testing là gì?

Performance testing (kiểm thử hiệu năng) là một loại kiểm thử phi chức năng (non-functional testing) đánh giá tốc độ, độ ổn định và khả năng chịu tải của phần mềm dưới một mức tải xác định. Thay vì hỏi "tính năng chạy có đúng không", performance test hỏi "chạy có nhanh, có mượt, có trụ nổi khi đông người dùng không".

Theo ISTQB, đây là kiểm thử thuộc nhóm non-functional — soi vào cách hệ thống vận hành chứ không phải cái hệ thống làm. Một API trả về đúng dữ liệu vẫn có thể "trượt" bài performance test nếu nó mất 8 giây để phản hồi khi có 500 người truy cập cùng lúc.

Lấy ví dụ quen thuộc trong series này — Hệ thống đặt phòng họp nội bộ. Chức năng đặt phòng có thể hoạt động hoàn hảo khi một mình bạn test. Nhưng 9 giờ sáng thứ Hai, khi cả công ty cùng vào giành phòng, hệ thống mới lộ điểm yếu: trang tải chậm, nút bấm treo, có người đặt được có người xoay vòng. Kiểm thử hiệu năng chính là để phát hiện những điểm gãy đó trước khi người dùng thật gặp phải.

Các loại kiểm thử hiệu năng: load, stress, spike, endurance

Performance testing không phải một phép test duy nhất mà là một họ các kiểu test, mỗi kiểu trả lời một câu hỏi khác nhau về tải. Bảng dưới tóm tắt bốn kiểu phổ biến nhất mà tester nên nắm:

Loại | Mô phỏng điều gì | Trả lời câu hỏi
Load testing | Tải kỳ vọng (bình thường tới đỉnh dự kiến) | Hệ thống đáp ứng tốt ở mức tải thực tế không?
Stress testing | Đẩy quá giới hạn cho tới khi hỏng | Ngưỡng chịu tải tối đa ở đâu, hỏng thế nào?
Spike testing | Tải tăng vọt đột ngột rồi giảm | Chịu nổi cú tăng đột biến (flash sale) không?
Endurance (soak) testing | Tải vừa phải kéo dài nhiều giờ/ngày | Có rò rỉ bộ nhớ, xuống cấp theo thời gian không?

Ngoài bốn kiểu trên, bạn sẽ còn gặp scalability testing (đo khả năng mở rộng khi thêm tài nguyên) và volume testing (kiểm thử với khối lượng dữ liệu lớn). Với người mới, hãy bắt đầu vững hai kiểu nền tảng là load và stress trước. Muốn hiểu rõ khác biệt và khi nào dùng cái nào, đọc bài chuyên sâu load test vs stress test.

Chỉ số quan trọng: response time, throughput, error rate

Đo performance mà không nắm chỉ số thì giống như lái xe không nhìn đồng hồ. Đây là những metric cốt lõi bạn phải đọc được trong mọi báo cáo kiểm thử hiệu năng:

Response time (thời gian phản hồi): thời gian từ lúc gửi request đến khi nhận đủ response. Đừng chỉ nhìn số trung bình — hãy xem percentile (p90, p95, p99). Chỉ số p95 nghĩa là 95% request nhanh hơn ngưỡng đó; nó phản ánh trải nghiệm "người xui" chân thực hơn con số trung bình rất nhiều.

Throughput: số request (hoặc giao dịch) hệ thống xử lý được trong một đơn vị thời gian, thường tính bằng requests/giây. Throughput cao = năng suất xử lý tốt.

Latency: độ trễ mạng — thời gian request đi tới server trước khi được xử lý. Latency là một phần của response time.

Error rate: tỷ lệ request lỗi trên tổng số. Khi tải tăng mà error rate vọt lên, đó là dấu hiệu hệ thống bắt đầu quá tải.

Concurrent users (người dùng đồng thời): số người cùng tương tác tại một thời điểm — biến số bạn tăng dần để quan sát các chỉ số trên phản ứng thế nào.

Điểm mấu chốt: ngưỡng "đạt/không đạt" của các chỉ số này không phải do tester tự nghĩ ra, mà đến từ yêu cầu phi chức năng (NFR) hoặc SLA của dự án. Ví dụ NFR ghi "p95 của API đặt phòng ≤ 2 giây với 500 người dùng đồng thời" — đó chính là tiêu chí pass/fail của bài test.

Công cụ kiểm thử hiệu năng: JMeter, k6, Gatling

Có nhiều công cụ, nhưng người mới chỉ cần chọn một cái để bắt đầu. Bảng dưới so sánh những công cụ phổ biến nhất, kèm ngôn ngữ và điểm mạnh để bạn định hướng:

Công cụ | Ngôn ngữ / cách viết test | Điểm mạnh
Apache JMeter | GUI kéo-thả, chạy CLI (Java) | Miễn phí, cộng đồng lớn, không cần code — hợp người mới
k6 | Script JavaScript, chạy CLI | Nhẹ, hợp CI/CD và developer, tích hợp Grafana
Gatling | DSL Scala/Java (dạng code) | Report đẹp, hiệu năng cao, hợp automation hướng code
Locust | Script Python | Định nghĩa hành vi user bằng Python, dễ mở rộng

Lời khuyên thật lòng: nếu bạn là tester mới, hãy bắt đầu với JMeter. Giao diện kéo-thả cho bạn "nhìn thấy" một test plan gồm gì (thread group, sampler, listener) mà chưa cần viết dòng code nào. Khi đã quen tư duy tải và muốn đưa test vào CI/CD, bạn chuyển dần sang k6 (JavaScript) hoặc Gatling rất nhẹ nhàng. Chi tiết cách dựng bài test đầu tiên, xem bài JMeter là gì.

Quy trình một bài test hiệu năng

Một bài kiểm thử hiệu năng nghiêm túc đi theo các bước có trật tự, không phải "mở JMeter bắn đại vài nghìn request rồi xem". Đây là quy trình tôi vẫn hướng dẫn học viên:

Xác định mục tiêu & NFR: chốt chỉ số cần đo và ngưỡng pass/fail (lấy từ SLA/NFR), ví dụ p95 ≤ 2s với 500 concurrent users.

Chọn kịch bản & tiêu chí tải: xác định luồng nghiệp vụ quan trọng nhất (đăng nhập, đặt phòng), số người dùng ảo, ramp-up (tăng tải dần) và think time (thời gian "nghỉ" mô phỏng người thật).

Chuẩn bị môi trường & dữ liệu test: môi trường càng giống production càng tốt; chuẩn bị test data đủ lớn để tránh cache che lấp vấn đề.

Dựng script & tạo baseline: viết test trong công cụ, chạy một lần ở tải thấp để lấy baseline làm mốc so sánh.

Thực thi test: chạy load/stress/spike theo kế hoạch, tăng tải dần và giám sát cả phía client lẫn server (CPU, RAM, database).

Phân tích & tìm bottleneck: đối chiếu response time, throughput, error rate với ngưỡng; khoanh vùng nghẽn (DB chậm? thiếu index? hết connection pool?).

Báo cáo & test lại: ghi nhận kết quả, đề xuất tối ưu; sau khi dev fix thì chạy lại để xác nhận cải thiện.

Bước hay bị bỏ qua nhất là số 1 và số 6. Không có ngưỡng rõ ràng thì không biết test "đậu hay rớt"; không phân tích bottleneck thì bạn chỉ có một đống biểu đồ mà không biết sửa gì.

Tester cần biết gì về performance

Nhiều bạn lo "phải giỏi code mới làm được hiệu năng". Thực tế, với JMeter bạn có thể chạy một bài load test cơ bản mà gần như không lập trình. Điều quan trọng hơn code là tư duy: hiểu luồng nghiệp vụ nào chịu tải nặng, đọc được chỉ số, và biết đặt câu hỏi đúng khi số liệu bất thường.

Performance testing nằm trong bức tranh lớn hơn của kiểm thử phi chức năng — cùng nhóm với security, usability, compatibility theo mô hình chất lượng ISO/IEC 25010. Nếu bạn chưa nắm rõ các nhánh test khác nhau, hãy đọc bài tổng quan các loại kiểm thử để định vị performance test trong toàn cảnh.

Với tester đang muốn rẽ sâu, đây là những năng lực nên rèn:

Đọc hiểu NFR/SLA: dịch được yêu cầu nghiệp vụ thành ngưỡng đo lường cụ thể.

Thiết kế kịch bản tải sát thực tế: ramp-up, think time, phân bổ luồng đúng tỷ lệ người dùng thật.

Giám sát tài nguyên server: biết nhìn CPU, memory, disk I/O, database để tìm nghẽn.

Giao tiếp kết quả: trình bày cho dev và quản lý hiểu "hệ thống trụ được đến đâu, gãy ở đâu".

Đây cũng chính là phần lõi thực hành trong khóa Performance JMeter của IT LEARN — học viên dựng test plan thật trên hệ thống mẫu, đọc chỉ số và truy bottleneck.