Kiểm thử đồng thời & tương tranh (Concurrency & Race Condition Testing) cho ví điện tử fintech

1. Tóm tắt nhanh & màn hình bạn sẽ test

Nếu bạn đã quen kiểm thử một người dùng thao tác một lúc, bài này đưa bạn sang một lớp rủi ro hoàn toàn khác: điều gì xảy ra khi HAI HAY NHIỀU thao tác cùng chạm vào cùng một dữ liệu gần như CÙNG LÚC. Với hầu hết ứng dụng, lỗi kiểu này chỉ gây khó chịu nhẹ; nhưng với ví điện tử — nơi mỗi con số là tiền thật — một lỗi tương tranh có thể khiến số dư âm, tiền 'nhân bản' từ hư không, hoặc một giao dịch bị trừ tiền hai lần. Đây cũng là dạng lỗi khó tìm nhất: chạy tuần tự thì luôn PASS, chỉ lộ ra khi đúng hai request va vào nhau trong một cửa sổ vài chục mili-giây. Chúng ta sẽ học qua ví điện tử VíNhanh: rút tiền, chuyển tiền tức thời, và cách hai thiết bị/hai người dùng có thể 'đua' nhau trên cùng một số dư.

2. Race condition, double-spend & vì sao ví điện tử đặc biệt rủi ro

Cơ chế gây ra race condition thường theo một khuôn mẫu quen thuộc gọi là 'đọc-sửa-ghi' (read-modify-write): hệ thống ĐỌC số dư hiện tại, TÍNH số dư mới sau giao dịch, rồi GHI lại số dư đó. Nếu hai giao dịch cùng đọc số dư ở gần như cùng một thời điểm — trước khi giao dịch kia kịp ghi — cả hai sẽ tính toán dựa trên CÙNG một số dư ban đầu, và giao dịch ghi sau sẽ VÔ TÌNH GHI ĐÈ lên kết quả của giao dịch ghi trước, khiến một trong hai giao dịch 'biến mất' khỏi số dư cuối cùng dù cả hai đều đã báo thành công với người dùng.

Double-spend — thuật ngữ vốn quen thuộc trong tiền mã hoá nhưng áp dụng y hệt cho ví điện tử truyền thống — là hậu quả trực tiếp có thể quan sát được của race condition: CÙNG một khoản tiền được 'chi' thành công NHIỀU HƠN MỘT LẦN. Với một sàn thương mại điện tử, một lỗi tương tranh hiếm gặp có thể chỉ gây một đơn hàng bị trùng, xử lý thủ công là xong; nhưng với ví điện tử, mỗi lần double-spend là tiền thật rời khỏi hệ thống mà không có gì đối ứng — công ty phải bù lỗ, hoặc tệ hơn, hệ thống đối soát không phát hiện ra và lỗ hổng bị lợi dụng lặp lại có chủ đích.

3. Khoá lạc quan, khoá bi quan & deadlock — vũ khí chống tương tranh

Để ngăn lost update, hệ thống cần một cơ chế KHOÁ để đảm bảo tại một thời điểm chỉ một giao dịch được phép thay đổi cùng một dữ liệu. Có hai chiến lược phổ biến. Optimistic locking (khoá lạc quan) 'đặt cược' rằng tranh chấp hiếm khi xảy ra: không khoá trước, chỉ gắn một số hiệu version vào bản ghi, và khi ghi mới so sánh version hiện tại với version lúc đọc — nếu có giao dịch khác đã ghi trước (version đã đổi), hệ thống từ chối và yêu cầu thử lại. Pessimistic locking (khoá bi quan) 'đặt cược' ngược lại: khoá hẳn bản ghi ngay khi giao dịch bắt đầu, mọi giao dịch khác muốn đụng vào cùng dữ liệu phải xếp hàng chờ tới khi khoá được giải phóng.

Chọn sai chiến lược khoá — hoặc chọn đúng nhưng cài đặt sai — sinh ra hai họ lỗi khác nhau mà tester cần biết cách phân biệt để kiểm thử đúng trọng tâm. Với optimistic locking, lỗi thường gặp là RETRY không được xử lý đúng: người dùng bị từ chối giao dịch nhưng ứng dụng không thử lại tự động hoặc không báo rõ lý do, khiến trải nghiệm giống như 'app bị treo' dù về bản chất hệ thống đang bảo vệ dữ liệu đúng cách. Với pessimistic locking, rủi ro nghiêm trọng hơn là DEADLOCK: khi giao dịch A khoá tài khoản 1 rồi chờ khoá tài khoản 2, trong lúc giao dịch B đã khoá tài khoản 2 và đang chờ khoá tài khoản 1 — cả hai kẹt vĩnh viễn, chờ nhau tới khi hệ thống hết timeout hoặc phải khởi động lại. Một hệ thống ví điện tử tốt luôn khoá tài khoản theo một THỨ TỰ CỐ ĐỊNH (ví dụ theo ID tăng dần) để loại trừ khả năng deadlock kiểu này.