SQL cơ bản cho tester: Những câu truy vấn cần biết để kiểm tra dữ liệu

4 tháng trước · 10 phút đọc

Tại sao tester cần biết SQL?

Mình nhớ lần đầu test tính năng đăng ký tài khoản. Bấm Submit, thấy màn hình hiện "Đăng ký thành công" - mình đánh dấu pass và chuyển sang test case tiếp. Kết quả? Bug nổ production vì dữ liệu user thật ra không được lưu vào database, chỉ có thông báo hiển thị đúng thôi.

Từ đó mình học được một điều: giao diện nói gì không quan trọng bằng database lưu gì.

344713 Verify trên UI chưa đủ - phải kiểm tra tận database

SQL (Structured Query Language) là ngôn ngữ để "nói chuyện" với database. Bạn không cần biết lập trình, không cần viết code phức tạp. Chỉ cần biết đủ để:

Xác minh dữ liệu có được lưu đúng sau khi submit form
Đối chiếu con số hiển thị trên UI với dữ liệu thật trong DB
Tìm record cụ thể để reproduce bug
Kiểm tra dữ liệu có bị trùng, bị thiếu, bị sai định dạng không

Good news: Tester không cần viết query phức tạp như dev. Phần lớn tester dùng SQL chủ yếu chỉ cần 4-5 câu lệnh cơ bản là đủ xử lý 90% công việc thực tế.

Bài này mình tập trung vào đúng những gì cần thiết - không dạy thừa, không bỏ sót phần quan trọng.

SELECT và WHERE: Bộ đôi kiểm tra dữ liệu cơ bản nhất

SELECT là câu lệnh lấy dữ liệu từ bảng. WHERE là điều kiện lọc. Hai cái này bạn sẽ dùng hàng ngày.

Cú pháp cơ bản:

SELECT cột1, cột2
FROM tên_bảng
WHERE điều_kiện;

Tình huống thực tế: Bạn vừa test tính năng đăng ký tài khoản với email [email protected]. Cần verify xem DB có lưu đúng không:

-- Tìm user vừa đăng ký
SELECT id, email, full_name, created_at, status
FROM users
WHERE email = '[email protected]';

344714 Một query SELECT đơn giản có thể xác nhận cả 5 trường dữ liệu cùng lúc

Nếu query trả về 1 row với đầy đủ thông tin đúng - pass. Nếu empty hoặc sai field - bug.

Những điều kiện WHERE hay dùng khi test:

-- Kiểm tra status sau khi user thực hiện hành động
SELECT id, email, status
FROM users
WHERE status = 'inactive';

-- Tìm record được tạo hôm nay (kiểm tra feature create)
SELECT *
FROM orders
WHERE DATE(created_at) = CURDATE();

-- Kiểm tra dữ liệu trong khoảng giá trị
SELECT *
FROM products
WHERE price BETWEEN 100000 AND 500000;

-- Tìm record bị NULL (field bắt buộc có được điền không?)
SELECT id, email
FROM users
WHERE phone_number IS NULL;

Cái cuối quan trọng lắm. Mình từng test form đăng ký có field "Số điện thoại" bắt buộc - UI validate đúng, nhưng query IS NULL lại trả về hàng loạt record. Hóa ra frontend validate nhưng backend không lưu. Bug nghiêm trọng mà nhìn UI không phát hiện được.

Mẹo nhỏ: Dùng SELECT * khi muốn xem tất cả cột, dùng SELECT cột cụ thể khi bảng có nhiều cột và bạn chỉ cần verify một vài trường. Khi bảng có hàng triệu record, thêm LIMIT 10 vào cuối để không bị timeout:

SELECT * FROM orders WHERE status = 'pending' LIMIT 10;

ORDER BY, DISTINCT và COUNT: Ba thứ cần biết thêm

Ba câu lệnh này ngắn nhưng giải quyết được nhiều tình huống test thực tế.

