Performance Testing

Performance Testing – P2

Bắt đầu từ kế hoạch – Planning for the Performance Test

Một kế hoạch kiểm thử hiệu năng tốt không chỉ trả lời “chúng ta test gì”, mà còn “tại sao test”, “test thế nào” và “đánh giá ra sao”.

Đây là giai đoạn đặt nền móng cho toàn bộ quá trình.
Khi lập kế hoạch, tester cần định nghĩa rõ bốn yếu tố cốt lõi:

Môi trường kiểm thử (Test Environment): nơi hệ thống sẽ được “thử lửa”.
Mục tiêu hiệu năng (Performance Goals): hệ thống cần nhanh đến mức nào.
Mô hình sử dụng (Usage Model): người dùng thật sự làm gì, bao lâu, tần suất ra sao.
Các chỉ số theo dõi (Key Metrics): tiêu chí đánh giá “đủ nhanh” là gì.

Nói gọn lại: bạn không thể kiểm thử điều mình không hiểu, và không thể đo thứ mình không xác định.

Xây dựng môi trường kiểm thử – Đừng xem nhẹ “sân khấu”

Môi trường kiểm thử hiệu năng không thể là bản sao hời hợt của môi trường thật.
Một sai lệch nhỏ trong cấu hình có thể khiến kết quả “đẹp trên giấy” nhưng sai hoàn toàn khi đưa vào vận hành.

Ba yếu tố tạo nên môi trường kiểm thử đúng chuẩn:

Hiểu hệ thống: nắm rõ chức năng, quy trình, điểm kết nối.
Chuẩn bị hạ tầng: server, cơ sở dữ liệu, mạng phải mô phỏng gần nhất với production.
Nắm hành vi người dùng: không chỉ “ai dùng”, mà “họ dùng như thế nào”.

Ví dụ:
Ứng dụng học trực tuyến có ba nhóm người dùng chính: sinh viên, giảng viên, và quản trị viên.
Nếu tester chỉ mô phỏng sinh viên làm bài mà quên hành vi giảng viên chấm bài, kết quả sẽ thiếu chính xác vì bỏ qua một phần tải đáng kể của hệ thống.

Đặt mục tiêu hiệu năng – “Nhanh” thôi chưa đủ

Không ít nhóm phát triển từng mắc lỗi “đặt mục tiêu mù mờ”:

“Chỉ cần hệ thống chạy nhanh là được.”

Vấn đề là — thế nào là nhanh?
Với người dùng, 3 giây có thể chấp nhận được, nhưng với ứng dụng giao dịch chứng khoán, 3 giây là “thảm họa”.

Một Performance Goal đúng nghĩa phải đo được:

Thời gian phản hồi tối đa.
Lượng người dùng đồng thời có thể xử lý.
Mức tăng trưởng dự kiến trong tương lai.

Ví dụ thực tế:
Một website đặt vé xe đặt mục tiêu:

Xử lý 10.000 người dùng đồng thời.
Thời gian phản hồi khi đặt vé < 2 giây.
Khả năng mở rộng 50% user tăng trưởng mỗi quý.

Khi mục tiêu rõ ràng, kiểm thử trở nên có hướng đi, có thước đo, và có giá trị.

Response Time – đo thế nào cho đúng?

“Response Time” nghe đơn giản, nhưng lại là khái niệm dễ gây tranh cãi nhất trong kiểm thử hiệu năng.
Có người đo từ lúc client gửi yêu cầu đến khi nhận được kết quả cuối cùng.
Người khác chỉ tính đến khi nhận byte đầu tiên của phản hồi.

Sự thật là — không có định nghĩa đúng tuyệt đối, chỉ có định nghĩa phù hợp và nhất quán.

Thông thường, Response Time được cấu thành từ ba phần:

Process Time: hệ thống xử lý yêu cầu.
Transportation Time: dữ liệu di chuyển qua mạng.
Drawing Time: hiển thị kết quả cho người dùng.

Nếu không thống nhất cách đo, cùng một hệ thống có thể “được” hoặc “trượt” chỉ vì hai người test khác nhau.

Bao nhiêu giây là “chấp nhận được”?

Không có con số cố định.
Giống như bạn không thể bắt tất cả quán cà phê phục vụ nhanh như Starbucks, mỗi hệ thống có chuẩn hiệu năng riêng.

