Ở bài viết trước, chúng ta đã cùng tìm hiểu về kiểm tra bảo mật của phần mềm. Nếu bạn bạn quan tâm, có thể tìm đọc lại bài viết tại đây. Còn trong bài viết này, hãy cùng mình tìm hiểu về chủ đề tiếp theo trong kiểm thử các đặc điểm chất lượng phần mềm, đó là kiểm thử hiệu năng. Nào, hãy bắt đầu cùng mình ngay bây giờ nhé.
Tổng Quan Về Kiểm Thử Hiệu Năng
Kiểm thử hiệu năng – Performance testing liên quan đến việc đo lường hiệu năng của một hệ thống hoặc phần mềm trong các điều kiện cụ thể liên quan đến lượng tài nguyên được sử dụng. Các tài nguyên điển hình bao gồm thời gian thực đã qua – elapsed time, thời gian CPU, bộ nhớ và băng thông. Kiểm thử hiệu năng bao gồm:

- Time behavior – Hành vi thời gian
- Resource utilization – Sử dụng tài nguyên
- Capacity – Sức chứa
Chúng ta sẽ lần lượt tìm hiểu trong các phần dưới đây nhé.
Kiểm tra Hành vi thời gian – Time Behavior
Kiểm tra hành vi thời gian – time behavior đo lường các khía cạnh sau của hệ thống (hoặc phần mềm) trong các điều kiện hoạt động được chỉ định:
- Elapsed time (hay Respone time) – Thời gian thực đã qua kể từ khi nhận được yêu cầu cho đến khi có phản hồi đầu tiên (nghĩa là thời gian bắt đầu phản hồi, không phải thời gian để hoàn thành hoạt động được yêu cầu).
- Turnaround time ( hay processing time) – thời gian quay vòng từ khi bắt đầu một hoạt động cho đến khi hoạt động được hoàn thành, còn được gọi là thời gian xử lý;
- Throughput rate – Xuất lượng: Số hoạt động đã hoàn thành trên một đơn vị thời gian (ví dụ: số thao tác cơ sở dữ liệu trên giây).
Kiểm Tra Sử Dụng Tài Nguyên – Resource Utilization
Kiểm thử sử dụng tài nguyên – resource utilization đo lường các khía cạnh sau của hệ thống (hoặc phần mềm) trong các điều kiện hoạt động được chỉ định:
- Sử dụng CPU, thường là phần trăm thời gian CPU có sẵn;
- Sử dụng bộ nhớ, thường là phần trăm bộ nhớ khả dụng;
- Sử dụng thiết bị i/o, thường là phần trăm thời gian thiết bị i/o khả dụng;
- Sử dụng băng thông, thường là phần trăm băng thông có sẵn.
Kiểm Tra Sức Chứa – Capacity
Kiểm thử sức chứa – capacity đo lường các giới hạn tối đa đối với các khía cạnh sau của hệ thống (hoặc phần mềm) trong các điều kiện hoạt động được chỉ định:
- Các giao dịch được xử lý trên một đơn vị thời gian (ví dụ: tối đa 687 từ được dịch mỗi phút);
- Người dùng đồng thời truy cập hệ thống (ví dụ: tối đa 1223 người dùng);
- Người dùng mới được thêm vào để có quyền truy cập hệ thống trên mỗi đơn vị thời gian (ví dụ: tối đa 400 người dùng được thêm vào mỗi giây).
Lập Kế Hoạch Kiểm Thử Hiệu Năng
Khi lập kế hoạch kiểm thử hiệu năng, cần quan tâm đến những điều sau đây:
- Thời gian: Thử nghiệm hiệu năng thường yêu cầu toàn bộ hệ thống được triển khai và chạy trên môi trường thử nghiệm đại diện, có nghĩa là nó thường được thực hiện như một phần của thử nghiệm hệ thống.
- Đánh giá: Đánh giá code, đặc biệt là những đánh giá tập trung vào tương tác cơ sở dữ liệu, tương tác thành phần và xử lý lỗi, có thể xác định các vấn đề về hiệu quả hoạt động (đặc biệt liên quan đến logic “chờ và thử lại” và các truy vấn không hiệu quả) và nên được lên lịch để thực hiện ngay khi code có sẵn (tức là trước thử nghiệm động).
- Thử nghiệm sớm: Một số thử nghiệm hiệu năng (ví dụ: xác định mức sử dụng CPU cho một thành phần quan trọng) có thể được lên lịch như một phần của component testing. Các thành phần được xác định là nút cổ chai bằng thử nghiệm hiệu năng có thể được cập nhật và thử nghiệm lại một cách riêng biệt như một phần của component testing.
- Thay đổi kiến trúc: Kết quả bất lợi từ hiệu năng. Thử nghiệm đôi khi có thể dẫn đến thay đổi kiến trúc hệ thống. Khi những thay đổi lớn như vậy đối với hệ thống có thể được đề xuất bởi kết quả kiểm thử hiệu năng, thì kiểm thử hiệu năng nên bắt đầu càng sớm càng tốt nhằm tối đa hóa thời gian có sẵn để giải quyết các vấn đề đó.
- Chi phí: Công cụ và môi trường thử nghiệm có thể tốn kém, điều đó có nghĩa là môi trường thử nghiệm tạm thời dựa trên đám mây có thể được thuê và “top-up” tool licenses có thể được sử dụng. Trong những trường hợp như vậy, việc lập kế hoạch kiểm tra thường cần tối ưu hóa thời gian chạy thử nghiệm để giảm thiểu chi phí.
- Môi trường kiểm thử: Môi trường kiểm thử cần phải càng đại diện cho môi trường vận hành càng tốt. Nếu không, thách thức trong việc nhân rộng kết quả kiểm thử hiệu năng từ môi trường kiểm thử sang môi trường vận hành dự kiến sẽ tăng lên.
- Tiêu chí đầu ra: Các yêu cầu về hiệu quả hoạt động đôi khi có thể khó đạt được từ khách hàng. Do đó thường căn cứ vào các hệ thống trước đó hoặc tương tự. Trong trường hợp các hệ thống nhúng liên quan đến an toàn, một số yêu cầu, chẳng hạn như lượng CPU và bộ nhớ tối đa được sử dụng, có thể được chỉ định bởi các tiêu chuẩn quy định.
- Các công cụ tải – Load generation tools: Các công cụ tạo tải thường được yêu cầu để hỗ trợ kiểm tra hiệu năng. Chẳng hạn, việc xác minh khả năng mở rộng của một trang web phổ biến có thể yêu cầu mô phỏng hàng trăm nghìn người dùng ảo. Các công cụ mô phỏng các hạn chế về tài nguyên cũng đặc biệt hữu ích cho stress testing. Cần thận trọng để đảm bảo rằng bất kỳ công cụ nào có được để hỗ trợ thử nghiệm đều tương thích với các giao thức truyền thông được sử dụng bởi hệ thống được thử nghiệm.
Mình xin tạm dừng bài viết hôm nay tại đây. Hẹn gặp lại các bạn trong các bài viết tiếp theo.
Happy testing!