Các Lệnh SQL Cơ Bản Mà Tester Nào Cũng Cần Biết
Nếu bạn đang làm Manual Tester hay Automation Tester, chắc hẳn không ít lần bạn cần tự tay kiểm tra dữ liệu trong database thay vì chỉ ngồi chờ Dev xác nhận. Biết SQL không biến bạn thành DBA, nhưng nó giúp bạn tự chủ hơn trong việc verify dữ liệu, viết bug report có bằng chứng thuyết phục hơn, và tiết kiệm rất nhiều thời gian tranh cãi “có bug hay không có bug” với team Dev.
Bài viết này tổng hợp những lệnh mà một Tester thực chiến sẽ dùng gần như mỗi ngày — không đi sâu học thuật, chỉ tập trung vào cái bạn cần để làm việc.
1. SELECT — Câu lệnh bạn sẽ gõ nhiều nhất
Việc đầu tiên và thường xuyên nhất của Tester là xem dữ liệu, không phải sửa dữ liệu. Vì vậy SELECT chính là lệnh “sống còn”.
SELECT * FROM users;
Lệnh trên lấy toàn bộ cột, toàn bộ dòng trong bảng users. Nhưng thực tế bạn hiếm khi cần lấy hết như vậy — nên chỉ định rõ cột cần xem:
SELECT id, username, email, status FROM users;
Tình huống thực tế: Test case yêu cầu “sau khi đăng ký, tài khoản phải có status = pending”. Thay vì hỏi Dev, bạn tự query:
SELECT id, username, status FROM users WHERE email = 'test@example.com';
2. WHERE — Lọc đúng dữ liệu bạn cần
WHERE là điều kiện lọc, giúp bạn không phải mò mẫm giữa hàng nghìn dòng dữ liệu.
SELECT * FROM orders WHERE status = 'failed';
Các toán tử hay dùng khi test:
| Toán tử | Ý nghĩa | Ví dụ |
|---|---|---|
= | Bằng | WHERE status = 'active' |
!= hoặc <> | Khác | WHERE status != 'deleted' |
>, <, >=, <= | So sánh số/ngày | WHERE price > 100000 |
LIKE | Tìm gần đúng (chuỗi) | WHERE email LIKE '%@gmail.com' |
IN | Nằm trong danh sách | WHERE status IN ('pending', 'failed') |
BETWEEN | Trong khoảng | WHERE created_at BETWEEN '2026-01-01' AND '2026-01-31' |
IS NULL | Giá trị rỗng | WHERE phone IS NULL |
Tình huống thực tế: Kiểm tra xem có user nào bị trùng email không (bug nghiêm trọng nếu hệ thống cho phép đăng ký trùng):
SELECT email, COUNT(*) as total
FROM users
GROUP BY email
HAVING COUNT(*) > 1;
3. ORDER BY và LIMIT — Sắp xếp và giới hạn kết quả
Khi bảng có hàng chục nghìn dòng, bạn cần sắp xếp để tìm dữ liệu mới nhất/cũ nhất, và giới hạn số dòng hiển thị để không bị “ngợp”:
SELECT * FROM orders
ORDER BY created_at DESC
LIMIT 10;
Lệnh trên lấy 10 đơn hàng mới nhất — cực kỳ hữu ích khi bạn vừa thực hiện 1 hành động trên UI (đặt hàng, đăng ký) và muốn xác nhận ngay dữ liệu vừa ghi vào DB có đúng không.
4. JOIN — Khi dữ liệu nằm ở nhiều bảng khác nhau
Đây là phần khiến nhiều Tester “sợ” nhất, nhưng thực ra chỉ cần hiểu ý tưởng: dữ liệu thật thường không nằm gọn trong 1 bảng. Ví dụ đơn hàng (orders) chỉ lưu user_id, còn tên khách hàng thật nằm ở bảng users.
SELECT o.id AS order_id, u.username, o.total_price, o.status
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.status = 'completed';
Tình huống thực tế: Kiểm tra bug “khách hàng A mua khóa học B nhưng không thấy trong danh sách khóa học đã mua”:
SELECT u.username, c.course_name, e.enrolled_at
FROM enrollments e
JOIN users u ON e.user_id = u.id
JOIN courses c ON e.course_id = c.id
WHERE u.username = 'nguyenvana';
Nếu query này trả về rỗng dù bạn biết chắc khách đã thanh toán thành công → bạn đã có bằng chứng cụ thể để báo bug, thay vì chỉ nói suông “em thấy nó bị lỗi”.
5. COUNT, SUM, AVG — Kiểm tra số liệu tổng hợp
Rất nhiều bug liên quan đến số liệu tính toán sai (tổng tiền, số lượng, điểm trung bình…). Các hàm tổng hợp giúp bạn tự verify:
SELECT COUNT(*) FROM orders;
SELECT SUM(total_price) FROM orders WHERE status = 'completed';
SELECT AVG(score) FROM quiz_results WHERE quiz_id = 5;
Tình huống thực tế: Test case “Tổng doanh thu hiển thị trên Dashboard Admin phải khớp với tổng các đơn hàng completed”:
SELECT SUM(total_price) AS total_revenue
FROM orders
WHERE status = 'completed';
So sánh kết quả này với số hiển thị trên UI — lệch là có bug ngay.
6. INSERT, UPDATE, DELETE — Dùng khi cần chuẩn bị dữ liệu test
Không chỉ đọc dữ liệu, đôi khi Tester cần tự tạo dữ liệu test thay vì thao tác qua UI (nhanh hơn nhiều, đặc biệt khi cần data đặc biệt như “user đã hết hạn khóa học”, “đơn hàng bị timeout thanh toán”…).
INSERT INTO users (username, email, status)
VALUES ('test_user_01', 'testuser01@example.com', 'active');
UPDATE enrollments
SET expired_at = '2025-01-01'
WHERE user_id = 100 AND course_id = 5;
DELETE FROM users WHERE username = 'test_user_01';
⚠️ Lưu ý an toàn: Luôn kèm
WHEREkhi dùngUPDATEhoặcDELETE. QuênWHEREnghĩa là bạn sửa/xóa toàn bộ bảng — đây là một trong những sự cố “kinh điển” mà cả Tester lẫn Dev đều từng mắc phải ít nhất một lần trong đời. Nên test trên môi trường Staging/Local, tuyệt đối tránh chạy tay trên Production nếu không chắc chắn 100%.
7. Một vài mẹo thực chiến khi test bằng câu lệnh
Luôn SELECT trước khi UPDATE/DELETE Trước khi sửa hoặc xóa, hãy chạy thử bằng SELECT với đúng điều kiện WHERE đó trước, để chắc chắn nó chỉ trả về đúng những dòng bạn muốn:
SELECT * FROM orders WHERE status = 'pending' AND created_at < '2026-01-01';
Nếu đúng số dòng mong muốn, mới chạy UPDATE/DELETE với cùng điều kiện.
Dùng LIMIT khi thử nghiệm trên bảng lớn Tránh query cả triệu dòng khi bạn chỉ cần kiểm tra vài dòng mẫu.
Đặt alias (AS) cho câu query dài — giúp kết quả dễ đọc hơn khi chụp màn hình đính kèm vào bug report.
Tổng kết
SQL không phải là công cụ để Tester thay thế Dev viết code, mà là công cụ giúp bạn:
- Tự verify dữ liệu thay vì đoán mò
- Viết bug report có bằng chứng cụ thể (kèm query + kết quả)
- Chuẩn bị dữ liệu test nhanh mà không cần thao tác lặp lại qua UI
Nắm vững SELECT, WHERE, JOIN, và các hàm tổng hợp là đủ để bạn xử lý 90% tình huống thường gặp trong công việc test hàng ngày. Phần còn lại (Stored Procedure, View, Transaction, CTE…) sẽ cần thiết hơn khi bạn tiến sâu vào Testing chuyên biệt hoặc muốn build data test phức tạp.
Nếu bạn muốn học bài bản từ cơ bản đến nâng cao dành riêng cho công việc Testing — với database thực hành, bài tập tình huống thật, và hướng dẫn chi tiết từng bước — hãy tham khảo khóa học SQL tại Đức Giang Tester Education.
