QA Skills thực hành, phần 3: Đo hiệu năng và tìm bằng chứng trong hệ thống

Khi một trang phản hồi chậm, kết quả kiểm thử chỉ mới cho biết người dùng gặp vấn đề. Để hiểu điều kiện nào gây chậm và cần điều tra ở đâu, QA phải mô tả tải, môi trường, dữ liệu và các tín hiệu bên trong hệ thống. Một biểu đồ đẹp chưa đủ nếu không thể nối nó với hành trình đang được kiểm tra.

Phần ba của loạt QA Skills thực hành kết hợp hiệu năng với khả năng quan sát hệ thống. Ví dụ minh họa là ứng dụng đọc sách có tìm kiếm, mở chi tiết và lưu sách. Bài viết không đưa ra kết quả đo thực tế hay một mức tải được khuyến nghị cho mọi sản phẩm; các quyết định phải dựa trên mục tiêu và điều kiện của dự án bạn có quyền kiểm tra.

Chốt câu hỏi trước khi tạo tải

Performance Tester có tài liệu và mẫu cho k6, Locust, báo cáo và dashboard. Trước khi chọn công cụ, viết một câu hỏi có thể đánh giá: “Ở tải dự kiến của môi trường thử nghiệm, người dùng có thể tìm sách và mở chi tiết trong ngân sách độ trễ đã thống nhất không?” Câu hỏi này cần được bổ sung bằng định nghĩa tải, ngân sách và lỗi được tính.

Thu thập mô hình sử dụng từ dữ liệu được phép truy cập hoặc giả định được nhóm chấp thuận. Bao nhiêu hành trình là tìm kiếm, bao nhiêu là mở chi tiết, người dùng nghỉ giữa các bước thế nào và dữ liệu có phân bố ra sao? Nếu chưa có dữ liệu vận hành, ghi rõ đó là mô hình giả định. Một bài demo học tập không nên được mô tả như mô phỏng chính xác lưu lượng khách hàng.

Đặt điều kiện đạt trước khi chạy để tránh chọn tiêu chí theo kết quả đã nhìn thấy. Ngân sách có thể gắn với độ trễ của hành trình, tỷ lệ lỗi, tính đúng của dữ liệu và giới hạn tài nguyên. Giá trị cụ thể cần được chủ sản phẩm và người vận hành thống nhất; các con số trong template nguồn chỉ là ví dụ.

Mô hình tải cần phản ánh điều bạn định kết luận

Số người dùng ảo chưa mô tả đầy đủ một bài kiểm thử. Cần biết mỗi người dùng làm gì, tần suất, thời gian suy nghĩ, cách chuẩn bị dữ liệu và tốc độ bắt đầu công việc mới. Khi hệ thống chậm đi, một mô hình chờ hoàn tất rồi mới gửi tiếp có thể tự giảm lượng yêu cầu. Vì vậy hãy kiểm tra cách công cụ tạo tải trước khi diễn giải throughput.

Viết kế hoạch theo các chiều sau:

Chiều cần ghi nhận	Ví dụ câu hỏi cho ứng dụng mẫu
Hành trình	Tìm kiếm, mở chi tiết và lưu sách được phối hợp thế nào?
Dữ liệu	Từ khóa phổ biến, không có kết quả và sách ít được truy cập có nằm trong mẫu không?
Nhịp tải	Tăng từ từ, tăng đột ngột hay giữ ổn định?
Thời gian	Có giai đoạn khởi động và đủ thời gian quan sát trạng thái ổn định không?
Môi trường	Cấu hình dịch vụ, cache và dịch vụ phụ thuộc khác môi trường thật ở đâu?
Điều kiện dừng	Dấu hiệu nào yêu cầu dừng và ai có trách nhiệm xử lý?

Bắt đầu bằng một lần smoke nhỏ để xác nhận kịch bản gửi đúng yêu cầu và kiểm tra đúng kết quả. Load test tìm hiểu ứng xử dưới tải dự kiến; stress test thăm dò giới hạn; soak test quan sát khi duy trì lâu; spike test xem phản ứng với thay đổi đột ngột. Chọn loại theo câu hỏi và quyền hạn, đồng thời phối hợp với người vận hành để tránh ảnh hưởng hệ thống dùng chung.

Đọc độ trễ cùng tỷ lệ lỗi và thông lượng

