50 câu hỏi SQL thường gặp dành cho Tester (Cập nhật 2026)

Last updated on January 19th, 2026 at 02:00 pm

1. SQL là gì và vì sao tester cần biết SQL?

SQL là ngôn ngữ chuẩn để truy vấn và thao tác dữ liệu trong các hệ quản trị cơ sở dữ liệu quan hệ như MySQL, PostgreSQL, SQL Server hay Oracle. Tuy nhiên, với tester, SQL không phải là kỹ năng “phụ trợ”, mà là công cụ để xác minh sự thật của hệ thống, độc lập với UI hay API.

Trong thực tế dự án, rất nhiều lỗi không thể phát hiện bằng cách nhìn giao diện. Ví dụ, UI hiển thị “tạo đơn hàng thành công” nhưng trạng thái đơn trong database vẫn là PENDING, hoặc API trả về HTTP 200 nhưng dữ liệu không được commit. Nếu tester không kiểm tra database, bug này sẽ trôi thẳng lên production.

Trong phỏng vấn, câu hỏi “Tester có cần SQL không?” thực chất để đánh giá xem ứng viên có tư duy data-aware hay chỉ test ở bề mặt.

2. Tester sử dụng SQL khác gì so với Developer?

Developer viết SQL để xây dựng hệ thống, còn tester dùng SQL để thẩm định hệ thống đó có đang vận hành đúng hay không. Điều này dẫn đến cách tiếp cận hoàn toàn khác.

Developer quan tâm hiệu năng, index, execution plan. Tester quan tâm dữ liệu có đúng với test case hay không. Một query “xấu” về performance vẫn có thể chấp nhận trong testing, nhưng một query trả sai dữ liệu thì hoàn toàn không chấp nhận được.

Trong nhiều dự án, tester giỏi SQL thường là người phát hiện bug sớm nhất vì họ nhìn vào dữ liệu thay vì tin vào giao diện.

3. Trong dự án thực tế, tester dùng SQL để làm gì?

SQL xuất hiện gần như xuyên suốt vòng đời test, đặc biệt khi dự án không đơn giản chỉ là CRUD. Tester dùng SQL để kiểm tra dữ liệu sau thao tác người dùng, đối chiếu response API với dữ liệu thực tế, xác minh số liệu báo cáo, kiểm tra batch job chạy đêm và điều tra bug không tái hiện được trên UI.

Một điểm quan trọng là SQL giúp tester thoát khỏi sự phụ thuộc vào developer. Khi dev nói “anh không thấy lỗi”, tester có thể dùng dữ liệu để chứng minh lỗi tồn tại.

4. Manual Tester có bắt buộc phải biết SQL không?

Về lý thuyết, manual tester vẫn có thể làm việc mà không biết SQL. Nhưng trong thực tế dự án trung bình trở lên, tester không biết SQL sẽ bị giới hạn nghiêm trọng về phạm vi test.

Khi không truy cập được database, tester buộc phải tin vào UI hoặc API response, trong khi đây chỉ là lớp hiển thị. Điều này khiến tester dễ bỏ sót bug backend và bị đánh giá là “test chưa đủ sâu”.

5. Tester cần biết SQL tới mức nào là đủ?

Tester không cần thiết kế database hay tối ưu truy vấn, nhưng cần đọc và viết được các query phản ánh logic nghiệp vụ. Điều quan trọng không phải cú pháp phức tạp, mà là hiểu dữ liệu đúng trông như thế nào.

Một tester biết SQL ở mức đủ sẽ:

• Viết được SELECT có JOIN, WHERE, GROUP BY
• Hiểu tác động của NULL
• Đọc được query của developer để debug bug

6. SELECT thực sự hoạt động như thế nào?

SELECT không đơn giản là “lấy dữ liệu”. Khi thực thi, database engine sẽ xác định bảng nguồn, áp dụng điều kiện WHERE, thực hiện JOIN, sau đó mới group, sort và trả kết quả. Nếu tester không hiểu logic này, rất dễ hiểu sai kết quả truy vấn.

Ví dụ, tester có thể nghĩ dữ liệu bị thiếu, trong khi thực chất bị lọc bởi JOIN hoặc WHERE.

7. Vì sao SELECT * là một sai lầm phổ biến trong testing?

