Performance Testing

Performance Test là tên gọi chung cho các hoạt động kiểm thử nhằm kiểm tra cách hệ thống hoạt động, nó nhắm tới khả năng đáp ứng, tính ổn định, độ tin cậy, tốc độ và việc sử dụng tài nguyên của phần mềm hay hệ thống

Các loại performance test khác nhau sẽ cung cấp các thông tin khác nhau về hiệu năng của hệ thống, các thông tin này sẽ được sử dụng để đánh giá chất lượng về:

Mức độ sẵn sàng
Đánh giá hiệu suất
Tìm ra nguồn gốc các vấn đề hiệu suất
Hỗ trợ điều chỉnh hệ thống (khi kết hợp với hoạt động so sánh các thông số hiệu suất, nó có thể giúp ta tìm ra cấu hình phù hợp, hoặc tối ưu)

Trong tình huống ngay từ đầu chúng ta nhận ra hệ thống / sản phẩm phần mềm có vấn đề về hiệu năng, thực hiện perf testing cũng sẽ giúp tìm ra vấn đề gây tắc nghẽn. Ngoài ra việc tổng hợp thông số hiệu năng cũng sẽ giúp vạch ra được đường cơ sở (baseline) nhằm mục đích kiểm thử hiệu năng bổ sung trong tương lai, khi đấy chúng ta có thể xác định hiệu năng đã được cải thiện hay bị giảm đi

Lý do thực hiện Performance Testing

Đầu tiên, ở cấp độ tổng quan, kiểm thử hiệu năng luôn được tiến hành với các sản phẩm phần mềm phục vụ mục đích kinh doanh, ví dụ như với các sản phẩm web apps, mobile apps của các dịch vụ tài chính, ngân hàng, thương mại điện tử,…

Perf testing nhắm tới kiểm thử để xác minh các yêu cầu phi chức năng liên quan đến hiệu năng của sản phẩm, việc sản phẩm không đạt được các yêu cầu phi chức năng trên sẽ ảnh hưởng trải nghiệm người dùng, gây thiệt hại về kinh tế và danh tiếng của chủ thể sở hữu và vận hành sản phẩm

Đánh giá sự sẵn sàng của hệ thống

Khi nói đến sẵn sàng thì chúng ta đang nói đến chuyện sắp đẩy sản phẩm lên production, rồi go-live. Vấn đề cốt lõi ở đây là sản phẩm phần mềm trong môi trường test (nếu không thực hiện perf test) thì sẽ chỉ bao gồm các request đơn lẻ của một vài tester, không thể lường trước sự thay đổi về hiệu năng khi hệ thống gặp hàng nghìn hay thậm chí hàng triệu request từ người dùng thực sự

Đứng từ góc độ này, perf test sẽ giúp xác định được khả năng đáp ứng của hệ thống khi gặp tình huống tải cao giống với thực tế, cũng như đánh giá khả năng mở rộng của hệ thống

Đánh giá cơ sở hạ tầng

Nhiều khi vấn đề chưa chắc đã nằm ở sản phẩm phần mềm - các dòng code mà đến từ cơ sở hạ tầng - server, database, gói mạng,… Perf test sẽ giúp xác định nguồn gốc vấn đề bằng cách chỏ tới được checkpoint đang gây tắc nghẽn

Đầu tiên, đánh giá được tính phù hợp của hiệu năng của cơ sở hạ tầng với yêu cầu của sản phẩm. Sau đó là khả năng ổn định, xác định năng lực của cơ sở hạ tầng và các thay đổi cần thiết để cung cấp hiệu suất chấp nhận được

Đồng thời việc thực hiện perf test với nhiều cơ sở hạ tầng kết hợp so sánh thông số sẽ giúp tìm ra cấu hình phù hợp với yêu cầu

Đánh giá hiệu suất

Giúp đánh giá hiệu suất trước và sau thay đổi, từ đó đánh giá được hiệu suất đã được cải thiện hay bị giảm đi

