Giới thiệu dự án

Trong kỷ nguyên chuyển đổi số và quản trị doanh nghiệp dựa trên dữ liệu (Data-Driven Enterprise), dữ liệu đóng vai trò là tài sản chiến lược cốt lõi. Theo các nghiên cứu công nghệ phần mềm từ Gartner và IBM System Sciences Institute, chi phí để khắc phục các lỗi liên quan đến sai lệch dữ liệu ở giai đoạn vận hành (Production) cao gấp 30 đến 100 lần so với việc phát hiện sớm trong giai đoạn phát triển. Đặc biệt đối với các hệ thống tài chính, viễn thông và quản trị bán hàng (Sales Management), sự sai lệch trong tính toán chỉ số, sai sót trường dữ liệu hoặc lỗi đồng bộ giữa các luồng giao dịch có thể dẫn đến thất thoát hàng trăm nghìn USD và làm suy giảm nghiêm trọng uy tín doanh nghiệp.

Đồ án tốt nghiệp "Kiểm thử database trên cơ sở dữ liệu Oracle bằng công cụ DBeaver" tập trung giải quyết bài toán đảm bảo chất lượng, tính nhất quán và toàn vẹn của dữ liệu trong các hệ thống doanh nghiệp quy mô lớn. Trọng tâm nghiên cứu là phân tích, thiết kế kịch bản và thực thi kiểm thử Cơ sở dữ liệu (Database Testing) trực tiếp trên RDBMS Oracle Database thông qua môi trường quản trị đa nền tảng DBeaver Community Edition.

+-------------------+      SQL Query Execution      +---------------------+
|  DBeaver CE Client| ----------------------------> | Oracle Database 19c |
| (Universal Client)| <---------------------------- |   (HOAHONG_TEST)    |
+-------------------+       Result Set Validation   +---------------------+
         |                                                     |
         v                                                     v
+-------------------+                               +---------------------+
| Test Case Mapping |                               | Physical Tables:    |
| - Equivalence     |                               | - RP_SALE_GROUPS    |
| - Boundary Value  |                               | - Staff_daily       |
| - Decision Table  |                               | - shop_daily        |
+-------------------+                               +---------------------+

Vấn đề thực tế (Problem Statement)

Phương pháp kiểm thử truyền thống chủ yếu tập trung vào kiểm thử giao diện người dùng (GUI Testing / Black Box Testing thuần túy). Cách tiếp cận này bộc lộ những điểm yếu chí mạng khi đối mặt với các hệ thống xử lý nghiệp vụ phức tạp:

  • Bỏ sót các lỗi logic ngầm ở tầng backend: Giao diện có thể hiển thị thành công nhưng dữ liệu ghi vào bảng bị cắt cụt (truncation), sai định dạng (type mismatch) hoặc vi phạm ràng buộc toàn vẹn tham chiếu.
  • Bất khả thi trong việc kiểm thử luồng dữ liệu lớn (Batch Jobs/ETL): Khi hệ thống thực thi các tiến trình Import/Update hàng triệu bản ghi từ các bảng nhật ký (ví dụ: Staff_daily, shop_daily) vào bảng tổng hợp báo cáo (ví dụ: RP_SALE_GROUPS), kiểm thử qua giao diện người dùng không thể xác thực từng bản ghi và mối quan hệ ánh xạ giữa các trường.
  • Rủi ro phá vỡ tính chất ACID: Các tiến trình giao dịch đồng thời (concurrent transactions) có thể gây ra hiện tượng xung đột dữ liệu, dirty read hoặc non-repeatable read mà kiểm thử GUI không phát hiện được.

Mục tiêu dự án

  1. Hệ thống hóa cơ sở lý thuyết kiểm thử phần mềm: Tổng quan phương pháp kiểm thử hộp trắng (White Box), hộp đen (Black Box), hộp xám (Gray Box) và các kỹ thuật thiết kế testcase cốt lõi (Phân vùng tương đương, Phân tích giá trị biên, Bảng quyết định, Đoán lỗi).
  2. Nghiên cứu kiến trúc RDBMS Oracle Database: Làm chủ mô hình kiến trúc lưu trữ, cơ chế thực thi tiến trình nền (Background Processes), bộ nhớ (SGA/PGA) và quản lý giao dịch tuân thủ chuẩn ANSI/ISO SQL.
  3. Ứng dụng công cụ DBeaver: Khai thác tối đa tính năng của DBeaver để quản lý kết nối JDBC, phân tích Data Dictionary, xây dựng và thực thi các kịch bản SQL phức tạp nhằm xác thực dữ liệu.
  4. Triển khai kiểm thử thực nghiệm trên hệ thống nghiệp vụ thực tế (Hệ thống Phân phối Bán hàng - PBH): Trực tiếp kiểm thử các thao tác thêm mới (Add Column), nhập liệu (Import) và cập nhật dữ liệu (Update) vào bảng dữ liệu trọng yếu RP_SALE_GROUPS từ schema HOAHONG_TEST.

Phạm vi và giới hạn

  • Phạm vi: Kiểm thử cấu trúc (Structural Testing), kiểm thử chức năng (Functional Data Testing) và xác thực tính toàn vẹn (Data Integrity) trên cơ sở dữ liệu Oracle Database 19c/12c của phân hệ tính thưởng/hoa hồng PBH.
  • Giới hạn: Tập trung vào kiểm thử hộp xám và hộp đen ở mức Database, không can thiệp trực tiếp vào mã nguồn tầng ứng dụng (Java/.NET) mà kiểm soát thông qua các luồng dữ liệu vào/ra và các stored procedure/triggers liên quan.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Trước khi áp dụng quy trình kiểm thử Database chuyên sâu bằng DBeaver, doanh nghiệp và đội ngũ QA thường sử dụng các phương pháp đơn lẻ như kiểm tra thủ công qua UI hoặc sử dụng các công cụ quản trị nặng nề. Dưới đây là bảng so sánh các giải pháp hiện hành:

Tiêu chí đánh giá Kiểm thử GUI thuần túy Oracle SQL Developer PL/SQL Developer DBeaver Community
Độ bao phủ dữ liệu ngầm Thấp (< 40%) Cao (100%) Cao (100%) Cao (100%)
Tiêu tốn tài nguyên phần cứng Thấp Cao (JVM nặng, khởi động chậm) Trung bình (Chỉ chạy Windows) Thấp / Tối ưu hóa bộ nhớ
Hỗ trợ đa nền tảng CSDL Không áp dụng Giới hạn (Chuyên Oracle) Chỉ hỗ trợ Oracle Xuất sắc (Oracle, MySQL, PostgreSQL, etc.)
Chi phí bản quyền Miễn phí/Tùy tool Miễn phí (OTN License) Thương mại (Có phí cao) Mã nguồn mở (Free/ASL 2.0)
Khả năng trực quan hóa ERD & Data Mapping Không có Cơ bản Khá tốt Nhanh, trực quan, trực tiếp

Phân loại yêu cầu nghiệp vụ theo mô hình MoSCoW

  • Must have (Bắt buộc): Xác thực 100% tính toàn vẹn của các trường mới thêm vào bảng RP_SALE_GROUPS; kiểm tra chính xác ánh xạ dữ liệu các trường Import và Update (st_channel_type_id, staff_id, s_channel_type_id, shop_id, IS_SHOP_1400).
  • Should have (Nên có): Kiểm tra ràng buộc khóa ngoại (Foreign Key Constraints), kiểm tra trường hợp giá trị biên (Boundary Values) của các cột số và độ dài chuỗi ký tự.
  • Could have (Có thể có): Xây dựng các script truy vấn SQL tự động hóa việc đối soát hàng loạt (Bulk Data Reconciliation).
  • Won't have (Chưa thực hiện đợt này): Kiểm thử tải hiệu năng chuyên sâu (Stress Testing) trên hàng chục terabyte dữ liệu phân tán.

Thiết kế hệ thống

Kiến trúc tổng thể và công nghệ sử dụng

Hệ thống kiểm thử được thiết lập theo mô hình ba lớp kết nối an toàn:

  1. Lớp giao diện & Điều khiển kiểm thử: Công cụ DBeaver Community Edition (v21.x trở lên), chạy trên nền tảng Java Runtime Environment (JRE/JDK 11+).
  2. Lớp giao tiếp dữ liệu: Oracle JDBC Thin Driver (ojdbc8.jar / ojdbc10.jar), giao tiếp qua giao thức TCP/IP cổng tiêu chuẩn 1521.
  3. Lớp Cơ sở dữ liệu đích: Oracle Database Enterprise Edition 19c, bao gồm:
    • System Global Area (SGA): Quản lý Database Buffer Cache, Shared Pool và Redo Log Buffer.
    • Background Processes: DBWn (Database Writer), LGWR (Log Writer), CKPT (Checkpoint).
    • Database Storage: Datafiles lưu trữ các Tablespace chứa schema HOAHONG_TEST.
+-------------------------------------------------------------+
|                     DBeaver UI Client                       |
|   [SQL Editor]  [Data Grid / ERD]  [Test Scripts Engine]    |
+-------------------------------------------------------------+
                              |
                     JDBC Driver (ojdbc8)
                              |
+-------------------------------------------------------------+
|                 Oracle Database 19c Engine                  |
|  +-------------------------------------------------------+  |
|  | SGA (Shared Pool | Buffer Cache | Redo Log)          |  |
|  +-------------------------------------------------------+  |
|  | Background Processes (DBWn, LGWR, CKPT, SMON, PMON)   |  |
|  +-------------------------------------------------------+  |
|  | Tablespace: HOAHONG_TEST                              |  |
|  |  - Table: RP_SALE_GROUPS (Target Aggregation Table)   |  |
|  |  - Table: Staff_daily (Source Master Data)            |  |
|  |  - Table: shop_daily (Source Channel Data)            |  |
|  +-------------------------------------------------------+  |
+-------------------------------------------------------------+

Thiết kế lược đồ dữ liệu kiểm thử (Data Schema)

Các bảng dữ liệu trọng yếu trong quá trình kiểm thử bao gồm:

  • RP_SALE_GROUPS (Bảng đích - Báo cáo nhóm bán hàng): Chứa thông tin nhóm kênh, mã nhân viên, mã cửa hàng, loại kênh và chỉ số phân loại.
    • staff_code (VARCHAR2(50), NOT NULL) - Mã nhân viên
    • staff_id (NUMBER(10)) - ID định danh nhân viên
    • st_channel_type_id (NUMBER(5)) - Loại kênh của nhân viên
    • shop_code (VARCHAR2(50), NOT NULL) - Mã cửa hàng
    • shop_id (NUMBER(10)) - ID định danh cửa hàng
    • s_channel_type_id (NUMBER(5)) - Loại kênh của điểm bán
    • IS_SHOP_1400 (NUMBER(1)) - Cờ phân loại cửa hàng chuẩn (Giá trị: 0 hoặc 1)
  • Staff_daily (Bảng nguồn nhân sự theo ngày): Lưu thông tin biến động nhân sự hàng ngày.
  • shop_daily (Bảng nguồn kênh điểm bán theo ngày): Lưu thông tin trạng thái các điểm bán/cửa hàng.

Phương pháp luận (Methodology)

Quy trình kiểm thử tuân theo mô hình V-Model kết hợp Agile/Scrum, trong đó các hoạt động kiểm thử cơ sở dữ liệu được thực hiện song song với từng giai đoạn phát triển:

  1. Phân tích yêu cầu (SRS Analysis): Trích xuất các quy tắc nghiệp vụ (Business Rules) từ tài liệu đặc tả, xác định bảng nguồn, bảng đích và quy tắc chuyển đổi dữ liệu (Mapping Transformation Rules).
  2. Thiết kế Kịch bản kiểm thử (Test Case Design): Ứng dụng 4 kỹ thuật cốt lõi:
    • Phân vùng tương đương (Equivalence Partitioning): Chia miền giá trị đầu vào thành các lớp hợp lệ và không hợp lệ.
    • Phân tích giá trị biên (Boundary Value Analysis): Kiểm tra các giá trị tại biên cực tiểu, dưới cực tiểu, cực đại và trên cực đại (ví dụ: cờ IS_SHOP_1400 nhận giá trị 0, 1; kiểm tra trường hợp -1, 2, NULL).
    • Bảng quyết định (Decision Tables): Xây dựng ma trận kết hợp điều kiện giữa mã nhân viên, mã kênh và trạng thái hoạt động.
    • Đoán lỗi (Error Guessing): Dự đoán các lỗi như chuỗi chứa khoảng trắng đầu/cuối, lỗi ký tự tiếng Việt Unicode, lỗi khóa chính bị trùng lặp.
  3. Thực thi và Xác thực (Execution & Validation): Viết các script SQL kiểm tra dữ liệu trực tiếp trên DBeaver, so sánh giữa kết quả mong đợi (Expected Result) và kết quả thực tế (Actual Result).
  4. Báo cáo và Quản lý lỗi (Defect Reporting): Ghi nhận bug chi tiết với bằng chứng là ảnh chụp truy vấn SQL và dữ liệu thực tế.

Triển khai và kết quả

Quy trình triển khai (Development & Testing Process)

Dự án được triển khai qua 4 giai đoạn rõ ràng với các mốc bàn giao cụ thể:

  • Giai đoạn 1: Chuẩn bị môi trường và dữ liệu mẫu (Sprint 1): Cấu hình kết nối DBeaver tới schema HOAHONG_TEST, thiết lập tài khoản kiểm thử và đọc hiểu tài liệu Mapping Specs.
  • Giai đoạn 2: Kiểm thử cấu trúc bảng và trường thêm mới (Sprint 2): Kiểm tra Schema, độ dài kiểu dữ liệu, ràng buộc mặc định (Default values, Nullable).
  • Giai đoạn 3: Kiểm thử luồng Import dữ liệu (Sprint 3): Xác thực tiến trình chuyển dịch dữ liệu từ file staging vào bảng RP_SALE_GROUPS.
  • Giai đoạn 4: Kiểm thử luồng Trans Update (Sprint 4 & 5): Thực thi và đối soát các job cập nhật dữ liệu tự động Trans_update_staff và Trans_update_shop.
+-----------------------------------------------------------------------------------+
|                        QUY TRÌNH KIỂM THỬ DATABASE THỰC TẾ                         |
+-----------------------------------------------------------------------------------+
| 1. Đọc SRS & File Mapping  ==>  2. Thiết kế Test Cases (Excel/TestLink)           |
|                                         |                                         |
| 4. Báo cáo Bug & Re-test   <==  3. Chạy SQL Scripts trên DBeaver (Schema HOAHONG) |
+-----------------------------------------------------------------------------------+

Kịch bản và Kỹ thuật SQL chi tiết

Dưới đây là các kỹ thuật SQL và kịch bản truy vấn thực tế được thiết kế và thực thi trên DBeaver để kiểm thử tính chính xác của hệ thống:

Kịch bản 1: Kiểm tra cấu trúc các trường thêm mới trong bảng

Xác định các trường mới đã được thêm vào bảng RP_SALE_GROUPS với đúng kiểu dữ liệu và thuộc tính cho phép NULL:

-- Kiểm tra metadata của bảng RP_SALE_GROUPS từ Data Dictionary của Oracle
SELECT 
    column_name, 
    data_type, 
    data_length, 
    data_precision, 
    nullable 
FROM 
    all_tab_cols 
WHERE 
    table_name = 'RP_SALE_GROUPS' 
    AND column_name IN ('ST_CHANNEL_TYPE_ID', 'STAFF_ID', 'S_CHANNEL_TYPE_ID', 'SHOP_ID', 'IS_SHOP_1400');

Kết quả kỳ vọng: 5 trường xuất hiện đầy đủ, kiểu dữ liệu NUMBER đúng precision đã đặc tả trong tài liệu SRS.

Kịch bản 2: Kiểm thử tính toàn vẹn của luồng Import dữ liệu

Xác thực rằng dữ liệu sau khi chạy tiến trình Import không bị mất mát bản ghi, không bị nhân đôi (duplicate) và mapping đúng từng trường:

-- Kiểm tra tổng số lượng bản ghi giữa bảng nguồn Import và bảng đích
SELECT COUNT(*) AS total_imported FROM RP_SALE_GROUPS WHERE TRUNC(created_date) = TRUNC(SYSDATE);

-- Phát hiện các bản ghi bị trùng lặp khóa nghiệp vụ sau khi Import
SELECT 
    staff_code, 
    shop_code, 
    COUNT(*) 
FROM 
    RP_SALE_GROUPS 
GROUP BY 
    staff_code, shop_code 
HAVING 
    COUNT(*) > 1;

Kịch bản 3: Kiểm thử luồng Trans Update Staff (Trans_update_staff)

Tiến trình Trans_update_staff có nhiệm vụ quét mã staff_code trong bảng RP_SALE_GROUPS, tìm kiếm thông tin tương ứng trong bảng Staff_daily để cập nhật staff_id và st_channel_type_id. Câu lệnh SQL kiểm tra đối soát chéo (Cross-table Validation):

-- Đối soát dữ liệu cập nhật giữa bảng RP_SALE_GROUPS và bảng nguồn Staff_daily
SELECT 
    a.staff_code,
    a.staff_id AS actual_staff_id,
    b.staff_id AS expected_staff_id,
    a.st_channel_type_id AS actual_channel_type,
    b.channel_type_id AS expected_channel_type
FROM 
    RP_SALE_GROUPS a
INNER JOIN 
    Staff_daily b ON a.staff_code = b.staff_code
WHERE 
    a.staff_id <> b.staff_id 
    OR a.st_channel_type_id <> b.channel_type_id
    OR (a.staff_id IS NULL AND b.staff_id IS NOT NULL);

Kết quả kỳ vọng: Truy vấn trả về 0 dòng (No rows selected), chứng minh 100% bản ghi đã được cập nhật chính xác theo bảng nguồn.

Kịch bản 4: Kiểm thử luồng Trans Update Shop (Trans_update_shop)

Tiến trình Trans_update_shop cập nhật các trường shop_id, s_channel_type_id và IS_SHOP_1400 dựa trên bảng shop_daily:

-- Kiểm tra cập nhật thông tin cửa hàng và cờ IS_SHOP_1400
SELECT 
    r.shop_code,
    r.shop_id AS r_shop_id,
    s.shop_id AS s_shop_id,
    r.s_channel_type_id AS r_channel_type,
    s.channel_type_id AS s_channel_type,
    r.IS_SHOP_1400 AS r_is_shop,
    s.IS_SHOP_1400 AS s_is_shop
FROM 
    RP_SALE_GROUPS r
LEFT JOIN 
    shop_daily s ON r.shop_code = s.shop_code
WHERE 
    r.shop_id <> s.shop_id 
    OR r.s_channel_type_id <> s.channel_type_id
    OR r.IS_SHOP_1400 <> s.IS_SHOP_1400
    OR (s.shop_id IS NULL AND r.shop_id IS NOT NULL);

Kết quả kiểm thử và số liệu xác thực (Validation Metrics)

Trong quá trình thực nghiệm tại đề tài, tổng cộng 128 testcases kiểm thử Database đã được thiết kế và thực thi, bao gồm:

  • Testcase thêm mới trường: 15 testcases (Đạt tỷ lệ Pass 100%).
  • Testcase luồng Import: 45 testcases (Bao gồm dữ liệu chuẩn, dữ liệu biên, dữ liệu rỗng, ký tự đặc biệt).
  • Testcase luồng Update: 68 testcases (Bao gồm đối soát cập nhật đơn lẻ, cập nhật hàng loạt, các mã không tồn tại trong bảng danh mục).
+-----------------------------------------------------------------------------------+
|                        TỔNG HỢP KẾT QUẢ THỰC THI KIỂM THỬ                         |
+-----------------------------------------------------------------------------------+
| Hạng mục kiểm thử             | Tổng Testcases | Passed | Failed (Bugs) | Tỷ lệ   |
+-------------------------------+----------------+--------+---------------+---------+
| Cấu trúc bảng (Schema)        | 15             | 15     | 0             | 100%    |
| Luồng dữ liệu Import          | 45             | 41     | 4             | 91.1%   |
| Luồng Trans Update Staff/Shop | 68             | 61     | 7             | 89.7%   |
| TỔNG CỘNG                     | 128            | 117    | 11            | 91.4%   |
+-----------------------------------------------------------------------------------+

Phân tích lỗi (Defects Analysis) phát hiện qua DBeaver

  1. Lỗi không đồng nhất kiểu dữ liệu (Data Type Mismatch): Cột st_channel_type_id trong tiến trình Import nhận giá trị String từ file CSV gây ra lỗi ORA-01722: invalid number khi ghi vào cột kiểu NUMBER.
  2. Lỗi lệch logic ánh xạ (Mapping Logic Error): Tiến trình Trans_update_shop ánh xạ nhầm cột channel_type_id của nhân viên vào cột s_channel_type_id của điểm bán trong một số điều kiện rẽ nhánh.
  3. Lỗi không xử lý giá trị NULL (Unchecked Null Values): Khi bảng shop_daily chưa có bản ghi mới trong ngày, câu lệnh UPDATE làm trắng trường IS_SHOP_1400 thay vì giữ nguyên giá trị mặc định là 0.

Tất cả 11 lỗi trên đã được ghi nhận, chuyển sang đội ngũ lập trình (Dev) khắc phục và được kiểm thử lại (Re-test/Regression Test) đạt kết quả 100% Pass trước khi chuyển giao hệ thống.

Đổi mới và đóng góp

  1. Chuẩn hóa quy trình kiểm thử Database bằng DBeaver: Đề tài đã xây dựng một bộ tài liệu hướng dẫn và quy trình chuẩn, giúp kiểm thử viên không chỉ phụ thuộc vào các công cụ nặng như Oracle SQL Developer mà có thể sử dụng DBeaver nhẹ nhàng, linh hoạt, hỗ trợ kết nối đa cơ sở dữ liệu.
  2. Xây dựng thư viện truy vấn đối soát dữ liệu tự động (Automated Reconciliation Scripts): Thay vì kiểm tra bằng mắt từng dòng (manual eyeball testing), đề tài đưa ra các mẫu câu lệnh FULL OUTER JOIN, MINUS, EXCEPT và các hàm tổng hợp (COUNT, SUM, GROUP BY) để phát hiện sai lệch dữ liệu tự động với độ chính xác tuyệt đối.
  3. Nâng cao hiệu suất phát hiện lỗi sớm: Việc áp dụng kiểm thử Database trực tiếp tại tầng lưu trữ giúp phát hiện lỗi sai dữ liệu ngay tại thời điểm job xử lý chạy xong, giảm 55% thời gian gỡ lỗi (debugging time) so với việc chờ hiển thị lên báo cáo giao diện.

Ứng dụng thực tế và triển khai

Kịch bản ứng dụng trong doanh nghiệp

Phương pháp kiểm thử trong đề tài có khả năng ứng dụng rộng rãi trong các dự án thực tế:

  • Hệ thống tính cước và hoa hồng viễn thông (Telecom Billing & Commission): Nơi dữ liệu phát sinh hàng chục triệu bản ghi cước mỗi ngày, yêu cầu đối soát số tiền chi trả cho đại lý với sai số bằng 0.
  • Hệ thống Ngân hàng và Cổng thanh toán (Core Banking & Fintech): Kiểm tra tính toàn vẹn của các giao dịch tiền tệ, đảm bảo các giao dịch nạp/rút/chuyển khoản tuân thủ nghiêm ngặt chuẩn ACID.
  • Hệ thống Kho dữ liệu và Báo cáo thông minh (Data Warehouse & BI): Kiểm tra các đường ống dữ liệu (ETL Data Pipelines) từ nguồn OLTP sang đích OLAP.
+-------------------------------------------------------------+
|               DOANH NGHIỆP / HỆ THỐNG THỰC TẾ               |
+-------------------------------------------------------------+
       |                                     |
       v                                     v
+-----------------------------+   +-----------------------------+
| Viễn thông / Bán hàng (PBH) |   | Ngân hàng / Tài chính (Core)|
| - Đối soát hoa hồng đại lý  |   | - Xác thực giao dịch ACID   |
| - Luồng Batch Update Staff  |   | - Kiểm thử ETL Data Mart    |
+-----------------------------+   +-----------------------------+

Yêu cầu triển khai hệ thống (Deployment Requirements)

  • Hệ điều hành: Microsoft Windows 10/11 (64-bit) hoặc Ubuntu Linux 20.04/22.04 LTS.
  • Phần mềm: DBeaver Community Edition phiên bản 21.0 trở lên.
  • Môi trường Java: OpenJDK 11 hoặc Oracle JDK 11 trở lên.
  • Mạng và Bảo mật: Kết nối VPN nội bộ, cấu hình mở cổng TCP 1521 tới Database Server Oracle; cấp quyền SELECT, INSERT, UPDATE có kiểm soát trên schema HOAHONG_TEST.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Các câu truy vấn kiểm thử hiện tại vẫn được kích hoạt thủ công (Manual Query Execution) trong trình biên tập SQL của DBeaver.
  • Chưa tích hợp cơ chế tự động sinh báo cáo kiểm thử dạng HTML/Allure Report tự động sau mỗi lần thực thi script.
  • Kiểm thử hiệu năng truy vấn mới dừng lại ở mức đo thời gian thực thi (Execution Time) và xem Kế hoạch thực thi (Explain Plan) cơ bản, chưa giả lập tải đồng thời hàng nghìn users.

Hướng phát triển trong tương lai

  • Tự động hóa hoàn toàn với CI/CD Pipeline: Tích hợp các bộ script kiểm thử SQL vào quy trình tích hợp liên tục (Jenkins / GitLab CI) sử dụng các framework như DbUnit, pytest-bdd hoặc thư viện Python cx_Oracle.
  • Áp dụng kiểm thử dữ liệu lớn (Big Data Testing): Mở rộng kỹ thuật kiểm thử sang các hệ thống dữ liệu phi quan hệ (NoSQL) và nền tảng phân tán như Apache Spark, Hadoop, ClickHouse.
  • Ứng dụng AI trong sinh dữ liệu kiểm thử: Sử dụng các mô hình học máy để tự động tạo dữ liệu mẫu (Synthetic Test Data) đa dạng, có tính bao phủ biên cao nhằm phát hiện các lỗi ẩn tinh vi.

Đối tượng hưởng lợi

+-----------------------------------------------------------------------+
|                         ĐỐI TƯỢNG HƯỞNG LỢI                           |
+-----------------------------------------------------------------------+
|  Sinh viên / Nghiên cứu sinh : Học liệu chuẩn hóa về Database Testing |
|  Kiểm thử viên (QA/QC)       : Nâng cao kỹ năng từ GUI sang Database  |
|  Doanh nghiệp phần mềm       : Nâng cao chất lượng sản phẩm dữ liệu   |
|  Chuyên viên dữ liệu (DE/DBA): Tối ưu hóa kiểm soát tính toàn vẹn ETL |
+-----------------------------------------------------------------------+
  • Sinh viên ngành CNTT / Mạng máy tính: Cung cấp tài liệu tham khảo thực chiến có tính ứng dụng cao về quy trình kiểm thử phần mềm, cấu trúc câu lệnh SQL nâng cao và cách làm việc với CSDL Oracle.
  • Kiểm thử viên (QA/QC Engineers): Nâng cao năng lực chuyên môn từ Manual UI Tester lên Database Tester / Data QA, nắm vững phương pháp viết script đối soát dữ liệu và phân tích mã lỗi backend.
  • Doanh nghiệp phát triển phần mềm: Áp dụng bộ quy trình kiểm thử để giảm thiểu lỗi nghiệp vụ trước khi bàn giao cho khách hàng (UAT), tiết kiệm từ 30-40% chi phí bảo trì sau phát hành.
  • Kỹ sư dữ liệu (Data Engineers / DBA): Có thêm công cụ và phương pháp kiểm thử tính chính xác của các đường ống chuyển đổi dữ liệu (ETL Pipelines).

Câu hỏi thường gặp

1. Yêu cầu kỹ thuật phần cứng và phần mềm để triển khai DBeaver cho kiểm thử Oracle Database là gì?

Để triển khai hiệu quả, máy trạm kiểm thử cần tối thiểu: CPU Dual-Core 2.0 GHz trở lên, RAM tối thiểu 4GB (khuyến nghị 8GB), ổ cứng trống 1GB. Về phần mềm, cần cài đặt Java Runtime (JRE 11+) và bản cài đặt DBeaver Community. Cần có file driver ojdbc8.jar phù hợp với phiên bản Oracle Database của máy chủ.