SELECT * khiến tester mất kiểm soát dữ liệu đang kiểm tra. Khi bảng có nhiều cột, tester dễ bỏ sót cột quan trọng như status, flag logic hoặc timestamp.

Nguy hiểm hơn, khi schema thay đổi (thêm cột, đổi thứ tự cột), kết quả query vẫn chạy nhưng test case dựa trên đó có thể sai mà tester không nhận ra.

8. WHERE ảnh hưởng thế nào đến độ chính xác của kiểm thử?

WHERE quyết định tester đang test đúng dữ liệu của test case hay dữ liệu “gần giống”. Rất nhiều tester query ra “có dữ liệu” rồi kết luận pass, trong khi dữ liệu đó không thuộc về scenario đang test.

Đây là nguyên nhân phổ biến khiến bug lọt production dù tester đã “check DB”.

9. So sánh = và LIKE trong kiểm thử dữ liệu

LIKE rất tiện, nhưng trong testing nó dễ che giấu bug. Một dữ liệu sai format vẫn có thể match LIKE, khiến tester xác nhận nhầm là đúng.

LIKE chỉ nên dùng khi test chức năng search hoặc fuzzy matching, không nên dùng để xác nhận dữ liệu nghiệp vụ quan trọng như email, mã giao dịch hay trạng thái.

10. DISTINCT giúp tester phát hiện bug gì trong dự án?

DISTINCT không chỉ để “lọc trùng”, mà là công cụ phát hiện bug logic insert hoặc job chạy lặp. Trong nhiều hệ thống, dữ liệu duplicate không hiển thị trên UI nhưng gây lỗi nghiêm trọng ở báo cáo hoặc billing.

Tester dùng DISTINCT có thể phát hiện sớm các bug mà UI không thể hiện.

11. NULL là gì và vì sao NULL là nguồn gốc của rất nhiều bug backend?

NULL đại diện cho việc không có giá trị, chứ không phải giá trị bằng 0 hay chuỗi rỗng. Trong thực tế dự án, NULL thường xuất hiện khi dữ liệu được migrate, khi user bỏ trống input, hoặc khi logic xử lý bị thiếu bước gán giá trị.

Vấn đề nằm ở chỗ NULL không tuân theo các quy tắc so sánh thông thường. Một phép tính, một điều kiện IF hoặc một câu query không xử lý NULL đúng cách có thể dẫn đến kết quả sai hoàn toàn, thậm chí gây crash API. Tester không để ý NULL thường chỉ test “happy case” và bỏ sót các lỗi nghiêm trọng xảy ra với dữ liệu không đầy đủ.

12. Vì sao dùng = NULL luôn là sai?

Trong SQL, NULL không thể so sánh bằng toán tử = vì NULL không phải là một giá trị cụ thể. Khi viết column = NULL, database không trả về TRUE hay FALSE mà là UNKNOWN, khiến điều kiện WHERE không bao giờ match.

Trong phỏng vấn tester, đây là câu hỏi rất phổ biến để phân biệt người hiểu dữ liệu và người chỉ học cú pháp. Một tester từng debug bug liên quan đến NULL sẽ không bao giờ mắc lỗi này.

13. IS NULL và IS NOT NULL giúp tester kiểm thử điều gì?

IS NULL và IS NOT NULL cho phép tester kiểm tra dữ liệu có thực sự tồn tại hay không. Điều này cực kỳ quan trọng khi test dữ liệu bắt buộc, test validate input hoặc test migration.

Trong nhiều dự án, UI có thể chặn input rỗng nhưng backend vẫn ghi NULL do logic xử lý sai. Tester chỉ phát hiện được điều này khi kiểm tra database.

14. NULL ảnh hưởng thế nào đến COUNT trong báo cáo?

COUNT(column) chỉ đếm các bản ghi có giá trị khác NULL, trong khi COUNT(*) đếm toàn bộ bản ghi. Nếu tester không hiểu sự khác biệt này, rất dễ xác nhận sai số liệu report.

Đây là nguyên nhân phổ biến khiến tester và BA tranh cãi vì “số liệu không khớp”, trong khi vấn đề nằm ở cách đếm dữ liệu.

15. Tester nên xử lý test case liên quan đến NULL như thế nào?

