SQL / Database Testing(Kiểm thử cơ sở dữ liệu)

1.SQL / Database Testing là gì?

Trong các hệ thống phần mềm doanh nghiệp đa tầng (Multi-tier Enterprise Systems), giao diện người dùng (Frontend) đóng vai trò là lớp vỏ tương tác ngoại quan, tầng dịch vụ (Backend/API) giữ nhiệm vụ điều phối và xử lý các quy tắc nghiệp vụ, nhưng nơi thực sự lưu giữ “linh hồn”, giá trị tài sản cốt lõi và thông tin sinh mệnh của toàn bộ hệ thống chính là Cơ sở dữ liệu (Database – DB).

Database Testing (Kiểm thử cơ sở dữ liệu) hay còn gọi là SQL Testing là quá trình kiểm tra, xác thực tính đúng đắn, toàn vẹn và an toàn của dữ liệu lưu trữ bên trong cơ sở dữ liệu (Database) của một ứng dụng.

Nếu kiểm thử giao diện (UI) là kiểm tra “bề nổi” của một tảng băng, thì Database Testing là việc đi sâu xuống “bề sâu” để đảm bảo rằng mọi dữ liệu hiển thị trên giao diện đều được lưu trữ, truy xuất và xử lý chính xác bên dưới hệ quản trị cơ sở dữ liệu (như SQL Server, MySQL, PostgreSQL, Oracle).

Mục đích cốt lõi của Database Testing

1. Đảm bảo tính toàn vẹn dữ liệu (Data Integrity):

   • Xác nhận dữ liệu không bị mất mát, méo mó hay sai lệch khi thực hiện các thao tác thêm, sửa, xóa (CRUD).

2. Xác thực logic nghiệp vụ ở Backend (Business Logic Verification):

   • Đảm bảo các ràng buộc (Constraints), thủ tục lưu trữ (Stored Procedures), triggers hay hàm (Functions) trong CSDL thực thi đúng quy tắc nghiệp vụ.

3. Đảm bảo tính đồng bộ (Data Consistency):

   • Khi người dùng thao tác trên giao diện, dữ liệu trong bảng tương ứng của CSDL phải được cập nhật tức thì và chính xác.

4. Bảo mật và Hiệu năng (Security & Performance):

   • Ngăn chặn các lỗ hổng bảo mật như SQL Injection và kiểm tra xem các câu lệnh truy vấn có chạy nhanh, không bị nghẽn (deadlock) khi có nhiều truy cập cùng lúc không.

Các thành phần chính cần kiểm tra trong Database Testing

Khi làm Database Testing, kiểm thử viên thường sử dụng ngôn ngữ SQL (Structured Query Language) để tương tác trực tiếp với CSDL và tập trung vào các nhóm công việc sau:

1. Kiểm thử cấu trúc (Structural Database Testing)

• Bảng (Tables) & Cột (Columns): Kiểm tra tên bảng, kiểu dữ liệu (DataType), độ dài cho phép (Length) và thuộc tính Allow Null/Not Null.

• Khóa (Keys): Kiểm tra Khóa chính (Primary Key – đảm bảo tính duy nhất) và Khóa ngoại (Foreign Key – đảm bảo mối quan hệ giữa các bảng).

• Chỉ mục (Indexes): Kiểm tra các Index xem có giúp tối ưu tốc độ truy vấn hay không.

2. Kiểm thử dữ liệu & Chức năng (Data & Functional Testing)

• Thao tác CRUD:

  • C (Create): Thêm mới trên UI $\rightarrow$ Dùng câu lệnh SELECT kiểm tra dữ liệu đã vào CSDL chưa.

  • R (Read): Dữ liệu trong CSDL hiển thị ra UI có đúng và đầy đủ không.

  • U (Update): Sửa thông tin trên UI $\rightarrow$ Kiểm tra câu lệnh UPDATE đã cập nhật đúng dòng dữ liệu chưa.

  • D (Delete): Xóa trên UI $\rightarrow$ Kiểm tra dữ liệu đã bị xóa (hoặc đánh dấu xóa mềm) trong CSDL chưa.

