[Performance JMeter] Bài 1 - Tổng quan và Tư duy (Mindset) về Performance Testing

✅ Khái niệm
✅ Các loại Performance Testing
✅ Quy trình thực hiện Performance Testing
✅ So sánh giữa Functional Test và Non-functional Test

✅ 1. Khái niệm

Performance Testing là quá trình kiểm thử để đánh giá tốc độ, độ ổn định, khả năng mở rộng và tính phản hồi của hệ thống dưới tải. Mục tiêu là đo lường các chỉ số như Response time và Throughput, từ đó phát hiện và xử lý các điểm nghẽn hiệu năng.

🔹 Response Time

Thời gian phản hồi của một request tính từ lúc client gửi gói tin đến lúc nhận lại phản hồi.

→ Cho biết tốc độ phản hồi nhanh hay chậm của hệ thống.

📊 Các chỉ số phổ biến trong đo Response Time:

🎯 Ghi nhớ:

• Các percentile giúp đánh giá độ ổn định và phân phối hiệu năng toàn hệ thống.
• Không nên chỉ dựa vào trung bình, vì có thể bỏ qua các trường hợp chậm bất thường gây ảnh hưởng thực tế.

🔹 Throughput (Thông lượng)

Throughput là số lượng request được xử lý trong một đơn vị thời gian, phản ánh khả năng xử lý đồng thời của hệ thống.

📊 Các chỉ số đo trong Throughput:

✅ 2. Các loại Performance Testing

Khi nhắc đến Performance Testing, nhiều người — đặc biệt là những người chưa từng thực hiện kiểm thử hiệu năng — rất dễ hiểu nhầm về khái niệm này.

Ví dụ, khi ai đó nói:
“Tôi muốn kiểm thử hiệu năng cho hệ thống A”, thì trên thực tế, câu nói này vẫn còn quá chung chung và chưa xác định rõ cần thực hiện những gì.

Performance Testing thực chất là một nhánh lớn trong kiểm thử phần mềm, tương tự như các khái niệm Manual Testing hay Automation Testing. Mỗi nhánh đều bao gồm nhiều kỹ thuật, công cụ và mục tiêu khác nhau bên trong.

Bạn không thể chỉ đơn giản nói “làm performance test” rồi bắt đầu kiểm thử được ngay. Thay vào đó, bạn cần xác định rõ:

• Mục tiêu kiểm thử là gì?
• Sẽ thực hiện loại kiểm thử hiệu năng nào? (Load, Stress, Spike, Endurance, Scalability, Volume...)
• Kịch bản kiểm thử và chỉ số đầu ra cần đo lường là gì?

Hiểu đúng và đầy đủ về khái niệm này sẽ giúp bạn xây dựng kế hoạch kiểm thử hiệu năng một cách hiệu quả và có định hướng rõ ràng hơn.

🔸 Load Testing

Load Testing là hình thức kiểm thử hiệu năng bằng cách tăng dần tải truy cập vào hệ thống để đánh giá ngưỡng tối đa mà hệ thống có thể xử lý một cách ổn định và hiệu quả.

Mục tiêu chính của Load Testing là xác định Capacity – tức ngưỡng mà tại đó hệ thống vẫn có thể hoạt động trơn tru, không xảy ra lỗi, và đáp ứng thời gian phản hồi chấp nhận được.

Khi tải vượt qua ngưỡng này, hệ thống thường bắt đầu xuất hiện các vấn đề như:

• Tỷ lệ lỗi tăng cao (Error rate tăng),
• Thời gian phản hồi tăng đột biến (Response time cao),
• Hiệu suất giảm sút rõ rệt.

👉 Load Testing giúp phát hiện sớm các điểm giới hạn của hệ thống trước khi đưa vào vận hành thực tế, từ đó hỗ trợ lên kế hoạch nâng cấp hoặc tối ưu hiệu năng phù hợp với nhu cầu sử dụng.

Ví dụ cụ thể:

Hình 1: Biểu đồ Response time

Hình 2: Biểu đồ tải tăng dần