Tester cần chủ động tạo test case với dữ liệu NULL, thay vì chỉ kiểm tra dữ liệu đầy đủ. Cần xác định rõ hệ thống mong đợi gì khi gặp NULL: reject, default value hay cho phép lưu.

Những test case này thường không được mô tả rõ trong requirement nhưng lại là nơi bug nghiêm trọng hay xuất hiện.

16. JOIN là gì trong góc nhìn của tester?

JOIN cho phép tester kiểm tra mối quan hệ giữa các bảng dữ liệu. Trong testing, JOIN không chỉ để “lấy đủ thông tin”, mà để xác minh dữ liệu có đi đúng flow nghiệp vụ hay không.

Ví dụ, một đơn hàng tồn tại nhưng không có bản ghi payment tương ứng là dấu hiệu rõ ràng của bug nghiệp vụ.

17. INNER JOIN khác gì LEFT JOIN trong kiểm thử?

INNER JOIN chỉ trả về các bản ghi có quan hệ đầy đủ ở cả hai bảng. Điều này khiến tester vô tình bỏ qua dữ liệu lỗi – những bản ghi bị thiếu liên kết.

LEFT JOIN giúp tester nhìn thấy các record “bị rơi rớt”, rất hữu ích khi test bug liên quan đến dữ liệu không hoàn chỉnh.

18. Khi nào tester nên ưu tiên LEFT JOIN?

Khi mục tiêu là tìm bug, không phải lấy dữ liệu “đẹp”. LEFT JOIN giúp phát hiện các trường hợp dữ liệu được tạo dở dang, job chạy lỗi hoặc logic nghiệp vụ bị ngắt quãng.

Tester chỉ dùng INNER JOIN khi chắc chắn dữ liệu phải tồn tại đầy đủ theo thiết kế.

19. JOIN sai gây hậu quả gì trong testing?

JOIN sai điều kiện có thể tạo ra dữ liệu nhân bản, khiến tester hiểu nhầm hệ thống ghi dữ liệu trùng. Trong nhiều trường hợp, bug không nằm ở hệ thống mà nằm ở query của tester.

Vì vậy, tester cần hiểu rõ khóa chính – khóa ngoại trước khi JOIN.

20. JOIN giúp tester debug bug nghiệp vụ như thế nào?

JOIN cho phép kiểm tra trạng thái của toàn bộ chuỗi nghiệp vụ, ví dụ từ user → order → payment → shipment. Khi một bước bị thiếu, tester có thể xác định chính xác lỗi nằm ở đâu, thay vì báo bug mơ hồ.

21. GROUP BY dùng để làm gì trong testing?

GROUP BY cho phép tổng hợp dữ liệu theo logic nghiệp vụ, thường dùng khi test báo cáo, dashboard và thống kê. Với tester, GROUP BY không chỉ là cú pháp SQL mà là cách mô phỏng cách hệ thống “tính toán số liệu”.

22. Vì sao GROUP BY dễ khiến tester xác nhận sai?

GROUP BY sai cột hoặc thiếu điều kiện WHERE khiến dữ liệu bị gộp sai phạm vi. Tester thấy số liệu “có vẻ hợp lý” nhưng thực chất đã bao gồm dữ liệu ngoài scope test.

Đây là lỗi tinh vi và rất khó phát hiện nếu không hiểu rõ nghiệp vụ.

23. HAVING khác WHERE thế nào trong thực tế test?

WHERE lọc dữ liệu trước khi nhóm, HAVING lọc sau khi đã nhóm xong. Nhầm lẫn hai khái niệm này khiến tester lọc sai dữ liệu mà không nhận ra.

Trong test báo cáo, HAVING thường được dùng để lọc các nhóm có tổng giá trị vượt ngưỡng nhất định.

24. COUNT, SUM, AVG có “bẫy” gì với tester?

COUNT có thể bỏ qua NULL, SUM và AVG có thể bị ảnh hưởng mạnh bởi dữ liệu bất thường. Nếu tester không hiểu điều này, rất dễ kết luận sai rằng hệ thống tính toán sai.

Tester cần hiểu dữ liệu đầu vào trước khi đánh giá kết quả tổng hợp.

25. Test report bằng SQL cần lưu ý điều gì?