• Triggers & Stored Procedures: Chạy thử các hành động kích hoạt tự động hoặc thủ tục lưu trữ xem có trả về kết quả đúng không.

3. Kiểm thử phi chức năng (Non-functional DB Testing)

• Bảo mật (Security): Kiểm tra phân quyền truy cập (User Permissions) và test lỗi SQL Injection.

• Hiệu năng (Performance / Stress Testing): Kiểm tra thời gian phản hồi của các câu truy vấn phức tạp khi cơ sở dữ liệu phình to lên hàng triệu bản ghi.

Ví dụ thực tế dễ hiểu

Giả sử bạn test tính năng “Rút tiền tại cây ATM”:

1. Trên Giao diện (UI Testing): Bạn nhập số tiền 500.000 VNĐ và bấm Rút. Cây nhả ra 500k và màn hình báo “Giao dịch thành công”.

2. Dưới CSDL (Database Testing): Bạn dùng công cụ (như SSMS, DBeaver) viết câu lệnh SQL:

SELECT Balance FROM Accounts WHERE AccountNumber = ‘123456789’;

1. • Kiểm tra: Số dư tài khoản trong bảng Accounts có bị trừ đúng 500.000 VNĐ hay không.

   • Kiểm tra lịch sử: Bảng Transactions có tự động thêm một dòng ghi nhận giao dịch rút tiền mới hay không.

Bảng tóm tắt nhanh

2. Bản chất lý luận, phân loại và các nguyên tắc cốt lõi của Database Testing:

A. Khái niệm và mục tiêu chiến lược

Database Testing là quá trình kiểm tra, đối soát và xác minh tính đúng đắn của cấu trúc cơ sở dữ liệu (Schema), các bảng (Tables), các mối quan hệ (Relationships), các ràng buộc (Constraints), thủ tục lưu trữ (Stored Procedures), hàm (Functions), Triggers, cũng như tính toàn vẹn và độ chính xác của dữ liệu sau khi hệ thống thực hiện các thao tác thêm, sửa, xóa, truy vấn từ phía giao diện hoặc API.

Mục tiêu chiến lược của Database Testing bao gồm:

• Xác minh tính toàn vẹn dữ liệu (Data Integrity): Đảm bảo dữ liệu không bị biến dạng, đứt gãy, mất mát hay ghi đè sai lệch khi luân chuyển qua các tầng ứng dụng.

• Xác minh logic nghiệp vụ ở tầng DB (Business Logic in DB): Đảm bảo các quy tắc nghiệp vụ được cài đặt trực tiếp bên trong cơ sở dữ liệu (như Triggers, Constraints, Stored Procedures) hoạt động chính xác theo đúng thiết kế.

• Đảm bảo hiệu năng và tính bảo mật (Performance & Security): Kiểm tra tốc độ thực thi của các câu lệnh SQL phức tạp, xác định các điểm nghẽn (Bottlenecks) do thiếu chỉ mục (Index), và đảm bảo hệ thống không chứa các lỗ hổng chèn mã độc nghiêm trọng (SQL Injection).

B. Nguyên tắc ACID – Chiếc kim chỉ nam trong Database Testing

Đối với các hệ quản trị cơ sở dữ liệu quan hệ (RDBMS) như Microsoft SQL Server, MySQL, PostgreSQL hay Oracle, kiểm thử viên phải luôn đánh giá và nghiệm thu dữ liệu dựa trên 4 nguyên tắc vàng ACID:

1. Atomicity (Tính nguyên tố): Quy định một giao dịch (Transaction) phải được thực thi hoàn toàn hoặc không thực thi bất kỳ phần nào. Nếu một quy trình chuyển tiền gồm 3 bước (Trừ tiền tài khoản A $\rightarrow$ Ghi nhận lịch sử $\rightarrow$ Cộng tiền tài khoản B) mà bước thứ 3 gặp sự cố, toàn bộ dữ liệu của bước 1 và 2 phải được khôi phục về trạng thái ban đầu (Rollback) như chưa từng có giao dịch xảy ra.

