Checklist kiểm thử biểu mẫu thanh toán là thứ mà đội nào cũng biết mình cần, nhưng thường chỉ viết ra sau khi đã có sự cố đầu tiên. Biểu mẫu thanh toán là nơi hiếm khi được phép sai, vì một lỗi ở trang đăng ký chỉ làm người dùng khó chịu, còn một lỗi ở bước thanh toán có thể làm mất tiền, và đôi khi mất tiền hai lần. Bài này là một danh sách kiểm tra có thể dùng trực tiếp, sắp xếp theo thứ tự mà một đội phát triển thường gặp vấn đề.
Cần chuẩn bị gì trước khi bắt đầu kiểm thử?
Hãy chuẩn bị ba thứ trước khi mở trình duyệt. Thứ nhất, một bộ dữ liệu thử gồm cả thẻ phải được chấp nhận và thẻ phải bị từ chối; nếu không có cả hai loại, bạn chỉ kiểm thử được một nửa luồng. Thứ hai, quyền truy cập vào nhật ký của cả hệ thống của bạn và của cổng thanh toán, vì phần lớn câu hỏi kiểu “vì sao giao dịch này thất bại” chỉ trả lời được từ nhật ký. Thứ ba, một môi trường thử có cấu hình giống môi trường thật ở những điểm quan trọng, đặc biệt là các bước xác thực bổ sung và các ràng buộc về số tiền.
Nếu bạn đang thiếu dữ liệu thử, trình tạo số thẻ tín dụng giả của trang này có thể sinh ra nhiều bộ số thẻ, ngày hết hạn và mã bảo mật cùng lúc, để bạn tập trung vào việc kiểm thử thay vì vào việc nghĩ ra dữ liệu.
Ma trận trạng thái của một giao dịch
Phần lớn lỗi trong biểu mẫu thanh toán không nằm ở việc giao dịch thành công hay thất bại, mà nằm ở những trạng thái trung gian. Đây là ma trận tối thiểu cần phủ.
| Trạng thái | Điều cần kiểm tra |
|---|---|
| Đang xử lý | Nút gửi phải bị vô hiệu hóa để tránh gửi hai lần |
| Thành công | Đơn hàng được ghi nhận đúng một lần, không có bản ghi trùng |
| Bị từ chối | Thông báo rõ ràng, và đơn hàng không được ghi nhận là đã thanh toán |
| Hết thời gian chờ | Người dùng biết mình cần kiểm tra lại, không thấy màn hình trắng |
| Mất kết nối giữa đường | Trạng thái không được kẹt vĩnh viễn ở bước đang xử lý |
| Bị hủy giữa đường | Đơn hàng không nên tồn tại ở trạng thái đã thanh toán |
Hãy kiểm thử từng dòng bằng cách cố tình tạo ra tình huống đó, chứ không chờ nó xảy ra tự nhiên. Với trường hợp mất kết nối, công cụ giả lập mạng yếu hoặc chế độ ngoại tuyến của trình duyệt là đủ.
Gửi lại và bấm hai lần có nguy hiểm không?
Đây là nhóm lỗi tốn tiền nhất, và cũng là nhóm dễ bỏ sót nhất.
Người dùng bấm nút gửi hai lần vì mạng chậm, vì giao diện không có phản hồi, hoặc đơn giản vì thói quen. Nếu hệ thống của bạn không xử lý được tình huống đó, khách hàng có thể bị trừ tiền hai lần và bạn sẽ phải hoàn lại một khoản, kèm theo một khách hàng đang rất khó chịu.
Cách kiểm thử là chủ động gửi hai yêu cầu giống hệt nhau trong khoảng thời gian rất ngắn, rồi kiểm tra xem có bao nhiêu giao dịch được tạo ra. Kết quả đúng là đúng một giao dịch, và yêu cầu thứ hai nên nhận lại kết quả của yêu cầu thứ nhất thay vì tạo ra một giao dịch mới.
Cũng cần kiểm thử trường hợp người dùng gửi yêu cầu, không thấy phản hồi, tải lại trang và gửi lại. Đây là kịch bản rất phổ biến trên mạng di động, và nó khác với việc bấm hai lần ở chỗ trạng thái của trang đã bị đặt lại.
Xử lý khi giao dịch bị từ chối
Một giao dịch bị từ chối có thể đến từ nhiều nguyên nhân khác nhau, và cách hệ thống phản hồi nên khác nhau tùy theo nguyên nhân.
Nếu lý do là số dư không đủ, người dùng cần biết rằng họ có thể thử một thẻ khác. Nếu lý do là thẻ đã hết hạn, họ cần được nhắc cập nhật thông tin thẻ. Nếu lý do là bước xác thực bổ sung không hoàn tất, họ cần biết rằng giao dịch chưa được thực hiện và có thể thử lại.
Điều không nên làm là hiển thị một thông báo chung chung cho mọi trường hợp, hoặc tệ hơn, hiển thị chi tiết kỹ thuật mà người dùng không hiểu. Hãy nhớ rằng thông báo từ hệ thống thanh toán thường được viết cho lập trình viên, không phải cho khách hàng, nên bạn cần một lớp chuyển đổi ở giữa.
Một chi tiết quan trọng khác: khi giao dịch bị từ chối, đừng xóa dữ liệu người dùng đã nhập. Việc phải gõ lại toàn bộ thông tin sau mỗi lần thất bại là một trong những nguyên nhân phổ biến nhất khiến khách hàng bỏ dở đơn hàng.
Hoàn tiền và các luồng sau giao dịch
Luồng hoàn tiền thường được kiểm thử muộn nhất, và vì thế thường là luồng có nhiều lỗi nhất.
Hãy kiểm tra rằng hoàn tiền toàn phần đưa đơn hàng về đúng trạng thái, rằng hoàn tiền một phần không làm thay đổi số tiền còn lại của các lần hoàn sau, và rằng không thể hoàn nhiều hơn số tiền đã thu. Hãy kiểm tra cả trường hợp hoàn tiền cho một giao dịch đã bị tranh chấp, vì đó là tình huống mà nhiều hệ thống xử lý sai.
Nếu hệ thống của bạn gửi thông báo cho khách hàng khi hoàn tiền, hãy kiểm tra cả nội dung và thời điểm gửi. Một thông báo hoàn tiền được gửi trước khi khoản tiền thực sự được xử lý sẽ tạo ra một cuộc gọi tới bộ phận hỗ trợ.
Phần dành cho nhà phát triển
Danh sách dưới đây tập trung vào những điểm thường bị bỏ qua khi rà soát trước khi phát hành.
- Xác định khóa chống trùng cho mỗi giao dịch. Một mã định danh duy nhất do phía hệ thống của bạn tạo ra, được gửi kèm mỗi yêu cầu và được hệ thống thanh toán tôn trọng, là cách xử lý gửi trùng đáng tin cậy nhất. Hãy kiểm thử rằng cùng một khóa không bao giờ tạo ra hai giao dịch.
- Lưu trạng thái trước khi gọi ra bên ngoài. Nếu bạn chỉ ghi lại kết quả sau khi nhận phản hồi, một lần mất kết nối sẽ để lại một giao dịch không ai biết là đã xảy ra. Hãy ghi lại ý định trước, rồi cập nhật kết quả sau.
- Có cơ chế đối soát định kỳ. Hãy chạy một tác vụ định kỳ so sánh trạng thái trong hệ thống của bạn với trạng thái tại hệ thống thanh toán, và tự động phát hiện những giao dịch lệch nhau.
- Kiểm thử các giá trị biên của số tiền. Số tiền bằng không, số tiền rất nhỏ, số tiền rất lớn và số tiền có nhiều chữ số thập phân đều là những trường hợp cần thử. Đây cũng là nơi các lỗi làm tròn xuất hiện.
- Kiểm thử với nhiều loại thẻ khác nhau. Một thẻ mười lăm chữ số có mã bảo mật bốn chữ số ở mặt trước sẽ phát hiện ra những lỗi mà một bộ kiểm thử toàn thẻ mười sáu chữ số không bao giờ chạm tới.
- Ghi lại mã định danh của yêu cầu trong nhật ký. Khi có sự cố, bạn cần tìm được đúng yêu cầu trong nhật ký của hệ thống thanh toán. Nếu mã định danh không được ghi lại, bạn sẽ phải đoán theo thời điểm và số tiền.
- Không ghi lại dữ liệu thẻ trong nhật ký. Hãy che số thẻ và tuyệt đối không ghi lại mã bảo mật, kể cả trong môi trường thử.
- Kiểm thử tính truy cập của biểu mẫu. Điều hướng bằng bàn phím, nhãn cho trình đọc màn hình và thông báo lỗi được liên kết với đúng ô nhập liệu là những điểm vừa ảnh hưởng đến trải nghiệm vừa ảnh hưởng đến tỷ lệ chuyển đổi.
Về dữ liệu, hãy giữ bộ dữ liệu thử ở dạng tổng hợp và tách biệt hoàn toàn khỏi dữ liệu thật. Mọi số thẻ do công cụ sinh ra đều đúng cấu trúc và hợp lệ theo phép kiểm tra chữ số, nhưng chúng chưa từng được phát hành, không gắn với tài khoản nào và không thể hoàn tất một giao dịch thanh toán. Chúng chỉ dành cho kiểm thử phần mềm và trình diễn biểu mẫu.
Tiếp theo
Nếu bạn muốn hiểu vì sao các giá trị biên như ngày hết hạn trong tháng hiện tại lại hay gây lỗi, hãy đọc bài định dạng ngày hết hạn thẻ. Còn nếu bạn cần một bộ dữ liệu phủ nhiều mạng thẻ trước khi bắt đầu, bài số thẻ thử nghiệm theo từng mạng sẽ giúp bạn chọn đúng dải số cần đưa vào.
Nếu bạn đang xây dựng môi trường thử cho một dự án và muốn tham khảo cách xử lý dữ liệu thử trong bài toán địa chỉ và số điện thoại, bài viết về kiểm thử địa chỉ và số điện thoại quốc tế là một phần mở rộng cùng chủ đề.