Đối soát dữ liệu 3 lớp: nguồn ↔ database ↔ giao diện

Lỗi giao diện thì ai nhìn cũng thấy. Lỗi dữ liệu thì khác: một con số sai trông vẫn hoàn toàn hợp lý. GDP quý này 5,2% thay vì 5,7%, giá đóng cửa lệch một ngày, tổng vốn đầu tư thiếu một tỉnh — người dùng không phát hiện, nhưng họ ra quyết định dựa trên con số đó.

Với các sản phẩm hiển thị dữ liệu (dashboard, app tài chính, báo cáo), đối soát dữ liệu là phần quan trọng nhất của việc test. Bài này trình bày cách làm có hệ thống.

Ba lớp, ba loại lỗi

Dữ liệu thường đi qua ba lớp trước khi tới mắt người dùng:

Nguồn (website, file, API bên thứ ba)
   │  thu thập / crawl / import
   ▼
Database
   │  API backend
   ▼
Giao diện (bảng, chart, tooltip, file export)

Mỗi lớp có những kiểu lỗi đặc trưng.

Lớp thu thập: nguồn → database

• Thiếu kỳ: nguồn có 12 tháng, DB chỉ có 11.
• Sai đơn vị: nguồn ghi “triệu USD”, DB lưu như USD.
• Đọc sai số: 1.234,5 (kiểu Việt/Âu) bị hiểu thành 1.2345.
• Trùng bản ghi: chạy lại job thu thập tạo thêm dòng thay vì cập nhật.
• Ghi đè dữ liệu cũ: nguồn sửa số liệu quá khứ, hệ thống không cập nhật — hoặc ngược lại, cập nhật nhầm kỳ.
• Lệch kỳ: dữ liệu tháng 9 được gán ngày 01/10.

Lớp lưu trữ và API: database → API

• Làm tròn sớm ở backend làm mất độ chính xác.
• Sai múi giờ khi chuyển đổi ngày.
• Lọc sai điều kiện, thiếu một nhóm (quốc gia, ngành, mã).

Lớp hiển thị: API → giao diện

• Định dạng số sai: thiếu dấu phân cách, hậu tố K/M/B sai.
• Định dạng ngày không đúng tần suất (dữ liệu quý mà hiển thị theo ngày).
• Bảng và tooltip làm tròn khác nhau cho cùng một giá trị.
• Legend không đổi theo khi đổi tab hoặc đổi đơn vị tiền tệ.
• File export khác với dữ liệu đang hiển thị.

Đừng dò hết bằng mắt: chọn mẫu thông minh

Một chart 10 năm dữ liệu tháng có 120 điểm, nhân với 5 quốc gia là 600 con số. Dò hết bằng mắt vừa mất thời gian vừa dễ sót.

Nếu có thể, so toàn bộ bằng script: xuất dữ liệu từ DB và từ API ra CSV rồi so tự động. Đây là việc rất hợp để giao cho máy.

Nếu phải làm tay, chọn mẫu theo rủi ro:

Mẫu	Vì sao
Kỳ mới nhất	Dữ liệu mới hay bị thiếu, chưa cập nhật
Kỳ cũ nhất	Lỗi khi lấy dữ liệu lịch sử, cắt khoảng thời gian
Kỳ chuyển năm	Lỗi định dạng ngày, lỗi sắp xếp
Giá trị 0, âm, rỗng	Lỗi hiển thị, lỗi chia cho 0
Giá trị lớn nhất	Tràn layout, sai hậu tố K/M/B
Mỗi nhóm một mẫu	Thiếu cả một quốc gia/ngành
Kỳ nguồn từng sửa số	Lỗi không cập nhật dữ liệu đã thay đổi

Quy tắc so sánh số

Trước khi so, thống nhất 3 điều với team:

1. Khoá so sánh: so theo cặp (kỳ, mã nhóm), không so theo thứ tự dòng.
2. Đơn vị: quy về cùng đơn vị trước khi so.
3. Dung sai làm tròn: giao diện hiển thị 2 chữ số thập phân thì chênh lệch dưới 0,005 là chấp nhận được; lớn hơn là lỗi.

Vài câu SQL chỉ đọc hữu ích

Bạn không cần giỏi SQL để đối soát. Vài mẫu dưới đây (dùng tài khoản chỉ đọc) giải quyết phần lớn nhu cầu.

Lấy 12 kỳ gần nhất của một nhóm:

SELECT period, value
FROM indicator_values
WHERE indicator_code = 'GDP_GROWTH' AND country = 'VN'
ORDER BY period DESC
LIMIT 12;

Tìm bản ghi trùng:

SELECT indicator_code, country, period, COUNT(*) AS n
FROM indicator_values
GROUP BY indicator_code, country, period
HAVING COUNT(*) > 1;

Kiểm kỳ mới nhất của từng nhóm (phát hiện nhóm bị dừng cập nhật):

SELECT country, MAX(period) AS latest
FROM indicator_values
WHERE indicator_code = 'GDP_GROWTH'
GROUP BY country
ORDER BY latest;

Tên bảng và cột ở trên chỉ là ví dụ — hãy hỏi Dev cấu trúc thật và xin một tài khoản chỉ đọc vào DB staging.

Ghi lỗi: chỉ rõ lớp sai

Khi ghi lỗi dữ liệu, cách hiệu quả nhất là đặt ba giá trị cạnh nhau:

Kỳ	Nguồn	DB	Giao diện	Kết luận
Q2/2026	5,7	5,7	5,2	Lỗi hiển thị
Q1/2026	6,1	(không có)	(trống)	Lỗi thu thập

Nhìn bảng này, Dev biết ngay cần sửa ở frontend hay ở job thu thập, không cần hỏi lại. Khi một Story có nhiều lỗi dữ liệu nhỏ, gom chúng vào một bug tổng hợp có đánh số theo nhóm (theo chart, theo bảng) thường dễ theo dõi hơn mười ticket rời rạc.

Kết

Đối soát dữ liệu tốt không phải là dò thật nhiều con số, mà là biết chọn con số nào để dò và chỉ ra được lỗi nằm ở lớp nào. Phần dò lặp lại thì nên để script làm; phần chọn mẫu theo rủi ro và kết luận thì cần đến hiểu biết của bạn về dữ liệu.