Kiểm tra dữ liệu sau thao tác: 5 bước cần soi trong DB testing
5 bước kiểm dữ liệu sau một thao tác
Áp dụng cho mọi thao tác có hệ quả. Cột cuối lấy thao tác "huỷ đơn hàng" làm ví dụ cho dễ hình dung.
| Bước | Câu hỏi cần trả lời | Ví dụ: thao tác huỷ đơn |
|---|---|---|
| 1. Bản ghi chính | Đúng bản ghi đó đã đổi đúng giá trị chưa? | Trạng thái đơn đã chuyển sang huỷ chưa |
| 2. Dữ liệu liên quan | Bảng con và các số liệu phụ thuộc có đổi theo không? | Dòng hàng trong đơn, tồn kho có được hoàn lại |
| 3. Dấu vết | Hệ thống có ghi lại rằng việc đó đã xảy ra không? | Cột đánh dấu xoá, thời điểm cập nhật, bản ghi lịch sử |
| 4. Dữ liệu KHÔNG liên quan | Có gì bị đổi ngoài ý muốn không? | Đơn của khách khác có bị đụng vào không |
| 5. Ràng buộc toàn vẹn | Sau thao tác, dữ liệu còn nhất quán không? | Không còn dòng con mồ côi; tổng tiền vẫn khớp chi tiết |
🔧 Năm bước, làm lần lượt
Thực hiện thao tác qua giao diện như người dùng thật — đừng sửa thẳng bằng SQL, vì thứ đang được kiểm chính là việc ứng dụng làm gì với dữ liệu.
- 1Bước 1 — Bản ghi chính
Kiểm đúng bản ghi vừa bị tác động: giá trị đã đổi chưa, đổi thành đúng cái cần đổi chưa. Điểm mấu chốt là đọc thẳng từ cơ sở dữ liệu, thay vì tin vào thông báo trên màn hình.
SELECT * FROM <bang_chinh> WHERE <khoa> = ?; -- Ví dụ với thao tác huỷ đơn: SELECT order_id, status FROM Orders WHERE order_id = 'ORD_003';
- 2Bước 2 — Dữ liệu liên quan
Thao tác nào cũng kéo theo dữ liệu khác: bảng con, tồn kho, số dư, tổng tiền. Đây là chỗ hay hỏng nhất vì nó nằm ngoài màn hình bạn đang đứng.
SELECT * FROM <bang_con> WHERE <khoa_ngoai> = ?; -- Ví dụ: tồn kho của sản phẩm nằm trong đơn SELECT p.product_id, p.stock FROM Products p JOIN Order_Items i ON i.product_id = p.product_id WHERE i.order_id = 'ORD_003';
- 3Bước 3 — Dấu vết
Hệ thống có ghi lại rằng việc đó đã xảy ra không: cột đánh dấu xoá, thời điểm cập nhật, bản ghi lịch sử. Thiếu dấu vết thì báo cáo lọc sai, và về sau không truy được ai đã làm gì.
-- Huỷ rồi mà chưa được đánh dấu xoá SELECT order_id, status, deleted_at FROM Orders WHERE status = 'CANCELLED' AND deleted_at IS NULL;
- 4Bước 4 — Dữ liệu KHÔNG liên quan
Bước ít người làm nhất. Để kiểm được, trước khi thao tác hãy chạy một câu lấy danh sách kèm cột quan trọng và giữ kết quả lại (copy ra Excel là đủ). Sau khi thao tác, chạy lại đúng câu đó rồi đặt cạnh nhau — thứ đổi mà lẽ ra không được đổi sẽ lộ ra.
-- Chạy 2 lần: trước và sau thao tác, rồi so SELECT <khoa>, <cot_quan_trong> FROM <bang_chinh> ORDER BY <khoa>;
- 5Bước 5 — Ràng buộc toàn vẹn
Kiểm các quy tắc chung mà dữ liệu luôn phải giữ: không có dòng con mồ côi, tổng khớp chi tiết, không trùng khoá. Điểm hay của bước này là câu kiểm viết một lần dùng lại mãi, vì nó soi quy tắc chứ không gắn với bản ghi cụ thể.
-- Đơn đã xoá mềm mà dòng hàng còn sót SELECT i.item_id, i.order_id, i.quantity FROM Order_Items i JOIN Orders o ON o.order_id = i.order_id WHERE o.deleted_at IS NOT NULL;
🐞 Góc nhìn Tester — Hạn chế & lỗi thường gặp
Các hạn chế thường gặp khi dùng — biết trước để chủ động kiểm lại.
- 1Năm bước chỉ soi được vùng bạn nghĩ ra. Bảng nào không nằm trong danh sách thì dù hỏng cũng không lộ — nên hỏi dev xem thao tác còn chạm bảng nào khác không.
- 2Có hệ thống cập nhật muộn vì xử lý chạy nền. Kiểm ngay rồi kết luận "chưa đổi là lỗi" có thể oan — cần biết trước thao tác đó có phần chạy bất đồng bộ hay không.
- 3Trên môi trường test dùng chung, người khác thao tác song song sẽ làm bước 4 báo sai. Chọn lúc vắng hoặc dùng dữ liệu riêng.
📌 Tóm lại
Giao diện cho bạn biết thao tác có chạy hay không. Dữ liệu mới cho biết nó đã thực sự làm những gì. Lần tới khi test một thao tác, thay vì dừng ở bản ghi vừa đụng vào, hãy đi hết năm bước. Riêng bước 4 và bước 5 — hai bước ít người làm nhất — thường là nơi những lỗi sống dai nhất đang nằm.