Kiểm thử báo cáo & đối soát dữ liệu ngân hàng: sổ cái ↔ giao dịch ↔ báo cáo (nâng cao)

1. Tóm tắt nhanh & bức tranh hệ thống đối soát

Bạn đang ở cấp độ nâng cao — bài này giả định bạn đã vững kiểm thử chức năng cơ bản và muốn đi sâu vào một mảng dễ bị đánh giá thấp nhưng lại gây thiệt hại lớn nhất khi sai: kiểm thử số liệu tài chính tổng hợp. Dự án xuyên suốt là TrustBank PayGate — hệ thống báo cáo tài chính và đối soát giao dịch của một cổng thanh toán ngân hàng, nơi mỗi ngày có hàng chục nghìn giao dịch chảy qua ba tầng dữ liệu khác nhau trước khi lên báo cáo cuối cùng gửi Ban điều hành.

2. Đối soát là gì & vì sao khó ở hệ ngân hàng

Ở một hệ e-commerce đơn giản, 'đúng' thường nghĩa là giao diện hiển thị số liệu như mong đợi. Ở hệ ngân hàng, 'đúng' phức tạp hơn nhiều: cùng một tập giao dịch phải cho ra CÙNG một kết quả dù bạn nhìn từ Core Banking (sổ cái), từ cổng thanh toán (nhật ký giao dịch), hay từ báo cáo tổng hợp gửi lên Ban điều hành. Ba hệ này thường do ba đội khác nhau xây, cập nhật ở tần suất khác nhau, và có thể lệch nhau vài giây tới vài phút — đó chính là gốc rễ của phần lớn lỗi đối soát.

Ba nguồn dữ liệu kinh điển bạn phải nắm rõ vai trò: (1) Sổ cái (General Ledger — GL) là nguồn 'sự thật cuối cùng' về tài chính, do Core Banking ghi nhận sau khi hạch toán; (2) Nhật ký giao dịch (Transaction Log — TXN) ghi mọi sự kiện xảy ra ở cổng thanh toán, kể cả giao dịch đang xử lý (Pending) chưa hạch toán; (3) Báo cáo tổng hợp (Report — RPT) là kết quả tổng hợp cuối cùng, thường qua một tầng ETL/kho dữ liệu trung gian. Đối soát chính là công việc chứng minh ba nguồn này 'kể cùng một câu chuyện' tại một mốc thời gian xác định.

Vì sao khó? Vì lệch có thể tới từ RẤT nhiều tầng: độ trễ đồng bộ giữa các hệ, quy tắc làm tròn khác nhau ở mỗi service, cách xử lý giao dịch đang treo (Pending/Reversal) không thống nhất, và mốc cắt ngày (cutoff) không đồng nhất về múi giờ. Một tester giỏi đối soát không chỉ so hai con số cuối — họ hiểu được TỪNG TẦNG dữ liệu đi qua để khoanh vùng đúng nơi gây lệch, thay vì báo chung chung 'số liệu sai'.

3. Kiến trúc luồng dữ liệu đối soát

Trước khi viết ca kiểm thử, hãy vẽ ra luồng dữ liệu thật của hệ thống — đây là bước nhiều tester nâng cao bỏ qua vì tưởng 'ai cũng biết'. Ở TrustBank PayGate, giao dịch đi qua bốn tầng: Core Banking ghi sổ cái gần như tức thời, Cổng thanh toán ghi nhật ký giao dịch, một tiến trình ETL đẩy dữ liệu vào Kho dữ liệu theo lô mỗi 15 phút, và cuối cùng Report Engine tổng hợp báo cáo lúc 23:59 mỗi ngày (giờ nghiệp vụ GMT+7).

Điểm mấu chốt: mỗi tầng có ĐỘ TRỄ khác nhau. Nếu bạn đối soát ngay tại thời điểm chưa hết chu kỳ ETL 15 phút, RPT sẽ luôn 'chậm' hơn TXN một chút — đó là lệch TẠM THỜI, bình thường, không phải bug. Ngược lại, nếu sau khi tất cả các batch đã chạy xong (ví dụ sau 00:30 hôm sau) mà vẫn còn lệch, đó mới là lệch THỰC SỰ cần điều tra. Phân biệt được hai loại lệch này là kỹ năng nền tảng của kiểm thử đối soát nâng cao.

-- Truy vấn đối soát mẫu: so khớp GL vs TXN theo ngày nghiệp vụ (GMT+7)
SELECT
  DATE(gl.posted_at AT TIME ZONE 'Asia/Ho_Chi_Minh') AS business_day,
  COUNT(gl.txn_id)  AS gl_count,
  COUNT(t.txn_id)   AS txn_count,
  SUM(gl.amount)    AS gl_total,
  SUM(t.amount)     AS txn_total
FROM ledger gl
FULL OUTER JOIN transaction_log t ON gl.txn_id = t.txn_id
WHERE gl.status <> 'PENDING'
GROUP BY 1
HAVING COUNT(gl.txn_id) <> COUNT(t.txn_id)
    OR SUM(gl.amount) <> SUM(t.amount);
-- Dòng trả về = ngày có lệch cần điều tra tiếp.

4. Sai lệch làm tròn & tỷ giá — kỹ thuật kiểm thử

Làm tròn là nguồn lỗi âm thầm nguy hiểm nhất trong hệ ngân hàng: từng khoản lệch có thể chỉ 1 đồng, nhưng nhân với hàng chục nghìn giao dịch/ngày sẽ tích lũy thành số tiền đáng kể lộ ra ở báo cáo tổng. Bước đầu tiên KHÔNG phải là viết ca kiểm thử — mà là hỏi rõ đội phát triển/nghiệp vụ: hệ thống đang dùng quy tắc làm tròn nào? Round-half-up (làm tròn .5 lên), round-half-even/banker's rounding (làm tròn .5 về số chẵn gần nhất), hay truncate (cắt bỏ, không làm tròn)?

▶ Bước 1: Xác nhận quy tắc làm tròn nghiệp vụ chính thức (round-half-up / banker's rounding / truncate) và đơn vị làm tròn (đồng, xu, %) — hỏi BA (Business Analyst), đừng đoán.

▶ Bước 2: Thiết kế input đúng tại biên .5 của đơn vị làm tròn nhỏ nhất, ví dụ phí = 2.499,5đ và 2.500,5đ, để phân biệt các quy tắc cho kết quả khác nhau.

▶ Bước 3: So khớp giá trị làm tròn ở CẢ BA tầng (GL/TXN/RPT) — nếu chỉ một tầng làm tròn còn hai tầng kia giữ số thập phân đầy đủ, tổng cộng dồn sẽ lệch dần theo thời gian.

▶ Bước 4: Kiểm thử tỷ giá quy đổi ngoại tệ: nhập tỷ giá có nhiều số thập phân (vd 25.482,368421 VND/USD), xác nhận số tiền quy đổi và tổng cộng vẫn khớp dù hiển thị đã làm tròn.