Hình 3: Biểu đồ số thread tăng dần

=> Dựa vào 3 biểu đồ trên thì ta thấy Capacity = 80 TPS response time ngưỡng 1100ms

🔸 Stress Testing

 Stress Testing là quá trình kiểm thử hiệu năng bằng cách đưa hệ thống hoạt động với mức tải vượt quá ngưỡng năng lực (capacity) đã được xác định từ quá trình load testing. Mục tiêu của stress testing là tìm ra điểm Breaking point và đánh giá khả năng chịu đựng và phục hồi của hệ thống khi đối mặt với tình trạng quá tải.

Kết quả mong đợi từ stress test là khi hệ thống bị đẩy vượt qua ngưỡng chịu tải, hiệu năng sẽ suy giảm đáng kể, thậm chí có thể xảy ra tình trạng ngừng hoạt động (downtime). Tuy nhiên, khi tải được giảm xuống dưới ngưỡng capacity, hệ thống cần có khả năng tự phục hồi và quay trở lại trạng thái hoạt động ổn định(Recovery).

Breaking point là điểm tại đó hệ thống không còn duy trì được hiệu suất ổn định khi tải tiếp tục tăng. Đây là thời điểm hệ thống bắt đầu:

• Phản hồi chậm đáng kể,
• Xuất hiện lỗi (error rate tăng),
• Hoặc ngừng hoạt động hoàn toàn (crash/downtime).

Ví dụ:

• Nếu hệ thống chạy mượt với 500 tps, nhưng đến 600 thì bắt đầu lỗi nhiều và treo, thì breaking point nằm ở khoảng 600 tps.

Lưu ý: Trên cơ sở lý thuyết là vậy nhưng trong thực tế thì chúng ta không cần phải test đến ngưỡng mà hệ thống chết hẳn. Chúng tả chỉ cần test tầm 80% và thấy hệ thống có vấn đề nghiêm trọng (Ram, cpu > 80%) thì nên ngừng đổ tải và có thể report đánh giá ước lượng được(+10%)

🔸 Spike Testing

 Spike Testing là hình thức kiểm thử hiệu năng nhằm đánh giá khả năng phản ứng của hệ thống khi đối mặt với sự gia tăng tải đột ngột trong một khoảng thời gian ngắn.

Ví dụ điển hình là các hệ thống bán hàng khi triển khai chương trình flash sale. Trước thời điểm mở bán, lưu lượng truy cập vào hệ thống thường thấp. Tuy nhiên, ngay khi bắt đầu mở bán, số lượng người dùng truy cập tăng vọt một cách đột ngột. Hệ thống cần được thiết kế để xử lý hiệu quả những tình huống tăng tải bất ngờ này mà không gặp sự cố về hiệu năng hay ổn định.

Trên thực tế, tại các doanh nghiệp, đội ngũ phát triển (Developers) thường áp dụng kỹ thuật Rate Limiting nhằm giới hạn số lượng yêu cầu đồng thời đến API, giúp bảo vệ hệ thống khỏi tình trạng quá tải. Vì vậy, khi thực hiện các bài kiểm thử spike testing, cần phối hợp chặt chẽ với đội phát triển và bộ phận nghiệp vụ để đảm bảo hiểu rõ cơ chế giới hạn truy cập và các hành vi mong đợi của hệ thống trong các tình huống tương

Hình 4: Biểu đồ lượng thread tăng đột ngột

🔸 Endurance Testing

 Endurance Testing (hay còn gọi là Soak Testing) là hình thức kiểm thử hiệu năng bằng cách đưa hệ thống hoạt động dưới một mức tải ổn định, thấp hơn ngưỡng năng lực (capacity) trong một khoảng thời gian dài (thường từ 8 giờ trở lên).

Mục tiêu của loại kiểm thử này là đánh giá độ ổn định và khả năng duy trì hiệu suất của hệ thống trong thời gian dài. Qua đó, giúp phát hiện các vấn đề tiềm ẩn như:

