Performance Testing – P3: Khi hệ thống bước vào “trận đấu thật”

Sau khi lên kế hoạch kỹ lưỡng, đã đến lúc hệ thống phải chứng minh thực lực.

Chào mừng đến Phần 3 — nơi “nói hay” không còn quan trọng, chỉ dữ liệu mới quyết định tất cả

Giai đoạn thực thi: Khi hệ thống rời bục lý thuyết và bước vào thực chiến

Ở Phần 2, chúng ta đã chuẩn bị đủ mọi thứ: mục tiêu, môi trường, mô hình người dùng, chỉ số đánh giá.
Giờ là lúc biến những thứ đó thành kịch bản kiểm thử (scripts) và cho máy chạy.

Và đây không phải là công việc “bấm nút là xong”.
Thực thi kiểm thử hiệu năng là một nghệ thuật—kết hợp giữa kỹ thuật, quan sát, và khả năng đọc vị hệ thống.

1. Tạo test scripts – “Viết kịch bản cho người dùng ảo”

Kịch bản kiểm thử hiệu năng mô phỏng hành động của người dùng thật:

• Đăng nhập

• Tìm kiếm

• Xem dữ liệu

• Thanh toán

• Tải báo cáo

Bất kỳ công cụ như JMeter, LoadRunner, Locust, k6… đều hoạt động dựa trên scripts.

Trong giai đoạn này, tester phải đảm bảo:

Script phản ánh đúng Usage Model

Script phải dựa trên hành vi người dùng trong thực tế, không phải tưởng tượng của tester.

Script có dữ liệu test thật

Không ai đăng nhập bằng user1–user9999 ngoài đời.
Dữ liệu phải đa dạng, ngẫu nhiên, và tương tự production.

Script mô phỏng think time

Người dùng không click như robot.
Think time (khoảng thời gian suy nghĩ giữa các thao tác) tạo ra nhịp điệu tự nhiên của traffic.

Script xử lý session, token, cookie đúng kiểu

Đặc biệt với API, authentication sai gây ra lỗi dây chuyền toàn bộ bài test.

*Ví dụ:
Thực hiện kiểm thử hệ thống xem điểm:

• 200 người đăng nhập mỗi phút

• 80% xem điểm

• 20% xem lịch sử môn học
  → Script phải mô phỏng đầy đủ hai hành vi này theo đúng tỉ lệ.

2. Chạy test: Warm-up, Load, Stress, Soak… mỗi bài test một mục đích

Khi script đã sẵn sàng, hệ thống sẽ được đưa vào những “bài kiểm tra sức bền” khác nhau:

Warm-up test

Mục tiêu: “khởi động hệ thống” để tránh sai lệch đo lường khi cache chưa nóng.

Load test

Kiểm tra hệ thống dưới tải mong đợi (expected load).
→ Đây là bài test chính xác nhất với thực tế.

Stress test

Cho hệ thống “chịu áp lực vượt mức” để xác định:

• Điểm sập (breakpoint)

• Mức tải tối đa

• Hệ thống khôi phục thế nào sau khi quá tải

Spike test

Tăng tải đột ngột → kiểm tra phản ứng khi có “đột biến user”, ví dụ:

• Ngày sale 11.11

• Mở cổng đăng ký học phần

• Thông báo điểm thi

Endurance / Soak test

Chạy liên tục nhiều giờ để phát hiện:

• Memory leak

• Rò rỉ kết nối

• Hiệu năng giảm dần theo thời gian

*Sự thật thú vị:
Nhiều hệ thống không sập vì tải cao, mà vì chạy lâu 8 tiếng liên tục → leak bộ nhớ làm nghẽn server.

3. Thu thập dữ liệu: Mọi con số đều có câu chuyện đứng sau

Khi test chạy, nhiệm vụ của tester giống như một bác sĩ theo dõi nhịp tim bệnh nhân trong phòng mổ.

Các dữ liệu cần thu thập:

• Response time từng request

• Throughput (request/giây)

• CPU, RAM, Disk I/O, Network I/O

