1. Bối cảnh doanh nghiệp & phạm vi
Bạn là QA Automation Lead tại NeoBank — một ngân hàng số phục vụ khoảng 3 triệu khách hàng, xử lý trung bình 1,2 triệu giao dịch mỗi ngày, cao điểm cuối tháng lên tới 2.500 giao dịch mỗi phút. Sản phẩm trọng yếu nhất là chuyển khoản: nội bộ (cùng NeoBank) và liên ngân hàng qua NAPAS. Quý này, đội Core Banking tái kiến trúc luồng chuyển khoản liên ngân hàng để giảm độ trễ và tăng tỉ lệ thành công. Mọi thay đổi trên luồng này đều là thay đổi 'chạm tiền thật': một lỗi nhỏ có thể trừ tiền khách hai lần, tạo 'tiền ảo', hoặc để giao dịch treo lơ lửng không rõ trạng thái.
Yêu cầu đặt ra cho đội QA không chỉ là 'test cho chạy được'. Ban lãnh đạo và bộ phận tuân thủ (compliance) đặt ra ràng buộc: hệ thống phải đạt SLA khả dụng 99,95%, thời gian phản hồi p95 dưới 3 giây cho bước xác nhận, và tuyệt đối không được có sai lệch tài chính lọt ra production. Ngân hàng Nhà nước yêu cầu mọi giao dịch phải truy vết được và đối soát khớp với NAPAS mỗi ngày. Vì thế, chiến lược kiểm thử phải phủ được không chỉ 'happy path' mà cả những ca lỗi tài chính hiếm gặp nhưng hậu quả nghiêm trọng.
Phạm vi tự động hoá của tài liệu này
- Luồng chuyển khoản liên ngân hàng đầu-cuối: từ thao tác trên app → xác nhận OTP → trừ tiền/treo → định tuyến NAPAS → ghi có/hoàn tiền.
- Các ca lỗi tài chính: idempotency (chống trừ tiền hai lần), hoàn tiền khi bị từ chối, xử lý timeout, vượt hạn mức.
- Đối soát cuối ngày (reconciliation) giữa sổ Core và file settlement của NAPAS.
- Đưa toàn bộ vào CI/CD chạy mỗi PR, kèm giám sát và chỉ số chất lượng.
- Tích hợp AI Agent để tăng tốc soạn ca kiểm thử và điều tra lỗi — với ranh giới trách nhiệm rõ ràng.
2. Kiến trúc hệ thống & luồng nghiệp vụ
Trước khi viết dòng test đầu tiên, một QA giỏi phải hiểu hệ thống như một kỹ sư. Luồng chuyển khoản liên ngân hàng đi qua nhiều thành phần và trộn lẫn cả xử lý đồng bộ lẫn bất đồng bộ — đây chính là gốc rễ của phần lớn độ khó khi kiểm thử.
Phần đồng bộ diễn ra ngay khi khách bấm xác nhận: App gọi API Gateway (xác thực phiên, chống lạm dụng), Gateway chuyển tới Transfer Service. Service này kiểm tra hạn mức, sinh một requestId duy nhất (khoá idempotency), gọi Core để TRỪ tiền người gửi và TREO (hold) khoản tiền vào một tài khoản trung gian, rồi trả về màn hình 'đang xử lý'. Đến đây khách đã thấy tiền bị trừ, nhưng người nhận CHƯA nhận được — trạng thái giao dịch là PENDING.
Phần bất đồng bộ mới là nơi rủi ro cao nhất. NAPAS Adapter đẩy lệnh sang NAPAS để định tuyến tới Bank B. Kết quả trở về dưới dạng callback (webhook) — có thể sau vài giây, có thể vài phút, và đôi khi KHÔNG bao giờ tới (timeout). Nếu callback là SUCCESS, hệ thống ghi có cho người nhận và chuyển trạng thái sang SUCCESS. Nếu là REJECT, hệ thống phải HOÀN tiền cho người gửi và giải phóng hold, trạng thái REFUNDED. Nếu callback không tới trong SLA, một job nền phải chủ động truy vấn hoặc tự hoàn tiền.
3. Mô hình dữ liệu & bất biến nghiệp vụ
Trái tim của một hệ thống ngân hàng là SỔ CÁI GHI KÉP (double-entry ledger): mỗi chuyển động tiền được ghi thành các bút toán Nợ/Có sao cho tổng Nợ luôn bằng tổng Có. Hiểu mô hình này giúp bạn định nghĩa 'oracle' — tức kết quả kỳ vọng chính xác — thay vì chỉ kiểm tra thông báo trên màn hình.
Bốn bất biến phải đúng ở MỌI thời điểm
- Bảo toàn tiền (conservation): tổng số dư toàn hệ thống không đổi; sum(Debit) = sum(Credit). Tiền chỉ dịch chuyển, không tự sinh/mất.
- Idempotency: cùng một requestId dù được gửi lại bao nhiêu lần cũng chỉ tạo ĐÚNG MỘT giao dịch và trừ tiền một lần.
- Trạng thái cuối duy nhất: mỗi giao dịch kết thúc ở đúng một trong SUCCESS / FAILED / REFUNDED — không 'lơ lửng' vô thời hạn.
- Khớp đối soát: mỗi giao dịch nội bộ phải có bản ghi tương ứng ở NAPAS và ngược lại; lệch phải được phát hiện.
Bốn bất biến này chính là bộ 'oracle' cho toàn bộ bài test. Thay vì assert 'màn hình hiện Thành công', mỗi test tài chính sẽ assert số dư chính xác ở cả hai đầu, sự tồn tại và giá trị của từng bút toán, trạng thái cuối, và (ở tầng đối soát) sự khớp với dữ liệu NAPAS. Đây là khác biệt lớn nhất giữa test 'cho có' và test bảo vệ được tiền thật.
4. Phân tích rủi ro & chiến lược kiểm thử
Không thể (và không nên) tự động hoá mọi thứ qua giao diện. Chiến lược đúng bắt đầu từ rủi ro: ưu tiên tự động hoá những luồng mà nếu hỏng sẽ gây mất tiền hoặc vi phạm quy định, và đẩy phần còn lại xuống các tầng test nhanh và rẻ hơn.
Ma trận rủi ro (xác suất × hậu quả)
- Cao/Cao — Trừ tiền hai lần khi double-submit: hiếm nhưng mất tiền khách & uy tín. Bắt buộc test tự động, chạy mỗi deploy.
- Thấp/Cao — Callback NAPAS không tới (timeout): xảy ra khi mạng/đối tác trục trặc, để lại giao dịch treo. Bắt buộc test.
- Trung bình/Cao — Đối soát lệch cuối ngày: nếu không phát hiện, sai lệch tích luỹ. Bắt buộc test luồng đối soát.
- Cao/Trung bình — Vượt hạn mức bị chặn sai: ảnh hưởng trải nghiệm & tuân thủ. Test data-driven theo bảng hạn mức.
- Trung bình/Thấp — Sai định dạng hiển thị số tiền: khó chịu nhưng không mất tiền. Test ở tầng component/UI nhẹ.
💬 Bình luận (0)
Chưa có bình luận nào. Hãy là người đầu tiên!