• Rò rỉ bộ nhớ (memory leak),
• Tăng dần mức sử dụng CPU hoặc RAM,
• Suy giảm hiệu suất theo thời gian,
• Hoặc sự cạn kiệt tài nguyên hệ thống.

Endurance Testing đặc biệt quan trọng đối với các hệ thống phải chạy liên tục không gián đoạn như dịch vụ web, hệ thống thanh toán, hoặc các nền tảng xử lý giao dịch trực tuyến. Các vấn đề liên quan đến resource thường xuất hiện khi hệ thống hoạt động ở một khoảng thời gian dài. Cho nên nếu chỉ sử dụng load test hay stress test thì khó phát hiện được. Đặc biệt với các service mới thì việc sử dụng Endurance test là điều rất cần thiết.

🔸 Scalability Testing

Scalability Testing là loại kiểm thử hiệu năng nhằm đánh giá khả năng mở rộng của hệ thống khi tài nguyên được tăng cường. Việc mở rộng có thể được thực hiện theo hai hướng:

• Mở rộng theo chiều ngang (Horizontal Scaling): Thêm nhiều máy chủ hoặc nút (nodes) vào hệ thống.Ví dụ như thêm instance trong môi trường phân tán hoặc cloud.
• Mở rộng theo chiều dọc (Vertical Scaling): Tăng cường tài nguyên phần cứng cho một máy chủ cụ thể, chẳng hạn như nâng cấp CPU, RAM, hoặc dung lượng đĩa.

Mục tiêu của scalability testing là kiểm tra xem khi tài nguyên tăng lên, hiệu năng hệ thống có được cải thiện tương ứng không, đồng thời đảm bảo hệ thống vẫn ổn định và hoạt động chính xác trong quá trình mở rộng.

Loại kiểm thử này đặc biệt quan trọng đối với các hệ thống cần xử lý lượng lớn người dùng hoặc dữ liệu, và có yêu cầu mở rộng linh hoạt theo nhu cầu thực tế.

Ví dụ: Giả sử hệ thống được cấu hình Auto scale tài nguyên khi mức sử dụng CPU vượt quá 80%. Trong bài kiểm thử khả năng mở rộng, chúng ta sẽ thực hiện các bước sau:

1. Tăng tải dần lên hệ thống, sao cho CPU tiến dần đến ngưỡng 80%.
2. Khi CPU chạm ngưỡng 80%, hệ thống cần tự động scale-up (mở rộng tài nguyên như thêm instance hoặc tăng CPU/RAM).
3. Tiếp tục tăng tải để kiểm tra khả năng hệ thống mở rộng nhiều lần nếu cần.
4. Sau đó, giảm dần tải xuống, và quan sát hệ thống có thực hiện scale-down đúng lúc, thu hồi tài nguyên không còn cần thiết.

Kết quả mong đợi (Expected Result):

• Trong suốt quá trình scale-up và scale-down, các chỉ số hiệu năng quan trọng như:
  • Response Time (thời gian phản hồi),
  • TPS (Transaction Per Second – số giao dịch mỗi giây),
  • Error Rate (tỷ lệ lỗi) đều không bị ảnh hưởng đáng kể và nằm trong ngưỡng chấp nhận được.
• Ở tầng hệ thống:
  • Việc mở rộng (scale) và thu hẹp (scale down) phải diễn ra đúng thời điểm,
  • Thời gian thực hiện scale cần đáp ứng SLA (Service Level Agreement) đã cam kết.
  • Lượng tải được phân bổ đều vào các pod
  • Tài nguyên dư thừa sau khi giảm tải cần được thu hồi tự động để tối ưu chi phí vận hành.

🔸 Volume Testing

Volume Testing (kiểm thử độ lớn dữ liệu) là một loại kiểm thử hiệu năng nhằm đánh giá hệ thống hoạt động như thế nào khi xử lý một lượng dữ liệu rất lớn.