Tester cần xác định rõ phạm vi dữ liệu, thời gian áp dụng và logic nghiệp vụ phía sau con số. Việc chỉ so sánh kết quả cuối cùng là không đủ.

26. Subquery là gì và tester dùng khi nào?

Subquery cho phép tester diễn đạt các điều kiện phức tạp, ví dụ “tìm user chưa từng phát sinh giao dịch” hoặc “đơn hàng có trạng thái A nhưng không có bản ghi B”.

Đây là công cụ rất mạnh khi debug bug khó.

27. EXISTS khác IN như thế nào trong testing?

EXISTS kiểm tra sự tồn tại của bản ghi, còn IN so sánh giá trị. Trong dữ liệu lớn, IN có thể gây sai lệch nếu không kiểm soát NULL, trong khi EXISTS an toàn hơn cho logic kiểm thử.

28. Subquery có thể che giấu bug không?

Có. Một subquery viết sai có thể loại bỏ dữ liệu lỗi khỏi kết quả, khiến tester tin rằng hệ thống hoạt động đúng. Vì vậy, tester cần hiểu rõ subquery đang lọc cái gì.

29. Tester có cần tối ưu subquery không?

Không cần tối ưu như developer, nhưng cần hiểu subquery có trả đúng tập dữ liệu cần kiểm tra hay không. Độ đúng quan trọng hơn tốc độ trong testing.

30. Subquery giúp debug bug khó tái hiện thế nào?

Subquery giúp khoanh vùng dữ liệu bất thường nhanh hơn nhiều so với việc kiểm tra thủ công từng bảng, đặc biệt khi bug chỉ xảy ra với một nhóm nhỏ dữ liệu.

31. Tester có nên sử dụng INSERT trong quá trình kiểm thử không?

Tester có thể sử dụng INSERT để chuẩn bị test data, nhưng đây là thao tác cần hiểu rõ bối cảnh và mục đích. INSERT trong testing không phải để “làm cho test pass”, mà để tạo dữ liệu phục vụ một kịch bản kiểm thử cụ thể mà hệ thống không hỗ trợ tạo qua UI hoặc API.

Trong thực tế, nhiều tester insert dữ liệu mà không hiểu đầy đủ mối quan hệ giữa các bảng, dẫn đến dữ liệu không phản ánh đúng nghiệp vụ. Điều này khiến test case mất giá trị và kết quả test không còn đáng tin cậy. Tester chỉ nên dùng INSERT khi nắm rõ cấu trúc dữ liệu và logic nghiệp vụ liên quan.

32. UPDATE tiềm ẩn rủi ro gì đối với tester?

UPDATE là câu lệnh nguy hiểm nhất với tester nếu không được kiểm soát chặt chẽ. Một UPDATE thiếu điều kiện WHERE hoặc sai điều kiện có thể làm thay đổi hàng loạt dữ liệu test, thậm chí ảnh hưởng đến dữ liệu của cả team.

Trong dự án thực tế, nhiều sự cố “mất dữ liệu test” không phải do hệ thống, mà do thao tác UPDATE bất cẩn. Tester chuyên nghiệp luôn kiểm tra SELECT trước khi UPDATE và hiểu rõ phạm vi dữ liệu mình đang tác động.

33. DELETE khác TRUNCATE như thế nào trong bối cảnh testing?

DELETE cho phép xóa dữ liệu theo điều kiện và có thể rollback trong transaction, trong khi TRUNCATE xóa toàn bộ dữ liệu bảng và không thể rollback. Với tester, sự khác biệt này mang ý nghĩa rất lớn về mức độ an toàn.

Trong môi trường dùng chung, việc dùng TRUNCATE có thể gây gián đoạn cho các tester khác và làm mất dữ liệu test quan trọng. Tester cần hiểu rõ để tránh thao tác không thể khắc phục.

34. DROP có vai trò gì trong công việc của tester?

DROP dùng để xóa hoàn toàn bảng hoặc object trong database. Trong testing hằng ngày, tester hầu như không sử dụng DROP. Việc hiểu DROP chủ yếu để tránh sử dụng nhầm, đặc biệt khi làm việc với quyền cao trên database.

Nhiều sự cố nghiêm trọng trong dự án xuất phát từ việc tester hoặc developer thao tác nhầm DROP trên môi trường không phù hợp.