2. Consistency (Tính nhất quán): Dữ liệu trước và sau khi thực hiện giao dịch phải luôn tuân thủ đúng tất cả các quy tắc, ràng buộc (Khóa chính – Primary Key, Khóa ngoại – Foreign Key, Unique, Check, Not Null) đã được định nghĩa trong cấu trúc DB.

3. Isolation (Tính cô lập): Các giao dịch thực thi đồng thời từ nhiều người dùng khác nhau không được xâm phạm, can thiệp hay làm ảnh hưởng đến dữ liệu đang xử lý của nhau.

4. Durability (Tính bền vững): Khi một giao dịch đã được hệ thống xác nhận thành công (Commit), dữ liệu phải được lưu trữ vĩnh viễn vào bộ nhớ cứng và không bị mất đi ngay cả khi máy chủ gặp sự cố sập nguồn hoặc mất điện đột ngột.

3. Hệ thống kỹ thuật SQL từ cơ bản đến nâng cao dành cho Kỹ sư QC:

Để thực hiện Database Testing một cách chuyên sâu, kỹ sư QC cần thành thạo ngôn ngữ truy vấn SQL, được chia thành các nhóm lệnh chính sau đây:

1. DDL (Data Definition Language – Ngôn ngữ định nghĩa dữ liệu)

Dùng để kiểm tra và xác minh tính đúng đắn của cấu trúc cơ sở dữ liệu so với tài liệu thiết kế:

• Các câu lệnh CREATE, ALTER, DROP: Kiểm tra tên bảng, tên trường, kiểu dữ liệu (Data types: VARCHAR, INT, DECIMAL, DATETIME), độ dài tối đa cho phép của từng trường, các chỉ mục (Indexes) và tính chính xác của các ràng buộc (Primary Key, Foreign Key, Not Null, Default Value).

2. DML (Data Manipulation Language – Ngôn ngữ thao tác dữ liệu)

Là nhóm lệnh được kiểm thử viên sử dụng thường xuyên nhất để truy vấn đối soát và chuẩn bị dữ liệu kiểm thử:

• Lấy dữ liệu truy vấn đối soát (SELECT):

— Kiểm tra đơn hàng vừa tạo trên Web có ghi nhận đúng giá trị và trạng thái trong DB hay không
SELECT order_id, customer_id, total_amount, status, created_at
FROM Orders
WHERE order_id = ‘HB-359’;

• Thêm dữ liệu thử nghiệm (INSERT):

Chủ động tạo trước dữ liệu mẫu (Test Data) để phục vụ kiểm thử các kịch bản API/UI
INSERT INTO Users (user_id, username, email, status)
VALUES (101, ‘testuser_01’, ‘[email protected]’, ‘Active’);

Cập nhật dữ liệu (UPDATE) & Xóa dữ liệu rác (DELETE): Dùng để dàn dựng môi trường test (Test Setup) hoặc dọn dẹp dữ liệu rác sau khi kiểm thử xong (Test Teardown).

3. Kỹ thuật ghép bảng (JOIN) và Gom nhóm dữ liệu nâng cao

Trong các hệ thống thực tế, dữ liệu không nằm ở một bảng đơn lẻ mà được phân tán qua nhiều bảng có quan hệ với nhau. QC phải sử dụng thành thạo các phép JOIN:

• INNER JOIN: Lấy các bản ghi có sự trùng khớp chính xác ở cả hai bảng.

• LEFT JOIN / RIGHT JOIN: Lấy toàn bộ dữ liệu ở bảng bên trái/phải và các bản ghi khớp ở bảng còn lại (rất hữu ích khi truy tìm các bản ghi bị mồ côi, khuyết dữ liệu hoặc lỗi Foreign Key).

• Aggregate Functions & GROUP BY: Kết hợp các hàm gom nhóm COUNT(), SUM(), AVG(), MIN(), MAX() và mệnh đề HAVING để kiểm tra các báo cáo tổng hợp, thống kê tài chính hay doanh thu trên hệ thống.

4. Quy trình chuẩn hóa thực hiện Database Testing :

Một quy trình kiểm thử cơ sở dữ liệu bài bản bao gồm 5 bước cốt lõi:

1. Phân tích sơ đồ thiết kế DB (Database Schema Analysis): Nghiên cứu sơ đồ quan hệ thực thể ERD (Entity Relationship Diagram), tài liệu mô tả các bảng, kiểu dữ liệu, các mối quan hệ (1-1, 1-N, N-N) và các quy tắc ràng buộc nghiệp vụ.

2. Chuẩn bị dữ liệu kiểm thử (Test Data Preparation): Viết các câu lệnh SQL INSERT hoặc chạy các script tự động để tạo trước các tập dữ liệu biên, dữ liệu đúng, dữ liệu sai trong DB phục vụ cho các kịch bản kiểm thử.

3. Thực thi thao tác trên ứng dụng (Execution via UI/API): Thực hiện các thao tác thêm mới, chỉnh sửa, xóa hoặc tìm kiếm từ màn hình giao diện người dùng (Frontend) hoặc gọi qua công cụ Postman (API).

4. Trực tiếp kiểm tra đối soát trong DB (Database Verification): Mở các công cụ quản trị cơ sở dữ liệu chuyên dụng (SSMS, DBeaver, MySQL Workbench, Navicat), viết các câu lệnh SELECT để kiểm tra xem dữ liệu trong các bảng có thay đổi chính xác, không bị biến dạng và không phát sinh bản ghi mờ ám hay không.

5. Báo cáo lỗi và theo dõi (Bug Reporting): Nếu phát hiện dữ liệu hiển thị trên giao diện một đằng nhưng lưu dưới DB một nẻo, hoặc thao tác lỗi nhưng dữ liệu bị lưu dở dang, QC tiến hành lập Bug Report ghi rõ nguyên nhân nằm ở tầng Database.

5. Các kịch bản kiểm thử Database nâng cao :

1. Kiểm thử đồng thời và khóa bản ghi (Concurrency & Lock Testing):

   • Kịch bản: Giả lập 2 phiên truy cập cùng lúc thực hiện rút tiền hoặc đặt mua món hàng cuối cùng trong kho tại đúng cùng một millisecond.

   • Mục tiêu: Kiểm tra cơ chế khóa bản ghi (Row-level Locking) của DB xem có ngăn chặn được tình trạng ghi đè dữ liệu sai lệch (Race Condition) hay không.

2. Kiểm thử ràng buộc và kiềm chế dữ liệu (Constraints Testing):

   • Kịch bản: Cố tình chèn trực tiếp bằng SQL một bản ghi trùng mã khóa chính (Primary Key), hoặc chèn mã khách hàng không tồn tại vào bảng Đơn hàng (Foreign Key Violation).

   • Mục tiêu: Xác minh DB có chủ động chặn lại và trả về lỗi ràng buộc an toàn hay không.

3. Kiểm thử Stored Procedures và Triggers:

   • Kịch bản: Thực hiện thao tác làm kích hoạt Trigger (ví dụ: khi đơn hàng chuyển sang trạng thái “Đã hủy”, Trigger phải tự động cộng trả lại số lượng tồn kho của sản phẩm).

   • Mục tiêu: Xác minh các đoạn mã logic viết trực tiếp bên trong DB chạy đúng và không gây treo máy chủ.

6.Các cạm bẫy tư duy và sai lầm cần tuyệt đối tránh khi kiểm thử Database:

• Thao tác trực tiếp trên môi trường Production: Tuyệt đối không chạy các câu lệnh UPDATE hay DELETE không có mệnh đề WHERE hoặc thực hiện test dữ liệu rác trực tiếp trên cơ sở dữ liệu thật của khách hàng.

• Chỉ tin tưởng vào thông báo hiển thị trên giao diện: Màn hình thông báo “Thành công” nhưng thực chất dữ liệu dưới DB chưa được ghi nhận, hoặc bị ghi sai trường. QC bắt buộc phải mở DB lên kiểm tra trực tiếp.

• Quên kiểm tra định dạng múi giờ (Timezone): Hệ thống lưu giờ UTC dưới DB nhưng khi hiển thị lên giao diện theo giờ địa phương (GMT+7) bị lệch ngày/giờ, gây ra các lỗi tính toán logic nghiêm trọng trong các chương trình khuyến mãi.