2. Sự khác biệt cốt lõi giữa kiểm thử giao diện (GUI Testing) và kiểm thử Database là gì?

Kiểm thử GUI kiểm tra các phần tử hiển thị (form, nút bấm, bảng hiển thị, thông báo lỗi người dùng) nhằm bảo đảm trải nghiệm người dùng (UX). Kiểm thử Database kiểm tra các thành phần vô hình đối với người dùng cuối như giản đồ (schema), bảng, cột, khóa ngoại, thủ tục lưu trữ (stored procedures), trigger và tính toán vẹn ACID của dữ liệu dưới tầng lưu trữ.

3. DBeaver có thể thay thế hoàn toàn Oracle SQL Developer trong kiểm thử không?

Đối với hầu hết các tác vụ kiểm thử dữ liệu (truy vấn, đối soát, kiểm tra cấu trúc, import/export dữ liệu mẫu, xem execution plan), DBeaver hoàn toàn có thể thay thế và thậm chí vượt trội hơn nhờ tốc độ phản hồi nhanh, tiêu tốn ít RAM và khả năng kết nối đa dạng nhiều loại CSDL. Tuy nhiên, đối với các tác vụ chuyên sâu của Quản trị viên CSDL (DBA) như tinh chỉnh nâng cao SGA/PGA, quản lý Redo Logs chuyên biệt của Oracle, SQL Developer vẫn có một số tính năng tích hợp sâu hơn.

4. Làm thế nào để kiểm thử các tác vụ Update lớn (Bulk Update) mà không làm ảnh hưởng đến môi trường Test chung?

Quy trình chuẩn bao gồm: (1) Sử dụng các lệnh kiểm soát giao dịch như SET TRANSACTION READ ONLY hoặc thực hiện trong một Transaction độc lập và sử dụng ROLLBACK sau khi kiểm tra xong; (2) Tạo bảng tạm (Temporary Table / Backup Table) bằng câu lệnh CREATE TABLE RP_SALE_GROUPS_BAK AS SELECT * FROM RP_SALE_GROUPS; trước khi chạy thử nghiệm; (3) Sử dụng schema kiểm thử riêng biệt (HOAHONG_TEST) cô lập với môi trường UAT/Staging.

5. Chi phí triển khai và hiệu quả đầu tư (ROI) của giải pháp này như thế nào?

Giải pháp sử dụng công cụ DBeaver Community Edition (mã nguồn mở, 100% miễn phí) giúp doanh nghiệp tiết kiệm hàng nghìn USD chi phí mua bản quyền phần mềm kiểm thử mỗi năm. Hiệu quả đầu tư (ROI) thể hiện rõ qua việc rút ngắn 40% thời gian thực thi kiểm thử dữ liệu và triệt tiêu các lỗi sai lệch báo cáo tài chính/hoa hồng ngay từ giai đoạn phát triển.

Kết luận

Đồ án tốt nghiệp "Kiểm thử database trên cơ sở dữ liệu Oracle bằng công cụ DBeaver" do sinh viên Trần Thị Khánh thực hiện đã giải quyết trọn vẹn và chuyên sâu bài toán kiểm thử tính toàn vẹn dữ liệu trong các hệ thống doanh nghiệp phức tạp. Bằng việc kết hợp chặt chẽ giữa nền tảng lý thuyết kiểm thử tiêu chuẩn quốc tế (ANSI/IEEE) và công cụ mã nguồn mở mạnh mẽ DBeaver, đề tài đã xây dựng thành công bộ kịch bản kiểm thử toàn diện cho hệ thống Phân phối Bán hàng (PBH).

Kết quả nghiên cứu và thực nghiệm cho thấy việc chuyển dịch trọng tâm kiểm thử từ tầng giao diện xuống tầng cơ sở dữ liệu là xu thế tất yếu, giúp nâng cao độ tin cậy của phần mềm, bảo vệ tính toàn vẹn của dữ liệu kinh doanh và tối ưu hóa chi phí vận hành cho doanh nghiệp. Bộ tài liệu và quy trình trong đồ án là nguồn học liệu và tài liệu kỹ thuật giá trị cho cộng đồng kiểm thử viên, lập trình viên và sinh viên chuyên ngành Công nghệ Thông tin.