• GC activity (Java), thread count, pool usage

• Tỷ lệ lỗi (error %)

• Log hệ thống (error log, exception log)

Không có dữ liệu → không có kết luận.
Dữ liệu chính là nguồn sống của performance testing.

4. Phân tích kết quả: Khi con số nói rõ ai đúng, ai sai

Đây là giai đoạn quan trọng nhất—nơi tester trở thành nhà phân tích hiệu năng.

Mục tiêu là trả lời:

1. Hệ thống có đạt mục tiêu đề ra không?

Nếu mục tiêu là thời gian phản hồi < 3 giây mà kết quả trung bình 1,5 giây → OK.
Nhưng nếu maximum lên đến 15 giây → cần xem lại.

2. Vấn đề đang nằm ở đâu?

• CPU 100% → code hoặc cấu hình không tối ưu.

• RAM tăng đều → khả năng memory leak.

• Network bottleneck → nghẽn băng thông.

• DB lock → truy vấn SQL chậm.

3. Nguyên nhân cốt lõi (root cause) là gì?

Đây mới là câu trả lời quan trọng nhất.
Tester không được trả về một báo cáo kiểu “hệ thống chậm, cần tối ưu”.
Phải chỉ ra chậm ở đâu, vì sao chậm, và cần sửa cái gì.

4. Cần cải thiện như thế nào?

Khuyến nghị có thể bao gồm:

• Index lại database

• Tối ưu code backend

• Thay đổi cấu hình thread pool

• Mở rộng server hoặc chuyển sang cloud auto-scale

• Tối ưu caching

*Điểm quan trọng:
Không phải lúc nào tăng server cũng giải quyết vấn đề.
Nhiều hệ thống chậm vì một dòng SQL viết sai chứ không phải thiếu CPU.

5. Tuning – Tối ưu hệ thống dựa trên dữ liệu thật

Tinh chỉnh (tuning) là nghệ thuật cân bằng giữa:

• kiến trúc,

• tài nguyên,

• code,

• cấu hình,

• và hành vi người dùng.

Tuning có thể diễn ra ở nhiều lớp:

Ứng dụng (Application tuning)

• Tối ưu vòng lặp, caching

• Giảm độ phức tạp của hàm

• Reuse object để giảm GC

Cơ sở dữ liệu (DB tuning)

• Thêm index

• Sửa query N+1

• Tối ưu join

• Tăng pool kết nối

Hệ điều hành & hạ tầng (System tuning)

• Điều chỉnh thread pool

• Tối ưu size heap

• Cấu hình connection limit

Network tuning

• Giảm round-trip

• Bật nén dữ liệu

• Tối ưu SSL handshake

UI/Front-end tuning

• Tối ưu số lượng request

• Bundling, minify tài nguyên

• Caching trình duyệt

Một hệ thống hiệu năng tốt là kết quả của hàng chục lần test → phân tích → tuning → test lại.

6. Báo cáo hiệu năng: Gói gọn dữ liệu thành câu chuyện dễ hiểu

Một báo cáo tốt phải:

• Rõ ràng

• Có số liệu

• Dễ hiểu cho người không phải dân kỹ thuật

• Có khuyến nghị cụ thể

Cấu trúc thường gồm:

1. Mục tiêu kiểm thử

2. Mô tả môi trường

3. Kịch bản test

4. Kết quả theo từng bài test

5. Phân tích bottleneck

6. Đề xuất cải tiến

7. Kết luận (đạt hay không đạt yêu cầu)

* Lưu ý:
Người đọc báo cáo thường là quản lý hoặc khách hàng—họ cần con số, không cần thuật ngữ phức tạp.

Tổng kết Phần 3

Phần 3 kết thúc vòng đời Performance Testing:

• Planning (P2)

• Execute (P3)

• Analyze & Tune (P3)

Nếu P2 là chiến thuật, thì P3 là lúc “ra sân” và P3 cũng là lúc “phân tích trận đấu”.
Performance Testing thực chất là một vòng lặp liên tục, không phải bài test chạy một lần rồi thôi.