Mức chấp nhận (Response Time Acceptability) phụ thuộc vào:

Kỳ vọng người dùng.
Tốc độ kết nối trung bình.
Loại ứng dụng.

Ví dụ:

Trang web tin tức: chấp nhận 2–4 giây.
Hệ thống ngân hàng: yêu cầu < 1 giây.
Website học trực tuyến: có thể 5–7 giây vẫn ổn.

Quan trọng là, đừng đoán – hãy khảo sát người dùng thật.

Throughput và Concurrent Users – Khi hệ thống “đông khách”

Hiệu năng không chỉ là chuyện một người dùng.
Thử tưởng tượng 10.000 người cùng “F5” website trường trong ngày công bố điểm thi — đó là “thử thách thật sự”.

Throughput (thông lượng) cho biết hệ thống xử lý được bao nhiêu giao dịch/giây.
Concurrent users (người dùng đồng thời) cho biết có bao nhiêu người “đang làm gì đó” cùng lúc.

Cả hai chỉ số này giúp ta đánh giá độ bền và sức chịu tải của hệ thống.

Ví dụ:
Nếu một hệ thống xử lý được 40.000 request/phút nhưng nhận 50.000 request, thì chắc chắn một phần người dùng sẽ gặp lỗi hoặc chậm trễ.

Dự đoán tăng trưởng – Kiểm thử cho tương lai

Một bài test tốt không chỉ chứng minh hệ thống đủ cho hôm nay, mà còn sẵn sàng cho ngày mai.
Nếu lượng người dùng tăng 50% mỗi tháng, kiểm thử phải tính cả phần “tăng trưởng” này.

Bỏ qua yếu tố đó, bạn sẽ có một hệ thống đẹp khi demo, nhưng sập khi nổi tiếng.

Usage Model – 20% hành vi, 80% tải

Không cần mô phỏng mọi thứ.
Nguyên tắc Pareto (80/20) trong performance testing chỉ ra rằng:

20% hành động của người dùng tạo ra 80% tải cho hệ thống.

Vì vậy, hãy tập trung test những hành động “nặng tải” nhất: đăng nhập, tìm kiếm, tải dữ liệu, thanh toán…

Mô hình này cần được trình bày và phê duyệt trước khi chạy test, để mọi người thống nhất: “Đây là cách người dùng thật sự sử dụng hệ thống của chúng ta.”

Key Metrics – Khi dữ liệu nói lên sự thật

Mỗi dự án có thể có tiêu chí khác nhau, nhưng hầu hết đều quan tâm đến những chỉ số sau:

Server utilization: CPU, RAM, disk, network.
Error rate: tỷ lệ lỗi của request.
Stability issues: rò rỉ bộ nhớ, crash, timeout.
Processing delay: thời gian hệ thống phản hồi yêu cầu.

Một tester giỏi không chỉ chạy test – họ phân tích ý nghĩa của các con số này để chỉ ra nguyên nhân gốc rễ.

Performance Test Plan – “Bản đồ chiến lược”

Khi tất cả thông tin đã sẵn sàng, kết quả cuối cùng của giai đoạn Planning là tài liệu Performance Test Plan.
Đây là bản kế hoạch chi tiết hướng dẫn toàn bộ quy trình test:

Nó bao gồm:

Mục đích và phạm vi kiểm thử.
Kiến trúc hệ thống và môi trường test.
Tiêu chí chấp nhận hiệu năng.
Kịch bản test và lịch trình thực hiện.
Mô tả script, công cụ và dữ liệu test.

Performance Test Plan không chỉ dành cho tester – mà là tài liệu chung để cả đội phát triển, quản lý và khách hàng cùng hiểu.

Kết nối lại với Phần 1

Nếu Phần 1 là lúc ta hiểu Performance Testing là gì, thì Phần 2 chính là khi ta học làm thế nào để chuẩn bị cho nó một cách thông minh.

Vì kiểm thử hiệu năng không chỉ là việc chạy tool và xem biểu đồ.
Đó là một quy trình có chiến lược: hiểu hệ thống, hiểu người dùng, đặt mục tiêu rõ ràng và đo lường chính xác.

Tin khác: