Why Test Database?

1. Data Mapping

    Trong các hệ thống phần mềm, dữ liệu thường di chuyển qua lại từ UI (User Inteface) đến backend DB và ngược lại. Vì vậy, đây là một số khía cạnh cần chú ý:

• Kiểm tra xem các trường trong các field tại giao diện có được ánh xạ (mapping) nhất quán với các trường tương ứng trong bảng DB hay không. Thông thường, thông tin ánh xạ này được xác định trong các tài liệu yêu cầu.
• Bất cứ khi nào một hành động nhất định được thực hiện ở giao diện người dùng, một hành động CRUD (Create, Select, Update và Delete) tương ứng sẽ được gọi ở backend. Tester sẽ phải kiểm tra xem hành động đúng có được gọi hay không và liệu hành động được gọi trong bản thân nó có thành công hay không.

2. ACID Properties Validation

    Atomicity, Consistency, Isolation, and Durability. Mọi giao dịch (transaction) trong database đều phải đảm bảo 4 nguyên tắc này

• Atomicity có nghĩa là một giao dịch sẽ chỉ có 1 trong 2 trạng thái thất bại hoặc thành công. Điều này có nghĩa là ngay cả khi một phần của giao dịch không thành công thì toàn bộ giao dịch được coi là thất bại. Thông thường chúng ta hay gọi đây là quy tắc "all or nothing".
• Consistency một giao dịch sẽ luôn dẫn đến trạng thái hợp lệ của database
• Isolation: Nếu có nhiều giao dịch và chúng được thực hiện cùng một lúc, kết quả / trạng thái của database phải giống như lúc chúng được thực hiện lần lượt.
• Durability: Sau khi giao dịch thành công, không có bất kỳ yếu tố nào như mất điện hoặc sự cố không mong muốn nào có thể thay đổi được dữ liệu.

3. Data Integrity

    Đối với bất kì hành động CRUD nào, cá giá trị, trạng thái khi được lấy ra sẽ luôn là dữ liệu mới nhất. Khi ứng dụng được sử dụng, người dùng cuối sẽ chủ yếu sử dụng các hoạt động CRUD.

• C: Create - Khi người dùng ‘Lưu’ bất kỳ giao dịch mới nào, hoạt động ‘Tạo’ sẽ được thực hiện.
• R: Retrive - Khi người dùng ‘Search’ hoặc ‘View’ bất kỳ giao dịch đã lưu nào, thao tác ‘Truy xuất’ được thực hiện.
• U: Update - Khi người dùng ‘Chỉnh sửa’ hoặc ‘Sửa đổi’ một bản ghi hiện có, hoạt động ‘Cập nhật’ của DB được thực hiện.
• D: Delete - Khi người dùng ‘Xóa’ bất kỳ bản ghi nào khỏi hệ thống, thao tác ‘Xóa’ của DB được thực hiện.

    Hãy tạo ra các trường hợp testing database theo cách bao gồm việc kiểm tra dữ liệu tất cả những nơi mà dữ liệu hiển thị xem chúng có nhất quán với nhau hay không.

4. Business Rule Conformity

    Sự phức tạp trong Databsae có nghĩa là các thành phần như quan hệ ràng buộc, trigger, store procedures,... Vì vậy tester sẽ phải đưa ra các câu truy vấn SQL thích hợp để xác nhận dữ liệu của các đối tượng này có chính xác hay không.

What To Test (Database Testing Checklist)

1. Transactions

    Khi test cá Transaction, điều quan trọng nhất là chúng phải đảm bảo các đặc tính ACID đã nêu ở trên.

    Đây là một số lệnh SQL thường được sử dụng:

• BEGIN TRANSACTION TRANSACTION#
• END TRANSACTION TRANSACTION#
• ROLLBACK TRANSACTION#

    Sau khi các lệnh đã được thực thi, hay sử dụng lệnh Select để xem nhưng giá trị đã thay đổi

• SELECT * FROM TABLENAME <tables which involve the transactions>

2. Database Schemas

    Database schema là một định nghĩa chính thức về cách dữ liệu được tổ chức ở bên trong database. Chúng ta cần test những việc sau:

• Xác định các yêu cầu mà cơ sở dữ liệu hoạt động dựa trên đó, ví dụ:
  • Primary key được tạo trước khi tạo các trường khác
  • Foregin Key nên được đánh index để dễ dàng tìm kiếm
  • Tên trường nên được bắt đầu hoặc kết thúc bằng các ký tự nhất định hoặc theo 1 format chung
  • Các trường có ràng buộc mà các giá trị nhất định có thể hoặc không thể insert vào
• Sử dụng một trong các phương pháp sau tuỳ theo mức độ phù hợp:
  • SQL Query DESC<table name> để kiểm tra validate
  • Sử dụng Regular Expressions để xác thực tên các trường riêng lẻ và giá trị của chúng
  • Sử dụng một số công cụ chẳng hạn như SchemaCrawler

3. Triggers

    Khi một sự kiện nhất định diễn ra trên 1 bảng, 1 đoạn code (1 trigger) có thể được tự động thực thi.

    Phương pháp phổ biến nhất để test là thực hiện truy vấn SQL được nhúng trigger một cách độc lập trước và ghi lại kết quả. Theo dõi điều đó với việc thực thi trigger thông thường, so sánh các kết quả với nhau

    Chúng có thể được test trong cả 2 giai đoạn là Black-box và White-box - White box testing: Stubs và Drivers được sử dụng để chèn hoặc cập nhật hoặc xoá dữ liệu có thể dẫn đến việc gọi trigger. Ý tưởng cơ bản là kiểm tra DB trước khi tích hợp với UI - Black box testing: Kể từ khi tích hợp UI và DB, chúng ta có thể hành động CRUD từ giao diệntheo cáh mà trigger được gọi. Sau đó, sử dụng lệnh SQL để truy xuất dữ liệu trong DB để xem trigger có hoạt động hay không. Hoặc cách thứ hai là chúng ta trực tiếp sử dụng dữ liệu sẽ gọi trigger và xem có hoạt động hay không.

4. Stored Procedures

    Stored procedures hiểu đơn giản là tập hợp của 1 hoặc nhiều đoạn code và giống với các hàm do người dùng định nghĩa. Chúng có thể được gọi bởi lệnh CALL/EXECUTE. Chúng được lưu trữ trong RDBMS và có sẵn trong ứng dụng.

    Dưới dây là một số cách test: - White box testing: các Stubs được sử dụng để gọi các thủ tục được lưu trữ và sau đó kết quả được xác nhận dựa trên kết quả mong đợi. - Black box testing: thực hiện một thao tác từ giao diện người dùng và kiểm tra việc thực thi stored procedure và kết quả của nó

5. Field Constraints

    The Default value (giá trị mặc định), Unique value (giá trị duy nhất), and Foreign key (khoá ngoại): - Thực hiện 1 hoạt động CRUD ở front-end tác động tới cơ sở dữ liệu - Xác thực kết quả với câu truy vấn SQL Kiểm tra giá trị mặc định cho một trường nhất định khá đơn giản. Nó là một phần của business rule validation. Bạn có thể làm thủ công hoặc sử dụng các công cụ như QTP. Theo cách thủ công, bạn có thể thêm giá trị khác với giá trị mặc định của trường từ giao diện xem có dẫn đến lỗi hay không.

    Việc kiểm tra giá trị duy nhất cũng có thể được thực hiện giống như khi test giá trị mặc định.

    Đối với khoá ngoại, hãy sử dụng trực tiếp dữ liệu đã vi phạm ràng buộc và xem ứng dụng có hạn chết chúng hay không. Hãy thực hiện các hoạt động trên UI theo cáh vi phạm ràng buộc xem có lỗi liên quan đến dữ liệu hay hiển thị hay không.

