Thử mất dịch vụ gợi ý để hiểu sức chịu lỗi của cửa hàng

Bỏ một tiện ích, giữ được việc mua hàng

Giả sử trang sản phẩm gọi dịch vụ gợi ý trước khi cho khách thêm hàng vào giỏ. Nếu gợi ý ngừng phản hồi, khách có còn mua được không? Câu hỏi này phù hợp với kiểm thử sức chịu lỗi vì nó bắt đầu từ một hoạt động cần bảo vệ. Mục tiêu không phải tạo ra sự hỗn loạn cho thật nhiều thành phần cùng lúc.

Trước khi chạm vào môi trường, hãy vẽ đường phụ thuộc và xác nhận dịch vụ gợi ý có thật sự đứng ngoài chức năng cốt lõi. Nếu giỏ hàng dùng chung tài nguyên với nó, phạm vi ảnh hưởng có thể rộng hơn tên dịch vụ gợi ý. Một sơ đồ đơn giản giúp đội nhận ra điều cần làm rõ trước khi chạy thí nghiệm.

Viết giả thuyết đủ cụ thể để bị bác bỏ

Với tình huống này, giả thuyết có thể là: khi gợi ý phản hồi chậm, trang vẫn cho thêm hàng, hiển thị phần thay thế phù hợp và không tạo yêu cầu lặp vô hạn. Mỗi vế cần bằng chứng riêng. Cảm giác “trang vẫn ổn” không chứng minh được dữ liệu giỏ hàng đúng hay lượng công việc phía sau đã được giới hạn.

Chọn môi trường, tài khoản giả lập, thời gian chạy và người có quyền dừng. Thống nhất tín hiệu dừng như xuất hiện lỗi ngoài phạm vi hoặc chức năng mua hàng vượt giới hạn đã thỏa thuận. Chuẩn bị thao tác gỡ lỗi được chèn và kiểm tra cách dùng trước. Kế hoạch hồi phục phải có từ đầu, không đợi thí nghiệm gây khó hiểu mới tìm.

Đo trạng thái bình thường bằng cùng hành trình sẽ dùng trong lúc thử. Lưu thời lượng, kết quả giỏ hàng và tín hiệu của các phụ thuộc. Mẫu đo này không tự trở thành chuẩn hiệu năng cho mọi thời điểm; nó chỉ là điểm đối chiếu trong điều kiện đã ghi. Tránh so hai lần chạy có dữ liệu hoặc tải nền quá khác nhau.

Chèn một lỗi, đọc nhiều hệ quả

Bắt đầu bằng độ trễ ở đúng đường gọi gợi ý, trong phạm vi nhỏ. Sau đó mới cân nhắc một thí nghiệm riêng cho mất kết nối hoặc phản hồi lỗi. Chạy nhiều loại lỗi cùng lúc khiến kết quả khó giải thích: nếu giỏ hàng hỏng, đội không biết yếu tố nào gây ra và cũng khó đánh giá bản sửa sau này.

Quan sát cả phía người dùng lẫn hệ thống. Trang có thông báo phù hợp không, nút mua có còn hoạt động không, mỗi lần bấm có thêm đúng số lượng không? Đồng thời xem số lần thử lại và tài nguyên tiêu thụ. Một giao diện có vẻ bình thường vẫn có thể che việc liên tục gọi một phụ thuộc đang lỗi, khiến áp lực lan sang phần khác.

Nếu sản phẩm có cơ chế ngắt tạm thời các cuộc gọi lỗi, đừng chỉ kiểm tra tên trạng thái của cơ chế ấy. Hãy chứng minh hành vi: cuộc gọi được hạn chế, phần thay thế xuất hiện, rồi các cuộc gọi được thử lại theo thiết kế khi phụ thuộc hồi phục. Đây là điểm cần kết hợp với kiểm thử khả năng quan sát để giải thích diễn biến.

Hồi phục cũng là một kết quả cần thử

Sau khi gỡ tác động, chạy lại hành trình và đối chiếu dữ liệu. Trang có thoát khỏi trạng thái thay thế không, giỏ hàng có bị nhân đôi không, cảnh báo đã trở về đúng trạng thái chưa? Phân biệt thời điểm gỡ lỗi với thời điểm sản phẩm hồi phục. Khoảng cách giữa hai mốc có thể tiết lộ bộ nhớ đệm hoặc trạng thái chưa được làm mới.

Báo cáo nên giữ giả thuyết, cách chèn lỗi, phạm vi, mốc dừng và bằng chứng trước, trong, sau. Không suy rộng rằng hệ thống chịu được mọi sự cố chỉ từ một phụ thuộc đã thử. AI có thể giúp rà kế hoạch, nhưng không thay đội vận hành quyết định phạm vi được phép. Một thí nghiệm tốt kết thúc bằng hiểu biết cụ thể và hành động sửa có thể kiểm chứng.

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.