ORDER BY - Sắp xếp để dễ kiểm tra

Khi test tính năng "hiển thị danh sách theo thứ tự mới nhất", cần verify DB trả dữ liệu đúng thứ tự:

-- Kiểm tra order được sort mới nhất lên đầu
SELECT id, customer_name, total_amount, created_at
FROM orders
ORDER BY created_at DESC
LIMIT 20;

DESC = giảm dần (mới nhất trước), ASC = tăng dần (cũ nhất trước). Đối chiếu thứ tự này với cái UI đang hiển thị - nếu khác nhau là bug.

DISTINCT - Phát hiện dữ liệu trùng

Mình dùng cái này khá nhiều khi test form submit. Điều đơn giản nhất: email user có bị duplicate không?

-- Đếm xem có email trùng không
SELECT email, COUNT(*) as so_lan_xuat_hien
FROM users
GROUP BY email
HAVING COUNT(*) > 1;

344715 Query tìm duplicate email - bug điển hình khi thiếu unique constraint

Nếu query này trả về kết quả, database đang có record trùng - đây là bug cần report ngay.

COUNT - Đối chiếu số lượng UI vs DB

UI hiển thị "Tổng 150 sản phẩm" nhưng thực tế bao nhiêu?

-- Đếm tổng record
SELECT COUNT(*) as tong_san_pham
FROM products
WHERE is_active = 1;

-- Đếm theo điều kiện cụ thể
SELECT COUNT(*) as don_hang_cho_xu_ly
FROM orders
WHERE status = 'pending'
AND DATE(created_at) = CURDATE();

So con số COUNT trả về với con số trên UI. Khác nhau = bug. Đơn giản vậy thôi, nhưng mình thấy nhiều fresher bỏ qua bước này và miss bug về pagination, filter.

GROUP BY: Kiểm tra thống kê và báo cáo

Tính năng báo cáo, dashboard thống kê là nơi GROUP BY cực kỳ hữu ích cho tester. UI hiển thị "Doanh thu theo tháng" hay "Số đơn hàng theo trạng thái" - bạn cần query để cross-check.

Cú pháp:

SELECT cột_nhóm, hàm_tổng_hợp
FROM bảng
GROUP BY cột_nhóm;

Ví dụ thực chiến - Test dashboard thống kê đơn hàng:

-- Đếm đơn hàng theo từng trạng thái
SELECT 
    status,
    COUNT(*) as so_don_hang
FROM orders
GROUP BY status;

Kết quả trả về dạng:

status      | so_don_hang
pending     | 45
processing  | 23
delivered   | 189
cancelled   | 12

Đem con số này so với widget dashboard trên UI. Một trường hợp mình hay gặp: UI hiển thị tổng nhưng không tách đúng theo status, hoặc filter theo ngày bị off 1 ngày do timezone.

344716 GROUP BY giúp đối chiếu số liệu dashboard với dữ liệu thật trong DB

Thêm HAVING để lọc nhóm:

HAVING là WHERE nhưng dùng sau GROUP BY - lọc theo kết quả tổng hợp:

-- Tìm user có nhiều hơn 5 đơn hàng (kiểm tra tính năng khóa account spam)
SELECT 
    user_id,
    COUNT(*) as tong_don
FROM orders
GROUP BY user_id
HAVING COUNT(*) > 5;

-- Tìm category có ít hơn 3 sản phẩm active
SELECT 
    category_id,
    COUNT(*) as so_san_pham
FROM products
WHERE is_active = 1
GROUP BY category_id
HAVING COUNT(*) < 3;

Lưu ý nhỏ nhưng quan trọng: WHERE lọc trước khi GROUP, HAVING lọc sau khi GROUP. Nhớ cái này để không viết nhầm điều kiện vào chỗ sai.

JOIN: Khi dữ liệu nằm ở nhiều bảng