Giá trị trung bình có thể che những yêu cầu chậm ở phần đuôi phân bố. Một percentile như p95 mô tả mức mà khoảng 95% quan sát trong mẫu không vượt quá. Khi báo cáo, ghi nó đo thời gian nào: phản hồi HTTP, một bước hay toàn bộ hành trình. Hai giá trị p95 không thể so sánh có ý nghĩa nếu chúng được tính từ hai phạm vi khác nhau.

Đọc độ trễ cùng thông lượng và tỷ lệ lỗi. Phản hồi nhanh hơn có thể đến từ việc hệ thống trả lỗi sớm. Thông lượng giảm có thể do hệ thống đích hoặc máy sinh tải đã chạm giới hạn. Theo dõi tài nguyên của cả hai phía và xác nhận các assertion nghiệp vụ: phản hồi thành công có chứa đúng dữ liệu, hành động lưu có thực sự được xác nhận hay không.

Tỷ lệ lỗi cần mẫu số bao gồm những yêu cầu thuộc phạm vi đo, với định nghĩa lỗi rõ ràng. Phân loại lỗi mạng, timeout, mã trạng thái ngoài kỳ vọng và dữ liệu sai theo mục tiêu bài kiểm thử. Đừng sao chép một metric tùy biến rồi mặc nhiên tin tên của nó đã bảo đảm cách tính đúng.

Nối tải với logs, metrics và traces

Observability Tester mô tả cách tạo sự kiện thử nghiệm rồi kiểm tra logs, metrics, traces và cảnh báo. Logs giúp xem sự kiện cụ thể; metrics giúp nhận ra xu hướng theo thời gian; traces giúp theo một yêu cầu qua các thành phần đã được gắn cơ chế theo dõi. Để liên kết chúng, cần đồng hồ phù hợp, mốc thời gian và mã tương quan được thiết kế nhất quán.

Trong staging, thực hiện một hành trình có dữ liệu tổng hợp dễ nhận diện. Kiểm xem log có thời điểm, tên dịch vụ, mức sự kiện và thông tin tương quan cần thiết không. Nếu hành trình đi qua nhiều dịch vụ, kiểm tra trace context có được truyền tiếp và span lỗi có phản ánh tình huống quan sát được không. Quyền truy cập dữ liệu quan sát cần được cấp riêng; đọc tài liệu skill không tự tạo kết nối đến hệ thống theo dõi.

Metrics cũng cần được kiểm tra về ý nghĩa. Một counter của thao tác lưu thành công phải tăng theo định nghĩa nghiệp vụ đã chọn. Nhãn phải giúp phân tích mà không đưa mã người dùng hoặc dữ liệu có độ biến thiên cao vào mọi chuỗi thời gian. Nội dung log cần được rà để tránh ghi token, thông tin cá nhân và dữ liệu không cần thiết.

Nếu p95 tăng cùng thời gian truy vấn cơ sở dữ liệu, đó là đầu mối điều tra, chưa tự chứng minh truy vấn là nguyên nhân duy nhất. So sánh trace, mức sử dụng kết nối, thay đổi cấu hình và thời điểm sự kiện. Ghi rõ “quan sát thấy tương quan” khi chưa có thực nghiệm xác nhận nguyên nhân.

Kiểm tra cảnh báo và viết báo cáo có giới hạn

Một cảnh báo cần được kiểm tra cả lúc kích hoạt lẫn phục hồi, trong môi trường và cách mô phỏng đã được cho phép. Xác nhận điều kiện, thời gian đánh giá, người nhận và nội dung hỗ trợ xử lý. Dashboard hiển thị đúng chưa bảo đảm người trực nhận được cảnh báo cần thiết.

Báo cáo nên lưu cấu hình tải, commit ứng dụng, phiên bản kịch bản, dữ liệu, thời điểm, giới hạn môi trường và các biểu đồ có cùng trục thời gian. Nêu điều kiện đạt đã đặt, kết quả quan sát và những điều chưa thể suy ra. Nếu staging có cấu hình nhỏ hơn production, không nhân tuyến tính kết quả rồi khẳng định sức chứa của production.

Bài thực hành là chuẩn bị một kế hoạch tải, chạy smoke được cấp phép, xác nhận metric và theo dấu một yêu cầu qua các tín hiệu sẵn có. Có thể hoàn thành phần thiết kế trước khi có môi trường; hãy ghi trạng thái trung thực. Chủ đề tham khảo từ bộ AI Tester Skills. Nội dung được biên soạn lại thành hướng dẫn thực hành cho người đọc.