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

> Có một câu tôi nghe hoài từ học viên: "Bài test chức năng của em pass hết, sao lên production lại chậm rùa bò?" 🙂 Đó chính là lúc performance testing là gì trở thành câu hỏi đáng tiền. Bài pillar này tôi sẽ dẫn bạn đi hết từ định nghĩa, các loại, chỉ số, công cụ (JMeter, k6, Gatling) đến quy trình một bài kiểm thử hiệu năng thật sự — gọn nhưng đủ để bắt đầu.

- **URL canonical**: https://itlearn.edu.vn/blog/performance-testing-la-gi
- **Published**: 2026-07-12T11:00:00+07:00
- **Modified**: 2026-07-12T12:32:15+07:00
- **Author**: Anh Tuấn
- **Category**: Performance test (https://itlearn.edu.vn/blog/cat/performance-test)
- **Reading time**: 12 phút
- **Source site**: IT LEARN — Học viện Software Testing tiếng Việt

---

## 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](/blog/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ì](/blog/jmeter-la-gi).

## 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ử](/blog/cac-loai-kiem-thu) để đị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](/performance.html) 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.

## Câu hỏi thường gặp

### Performance testing là gì?

Performance testing (kiểm thử hiệu năng) là loại kiểm thử phi chức năng theo ISTQB, đá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. Nó trả lời câu hỏi hệ thống chạy có nhanh, có mượt và trụ nổi khi đông người dùng đồng thời hay không.

### Load test khác stress test không?

Khác. Load testing mô phỏng tải kỳ vọng ở mức bình thường tới đỉnh dự kiến để xem hệ thống đáp ứng tốt không. Stress testing lại cố tình đẩy vượt giới hạn cho tới khi hệ thống hỏng, nhằm tìm ngưỡng chịu tải tối đa và quan sát cách nó gãy. Hai mục tiêu khác nhau rõ rệt.

### Công cụ test hiệu năng nào phổ biến?

Phổ biến nhất với người mới là Apache JMeter nhờ giao diện kéo-thả, miễn phí, không cần code. Ngoài ra có k6 (viết script JavaScript, hợp CI/CD), Gatling (DSL Scala/Java, report đẹp) và Locust (Python). Bạn nên bắt đầu từ JMeter rồi mở rộng dần theo nhu cầu dự án.

### Response time bao nhiêu là tốt?

Không có con số vàng cho mọi hệ thống; ngưỡng đến từ NFR/SLA của dự án. Theo hướng dẫn trải nghiệm kinh điển, dưới 1 giây là mượt, tới 10 giây là giới hạn giữ chú ý người dùng. Với web hiện đại, nhiều nhóm nhắm p95 dưới 2–3 giây. Hãy dùng percentile thay vì chỉ trung bình.

### Performance test có cần code không?

Không bắt buộc để bắt đầu. Với JMeter, bạn dựng test plan bằng giao diện kéo-thả mà gần như không lập trình. Bạn chỉ cần biết code khi muốn dùng k6 (JavaScript), Gatling (Scala/Java) hay Locust (Python), hoặc đưa test vào pipeline CI/CD. Tư duy về tải quan trọng hơn kỹ năng code. Muốn học kiểm thử hiệu năng bài bản với JMeter và thực hành trên hệ thống thật, bạn có thể tham khảo [khóa Performance JMeter](/performance.html) của IT LEARN. Nếu bạn mới bắt đầu, hãy nắm chắc nền tảng với bài [JMeter là gì](/blog/jmeter-la-gi) và phân biệt [load test vs stress test](/blog/load-test-vs-stress-test) trước.