Đọc một lần kiểm thử tải từ hành trình người dùng

Trang đăng ký một sự kiện vẫn mở nhanh, nhưng thư xác nhận tới muộn đến mức người dùng tưởng đăng ký chưa thành công. Nếu bài kiểm thử chỉ đo tốc độ mở trang chủ, hệ thống có thể đạt mục tiêu kỹ thuật mà trải nghiệm quan trọng vẫn không đạt.

Trong tình huống giả định này, điều cần bảo vệ là hành trình chọn suất, gửi đăng ký và nhận trạng thái xác nhận. Kiểm thử tải bắt đầu từ việc chọn đúng hành trình, trước khi chọn số người dùng ảo hay một ngưỡng thời gian đẹp trên biểu đồ.

Mô hình tải là một giả thuyết cần giải thích

Khách không nhất thiết làm mọi thao tác với cùng tần suất. Nhiều người xem thông tin, một số chọn suất, ít người hoàn thành. Người đang chờ có thể tải lại. Những tỷ lệ ấy cần dựa vào dữ liệu quan sát hoặc giả định được ghi rõ.

Nếu chưa có số liệu, lập một mô hình ban đầu và nói nó dùng để thăm dò điều gì. Không lấy cấu hình ví dụ trong tài liệu làm sức tải mục tiêu cho mọi sản phẩm. Một trăm người dùng ảo có thể tạo lượng yêu cầu khác nhau tùy thời gian nghỉ, độ dài hành trình và cách công cụ lập lịch.

Dữ liệu cũng thay đổi tải. Nếu mọi người dùng ảo cùng một tài khoản hoặc cùng một suất cuối, bạn có thể đang đo tranh chấp ở một điểm hẹp. Điều đó hữu ích khi chủ đích thử tranh chấp, nhưng không đại diện toàn bộ hoạt động đăng ký.

Đo điều hoàn tất, không chỉ điều đã gửi

Theo dõi số đăng ký được chấp nhận và số xác nhận hoàn thành cùng với số yêu cầu. Nếu hàng đợi tiếp tục dài ra trong khi máy chủ vẫn trả lời nhanh, độ trễ người dùng cảm nhận đang tích lũy ở phía sau.

Một phản hồi lỗi rất nhanh còn có thể kéo số đo trung bình xuống. Vì vậy, độ trễ cần được đọc cùng tỷ lệ lỗi, thông lượng và kết quả nghiệp vụ. Biểu đồ đẹp hơn sau khi nhiều yêu cầu bị từ chối không tự chứng minh hệ thống nhanh hơn.

Các phân vị như p95 giúp nhìn vùng chậm mà giá trị trung bình dễ che khuất. Cần ghi tập quan sát, khoảng thời gian và loại yêu cầu được tính. Gộp trang tĩnh với bước ghi đăng ký có thể làm mất dấu nơi người dùng thực sự đang chờ.

Tăng tải để đặt câu hỏi khác nhau

Lượt rất nhỏ trước tiên xác nhận kịch bản, dữ liệu và phép đo hoạt động. Sau đó mới giữ tải dự kiến đủ lâu để xem hệ thống đạt trạng thái ổn định hay tiếp tục tích lũy công việc.

Tải tăng dần giúp tìm vùng bắt đầu suy giảm. Tải tăng đột ngột kiểm tra phản ứng trước một đợt khách cùng tới. Một lượt dài có thể bộc lộ sự tích lũy tài nguyên mà lượt ngắn chưa thấy. Không cần chạy mọi dạng trong lần đầu; chọn dạng phù hợp câu hỏi và phạm vi môi trường được phép thử.

Trước lượt nặng, thống nhất điều kiện dừng và người theo dõi. Mục tiêu là thu bằng chứng về giới hạn, không phải giữ bài chạy bằng mọi giá khi dữ liệu hoặc dịch vụ liên quan đang bị ảnh hưởng ngoài dự kiến.

Tìm nút thắt bằng các dấu hiệu cùng thời điểm

Nếu độ trễ tăng, xem đồng thời tài nguyên ứng dụng, kết nối cơ sở dữ liệu, truy vấn và hàng đợi. CPU thấp không loại trừ việc mọi yêu cầu đang chờ một phụ thuộc. Tăng máy ứng dụng cũng chưa chắc giúp nếu điểm giới hạn nằm ở nơi khác.

Máy tạo tải cần được quan sát nữa. Khi nó không tạo đủ lưu lượng, đồ thị không còn mô tả sức chịu tải của đích như bạn nghĩ. Giữ mốc thời gian chung giúp nối một đợt lỗi với sự kiện ở đúng thành phần.

Kết luận luôn đi kèm điều kiện

Báo cáo nên nêu phiên bản, cấu hình môi trường, mô hình hành vi, dữ liệu, nhịp tải và khoảng đo ổn định. So với đường cơ sở chỉ có ý nghĩa khi các khác biệt quan trọng đã được kiểm soát hoặc giải thích.

Một lượt đạt không bảo đảm mọi đợt sự kiện thật đều ổn; một lượt không đạt cũng chưa chỉ ra cách sửa. Đầu ra hữu ích là vùng tải đã quan sát, hậu quả khi vượt vùng đó và giả thuyết cần kiểm tra tiếp. Khi cần nối tín hiệu giữa dịch vụ, có thể đọc thêm kiểm thử khả năng quan sát.

Về nguồn tham khảo

Chủ đề tham khảo từ bộ AI Tester Skills. Bài viết và tình huống minh họa được biên soạn lại cho người đọc.