• Không làm sạch dữ liệu sau khi kiểm thử (Teardown Fail): Nhập quá nhiều dữ liệu rác bằng SQL nhưng không xóa đi, làm sai lệch kết quả của các đợt kiểm thử tự động (Automation Test) tiếp theo.

7. Cảm nhận, chiêm nghiệm :

• Thông qua việc nghiên cứu chuyên sâu và thực hành SQL / Database Testing, em nhận thức rõ ràng rằng kiểm thử phần mềm chỉ thực sự toàn diện khi người kỹ sư QC có khả năng thâm nhập vào tầng lưu trữ dữ liệu gốc rễ của hệ thống.

• Ngôn ngữ SQL không chỉ đơn thuần là công cụ để xem dữ liệu, mà là chiếc chìa khóa giúp QC chủ động dàn dựng môi trường test, vạch trần các lỗi biến dạng dữ liệu ngầm, và đánh giá được độ ổn định của hệ thống dưới góc độ lưu trữ. Việc thành thạo Database Testing cùng với API Testing và UI Testing giúp hoàn thiện năng lực kiểm thử đa tầng (Full-stack Testing), tạo nền tảng chuyên môn vững chắc để phát triển sự nghiệp trong ngành đảm bảo chất lượng phần mềm.

Vu Do

Xem tất cả bài viết của tác giả

Bài viết khác

Test Automation(Kiểm thử tự động)

1.Test Automation (Kiểm thử tự động) là gì? Trong các dự án phát triển phần mềm truyền thống trước đây, toàn bộ quy trình kiểm thử (Testing) đều được thực hiện thủ công (Manual Testing) bởi con người. Các kiểm thử viên trực tiếp thao tác trên giao diện, nhập dữ liệu, kiểm tra kết […]

Đọc thêm

Postman

1.Postman là gì? Trong quá trình phát triển và kiểm thử phần mềm hiện đại, khi kiến trúc hệ thống dịch chuyển mạnh mẽ sang mô hình dịch vụ vi mô (Microservices) và các ứng dụng đa nền tảng, việc kiểm thử tầng dịch vụ API (API Testing) trở thành công việc thường nhật của […]

Đọc thêm

API Testing(Kiểm thử API)

1.API Testing (Kiểm thử API) là gì? Trong các hệ thống phần mềm doanh nghiệp truyền thống trước đây (kiến trúc Monolithic), ứng dụng thường được xây dựng thành một khối thống nhất gồm giao diện người dùng (Frontend) gắn liền trực tiếp với tầng xử lý logic và cơ sở dữ liệu (Backend). Tuy […]

Đọc thêm

CI/CD – Continuous Integration và Continuous Delivery/Deployment

CI/CD – Continuous Integration và Continuous Delivery/Deployment CI/CD là một trong những nền tảng quan trọng của DevOps, giúp tự động hóa quá trình kiểm tra, xây dựng, đóng gói và triển khai phần mềm. Thay vì phải thực hiện thủ công từng bước mỗi khi lập trình viên cập nhật mã nguồn, CI/CD cho […]

Đọc thêm

State Transition Testing(Kiểm thử chuyển đổi trạng thái)

1.State Transition Testing là gì? Trong các hệ thống phần mềm doanh nghiệp hiện đại, phần lớn các ứng dụng không hoạt động một cách tĩnh (static) mà mang tính động (dynamic) mạnh mẽ. Trạng thái phản hồi của một hệ thống tại một thời điểm không chỉ phụ thuộc vào đầu vào hiện tại, […]

Đọc thêm

Firebase Cloud Messaging (FCM)

Firebase Cloud Messaging (FCM) 1. Tổng quan về Firebase Cloud Messaging Firebase Cloud Messaging (FCM) là dịch vụ nhắn tin đám mây do Google cung cấp, cho phép ứng dụng gửi và nhận thông báo hoặc dữ liệu từ máy chủ đến các thiết bị như điện thoại Android, iPhone và trình duyệt web. FCM […]

Đọc thêm