Đánh giá hiệu suất ở các mức tải khác nhau, đưa ra được đường cơ sở (baseline):

Khi đưa vào production / go-live, dựa vào đường cơ sở có thể đánh giá nếu hiệu năng đang có vấn đề hay bình thường, vì dù sao tải trên production cũng khác biệt so với tải khi test, các request có thể đến từ nhiều nguồn, dồn dập, thậm chí có thể các request này bị loss

Các loại Performance Testing

Load Testing

Load test về cơ bản là kiểm tra hệ thống hoạt động tốt đến đâu dưới một số lượng người dùng ảo đồng thời thực hiện các giao dịch nói chung, các giao dịch ở đây có thể hiểu là các sự trao đổi thông tin giữa client và server, thông qua các request/response

Đặc điểm của Load Test là sẽ chạy hệ thống ở các mức tải khác nhau, ví dụ như 1000 người dùng, 5000 người dùng, 10000 người dùng, 50000 người dùng,… và đánh giá hiệu năng của hệ thống ở mỗi mức tải

Một công cụ load test phổ biến là JMeter, mình sẽ viết ở bài JMeter

Một số tình huống ứng dụng Load Test:

Xác định số lượng người dùng mà hệ thống có thể xử lý
Sau khi đã thực hiện Load Test một lần nhưng có thay đổi về hạ tầng máy chủ, hạ tầng mạng, hay sau khi mở rộng

Stress Testing

Stress Test là kiểm thử khả năng hoạt động của hệ thống dưới một ngưỡng load cao, thường gần tối đa (so với thông số ước lượng), ví dụ một hệ thống được ước lượng có thể tải đến 50000 lượt truy cập cùng lúc, thì chúng ta chạy luôn ở mức 50000 lượt truy cập

Thường trong Stress Test thì mặc định hệ thống sẽ gặp vấn đề, quan trọng là chúng ta cần theo dõi cách hệ thống xử lý lượng tải này hợp lý và hồi phục đúng cách, các thông số cần theo dõi là throughputs và thời gian phản hồi, mình sẽ nói cụ thể hơn

Stress Test nên được thực hiện khi hệ thống có các tình huống đạt tải cực cao, ví dụ như các hệ thống banking, thương mại điện tử, giải trí,…

Đồng thời Stress Test cũng có thể được thực hiện kết hợp Security Test, đề phòng khi hệ thống dưới tải cao lộ ra các lỗ hổng bảo mật

Quy trình thực hiện

Xác định tải công việc của hệ thống (15%)

Xác định tải công việc có thể được thực hiện thông qua nghiên cứu yêu cầu, cũng như kiến trúc hạ tầng để mô tả được khối lượng công việc bằng các tham số định lượng (ví dụ như số lượng người dùng, số lượng request, số lượng giao dịch,…) và chức năng (ví dụ như chức năng đăng nhập, chức năng đặt hàng, chức năng thanh toán,…) để tìm ra mô hình có thể hiển thị, ghi lại và tái tạo hành vi của khối lượng công việc đã xác định. Bao gồm:

Sức tải người dùng:
- Số lượng người dùng
- Số lượng người dùng đồng thời lớn nhất
- Tỷ lệ người dùng đồng thời mỗi loại trong một khoảng thời gian
- Thời gian các phiên làm việc mỗi loại
- Số lượng mỗi loại hoạt động thực hiện bởi người dùng
Sức tải công ứng dụng:
- Thông số hạ tầng (tốc độ truyền dữ liệu, số thao tác xử lý được / giây, …)
- Tỷ lệ các màn hình được yêu cầu
- Tỷ lệ các đầu request được yêu cầu

Ví dụ:

1. Phân tích yêu cầu và kiến trúc hạ tầng
a. Nghiên cứu yêu cầu người dùng (User Load):