How To Test The Database (Step-By-Step Process)

    Quy trình kiểm thử database nói chung không khác nhiều so với quy trình kiểm thử ứng dụng. Bao gồm các bước như sau:

    Bước 1 Chuẩn bị môi trường

    Bước 2 Thực hiện test

    Bước 3 Kiểm tra kết quả test

    Bước 4 Xác thực theo kết quả mong đợi

    Bước 5 Báo cáo kết quả

    Thông thường, câu lệnh được sử dụng phổ biến nhất là "select..." để test dữ liệu. Ngoài ra còn có 3 loại lệnh quan trọng:

• DDL: Data definition language
  

• DML: Data manipulation language
  

• DCL: Data control language
  

      Hãy xem chi tiết cấu trúc của từng loại và một vài câu lệnh phổ biến:

  • Data Definition language sử dụng CREATE, ALTER, DROP, TRUNCATE để xử lý các bảng và các indexs
  • Data Manipulation language bao gồm các lệnh insert, update ,delete các bản ghi trong bảng
  • Data control language: sử dụng cho việc cấp quyền người dùng và thao tác với dữ liệu. GRANT và REVOKE là 2 câu lệnh thường được sử dụng

Một số lưu ý

1. Tự viết Query

    Để kiểm tra Cơ sở dữ liệu một cách chính xác, tester phải có kiến thức rất tốt về các câu lệnh SQL và DML (Ngôn ngữ thao tác dữ liệu). Tester cũng nên biết cấu trúc DB bên trong của AUT.

    Bạn có thể kết hợp GUI và xác minh dữ liệu trong các bảng tương ứng để có thể bao quát phạm vi ảnh hưởng tốt hơn. Nếu bạn đang sử dụng máy chủ SQL thì bạn có thể sử dụng SQL Query Analyzer để viết các truy vấn, thực thi chúng và truy xuất kết quả.

    Đây là cách tốt nhất và mạnh mẽ để kiểm tra cơ sở dữ liệu khi ứng dụng có mức độ phức tạp vừa hoặc nhỏ.

    Nếu ứng dụng rất phức tạp thì tester có thể khó hoặc không thể viết tất cả các truy vấn SQL được yêu cầu. Đối với các truy vấn phức tạp, bạn cần trợ giúp từ dev, bạn nên sử dụng phương pháp này vì nó mang lại cho bạn sự tự tin khi kiểm tra và cũng nâng cao kỹ năng SQL của bạn.

2. Quan sát dữ liệu trong mỗi bảng

    Bạn có thể thực hiện xác minh dữ liệu bằng cách sử dụng kết quả của hành động CRUD. Điều này có thể được thực hiện thủ công bằng cách sử dụng giao diện người dùng ứng dụng khi bạn biết tích hợp cơ sở dữ liệu. Nhưng đây có thể là một công việc tẻ nhạt và cồng kềnh khi có dữ liệu khổng lồ trong các bảng cơ sở dữ liệu khác nhau.

    Đối với Kiểm tra Dữ liệu Thủ công, Người kiểm tra Cơ sở dữ liệu phải có kiến thức tốt về cấu trúc bảng cơ sở dữ liệu.

3. Sử dụng Queries từ developers

    Đây là cách đơn giản nhất để kiểm tra Cơ sở dữ liệu. Thực hiện bất kỳ hoạt động CRUD nào từ GUI và xác minh các tác động của nó bằng cách thực hiện các truy vấn SQL tương ứng thu được từ nhà phát triển. Nó không yêu cầu kiến thức tốt về SQL cũng như không yêu cầu kiến thức tốt về cấu trúc DB của ứng dụng.

    Nhưng phương pháp này cần được sử dụng một cách thận trọng. Có thể truy vấn do developers viết ra không đáp ứng được nghiệp vụ hoặc tệ hơn có thể là một câu truy vần sai.

4. Hãy sử dụng các công cụ Database Automation Testing

    Có một số công cụ có sẵn cho quá trình Kiểm tra dữ liệu. Bạn nên chọn đúng công cụ theo nhu cầu của mình và sử dụng nó một cách tốt nhất.

Tư liệu tham khảo

    https://www.softwaretestinghelp.com/database-testing-process/