Kịch bản đăng nhập, thêm sản phẩm và thanh toán có nhiều trạng thái nối tiếp. Nếu công cụ QA đổi tuyến proxy giữa chừng mà không ghi nhận, lỗi phiên có thể bị nhầm thành lỗi giỏ hàng. Giải pháp là giữ điều kiện mạng ổn định cho ca cơ sở, sau đó thiết kế ca đổi mạng riêng trên staging do mình sở hữu hoặc được cho phép kiểm thử.
Giới hạn phạm vi và dữ liệu thử
Dùng tài khoản QA, sản phẩm giả, địa chỉ giả và môi trường thanh toán sandbox. Chặn gửi thông báo tới khách hàng thật hoặc kích hoạt giao hàng thật. Đặt giới hạn số lần đăng nhập để không tạo tải ngoài phạm vi được duyệt; không sử dụng danh sách mật khẩu rò rỉ hay tài khoản không thuộc quyền kiểm thử.
Proxy phục vụ kiểm tra tuyến mạng, không phải công cụ vô hiệu hóa chống gian lận. Nếu ứng dụng yêu cầu xác thực bổ sung sau đổi IP, cần đánh giá đó có đúng chính sách hay không, thay vì tìm cách vượt qua để kịch bản luôn báo thành công.
Ca cơ sở: giữ tuyến trong toàn bộ hành trình
Gắn một cấu hình tuyến có phiên bản với lần chạy: mở trang → đăng nhập → thêm hàng → cập nhật số lượng → xem tổng tiền → tới sandbox thanh toán → đăng xuất. Ghi mã lần chạy và mã tuyến, không ghi cookie hoặc mật khẩu. Khởi tạo môi trường trình duyệt sạch cho từng tài khoản thử.
Giữ tuyến không đảm bảo phiên vô hạn. Token có thể hết hạn, ứng dụng có thể đổi session ID sau đăng nhập hoặc cấp quyền. OWASP Session Management xem vòng đời phiên và các biến đổi môi trường là những yếu tố cần kiểm soát, đồng thời yêu cầu tránh lộ session ID trong log.
Ma trận đổi mạng có chủ đích
Tạo các ca riêng: đổi tuyến trước đăng nhập, sau đăng nhập, sau thêm hàng và sau khi gửi yêu cầu thanh toán sandbox. Chỉ thay một điều kiện mỗi ca. Kỳ vọng có thể khác nhau: một bước đọc giữ phiên, bước nhạy cảm yêu cầu xác thực lại, hoặc phiên bị kết thúc theo chính sách.
Proxy và browser fingerprint là hai lớp khác nhau. Đừng đổi đồng thời IP, trình duyệt và cookie rồi quy mọi khác biệt cho proxy. Với mỗi ca, lưu cấu hình mạng, phiên bản ứng dụng và kết quả chuẩn hóa để có thể tái hiện.
Kiểm tra cookie và giỏ hàng độc lập
Giỏ hàng có thể nằm ở máy chủ, cookie hoặc lưu trữ trình duyệt. Phải xác nhận thiết kế thực tế trước khi đặt kỳ vọng. MDN về Set-Cookie mô tả các thuộc tính Secure, HttpOnly, SameSite, Domain và Path; cấu hình phạm vi cookie có thể ảnh hưởng luồng đăng nhập và chuyển trang.
Không nới cookie production để làm test dễ hơn. Kiểm tra tài khoản A không thấy giỏ của B, đăng xuất không để lại quyền truy cập nhạy cảm và giỏ khách được hợp nhất đúng chính sách khi đăng nhập. Thử cả tab mới, làm mới trang và phiên hết hạn bằng dữ liệu giả.
Ví dụ giả định: đổi tuyến sau thêm hàng
Trên một cửa hàng staging, tài khoản QA thêm hai sản phẩm giả bằng tuyến A. Người kiểm thử đổi sang tuyến B theo ca đã duyệt rồi mở trang thanh toán. Thiết kế giả định yêu cầu xác thực lại nhưng giữ giỏ hàng. Nghiệm thu là xuất hiện đúng bước xác thực và tổng tiền không thay đổi, không phải tiếp tục mua hàng bằng mọi giá.
Nếu hệ thống trả lỗi, đối chiếu mã yêu cầu và trạng thái giỏ trên staging. Không phát lại lệnh thanh toán mù quáng. Khi dùng Stripe cho môi trường thử, tài liệu testing của Stripe hướng dẫn dùng chế độ và dữ liệu thử; quy trình này chỉ áp dụng nếu dự án thực sự tích hợp Stripe, không phải mô tả nhà cung cấp thanh toán của ProxySmart.
Tiêu chí nghiệm thu và vệ sinh sau chạy
- Ca cơ sở hoàn thành bằng tuyến đã chọn, không có thay đổi mạng ngoài dự kiến.
- Mỗi ca đổi mạng có kết quả đúng với chính sách đã phê duyệt.
- Không tạo đơn thật, trừ tiền thật hoặc gửi thông báo tới người dùng thật.
- Không xuất hiện cookie, mã thanh toán hoặc mật khẩu trong log và ảnh báo cáo.
- Dữ liệu, phiên và tài khoản QA được dọn theo chính sách môi trường thử.
Đo tỷ lệ hoàn thành từng bước, số lần yêu cầu xác thực lại và lỗi giỏ, nhưng không diễn giải ít xác thực hơn là an toàn hơn. Ca thử quy mô nhỏ nên có kết quả mong đợi rõ; xem kiểm thử proxy trước production để chuẩn bị phần mạng.
Câu hỏi thường gặp
Đổi IP phải giữ đăng nhập mới là đạt?
Không. Một ứng dụng có thể yêu cầu xác thực lại khi tín hiệu rủi ro thay đổi. Đạt là phản ứng đúng chính sách, không phải luôn giữ phiên.
Có dùng tài khoản khách thật để QA không?
Không nên. Dùng tài khoản và dữ liệu thử đã được phê duyệt để tránh lộ thông tin và tạo giao dịch ngoài ý muốn.
Kết luận
Giải pháp proxy cho QA đăng nhập và giỏ hàng cần tách ca tuyến ổn định khỏi ca thay đổi mạng. Tài khoản thử, sandbox thanh toán và tiêu chí chính sách giúp tìm lỗi mà không vượt qua kiểm soát bảo mật hay tạo tác dụng phụ thật.