Số lượng người dùng:
Ví dụ, website thương mại điện tử có thể phục vụ 100,000 người dùng đăng ký hàng tháng.
Số lượng người dùng đồng thời lớn nhất:
Giả sử vào giờ cao điểm (ví dụ từ 18h đến 20h) có khoảng 5,000 người dùng truy cập đồng thời.
Tỷ lệ người dùng đồng thời theo loại:
Người dùng duyệt sản phẩm (Browsing): 70%
Người dùng thêm sản phẩm vào giỏ (Add-to-Cart): 20%
Người dùng thanh toán (Checkout): 10%
Thời gian phiên làm việc:
Người dùng duyệt sản phẩm: trung bình 10 phút
Người dùng thêm sản phẩm: trung bình 5 phút
Người dùng thanh toán: trung bình 3 phút
Số lượng hoạt động của mỗi loại:
Ví dụ, mỗi người dùng duyệt trung bình 20 trang sản phẩm; trong khi đó, người dùng thêm sản phẩm vào giỏ khoảng 3 sản phẩm và thực hiện 1 giao dịch thanh toán.
b. Nghiên cứu yêu cầu về sức tải công ứng dụng (Application Load):

Thông số hạ tầng:
Tốc độ truyền dữ liệu từ server đến client: mục tiêu có thể là đáp ứng dưới 200ms cho mỗi request.
Số thao tác xử lý (requests) trên giây: cần đảm bảo hệ thống có thể xử lý tối thiểu 1,000 request/giây trong giờ cao điểm.
Tỷ lệ các màn hình được yêu cầu:
Ví dụ:
Trang chủ: 50% các request
Trang danh mục sản phẩm: 20%
Trang chi tiết sản phẩm: 15%
Trang giỏ hàng và thanh toán: 15%
Tỷ lệ các đầu request:
API đăng nhập: 5%
API lấy danh sách sản phẩm: 40%
API chi tiết sản phẩm: 15%
API thêm sản phẩm vào giỏ: 10%
API thanh toán: 5%
Các API khác (tìm kiếm, gợi ý sản phẩm,...) chiếm phần còn lại.

Cài đặt môi trường kiểm thử hiệu năng (5%)

Tại đây, trước khi cài đặt môi trường kiểm thử thì cần nắm được môi trường cần phải đáp ứng được những vấn đề gì

Trước tiên cần nắm bắt:

Chức năng hệ thống và quy trình kinh doanh

Ví dụ, với một trang thương mại điện tử, chức năng cơ bản bao gồm: Đăng nhập/Đăng ký, Duyệt, Giỏ hàng, Thanh toán, Xử lý đơn hàng,... Và quy trình kinh doanh là các flow E2E. 
Vậy thì môi trường kiểm thử cần thiết cần phải đảm bảo chạy được các chức năng trên và chạy các chức năng theo chuỗi

Nắm bắt các hoạt động người dùng

Ví dụ, với các chức năng kể trên, người dùng có thể duyệt trang mua hàng với một khoảng thời gian trung bình x phút, liên tục kéo xuống cuối trang và load thêm sản phẩm mỗi y giây. 
Hay người dùng thường đặt nhiều mặt hàng vào giỏ rồi ấn mua một lần,...
Vậy thì môi trường kiểm thử cần đảm bảo chạy được các hoạt động người dùng này theo vòng lặp với căn thời gian

Nắm bắt được kiến trúc logic và vật lý

Cuối cùng, với kiến trúc vật lý và logic, ví dụ như sản phẩm web có tầng front-end, back-end, database
Dữ liệu được truyền tải giữa các thành phần bằng APIs,... 
Vậy thì môi trường kiểm thử cần đảm bảo chạy được các tác vụ tự động hoá trình duyệt web và APIs. 

Với kiến trúc vật lý là máy chủ, database, mạng

Tất cả các thông tin trên giúp chúng ta tạo được môi trường kiểm thử gần giống với production

Đồng thời giúp chúng ta làm được:

Xác định các flow E2E cho khâu tạo kịch bản kiểm thử
Chọn ra các công cụ kiểm thử mô phỏng hành vi con người

Vậy chốt lại, môi trường kiểm thử sẽ:

Môi trường riêng biệt với production để không ảnh hưởng, nhưng cũng sẽ sao chép cấu hình phần cứng, phần mềm, kiến trúc mạng của hệ thống production
Hạ tầng phần cứng như server và config cần đảm bảo đủ mạnh để mô phỏng tải cao, nó sẽ chứa các server web, server app, server database
Mạng và băng thông tương đồng production
Các công cụ kiểm thử hiệu năng như JMeter, LoadRunner, Gatling, k6, Artillery, Locust,…
Giám sát hệ thống dùng Grafana, Prometheus,…

Xây dựng kịch bản kiểm thử (30%)

Khi xây dựng kịch bản kiểm thử, quan tâm nhất là chú ý đến context người dùng:

Người dùng đăng nhập, người dùng vãng lai
Người dùng thực hiện mua hàng, không mua hàng
…

Các bước cần thực hiện sẽ là các chức năng cơ bản của hệ thống, ví dụ như:

Đăng nhập
Duyệt sản phẩm
Thêm sản phẩm vào giỏ
Thanh toán

Sau đó là cấu thành các kịch bản dạng flow E2E:

Người dùng đăng nhập, duyệt sản phẩm, thêm sản phẩm vào giỏ, thanh toán
Người dùng đăng nhập, duyệt sản phẩm, thêm sản phẩm vào giỏ, không thanh toán
…

Thực hiện kiểm thử hiệu năng (45%)

Bao gồm các khâu:

Tạo dữ liệu kiểm thử
Thiết lập tham số của bộ kiểm thử
Thực thi
Điều chỉnh
Thực thi lại

Với việc tạo dữ liệu kiểm thử, chúng ta cần đảm bảo dữ liệu kiểm thử phản ánh đúng thực tế, ví dụ:

Với 5000 người dùng, 5000 người dùng này cần phải có thông tin đăng nhập để test hiệu năng khâu đăng nhập, sau đó tiến vào các flow E2E, cần đảm bảo hành động mua hàng của mỗi người là khác nhau, có người mua 1 món, có người mua nhiều món,…

Sau đó, thiết lập tham số của bộ kiểm thử sẽ bao gồm:

Xác định các tham số định lượng: số người dùng ảo, tỷ lệ phân bố hành động
Thông số cấu hình:
- Thời gian ramp-up random, để tránh sốc tải
- Thời gian duy trì tải đủ lâu để đạt mục đích kiểm thử
- Thời gian test

Chạy kịch bản kiểm thử ban đầu:

Khởi chạy bộ kiểm thử với các tham số đã thiết lập và theo dõi các chỉ số hệ thống (CPU, RAM, tốc độ phản hồi, throughput,…)
Ghi nhận log, báo cáo lỗi và các thông số quan trọng trong quá trình test
Quan sát hành vi hệ thống và so sánh các chỉ số với mục tiêu đã đặt ra

Điều chỉnh kịch bản:

Phân tích kết quả: Xác định xác điểm nghẽn, đánh giá mực độ ảnh hưởng
Điều chỉnh tham số và kịch bản: Nếu có lỗi hoặc thời gian phản hồi vượt mức, chúng ta sẽ điều chỉnh tham số định lượng để tiếp tục dí vào các lỗi này nhằm tìm ra đầy đủ thông tin về mức độ ảnh hưởng

Thực thi lại: Chạy lại test sau khi đã điều chỉnh tham số để đào sâu hơn vào các vấn đề hiệu năng

Báo cáo kiểm thử hiệu năng (5%)

Phần việc này bao gồm:

Mô tả đặc điểm của hệ thống
Phân tích dữ liệu và tìm nguyên nhân của các vấn đề hiệu năng