Ví dụ: Trong một hệ thống ecomerce khi hiển thị danh sách đơn hàng. Table order có 1000 record thì response time api  getOrders chỉ mất 200ms để trả ra kết quả. Vậy nếu Table order nở rộng ra lên tới hàng triệu recor thì sao?. Chúng ta cần Vollume testing để xác định được khi độ lớn dữ liệu thay đổ thì hiệu năng của hệ thống cũng không bị ảnh hưởng. Các kỹ thuật mà develope thường dùng là đánh indexing, chia partition.

✅ 3. Quy trình thực hiện Performance Testing

🔆Quy trình Kiểm thử Hiệu năng (Performance Testing Procedure)

1. Setup Performance Test Environment (Thiết lập môi trường kiểm thử)

• Chuẩn bị phần cứng, phần mềm, dữ liệu thử nghiệm và cấu hình hệ thống để mô phỏng môi trường thực tế.
• Xác định các công cụ kiểm thử (ví dụ: JMeter, Gatling, LoadRunner).
• Giám sát và chuẩn bị các chỉ số hệ thống cần theo dõi: CPU, RAM, Disk, Network, Database, Cache, Message Queue.

2. Establish Performance Criteria Goals (Xác định tiêu chí và mục tiêu hiệu năng)

• Xác định các tiêu chí SLA (Service Level Agreement) cần đạt được:
  • Thời gian phản hồi (Response Time)
  • Thông lượng (Throughput / TPS)
  • Độ ổn định và khả năng mở rộng (Stability & Scalability)
• Phân tích hệ thống để xác định các luồng nghiệp vụ quan trọng.
• Lập kế hoạch kiểm thử: chọn loại kiểm thử (Load, Stress, Spike, Endurance) và số lượng người dùng ảo.

3. Create/Update Performance Test Scenario (Tạo/Cập nhật kịch bản kiểm thử)

• Mô phỏng hành vi người dùng và tải hệ thống dựa trên các mục tiêu đã xác định.
• Phân bố tỷ lệ người dùng ảo cho từng luồng nghiệp vụ.
• Thiết lập dữ liệu đầu vào, tham số hóa, logic kiểm tra.
• Tích hợp các kiểm tra chức năng cơ bản để đảm bảo tính đúng đắn của kịch bản.

4. Collect Performance Metrics (Thu thập số liệu hiệu năng)

• Thực thi kịch bản với số lượng người dùng ảo và thời gian kiểm thử phù hợp.
• Thu thập các chỉ số hệ thống và hiệu năng:
  • Response Time, Throughput, Error Rate
  • CPU, RAM, Disk, Network, Database
• Sử dụng các công cụ giám sát: Grafana, Dynatrace, hoặc báo cáo từ JMeter.

5. Analyze (Phân tích)

• So sánh kết quả với các tiêu chí SLA đã đặt ra.
• Xác định các điểm nghẽn hiệu năng (Performance Bottlenecks).
• Đề xuất cải tiến:
  • Tuning: điều chỉnh hệ thống và quay lại bước tạo/cập nhật kịch bản.
  • New Tests Identified: xác định các bài kiểm thử bổ sung cần thực hiện trước khi xuất bản baseline.

6. Publish Baseline (Xuất bản kết quả chuẩn)

• Xuất bản kết quả chuẩn (baseline) làm cơ sở so sánh cho các lần kiểm thử hiệu năng trong tương lai.
• Báo cáo kết quả chi tiết: số liệu, phân tích, điểm nghẽn, đề xuất cải tiến và các bài kiểm thử bổ sung.

✅ 4. So sánh giữa Functional Test và Non-functional Test

Functional Test và Non-functional Test là hai hướng kiểm thử chính, mỗi loại trả lời một câu hỏi khác nhau trong quá trình đánh giá phần mềm:

• ✅ Functional Test: Tính năng đã hoạt động đúng chưa?
• ✅ Non-functional Test: Tính năng đó hoạt động như thế nào trong điều kiện thực tế?

📌 Ghi chú bổ sung:

• Functional Testing thường được thực hiện sớm và lặp lại nhiều lần trong vòng đời phát triển phần mềm.
• Non-functional Testing thường được thực hiện ở giai đoạn sau, đặc biệt trước khi đưa hệ thống vào vận hành chính thức.