35. Làm thế nào để thao tác dữ liệu an toàn khi kiểm thử?

An toàn dữ liệu trong testing không đến từ may mắn, mà từ thói quen. Tester cần luôn xác định rõ mình đang làm việc trên môi trường nào, dữ liệu nào và trong phạm vi nào.

Việc kiểm tra lại câu lệnh trước khi chạy, giới hạn điều kiện WHERE và ưu tiên làm việc trên dữ liệu test riêng là những nguyên tắc cơ bản giúp tester tránh lỗi nghiêm trọng.

36. Transaction là gì và vì sao tester cần hiểu transaction?

Transaction đảm bảo tính toàn vẹn của dữ liệu bằng cách nhóm nhiều thao tác thành một đơn vị xử lý. Với tester, transaction đặc biệt quan trọng khi kiểm thử các tình huống lỗi giữa chừng, ví dụ thanh toán thất bại hoặc hệ thống bị gián đoạn.

Nếu tester không hiểu transaction, rất dễ nhầm lẫn giữa bug dữ liệu và dữ liệu chưa được commit.

37. COMMIT và ROLLBACK ảnh hưởng thế nào đến kết quả test?

COMMIT xác nhận thay đổi dữ liệu, còn ROLLBACK hủy bỏ toàn bộ thay đổi trong transaction. Trong testing, nhiều trường hợp tester query không thấy dữ liệu đơn giản vì transaction chưa được commit.

Việc hiểu rõ cơ chế này giúp tester tránh báo bug sai và đánh giá đúng hành vi của hệ thống khi xảy ra lỗi.

38. Dirty read là gì và vì sao tester cần quan tâm?

Dirty read xảy ra khi một transaction đọc dữ liệu chưa được commit từ transaction khác. Điều này có thể khiến kết quả test không ổn định, lúc đúng lúc sai, rất khó tái hiện.

Tester cần nhận diện hiện tượng này để phân biệt bug thực sự và vấn đề liên quan đến isolation level của database.

39. Deadlock ảnh hưởng thế nào đến quá trình kiểm thử?

Deadlock xảy ra khi các transaction chờ lẫn nhau và không thể tiếp tục. Trong testing, deadlock thường xuất hiện dưới dạng lỗi ngẫu nhiên, khó tái hiện, khiến tester nhầm lẫn với bug logic.

Hiểu được deadlock giúp tester báo bug chính xác hơn và phối hợp tốt hơn với developer trong quá trình debug.

40. Tester có thể kiểm thử concurrency bằng SQL như thế nào?

SQL giúp tester quan sát trạng thái dữ liệu khi nhiều thao tác diễn ra đồng thời. Bằng cách kiểm tra thời điểm ghi dữ liệu và trạng thái bản ghi, tester có thể đánh giá hệ thống xử lý xung đột và đồng thời đúng hay không.

Đây là mảng kiểm thử khó, nhưng rất quan trọng với các hệ thống có nhiều người dùng.

41. Tester có cần quan tâm đến performance SQL không?

Tester không cần tối ưu SQL, nhưng cần nhận biết khi truy vấn dữ liệu trở thành nguyên nhân gây chậm hệ thống. Nhiều lỗi hiệu năng trong test không xuất phát từ code, mà từ query SQL thiếu điều kiện hoặc xử lý dữ liệu quá lớn.

Việc đặt câu hỏi “vì sao hệ thống chậm” là dấu hiệu của tester có tư duy toàn diện, không chỉ test chức năng.

42. Index ảnh hưởng thế nào đến kết quả kiểm thử?

Index giúp database truy vấn dữ liệu nhanh hơn. Khi thiếu index, API có thể chậm bất thường dù logic đúng, khiến test performance fail.

Tester cần nhận diện được trường hợp này để tránh báo bug sai và hỗ trợ developer xác định nguyên nhân gốc rễ.

43. Vì sao cùng một query chạy nhanh trên dev nhưng chậm trên staging?

Khác biệt về khối lượng dữ liệu và cách phân bố dữ liệu là nguyên nhân phổ biến nhất. Tester cần hiểu điều này để đánh giá kết quả test trong bối cảnh phù hợp, thay vì so sánh máy móc giữa các môi trường.