Phần lớn ứng dụng thực tế lưu dữ liệu phân tán ở nhiều bảng liên quan nhau. Thông tin đơn hàng ở bảng orders, tên khách hàng ở bảng users, tên sản phẩm ở bảng products. JOIN là cách kết hợp dữ liệu từ nhiều bảng trong một query.

Bạn không cần nhớ hết các loại JOIN phức tạp. Tester chủ yếu dùng INNER JOIN và đôi khi LEFT JOIN.

INNER JOIN - Lấy record có ở CẢ HAI bảng:

-- Xem chi tiết đơn hàng kèm tên khách hàng
SELECT 
    o.id as order_id,
    u.full_name as ten_khach,
    u.email,
    o.total_amount,
    o.status
FROM orders o
INNER JOIN users u ON o.user_id = u.id
WHERE o.status = 'pending';

344717 INNER JOIN kết hợp dữ liệu từ 2 bảng - như ghép 2 danh sách lại với nhau

Tình huống test cụ thể: Bạn test tính năng "Quản lý đơn hàng". UI hiển thị tên khách hàng kèm đơn hàng - bạn cần verify thông tin này khớp với DB, không phải random hay hiển thị nhầm user.

LEFT JOIN - Tìm record không có dữ liệu liên kết:

Cái này đặc biệt hữu ích để tìm bug "dữ liệu mồ côi":

-- Tìm user chưa có đơn hàng nào (kiểm tra tính năng onboarding)
SELECT 
    u.id,
    u.email,
    u.created_at
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE o.id IS NULL;

-- Tìm sản phẩm chưa được phân loại vào category nào
SELECT 
    p.id,
    p.product_name
FROM products p
LEFT JOIN product_categories pc ON p.id = pc.product_id
WHERE pc.category_id IS NULL;

Thấy khó ở phần JOIN bình thường - mình cũng mất cả tuần mới quen. Cách mình nhớ: INNER JOIN như "giao 2 vòng tròn", LEFT JOIN như "toàn bộ vòng trái + phần giao". Thực hành 5-10 query là thấm ngay.

Quy trình kiểm tra dữ liệu sau khi submit form

Đây là tình huống test phổ biến nhất mà mình muốn tổng hợp lại thành quy trình cụ thể. Mỗi lần submit form là bạn cần verify ít nhất 3 điều trong database.

Bước 1: Record có được tạo không?

-- Verify record tồn tại
SELECT * FROM users 
WHERE email = 'email_bạn_vừa_dù[email protected]';

Empty = bug. Record có = tiếp tục bước 2.

Bước 2: Dữ liệu có được lưu đúng không?

-- So sánh từng field với data bạn nhập
SELECT 
    full_name,      -- Có khớp với tên bạn nhập?
    email,          -- Có viết hoa/thường đúng?
    phone,          -- Có lưu đủ 10 số?
    created_at,     -- Timestamp có đúng timezone?
    status          -- Default status có đúng không?
FROM users 
WHERE email = 'email_bạn_vừa_dù[email protected]';

344718 Checklist 3 bước verify sau submit - quy trình tester nên làm thành thói quen

Bước 3: Không có dữ liệu thừa/trùng không?

-- Kiểm tra submit nhiều lần có tạo duplicate?
SELECT email, COUNT(*) as so_lan
FROM users
WHERE email = 'email_bạn_vừa_dù[email protected]'
GROUP BY email;

Nếu so_lan > 1 khi bạn chỉ submit 1 lần, đó là bug trùng record. Nếu bạn cố tình submit 2 lần, bạn cần xem hệ thống có chặn được không.

Checklist đầy đủ khi test form: Tải checklist verify DB sau submit form

Quy trình 3 bước này nghe đơn giản nhưng mình thấy nhiều tester skip bước 2 và 3, chỉ check bước 1. Đó là lý do bug "field lưu sai" hay "submit 2 lần được" tồn tại đến tận production.