Kiểm thử hay còn gọi là testing, là quá trình đánh giá một hệ thống hay các thành phần của nó với mục đích tìm xem liệu hệ thống có đáp ứng các yêu cầu được đã được chỉ định hay không. Nói một cách đơn giản, kiểm thử được thực hiện trên một hệ thống để xác định bất kỳ lỗ hổng, các lỗi hoặc các yêu cầu đang bị thiếu hay trái ngược với các yêu cầu thực tế đã được đề ra.
TỔNG QUAN VỀ KIỂM THỬ
Change-related Testing (Kiểm thử thay đổi)
Kiểm thử thay đổi có mục đích kiểm tra khả năng vận hành của phần mềm sau khi thực hiện sửa lỗi Loại kiểm thử này bao gồm hai hình thức chính.
Kiểm thử xác nhận (Confirmation Testing) diễn ra sau khi lỗi trong phần mềm đã được xác nhận và sửa chữa Mục tiêu của kiểm thử này là xác minh xem lỗi đã được khắc phục hoàn toàn hay chưa Các tester thực hiện kiểm thử bằng cách cung cấp đầu vào giống như ban đầu và kiểm tra xem đầu ra có đạt yêu cầu mong muốn hay không.
Kiểm thử hồi quy (Regression testing) là quá trình xác nhận rằng các thay đổi trong phần mềm hoặc môi trường không gây ra tác động tiêu cực và hệ thống vẫn đáp ứng các yêu cầu đã đề ra Hình thức kiểm thử này được thực hiện khi có sự thay đổi trong phần mềm, bao gồm sửa lỗi hoặc thêm chức năng mới Ngoài ra, việc thực hiện kiểm thử hồi quy cũng cần được xem xét khi có sự thay đổi trong môi trường xung quanh phần mềm.
KIỂM THỬ DATABASE VÀ CÔNG CỤ DBEAVER
2.1 Giới thiệu về SQL, Database và Cơ sở dữ liệu Oracle
SQL, hay còn gọi là Ngôn ngữ Truy vấn Có cấu trúc, là một ngôn ngữ chuyên dụng dùng để tương tác với cơ sở dữ liệu Nó cho phép người dùng lưu trữ, thao tác và truy xuất dữ liệu trong các cơ sở dữ liệu quan hệ một cách hiệu quả.
SQL là tiêu chuẩn ANSI (Viện tiêu chuẩn quốc gia Hoa Kỳ) cho việc truy xuất dữ liệu từ các hệ thống cơ sở dữ liệu Các câu lệnh SQL được áp dụng để lấy và cập nhật thông tin trong cơ sở dữ liệu.
SQL hoạt động với hầu hết các chương trình CSDL như Oracle, MySQL,…
Cơ sở dữ liệu (CSDL) là tập hợp các dữ liệu có mối quan hệ logic, được tổ chức một cách có cấu trúc và lưu trữ trên máy tính CSDL được thiết kế và xây dựng với mục đích cụ thể, nhằm phục vụ cho việc lưu trữ và truy xuất dữ liệu cho các ứng dụng hoặc người dùng.
Bảng CSDL là thành phần chính của một cơ sở dữ liệu, bao gồm một hoặc nhiều bảng được xác định bằng tên riêng Mỗi bảng chứa các mẩu tin, hay còn gọi là dòng, đại diện cho dữ liệu trong bảng đó.
2.1.3 Cơ sở dữ liệu Oracle
Oracle là một trong những nhà cung cấp hàng đầu trong lĩnh vực công nghệ hiện nay, nổi bật với sản phẩm chủ lực là hệ thống quản lý cơ sở dữ liệu quan hệ (RDBMS) mang tên Oracle Database Phần mềm này đóng vai trò quan trọng trong hạ tầng IT của doanh nghiệp, hỗ trợ nhiều nhiệm vụ như xử lý giao dịch, phân tích kinh doanh (BI) và các ứng dụng phân tích dữ liệu.
Kiến trúc cơ sở dữ liệu của Oracle
Oracle được kiến trúc theo mô hình 3 lớp:
+ Lớp dữ liệu (File Systems)
+ Lớp xử lý bên dưới (Backgruond Processes)
Oracle Database sử dụng cấu trúc bảng theo hàng và cột, giúp kết nối các phần tử dữ liệu từ nhiều bảng khác nhau Điều này mang lại sự liên quan giữa các bảng và giúp người dùng dễ dàng quản lý và xử lý dữ liệu mà không cần phải lưu trữ thông qua nhiều bảng.
2.2 Khái quát về kiểm thử Database
Cơ sở dữ liệu đóng vai trò quan trọng trong hầu hết các ứng dụng phần mềm hiện nay, đặc biệt là trong các lĩnh vực chuyên ngành như giáo dục và y tế Điều này yêu cầu các nhà phát triển phần mềm phải chú trọng đến việc thiết kế và kiểm thử cấu trúc cơ sở dữ liệu một cách nghiêm túc và đảm bảo chất lượng.
Kiểm tra cơ sở dữ liệu là một hình thức kiểm thử phần mềm, tập trung vào việc xác minh tính chính xác của các bảng và lược đồ quan hệ trong cơ sở dữ liệu.
Nó kiểm tra tính toàn vẹn và nhất quán của dữ liệu, đồng thời đánh giá hoạt động của Cơ sở dữ liệu trước các luồng dữ liệu đầu vào thông thường và bất thường.
2.2.2 Tầm quan trọng của kiểm thử Database
Tính toàn vẹn của dữ liệu liên quan đến các hoạt động CRUD (Tạo, Truy xuất, Cập nhật và Xóa) nhằm quản lý và hiển thị thông tin trên màn hình hoặc biểu mẫu Việc cập nhật dữ liệu trong cơ sở dữ liệu giúp xác minh rằng thông tin trên giao diện người dùng được cập nhật chính xác Quá trình kiểm tra này cho phép xác nhận tính nhất quán của dữ liệu ở nhiều vị trí khác nhau.
Trong giai đoạn phát triển của một ứng dụng, các hành động CRUD (Tạo, Đọc, Cập nhật, Xóa) của người dùng cuối sẽ được giả định và kiểm thử thông qua các công cụ của cơ sở dữ liệu.
+ Create: Khi người dùng thực hiện “Lưu” bất kì một giao dịch mới nào
+ Read/Retrieve: Khi người dùng thực hiện các hành động “Tìm kiếm” hoặc
“Xem” bất kì giao dịch đã lưu nào
+ Update: Khi người dùng thực hiện “Chỉnh sửa” một dữ liệu nào đó đã tồn tại
+ Delete: Khi người dùng thực hiện hoạt động “Xóa” dữ liệu khỏi hệ thống
Bất kỳ hoạt động cơ sở dữ liệu nào được thực hiện bởi người dùng cuối luôn là một trong bốn thao tác trên.
Hãy xây dựng các trường hợp thử nghiệm cơ sở dữ liệu (DB) bằng cách kiểm tra tính nhất quán của dữ liệu ở tất cả các vị trí mà nó xuất hiện.
Dữ liệu liên tục di chuyển giữa giao diện người dùng (UI) và cơ sở dữ liệu, vì vậy cần kiểm tra tất cả các trường trong UI để đảm bảo chúng ánh xạ chính xác với bảng trong cơ sở dữ liệu Các thao tác CRUD từ UI phải đồng bộ với dữ liệu trong ứng dụng, vì vậy việc xác minh rằng các hành động dữ liệu được thực hiện có được ánh xạ đúng cách là rất quan trọng.
Hình 2.14 Ví dụ File mapping Import các trường
Sự tuân thủ quy tắc trong quản lý cơ sở dữ liệu phụ thuộc vào độ phức tạp của dự án Khi cơ sở dữ liệu trở nên phức tạp, các thành phần như trình kích hoạt, ràng buộc quan hệ và thủ tục lưu trữ cũng sẽ phức tạp theo Do đó, khi kiểm tra, cần chú ý đến một số yếu tố, đặc biệt là việc sử dụng Truy vấn SQL để đánh giá độ phức tạp của cơ sở dữ liệu.
2.2.2.4 Xác thực các thuộc tính ACID
Chủ yếu có 4 thuộc tính mà hiệu suất của CSDL phụ thuộc vào:
Tính bảo toàn (Atomicity) là khái niệm cho rằng một hoạt động phải thành công hoàn toàn hoặc thất bại hoàn toàn Điều này có nghĩa là khi một hành động liên quan đến nhiều xử lý, nếu bất kỳ phần nào của hành động không thành công, toàn bộ hành động sẽ được coi là thất bại Quy tắc này thường được gọi là "tất cả hoặc không có gì".
TRIỂN KHAI SỬ DỤNG CÔNG CỤ DBEAVER CHO KIỂM THỬ DATABASE TRÊN CƠ SỞ DỮ LIỆU ORACLE
THỬ DATABASE TRÊN CƠ SỞ DỮ LIỆU ORACLE
Chương cuối này sẽ là kết quả của quá trình thực hiện kiểm thử Database.
Do còn nhiều hạn chế đồ án này em sẽ thực hiện kiểm thử trên công cụ DBeaver với
2 nghiệp vụ chính là Import và Update dữ liệu vào bảng.
Quá trình kiểm thử bao gồm các bước từ thu thập dữ liệu và tìm hiểu hệ thống, đến việc viết testcase và thực hiện kiểm thử để đạt được kết quả mong muốn.
Hình 3.74 Quá trình kiểm thử
3.1 Lấy dữ liệu và tìm hiểu hệ thống
3.1.1 Thu thập dữ liệu và đọc yêu cầu nghiệp vụ
Những dữ liệu cần thiết trước khi thực hiện kiểm thử:
-File Tài liệu giải pháp:
+ Bảng mapping: Thông tin các trường Import và Update
Thông tin VBI và trường trong PBH: Luồng trả tháng N+1 và N+2 đối với đóng cước trước
Hiển thi tên bảng và tên trường cần Import và Update từ Trường VBI cung cấp đến Bảng phí bán hàng (RP_SALE_GROUPS)
Hình 3.75 File mapping+ Thông tin yêu cầu của nghiệp vụ:
Nghiệp vụ cũ: Chưa có luồng Import và thực hiện trả phí cho việc điều chỉnh luồng trả phí bán hàng nhóm FMC
Nghiệp vụ mới được triển khai nhằm xây dựng luồng Import để thực hiện việc điều chỉnh phí bán hàng FMC cho tháng N+1 và N+2 đối với cước đóng trước Các trường thông tin cần bổ sung vào bảng RP_SALE_GROUPS sẽ được cập nhật để đảm bảo quy trình hoạt động hiệu quả.
Hình 3.76 Các trường thêm mới
-File txt: Thông tin các bản ghi mình cần Import và Update
Hình 3.77 Thông tin các bản ghi
DEV sẽ cung cấp cho chúng ta hệ thống đã hoàn tất việc nhập và cập nhật dữ liệu thông qua công cụ ETL Hệ thống này sẽ được kết nối với cơ sở dữ liệu HOAHONG_TEST.
Khi kiểm tra hệ thống PBH, chúng ta chỉ cần chú ý đến các giao dịch import, cập nhật nhân viên và cập nhật cửa hàng Mở các giao dịch này cho phép chúng ta xác định các trường cần nhập, các trường cần cập nhật cho nhân viên và các trường cần cập nhật cho cửa hàng.
Khi xem file mapping, chúng ta có thể gặp khó khăn trong việc xác định trường nào cần được import Để giải quyết vấn đề này, cần truy cập vào hệ thống, mở giao diện trans Import và sau đó mở Table Output để có cái nhìn rõ hơn.
Trong Table sẽ hiện thông tin các trường cần Import để có thể viết Testcase.
Và hiện thông tin hệ thống kết nối đến DB HOAHONG_TEST
Hình 3.81 Luồng Trans Update staff và shop Luồng của Trans_update_staff và Trans_update_shop sẽ giống nhau như hình (3.8)
Cũng giống như Trans Import, để thực hiện Trans update staff và Trans update shop, chúng ta cần xác định thông tin cần cập nhật cho từng trường hợp, bao gồm các trường cần cập nhật ở staff và các trường cần cập nhật ở shop.
3.2 Tiến hành kiểm thử và kết quả
Thực hiện kiểm thử Database trên công cụ DBeaver, kết nối đến DB HOAHONG_TEST
Thông tin kết nối Dbeaver:
Hình 3.84 Kết nối DB HOAHONG_TEST
Hình 3.85 Giao diện sau khi kết nối xong
3.2.1 Kiểm thử các trường thêm mới vào bảng RP_SALE_GROUPS
Kịch bản kiểm thử thêm mới các trường dựa vào thông tin ở Tài liệu giải pháp đưa ra chúng ta sẽ có các testcase sau:
Hình 3.86 Testcase thêm mới trường
Hình 3.87 Kiểm tra các trường thêm mới
The test results indicate that the testing case aligns with the expected outcomes, as the fields for prepaid billing, config group code, config group name, telecom service ID, status n2, act status n2, and data type have been successfully added to the RP_SALE_GROUPS table The test results will display a "P" when the test case is correct.
3.2.2 Kiểm thử các trường Import vào bảng RP_SALE_GROUPS
The testing script for importing fields is based on the information from the mapping file, system data provided, and the record data in the TXT file This will lead to the creation of several test cases.
Thông tin giá trị các bản ghi khi lấy ra:
Hình 3.88 Giá trị các bản ghi Import
Hình 3.89 Testcase Import các trường
Kết quả từ các trường Import cho thấy rằng các giá trị bản ghi từ trường VBI đã được nhập thành công vào bảng RP_SALE_GROUPS, và các giá trị này hoàn toàn khớp với các bản ghi trong tệp txt Trong phần kiểm thử, kết quả sẽ hiển thị chữ P khi trường hợp kiểm thử đó chính xác.
3.2.3 Kiểm thử các trường Update vào bảng RP_SALE_GROUPS
Kịch bản kiểm thử Update các trường dựa vào TLGP có nói lấy giá trị từ PBH, Update từ staff_code hoặc shop_code
Update từ staff_code (Ở bảng Staff_daily)
Hình 3.91 Testcase Update st_channel_type_id
To retrieve the data, extract the Staff_code and RP_SALE_GROUP_ID from the RP_SALE_GROUP table to find the value of the channel_type_id field Next, compare the value of the channel_type_id field with the st_channel_type_id field When the values of both fields match, it indicates that the system has successfully updated the record with the correct value.
Hình 3.92 Giá trị bản ghi trường Staff_code
Hình 3.93 Giá trị bản ghi trường channel_type_id
Hình 3.94 Kết quả giá trị bản ghi st_channel_type_id
To retrieve the staff_id values, extract the Staff_code and RP_SALE_GROUP_ID from the RP_SALE_GROUP table Next, compare the staff_id from the staff_daily table with the staff_id from the RP_SALE_GROUP table If the values of both fields match, the system confirms that the update has been successfully executed with the correct record values.
Hình 3.95 Testcase Update staff_id
Hình 3.96.Giá trị trường bản ghi Staff_code
Hình 3.97 Giá trị bản ghi trường Staff_id (bảng Staff_daily)
Hình 3.98 Kết quả giá trị bản ghi trường Staff_id (RP_SALE_GROUP)
Update từ shop_code (Ở bảng Shop_daily)
Hình 3.99 Testcase Update s_channel_type_id
To retrieve the Shop_code and RP_SALE_GROUP_ID from the RP_SALE_GROUP table, we will identify the value of the channel_type_id field Subsequently, we will compare this value with the s_channel_type_id field If the values of both fields match, it indicates that the system has successfully updated the record with the correct value.
Hình 3.100 Giá trị trường bản ghi Shop_code
Hình 3.101 Giá trị bản ghi trường channel_type_id
Hình 3.102.Kết quả giá trị bản ghi trường s_channel_type_id
To retrieve the shop_id value, extract the Shop_code and RP_SALE_GROUP_ID from the RP_SALE_GROUP table Next, compare the shop_id from the Shop_daily table with the shop_id from the RP_SALE_GROUP table If the values of these two fields match, the system confirms that the update was successful and accurate.
Hình 3.103.Testcase Update shop_id
Hình 3.104 Giá trị trường bản ghi Shop_code
Hình 3.105 Giá trị bản ghi trường shop_id (bảng shop_daily)
Hình 3.106 Kết quả giá trị bản ghi trường shop_id (bảng RP_SALE_GROUP)
To retrieve the Shop_code and RP_SALE_GROUP_ID from the RP_SALE_GROUP table, we will identify the value of the IS_SHOP_1400 field based on the specified conditions Subsequently, we will compare the IS_SHOP_1400 value from the Shop_daily table with that from the RP_SALE_GROUP table If the values of these two fields match, it indicates that the system has successfully updated the record with the correct value.
Hình 3.107 Testcase Update IS_SHOP_1400
Hình 3.108 Giá trị trường bản ghi Shop_code
Hình 3.109 Giá trị bản ghi trường IS_SHOP_1400 (bảng shop_daily)
Giá trị bản ghi trường IS_SHOP_1400 trong bảng RP_SALE_GROUP đã được cập nhật theo yêu cầu của TLGP, với các bản ghi trong bảng RP_SALE_GROUPS khớp với giá trị trong bảng staff_daily và shop_daily Kết quả kiểm thử sẽ hiển thị P khi trường hợp kiểm thử được xác nhận đúng.
