# Load Test Vs Stress Test + Các Chỉ Số Hiệu Năng

> Hồi mới đụng tới kiểm thử hiệu năng, mình cũng lẫn lộn hai khái niệm này suốt. 🙂 Nghe thì na ná nhau — đều là "đổ tải vào hệ thống" — nhưng mục tiêu lại khác hẳn. Bài này mình gỡ rối cho bạn chuyện load test vs stress test: khác nhau ở đâu, chạy thế nào, quan sát chỉ số gì. Mình dùng lại bối cảnh quen thuộc suốt series — một Hệ thống đặt phòng họp nội bộ của công ty — để bạn dễ hình dung.

- **URL canonical**: https://itlearn.vn/blog/load-test-vs-stress-test
- **Published**: 2026-07-16T11:00:00+07:00
- **Modified**: 2026-08-24T07:22:33+07:00
- **Author**: Anh Tuấn
- **Category**: Performance test (https://itlearn.vn/blog/cat/performance-test)
- **Reading time**: 11 phút
- **Source site**: IT LEARN — Học viện Software Testing tiếng Việt

---

## Load vs Stress — bảng phân biệt nhanh

**Load test vs stress test khác nhau ở mục tiêu: load test kiểm tra hệ thống dưới tải kỳ vọng (số người dùng thật, kể cả giờ cao điểm) xem có đáp ứng đúng cam kết không; còn stress test cố tình đẩy tải vượt ngưỡng cho tới điểm gãy (breaking point) để xem hệ thống hỏng ra sao và phục hồi thế nào.** Nói ngắn: load test hỏi "chịu nổi mức bình thường chứ?", stress test hỏi "gãy ở đâu và gãy có êm không?".

Cả hai đều là dạng **performance testing** (kiểm thử hiệu năng) — một loại kiểm thử phi chức năng, thuộc nhóm *performance efficiency* trong tiêu chuẩn chất lượng ISO/IEC 25010. Chúng không kiểm tra "app làm đúng chức năng không" mà kiểm tra "app làm nhanh, ổn định, chịu tải tới đâu".

Tiêu chí

Load test

Stress test

**Mục tiêu**

Xác nhận đáp ứng ở tải kỳ vọng & peak

Tìm điểm gãy, xem cách hỏng và phục hồi

**Mức tải**

Bằng hoặc quanh tải thật dự kiến

Vượt ngưỡng, tăng dần tới khi hệ thống hỏng

**Câu hỏi trả lời**

"Có đạt SLA ở giờ cao điểm không?"

"Bao nhiêu user thì sập? Sập có êm không?"

**Chỉ số quan sát**

Response time, throughput ổn định

Điểm bắt đầu lỗi, degradation, recovery

**Kết quả kỳ vọng**

Hệ thống chạy mượt, trong ngưỡng

Hệ thống hỏng có kiểm soát, hồi phục được

## Load testing là gì

**Load testing là gì? Đó là việc mô phỏng số lượng người dùng và giao dịch đúng bằng mức tải mà hệ thống dự kiến gặp trong thực tế — cả tải trung bình lẫn tải đỉnh (peak) — để xác nhận hệ thống vẫn đáp ứng đúng cam kết về tốc độ và độ ổn định.** Trọng tâm là "bình thường và cao điểm", không phải "vắt kiệt".

Với Hệ thống đặt phòng họp, giả sử công ty có 200 nhân viên, và giờ cao điểm là 8–9h sáng khi mọi người tranh nhau đặt phòng cho cuộc họp trong ngày. Load test sẽ mô phỏng khoảng 200 người dùng đồng thời đăng nhập, tìm phòng trống, đặt phòng — rồi đo xem trang phản hồi có còn nhanh, giao dịch có bị rớt không.

- **Mục tiêu:** kiểm chứng hệ thống đạt **SLA/SLO** (ví dụ: 95% request trả về dưới 2 giây) ở mức tải thật.

- **Cách chạy:** tăng tải dần (ramp-up) tới mức kỳ vọng rồi giữ ổn định một khoảng, quan sát response time và throughput có "phẳng" không.

- **Quan sát:** response time không tăng vọt, error rate gần 0, throughput đạt mức mong đợi.

Load test trả lời cho câu hỏi kinh doanh: "Đến ngày go-live, khi cả công ty vào dùng, app có trụ được không?". Muốn hiểu bức tranh lớn hơn về loại kiểm thử này, bạn đọc thêm bài [performance testing là gì](/blog/performance-testing-la-gi).

## Stress testing là gì

**Stress testing là gì? Đó là việc cố tình đẩy tải vượt xa ngưỡng bình thường — tăng dần số người dùng ảo cho tới khi hệ thống bắt đầu lỗi hoặc sập — nhằm tìm ra breaking point (điểm gãy) và quan sát hệ thống suy giảm, hỏng, rồi phục hồi ra sao.** Ở đây ta chủ động "làm khó" hệ thống, không mô phỏng tải thật nữa.

Vẫn là Hệ thống đặt phòng họp, nhưng lần này mình không dừng ở 200 người. Mình đẩy lên 500, 1000, 2000 người dùng đồng thời… tới khi trang bắt đầu timeout, database từ chối kết nối, hoặc server trả lỗi 500. Điểm mà hệ thống "gục" chính là breaking point ta muốn biết.

- **Mục tiêu:** biết giới hạn chịu đựng, xem lỗi xuất hiện ở đâu trước (CPU, RAM, connection pool, database), và hệ thống có **hồi phục** khi hạ tải không.

- **Cách chạy:** tăng tải liên tục vượt ngưỡng, hoặc giữ tải rất cao trong thời gian dài, ghi lại thời điểm và cách hệ thống bắt đầu degrade.

- **Quan sát:** error rate leo thang, response time tăng đột biến, và quan trọng: sau khi hạ tải, hệ thống có tự trở lại bình thường (graceful recovery) hay treo luôn.

Một hệ thống tốt không phải là hệ thống "không bao giờ gãy" — mà là gãy có kiểm soát: báo lỗi rõ ràng, không mất dữ liệu, và phục hồi được khi tải giảm.

## Các chỉ số: response time, throughput, error rate, concurrency

Dù chạy load hay stress test, bạn đều nhìn vào một bộ chỉ số hiệu năng chung. Đây là bảng mình hay dùng để giải thích cho học viên:

Chỉ số

Ý nghĩa

Đơn vị

**Response time**

Thời gian từ lúc gửi request tới lúc nhận đủ phản hồi

ms / giây

**Throughput**

Số request (hoặc giao dịch) hệ thống xử lý trong 1 giây

req/s hoặc TPS

**Error rate**

Tỷ lệ request lỗi trên tổng số request

%

**Concurrency**

Số người dùng / request đang hoạt động cùng lúc

số user

Vài lưu ý mình muốn nhấn để bạn không hiểu sai:

- **Response time** — đừng chỉ nhìn con số trung bình (average), vì nó dễ che giấu những request chậm. Nên nhìn **percentile**, thường là **p90/p95** (90% hoặc 95% request nhanh hơn ngưỡng này). Ví dụ "p95 = 1,8 giây" nghĩa là 95% người dùng chờ dưới 1,8 giây — thông tin hữu ích hơn nhiều so với con số trung bình.

- **Throughput** là **throughput là gì** hay bị nhầm với concurrency: throughput đo *việc đã xong* (req/s), còn concurrency đo *số việc đang chạy song song*. Throughput cao mà response time thấp mới là tốt.

- **Error rate** tăng là dấu hiệu đầu tiên báo hệ thống sắp tới giới hạn — trong stress test, đây thường là "chuông báo" của breaking point.

- **Concurrency** là số người dùng thực sự hoạt động đồng thời; trong công cụ như JMeter nó được mô phỏng bằng **virtual users** (thread). Lưu ý: 1000 virtual users cấu hình sẵn không đồng nghĩa 1000 request cùng lúc — còn phụ thuộc ramp-up và thời gian nghĩ (think time).

Muốn thực hành đo các chỉ số này bằng công cụ cụ thể, bạn xem [JMeter là gì](/blog/jmeter-la-gi) và bài hướng dẫn [kiểm thử hiệu năng web JMeter](/blog/kiem-thu-hieu-nang-jmeter).

## Spike & endurance test (bổ sung)

Ngoài load và stress, có hai biến thể bạn nên biết vì hay bị hỏi trong phỏng vấn:

- **Spike test:** đổ một lượng tải **tăng đột ngột** trong thời gian rất ngắn rồi rút đi, mô phỏng tình huống bất ngờ — ví dụ công ty gửi email thông báo họp toàn thể và cả nghìn người vào đặt phòng cùng một phút. Mục tiêu là xem hệ thống có nuốt nổi cú sốc và phục hồi nhanh không.

- **Endurance test (soak test):** giữ tải ở mức vừa phải (thường quanh mức load kỳ vọng) nhưng **kéo dài nhiều giờ hoặc nhiều ngày**, để phát hiện các vấn đề chỉ lộ ra theo thời gian như **memory leak** (rò rỉ bộ nhớ), đầy log, hoặc connection pool cạn dần.

Có thể hình dung nhanh: spike test kiểm tra "cú sốc bất ngờ", endurance test kiểm tra "sức bền lâu dài", load test kiểm tra "ngày làm việc bình thường", còn stress test kiểm tra "giới hạn chịu đựng". Bốn góc nhìn bổ sung cho nhau, không thay thế nhau.

Nếu gặp thuật ngữ lạ khi đọc, bạn tra nhanh ở [thuật ngữ kiểm thử](/blog/thuat-ngu-kiem-thu/) cho chắc.

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

### Load test khác stress test thế nào?

Load test kiểm tra hệ thống dưới tải kỳ vọng (số người dùng thật, kể cả giờ cao điểm) để xác nhận đạt cam kết về tốc độ và ổn định. Stress test thì cố tình đẩy tải vượt ngưỡng tới điểm gãy, xem hệ thống hỏng ra sao và có phục hồi được không. Một cái đo "bình thường", một cái đo "giới hạn".

### Throughput là gì?

Throughput là số request hoặc giao dịch mà hệ thống xử lý xong trong một giây, thường tính bằng req/s hoặc TPS. Nó đo lượng việc đã hoàn thành, khác với concurrency đo số việc đang chạy song song. Throughput cao đi kèm response time thấp và error rate gần 0 mới là dấu hiệu hệ thống khỏe.

### Response time bao nhiêu là đạt?

Không có con số chuẩn chung, mà tùy cam kết SLA của từng dự án. Nên đo theo percentile (p90/p95) thay vì trung bình, vì trung bình dễ che giấu request chậm. Ví dụ mục tiêu thường gặp là "95% request dưới 2 giây". Con số cụ thể do đội và khách hàng thống nhất trước khi test.

### Spike test là gì?

Spike test đổ một lượng tải tăng đột ngột trong thời gian rất ngắn rồi rút đi, mô phỏng tình huống bất ngờ như cả nghìn người truy cập cùng một phút. Mục tiêu là xem hệ thống có chịu nổi cú sốc và phục hồi nhanh không. Nó khác stress test ở chỗ nhấn vào tính đột ngột chứ không phải mức tải tối đa kéo dài.

### Concurrency là gì?

Concurrency là số người dùng hoặc request đang hoạt động đồng thời trên hệ thống tại một thời điểm. Trong công cụ như JMeter, nó được mô phỏng bằng virtual users (thread). Lưu ý số virtual users cấu hình sẵn không đồng nghĩa số request cùng lúc, vì còn phụ thuộc ramp-up và think time giữa các thao tác. Bạn muốn học kiểm thử hiệu năng bài bản, thực hành trên dự án thật với JMeter? Tham khảo khóa [kiểm thử hiệu năng](/performance.html) của IT LEARN nhé.