44. SQL hỗ trợ debug log backend như thế nào?

Log backend thường phản ánh luồng xử lý, còn SQL cho thấy kết quả thực tế. Khi log báo thành công nhưng dữ liệu sai, SQL là công cụ giúp tester chứng minh lỗi tồn tại.

Sự kết hợp giữa log và SQL giúp quá trình debug nhanh và chính xác hơn.

45. Tester có nên đọc execution plan không?

Tester không bắt buộc phải đọc execution plan, nhưng nếu đọc được, sẽ hiểu rõ hơn vì sao query chậm hoặc xử lý không như mong đợi. Đây là kỹ năng cộng thêm, giúp tester làm việc hiệu quả hơn trong các dự án phức tạp.

46. Những câu hỏi SQL nào thường xuất hiện nhất trong phỏng vấn tester?

Phỏng vấn SQL cho tester thường xoay quanh các tình huống thực tế như kiểm tra dữ liệu sau thao tác người dùng, xử lý NULL, JOIN giữa các bảng nghiệp vụ và kiểm tra báo cáo.

Nhà tuyển dụng quan tâm cách ứng viên suy luận bằng SQL hơn là khả năng nhớ cú pháp.

47. Nhà tuyển dụng đánh giá năng lực SQL của tester dựa trên tiêu chí nào?

Tiêu chí quan trọng nhất là tư duy kiểm thử dữ liệu. Tester giỏi SQL là người biết dùng dữ liệu để chứng minh bug, không chỉ trả lời đúng câu hỏi lý thuyết.

Khả năng giải thích vì sao query đó phản ánh đúng test case là điểm cộng rất lớn trong phỏng vấn.

48. Tester học SQL sai cách thường gặp những vấn đề gì?

Học SQL tách rời khỏi dự án thực tế khiến tester biết cú pháp nhưng không biết áp dụng. Kết quả là việc kiểm thử trở nên hình thức, thiếu chiều sâu và không tạo ra giá trị cho sản phẩm.

49. SQL có giúp tester phát triển sự nghiệp lâu dài không?

SQL mở ra nhiều hướng phát triển cho tester, từ test API, test backend đến data testing và automation. Tester có nền tảng SQL tốt thường được tin tưởng giao những phần kiểm thử phức tạp hơn.

50. Lời khuyên quan trọng nhất khi học SQL dành cho tester

Tester nên học SQL như một công cụ để đặt câu hỏi và tìm ra bug, không phải như một môn học thuần kỹ thuật. Mỗi câu query cần gắn với một test case cụ thể và một kỳ vọng rõ ràng về dữ liệu.

Khi SQL trở thành phương tiện kiểm chứng logic hệ thống, tester sẽ sử dụng nó đúng cách và tạo ra giá trị thực sự cho dự án.

INDA Academy tự hào là đơn vị tiên phong trong việc đào tạo phân tích dữ liệu và AI chuyên sâu, đặc biệt cho khối ngành Ngân hàng – Tài chính – Bảo hiểm tại Việt Nam. Sau hơn 12 năm “thực chiến” cùng những dòng chảy dữ liệu khổng lồ, chúng tôi đã xây dựng nên một hệ sinh thái đào tạo toàn diện, giúp hàng nghìn học viên chuyển mình từ người mới bắt đầu trở thành những chuyên gia lành nghề, sẵn sàng đáp ứng tiêu chuẩn khắt khe của các doanh nghiệp lớn.

Điểm khác biệt lớn nhất tại INDA chính là triết lý đào tạo dựa trên các dự án thực tế (Project-based) và lộ trình cá nhân hóa nhờ ứng dụng AI. Chúng tôi không chỉ dạy bạn cách sử dụng công cụ, mà còn truyền tải tư duy khai phá giá trị từ dữ liệu để đưa ra quyết định kinh doanh chính xác.

Tìm hiểu thêm về các khóa học TẠI ĐÂY:
Môn học SQL
Lộ trình đào tạo Data Engineer
Lộ trình đào tạo Data Analyst
Lộ trình đào tạo Tester
Khóa học Data Engineer nâng cao – Thực chiến 5 dự án doanh nghiệp
Khóa học Data Analyst nâng cao – Thực chiến 5 dự án doanh nghiệp