ĐỒ ÁN KIỂM THỬ DATABASE TRÊN CƠ SỞ DỮ LIỆU ORACLE BẰNG CÔNG CỤ DBEAVER

BỘ GIÁO DỤC VÀ ĐÀO TẠO

TRƯỜNG ĐẠI HỌC MỎ ĐỊA CHẤT

TRẦN THỊ KHÁNH
 
 
 
 
 

ĐỒ ÁN TỐT NGHIỆP
NGÀNH CÔNG NGHỆ THÔNG TIN

ĐỀ TÀI

KIỂM THỬ DATABASE TRÊN CƠ SỞ DỮ LIỆU ORACLE BẰ
 
 
 
 
 

Hà Nội 2021


LỜI CẢM ƠN
Lời đầu tiên em xin chân thành cảm ơn các thầy cô, trong khoa Công nghệ
thông tin, trường Đại học Mỏ - Địa chất đã tạo điều kiện thuận lợi cho em trong quá
trình học tập cũng như trong thời gian thực hiện đồ án tốt nghiệp. Đặc biệt, em
muốn gửi lời cảm ơn tới ThS. Nguyễn Tuấn Anh – giảng viên trực tiếp hướng dẫn,

chỉ bảo, giúp em khắc phục những khó khăn, thiếu sót để có thể hoàn thành các
phần trong đề tài “Kiểm thử database trên cơ sở dữ liệu Oracle bằng công cụ
DBeaver” từ lý thuyết cho tới thực hành sử dụng công cụ.
Mặc dù đã có nhiều cố gắng để thực hiện đề tài một cách hồn chỉnh nhất,
nhưng do thời gian có hạn, năng lực và kinh nghiệm còn hạn chế nên đồ án khơng
thể tránh khỏi những thiếu sót. Kính mong nhận được sự đóng góp ý kiến từ phía

BỘ GIÁO DỤC VÀ ĐÀO TẠO
thầy cơ, bạn bè để em có thể nâng cao kiến thức
của bản thân,
thiện
đồ ĐỊA
án tốtCHẤT
TRƯỜNG
ĐẠIhoàn
HỌC
MỎ
hơn.
Em xin chân thành cảm ơn!!!!

TRẦN THỊ KHÁNH
 
 
 
 
 

ĐỒ ÁN TỐT NGHIỆP
CHUYÊN NGÀNH MẠNG MÁY TÍNH

ĐỀ TÀI

KIỂM THỬ DATABASE TRÊN CƠ SỞ DỮ LIỆU ORACLE BẰ
 
 
 
 
 


Tha

MỤC LỤC

Hà Nội 2021


DANH MỤC CÁC HÌNH VẼ


DANH MỤC CÁC BẢNG BIỂU


Báo cáo thực tập tốt nghiệp

THÔNG TIN KẾT QUẢ NGHIÊN CỨU
1. Thông tin chung
Tên đề tài: Kiểm thử database trên cơ sở dữ liệu Oracle bằng công cụ
DBeaver
Thời gian thực hiện: 2021

2. Mục tiêu
-

Tìm hiểu tổng quan về kiểm thử, kiểm thử database và các kỹ thuật kiểm thử phần

-

mềm
Nghiên cứu kiểm thử database trên cơ sở dữ liệu Oracle bằng cơng cụ DBeaver
Hiểu được ưu điểm, lợi ích của kiểm thử database
Thực hiện sử dụng công cụ DBeaver cho kiểm thử database
3. Nội dung chính
Nội dung chính gồm 3 chương:
-

Chương 1: Tổng quan về kiểm thử
Chương này trình bày khái niệm tổng quan về kiểm thử, quy trình kiểm thử

và các loại kiểm thử, cũng như các kỹ thuật kiểm thử
-

Chương 2: Kiểm thử database và công cụ DBeaver
Chương này trình bày khái niệm về kiểm thử database, các loại kiểm thử

database, nói qua về cơ sở dữ liệu Oracle, giới thiệu chung về công cụ DBeaver, cài
đặt và sử dụng công cụ DBeaver.
-

Chương 3: Triển khai sử dụng công cụ DBeaver cho kiểm thử database trên
cơ sở dữ liệu Oracle

Chương này báo cáo và đánh giá kết quả đạt được

4. Kết quả chính đạt được
- Nắm rõ được các khái niệm cơ bản về kiểm thử, kiểm thử database, cơ sở dữ liệu
Oracle
- Hiểu được khi nào thì sử dụng kiểm thử database
- Sử dụng được công cụ DBeaver vào kiểm thử database thực tế với nhiều dự án

6
6


Báo cáo thực tập tốt nghiệp

CHƯƠNG 1: TỔNG QUAN VỀ KIỂM THỬ
1.1 . Các khái niệm về kiểm thử và một số khái niệm liên quan
1.1.1 . Kiểm thử là gì?
Kiểm thử hay cịn gọi là testing, là q 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.
Theo tiêu chuẩn ANSI / IEEE 1059, kiểm thử có thể được định nghĩa là q
trình phân tích các thành phần của phần mềm để phát hiện sự khác biệt giữa những
điều kiện của phần mềm đang tồn tại thực tế và những điều kiện được yêu cầu (đó
là defects/ errors/ bugs) và từ đó có thể đánh giá được chất lượng của chất lượng
của phần mềm.
1.1.2 . Một số khái niêm liên quan
-

Bug (Lỗi): là một khiếm khuyết trong một thành phần hoặc hệ thống mà nó có thể
làm cho thành phần hoặc hệ thống này không thực hiện đúng chức năng u cầu của

-

nó, ví dụ như thơng báo sai hoặc định nghĩa dữ liệu không đúng.
Testcase (Kịch bản kiểm thử) có nghĩa là: test là kiểm tra, cases là các tình huống.
Tức là các tình huống, các trường hợp cần kiểm tra, kiểm tra các chức năng của
phần mềm hoạt động đúng hay sai. Được viết dựa trên tài liệu giải pháp hay còn gọi
là tài liệu SRS
+ Mô tả dữ liệu đầu vài định test cái gì
+ Hành động hay mơ tả các bước để test (Step)
+ Và một kết quả mong đợi để xác định một chức năng của ứng dụng phần

-

mềm hoạt động đúng hay không.
Re-test: Đồng nghĩa với confirmation testing (kiểm tra xác nhận), Là thực hiện test
để kiểm tra xem bug mình đã post có được fixed hay chưa (kiểm tra lại xem đã hết
bị lỗi mà mình đã gặp chưa). Nếu đã được sửa xong thì mình báo cáo Close bug.
Ngược lại, nếu vẫn cịn lỗi thì báo cáo re-open để DEV sửa lại.

7
7


Báo cáo thực tập tốt nghiệp

1.1.3 . Yêu cầu khách hàng
Hệ thống được phát triển dựa trên nhu cầu của khách hàng. Chính vì lẽ đó,

các chức năng của hệ thống được xây dựng dựa trên việc thu nhập, phân tích, khảo
sát nhu cầu khách hàng thơng qua những u cầu cụ thể. Đối với hệ thống, yêu cầu
thường được tổng hợp từ phí khách hàng, các tổ chức có mức độ chuyên môn
1.1.4 . Tài liệu Đặc tả yêu cầu (SRS document)
Tài liệu đặc tả yêu cầu là những u cầu chính thức về những gì cần phải
thực hiện của đội phát triển phần mềm. Tài liệu đặc tả yêu cầu nên bao gồm tất cả
các định nghĩa về yêu cầu của người sử dụng và đặc tả yêu cầu của hệ thống.
Các khái niệm về lỗi đã nói ở trên cũng chính là đề cập đến việc phần mềm
sau khi xây dựng hoạt động không đúng với bản đặc tả yêu cầu phần mềm. Tài liệu
đặc tả yêu cầu cũng cần cung cấp đầy đủ các thông tin về chi phí, rủi ro và lịch trình
cho q trình phát triển sản phẩm.
Đặc tả yêu cầu được viết ra phục vụ rất nhiều đối tượng từ người dùng hệ
thống, khách hàng đến các nhà phát triển và bảo trì phần mềm. Do đó, tài liệu đặc tả
nên được viết bằng ngôn ngữ tự nhiên, sử dụng biểu đồ, bảng biểu để đảm bảo tính
dễ hiểu, dễ sử dụng cho tất cả các đối tượng trên.

8
8


Báo cáo thực tập tốt nghiệp

1.2 . Quy trình kiểm thử

Hình 1.1. Quy trình kiểm thử
Lập kế hoạch test (Test Plan): Test Plan chính là tài liệu tổng quan về việc
kiểm thử 1 project: phạm vi kiểm thử, hướng tiếp cận, quy trình kiểm thử, tài
nguyên và nhân lực test cần có, các chức năng, module cần được test, các cơng cụ
và mơi trường test cần có. Bao gồm cả kế hoạch ai test chức năng nào, khi nào bắt
đầu thực hiện viết và hoàn thành testcase; khi nào bắt đầu thực hiện test và khi nào

hoàn thành test. Dựa vào kế hoạc chung của dự án để lên kế hoạch cho bên kiểm
thử. Trong trường hợp khi làm thực tế thấy có khả năng khơng đúng như kế hoạch
đã lên thì phải báo lại cho Test Lead hoặc người Quản trị dự án sớm.
Thực hiện viết Testcase: Test case mô tả một dữ liệu đầu vào (input), hành
động (action) và một kết quả mong đợi (expected response), để xác định một chức
năng của ứng dụng phần mềm hoạt động đúng hay khơng.
Biểu mẫu Testcase gồm có 4 nội dung chính:
- Mục đích kiểm thử
9
9


Báo cáo thực tập tốt nghiệp

- Các bước thực hiện
- Kết quả mong muốn (Hệ thống phải chạy đúng như kết quả mong muốn)
- Kết quả thực thế (điền Pass/Fail)
Thực hiện Test (Testing Execution): Thực hiện test trực tiếp trên hệ thống
sau khi lập trình viên bàn giao. Dựa trên các test cases đã được viết trước đó để thực
hiện test trên hệ thống. Thực hiện ghi nhận kết quả kiểm thử vào cột kết quả của tài
liệu kịch bản kiểm thử. Nếu kết quả kiểm thử là thất bại thì nhóm kiểm thử ghi nhận
lỗi lên hệ thống quản lý lỗi. Nhóm kiểm thử, QTDA, nhóm lập trình, nhóm giải
pháp tham gia vào quá trình quản lý/xử lý lỗi (bug/ defect)
Lập báo cáo Kiểm thử (Test Report): Test Report có thể hiểu đơn giản là
một bản tóm tắt, trong đó chứa mục tiêu kiểm thử, hoạt động kiểm thử và kết quả.
Mục đích của test report là giúp những bộ phận liên quan như bộ phận dev, test,
phân tích, v.v… đánh giá được chất lượng sản phẩm và liệu sản phẩm hay giải pháp
đó đã có thể đưa vào vận hành được chưa. Tuy nhiên, test report không chỉ dùng để
đánh giá chất lượng, mà còn được sử dụng để những nhà phát triển hiểu rõ hơn về
quy trình của bài test.

Test Report thường chứa các nội dung như:
-Số lương test cases đã viết/ số lượng testcase đã test
-Số lượng test cases passed/failed
-Số lượng defects tìm ra và status, severity của defects
-Số lượng defects trên từng module
-Các vấn đề liên quan đến testing, bản build, tiến độ sửa lỗi…
1.3 . Các kỹ thuật kiểm thử
1.3.1 . Phương pháp kiểm thử hộp trắng (White Box Testing)
Kiểm thử hộp trắng là phương pháp kiểm thử dựa vào cả giải thuật, cấu trúc
code bên trong phần mềm. Là phương pháp kiểm thử mà các chuyên gia tester tập
trung vào các dữ liệu đầu vào và ra, truy cập thẳng vào bên trong source code.

10
10


Báo cáo thực tập tốt nghiệp

Hình 1.2. White Box Testing
Các loại white box testing:
-

API testing (application programming interface) – Kiểm thử ứng dụng bằng

-

cách sử dụng các hàm API public và private.
Code coverage – Là việc tạo các trường hợp test để thỏa mãn một số điều
kiện bao phủ code – code coverage (ví dụ như, người thiết kế test có thể tạo
ra các trường hợp test sao cho tất cả các câu lệnh của chương trình đều được

-

thực thi ít nhất 1 lần).
Fault injection methods – cải tiến bao phủ một trường hợp bằng cách đưa

-

một số lỗi vào để test các đường dẫn code.
Mutation testing methods.
Static testing – White box testing bao gồm tất cả các phương pháp kiểm thử
tĩnh (ví dụ review code).
Với phương pháp kiểm thử này, kiểm thử viên không cần hiểu biết về mã

lệnh để xử lý chức năng đó thế nào. Các kiểm thử viên sẽ căn cứ vào tài liệu đặc tả,
bản prototype của phần mềm cũng như dựa trên các testcase đã viết để kiểm tra
chức năng. Cả hai hình thức trên đề trả về một cách đo độ bao phủ code, sự đo
lường được tính bằng phần trăm %.
Ưu điểm:
Dễ dàng tự động hóa
11
11


Báo cáo thực tập tốt nghiệp

Cung cấp các quy tắc dựa trên kỹ thuật rõ ràng cho thời điểm ngừng thử
nghiệm.
Buộc các chuyên gia thử nghiệm phải suy luận cẩn thận về việc test lỗi vì
vậy lỗi sẽ được triệt để.

Nhược điểm:
Khá tốn thời gian và công sức.
Vẫn sẽ tồn tại lỗi.
Để kiểm tra được bằng phương pháp này cần có kinh nghiệm và trình độ
chun sâu về kiểm thử.
1.3.2 . Phương pháp kiểm thử hộp đen (Black Box Testing)
Kiểm thử hộp đen là phương pháp test dựa trên đầu vào và đầu ra của
chương trình để test mà khơng quan tâm tới code bên trong. Chỉ test chức năng và
giao diện dựa trên nghiệp vụ của hệ thống mà khơng cần quan tâm đến code bên
trong

Hình 1.3. Black Box Testing
Ưu điểm:
Rất phù hợp và hiệu quả khi mà số lượng các dòng lệnh của hệ thống là lớn.

12
12


Báo cáo thực tập tốt nghiệp

Không cần truy cập vào các dòng lệnh. - Phân biệt được rõ ràng quan điểm
của người dùng với quan điểm của nhà phát triển.
Không cần địi hỏi những kiến thức về ngơn ngữ lập trình ở các kiểm thử
viên để có thể kiểm thử hệ thống.
Nhược điểm:
Bị giới hạn ở độ bao phủ của các trường hợp kiểm thử.
Sẽ không hiệu quả bởi thực tế các kiểm thử viên bị giới hạn kiến thức về hệ
thống.
Độ bao phủ sẽ bị thiếu vì kiểm thử viên không kiểm tra được các đoạn lệnh

của hệ thống hoặc tập trung vào các dòng lệnh dễ xảy ra lỗi.
Sẽ khó để có thể thiết kế đầy đủ các trường hợp kiểm thử.
1.3.3 . Phương pháp kiểm thử hộp xám (Gray Box Testing)
Kiểm thử hộp xám là một phương pháp kiểm thử phần mềm được kết hợp
giữa Phương pháp kiểm thử Black Box (Hộp đen) và White Box (Hộp trắng). Trong
kiểm thử hộp xám, cấu trúc bên trong sản phẩm chỉ được biết một phần, tester có
thể truy cập vào cấu trúc dữ liệu bên trong và thuật toán của chương trình với mục
đích là để thiết kế testcase, nhưng khi test thì test như là người dùng cuối hoặc là ở
mức hộp đen.

13
13


Báo cáo thực tập tốt nghiệp

Hình 1.4. Gray Box Testing
Ưu điểm:
Là sự kết hợp của kiểm thử hộp đen và hộp trắng nên sẽ tối ưu hơn.
Kiểm tra bằng phương pháp hộp màu xám có thể thiết kế kịch bản thử
nghiệm phức tạp một cách thơng minh hơn.
Nhược điểm:
Rất khó để liên kết lỗi khi thực hiện kiểm tra hộp xám cho một ứng dụng có
hệ thống phân tán.
1.4 . Phương pháp kiểm thử hộp đen
Đây là 4 phương pháp phổ biến nhất trong kỹ thuật kiểm thử hộp đen
1.4.1 . Phân vùng tương đương (Equivalence partitioning)
Phân vùng tương đương (Equivalence partitioning) là một loại kiểm thử
Black Box mà ta có thể áp djng vào tất cả các cấp độ kiểm thử: như kiểm thử đơn vị
(Unit Testing), kiểm thử tích hợp (Integration Testing), kiểm thử hệ thống (System

Testing) …
Trong kỹ thuật này, các đơn vị dữ liệu đầu vào được chia thành các phân
vùng tương đương. Tất cả các giá trị trong một vùng tương đương sẽ cho ra kết quả
14
14


Báo cáo thực tập tốt nghiệp

đầu ra giống nhau. Có thể chọn ra một giá trị đại diện trong một vùng tương đương
để tiến hành kiểm thử.

Hình 1.5. Phân vùng tương đương
Mục đích: Giảm đáng kể số lượng test case cần phải thiết kế vì với mỗi lớp
tương đương ta chỉ cần test trên các phần tử đại diện.
Việc thiết kế ca kiểm thử bằng kỹ thuật phân lớp tương đương dựa trên
nguyên tắc xác định số vùng tương đương hợp lệ và số vùng tương đương không
hợp lệ
Thiết kế Test case bằng phân lớp tương đương tiến hành theo 2 bước:
-Xác định lớp tương đương
- Xác định các ca kiểm thử
Ví dụ: Xác định phân vùng tương đương và test case thích hợp theo yêu cầu dưới
đây:
ZIP CODE: 5 chữ số
Phân vùng tương đương ZIP CODE:
-

Ký tự số:
+ Không nhập ký tự nào
+ Nhập < 5 ký tự

+ Nhập 5 ký tự
+ Nhập > 5 ký tự
15
15


Báo cáo thực tập tốt nghiệp

-

Ký tự chữ:
Ký tự đặc biệt
Điều kiện đầu vào yêu cầu một giá trị xác định, phân hoạch thành một lớp

tương đương hợp lệ và 2 lớp tương đương không hợp lệ. Chẳng hạn đầu vào x = 5
(x là ZIP CODE), thì lớp hợp lệ là x = 5, các lớp không hợp lệ là
x > 5 và x < 5.
Phát triển thành testcases:
+ Nhập ZIP CODE = số => Hợp lệ
+ Nhập ZIP CODE = chữ => Không hợp lệ
+ Nhập ZIP CODE = ký tự đặc biệt => Không hợp lệ
+ Nhập ZIP CODE = 5 ký tự số => Hợp lệ
+ Nhập ZIP CODE > 5 ký tự số => Hợp lệ
+ Nhập ZIP CODE < 5 ký tự số => Hợp lệ
Như vậy với kỹ thuật trên, kiểm thử viên đã rút ngắn được số ca kiểm thử
cần sinh ra so với việc phải kiểm thử toàn bộ các giá trị đầu vào.
1.4.2 . Phân tích giá trị biên (Boundary value analysis)
Đây là phương pháp test mà chúng ta sẽ test tất cả các giá trị ở vùng biên ở
dữ liệu đầu vào và dữ liệu đầu ra. Chúng ta sẽ tập chung vào các giá trị biên chứ
không test tồn bơ dữ liệu. Thay vì chọn nhiều giá trị trong lớp tương đương để làm

đại diện, phân tích giá trị biên yêu cầu chọn một hoặc vài giá trị biên yêu cầu chọn
một hoặc vài giá trị các cạnh của lớp tương đương để làm điều kiện test.

16
16


Báo cáo thực tập tốt nghiệp

Hình 1.6. Phân tích giá trị biên
Test các giá trị biên chúng ta chỉ test các phần sau: Thay vì test tồn bộ vùng
cần test ta có thế test 6 hoặc 4 case và vẫn đảm bảo là hệ thống hoạt động tốt.
Boundary conditions là các vị trí ở giữa, trên và dưới các biên của lớp tương đương.
Phân tích giá trị biên là trường hợp đặc biệt của phân vùng tương đương, dựa
trên những phân vùng tương đương kiểm thử viên sẽ xác định giá trị biên giữa
những phân vùng này và lựa chọn ca kiểm thử phù hợp. Mục tiêu là lựa chọn các ca
kiểm thử để thực thi giá trị biên.
Phân tích giá trị biên sẽ chọn các giá trị:
-

Giá trị nhỏ nhất
Giá trị ngay dưới giá trị nhỏ nhất
Giá trị bình thường
Giá trị ngay trên giá trị lớn nhất
Giá trị lớn nhất

Ví dụ: Điểm từ [0, 10], ta có giá trị biên là:
+ Giá trị nhỏ nhất: 0
+ Giá trị ngay dưới giá trị nhỏ nhất: -1
+ Giá trị năm trong 0 và 10: 5

+ Giá trị ngay trên giá trị lớn nhất: 11
+ Giá trị lớn nhất: 10
Phát triển thành các testcase:
+ Nhập điểm = 0 => Hợp lệ
+ Nhập điểm = 10 => Hợp lệ

17
17


Báo cáo thực tập tốt nghiệp

+ Nhập điểm = 11 => Không hợp lệ
+ Nhập điểm = -1 => Không hợp lệ
Đây là phương pháp test mà chúng ta sẽ test tất cả các giá trị ở vùng biên của
dữ liệu vào và dữ liệu ra. Chúng ta sẽ tập trung vào các giá trị biên chứ khơng test
tồn bộ dữ liệu.

Hình 1.7. Boundary Value Analysis
1.4.3 . Bảng quyết định (Decision Tables)
Trong các kỹ thuật kịch bản kiểm thử, đối với các trường dữ liệu dơn như
textbox, như chúng ta thường sử dụng các phương pháp như lớp tương đương
(Equivalence partitioning) hay phương pháp phân tích giá trị biên (Boundary value
analysis). Đối với kiểm thử hành vi của hệ thống với nhiều trường dữ liệu, bảng
quyết định (Decision Tables) sẽ giúp chúng ta phân loại và định hình được kịch bản
kiểm thử một cách chính xác và rõ ràng hơn.
Bảng quyết định là một kỹ thuật tốt để áp dụng cho những trường hợp cần
nhiều sự kết hợp.
Bảng quyết định hỗ trợ việc lựa chọn test case một cách có hệ thống và có
thể đem lại nhiều lợi ích trong việc nhận biết vấn đề tiềm ẩn và sự không rõ ràng

trong đặc tả (Specification)
18
18


Báo cáo thực tập tốt nghiệp

Bảng quyết định là kỹ thuật quyết định số test case tối thiểu với độ bao phủ
tối đa.
Các bước để tạo bảng quyết định:
- Liệt kê tất cả đầu vào.
- Tính số lượng kết hợp có thể.
- Đặt tất cả các kết hợp trong bảng.
- Giảm thiểu các trường hợp kết hợp và quyết định kịch bản kiểm thử.
1.4.4 . Đoán lỗi (Error Guessing)
Đoán lỗi là một phương pháp kiểm thử, trong đó các trường hợp kiểm thử
được sử dụng để tìm lỗi trong các chương trình đã được phát triển dựa vào kinh
nghiệm trong các lần kiểm thử trước. Phạm vi của các trường hợp kiểm thử thường
được dựa vào các kiểm thử viên có kiến thức liên quan, là những người đã có kinh
nghiệm sử dụng và trực giác để xác định những tình huống thường gây ra lỗi trong
Đồ án tốt nghiệp chuyên ngành Mạng máy tính Nguyễn Thị Thùy 28 phần mềm.
Các lỗi điển hình như chia cho khơng, con trỏ khơng xác định, hoặc các biến khơng
hợp lệ, …
Cách đốn lỗi:
- Kiểm thử viên nên sử dụng kinh nghiệm trước đây để kiểm thử các ứng
dụng tương tự.
- Hiểu biết về hệ thống đang kiểm thử.
- Kiến thức về các lỗi thực hiện điển hình.
- Nhớ những chức năng phức tạp trước đây.
- Đánh giá lịch sử dữ liệu và kết quả kiểm thử.

19
19


Báo cáo thực tập tốt nghiệp

1.5 . Các loại kiểm thử (Test Types)
Nói một cách đơn giản, Test Type có thể được hiểu là sự phân loại các hoạt
động kiểm thử theo mục đích, chiến thuật kiểm thử. Mỗi Test Type sẽ gắn với một
mục tiêu kiểm thử nhất định.
Có 4 mục tiêu kiểm thử chính. Tương đương với chúng, ta có 4 loại Test
Type:
- Functional Testing (Kiểm thử chức năng)
- Non-functional Testing (Kiểm thử phi chức năng)
- Structural Testing (Kiểm thử cấu trúc)
- Change-related Testing (Kiểm thử thay đổi)
+ Kiểm thử xác nhận (Confirm testing)
+ Kiểm thử hồi quy (Regression testing)

Hình 1.8. Test Types
1.5.1 . Kiểm thử chức năng (Functional testing)
Kiểm thử chức năng: tương tự black box testing (kiểm tra đến chức năng của
chương trình mà khơng quan tâm đến cấu trúc bên trong). Kiểm thử chức năng là
chỉ tập trung kiểm tra chức năng của ứng dụng đó có hoạt động đúng như khách
hàng mong đợi khơng?

20
20

Báo cáo thực tập tốt nghiệp

Kiểm thử chức năng dựa trên tài liệu yêu cầu (requirement) và dựa trên tài
liệu mơ tả chi tiết (specification) quy trình nghiệp vụ:
- Dựa trên yêu cầu: Sử dụng các đặc tả yêu cầu của hệ thống làm cơ sở để
thiết kế kịch kiểm thử. Một cách tốt để bắt đầu là sử dụng bảng nội dung của đặc tả
yêu cầu như một danh sách các mục kiểm thử và không kiểm thử. Nên xét độ ưu
tiên của yêu cầu dựa trên các tiêu chí rủi ro và sử dụng độ ưu tiên để kiểm thử. Điều
này sẽ đảm bảo những phần quan trọng nhất sẽ được kiểm thử.
- Dựa trên quy trình nghiệp vụ: Sử dụng các kiến thức về quy trình nghiệp
vụ. Quy trình nghiệp vụ mơ tả các kịch bản liên quan đến nghiệp vụ hằng ngày của
hệ thống. Các trường hợp người dùng bắt nguồn từ hướng đối tượng, nhưng ngày
nay phổ biến nhiều là dựa trên vòng đời phát triển phần mềm. Có thể lấy quy trình
nghiệp vụ là điểm bắt đầu. Các trường hợp người dùng là một cơ sở rất hữu ích tạo
ra các trường hợp kiểm thử từ góc nhìn về nghiệp vụ.
Các loại kiểm thử chức năng
-

Kiểm thử đơn vị (Unit Testing): Lập trình viên test
Kiểm tra khói (Smoke Test): kiểm tra nhanh xem hệ thống có khởi động được hay

-

khơng
Kiểm tra tình trạng (Compatability Test)
Kiểm thử giao diện (Interface Testing)
Kiểm thử tích hợp (Integration Testing): là test tích hợp các chức năng, các module
có liên quan đến nhau hay còn gọi là test luồng nghiệp vụ giữa các chức năng, các
module. Các chức năng có sự liên kết hay liên quan với nhau về nghiệp vụ nên việc

-

test tích hợp thơng luồng nghiệp vụ các chức năng là vô cùng quan trọng.
Kiểm thử hệ thống (System Testing): Kiểm thử hệ thống là kiểm thử hộp đen, là
kiểm thử toàn bộ chức năng và giao diện của hệ thống, đảm bảo hệ thống khơng có

-

lỗi và đáp ứng đúng theo yêu cầu nghiệp vụ.
Kiểm thử hồi quy (Regression Testing)
Kiểm thử chấp nhận (Acceptance Testing): Khách hàng test

21
21


Báo cáo thực tập tốt nghiệp

1.5.2 . Kiểm thử phi chức năng (Non – Functional testing)
Kiểm thử phi chức năng là các đặc tính chất lượng của hệ thống sẽ được
kiểm tra. Nên quan tâm đến việc mọi thứ hoạt động tốt không? Hay nhanh như thế
nào? Sẽ kiểm tra những thứ cần phải đo như thời gian phản hồi, hay bao nhiêu
người có thể đăng nhập cùng một lúc? Kiểm thử phi chức năng cũng giống như
kiểm thử chức năng được thực hiện ở tất cả các cấp độ kiểm thử.
Kiểm thử phi chức năng bao gồm:
- Kiểm thử hiệu năng.
- Kiểm thử khả năng chịu tải.
- Kiểm thử áp lực.
- Kiểm thử tính khả dụng.

- Kiểm thử bảo trì.
- Kiểm thử độ tin cậy.
- Kiểm thử tính tương thích
Đặc điểm phụ tương ứng
- Độ tin cậy: Được xác định rõ hơn từ các đặc trưng phụ đã được tính tốn
cẩn thận (độ bền), khả năng chịu lỗi, phục hồi và tuân thủ.
- Khả năng sử dụng: Được chia thành các đặc trưng dễ hiểu, khả năng học
hỏi, khả năng hoạt động, sự thu hút và tính tuân thủ.
- Tính hiệu quả: Được chia thành hành vi về thời gian (hiệu suất), sử dụng tài
nguyên và tuân thủ.
- Khả năng bảo trì: Bao gồm 5 đặc điểm phụ: Phân tích, khả năng thay đổi,
tính ổn định, khả năng kiểm tra và tuân thủ.
- Tính tương thích: Bao gồm 5 đặc điểm phụ: khả năng thích ứng, khả năng
cài đặt, cùng tồn tại, khả năng thay thế và tuân thủ.

22
22


Báo cáo thực tập tốt nghiệp

1.5.3 . Kiểm thử cấu trúc (Strucural testing)
Kiểm thử cấu trúc có thể xảy ra ở bất kỳ mức độ kiểm thử nào, được áp dụng
chủ yếu ở kiểm thử thành phần, tích hợp.
Kiểm thử cấu trúc thường được sử dụng như một cách đo lường của kiểm thử
thông qua độ bao phủ của một tập hợp các yếu tố cấu trúc hoặc các mục bao phủ.
Ở cấp độ thành phần, và mức thấp hơn trong kiểm thử tích hợp thành phần
có hỗ trợ cơng cụ tốt để đo mức độ bao phủ của mã. Các công cụ đo lường độ bao
phủ đánh giá tỉ lệ phần trăm thực thi đã được thực hiện bởi một bộ kiểm thử. Nếu
độ bao phủ không phải là 100% thì các kiểm thử bổ sung có thể cần phải được viết

và chạy để bao phủ những phần chưa được thực hiện.
Các kỹ thuật được sử dụng để kiểm tra cấu trúc là kỹ thuật kiểm thử hộp
trắng, các mơ hình luồng điều khiển thơng thường được dùng để kiểm thử các cấu
trúc.
1.5.4 .Change-related Testing (Kiểm thử thay đổi)
Mục đích của kiểm thử thay đổi là để kiểm tra xem phần mềm có vận hành
trơn tru sau những lần sửa lỗi hay không. Kiểm thử thay đổi gồm 2 loại chính:
Kiểm thử xác nhận (Confirm testing): Thường Confirmation Testing sẽ
diễn ra sau khi lỗi trong phần mềm đã được xác nhận và được sửa. Lúc này, vai trò
của Kiểm thử xác nhận là để xem lỗi đã thực sự được sửa hay chưa. Các tester sẽ
tiến hành bằng cách cho một input giống hệt ban đầu và test xem output có ra được
như mong muốn hay khơng.
Kiểm thử hồi quy (Regression testing): Mục đích của kiểm thử hồi quy để 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 bất lợi
ngồi mong muốn và hệ thống vẫn đáp ứng các yêu cầu. Kiểm thử hồi quy được
thực hiện khi phần mềm thay đổi, do sửa lỗi hoặc do chức năng mới. Việc thực
thi Regression Testing cũng nên được cân nhắc khi môi trường xung quanh phần
mềm có sự thay đổi.

23
23


Báo cáo thực tập tốt nghiệp

CHƯƠNG 2: 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
2.1.1 . SQL
SQL (viết tắt của từ Structured Query Language) nghĩa là ngôn ngữ truy
vấn dữ liệu, là tập hợp các lệnh để tương tác với cơ sở dữ liệu. Dùng để lưu trữ,

thao tác và truy xuất dữ liệu được lưu trữ trong một cơ sở dữ liệu quan hệ.
SQL là một chuẩn ANSI (American National Standards Institute – Viện tiêu
chuẩn quốc gia Hoa Kỳ) về truy xuất các hệ thống CSDL. Các câu lệnh SQL được
sử dụng để truy xuất và cập nhật dữ liệu trong một CSDL.
SQL hoạt động với hầu hết các chương trình CSDL như Oracle, MySQL,…
2.1.2 . Database
Cơ sở dữ liệu (Database), viết tắt là CSDL hoặc DB, là một tập hợp các dữ
liệu có quan hệ logic với nhau. CSDL là tập hợp có cấu trúc của những dữ liệu có
liên quan với nhau được lưu trữ trong máy tính. Một CSDL được thiết kế, xây dựng
và lưu trữ với một mục đích xác định như phục vụ lưu trữ, truy xuất dữ liệu cho các
ứng dụng hay người dùng.
Bảng CSDL: Một CSDL thường bảo gồm một hoặc nhiều bảng (table). Mỗi
bảng được xác định thông qua một tên. Bảng chứa mẩu tin – dòng, là dữ liệu của
bảng.

Hình 2.9. DATABASE
24
24


Báo cáo thực tập tốt nghiệp

2.1.3 . Cơ sở dữ liệu Oracle
Oracle là một trong những nhà cung cấp lớn nhất trên thị trường công nghệ
hiện nay. Cái tên Oracle chính là tên viết tắt từ sản phẩm chủ lực của hãng, hệ thống
quản lý cơ sở dữ liệu quan hệ (RDBMS) có tên chính thức là Oracle Database. Phần
mềm cơ sở dữ liệu thường giữ vị trí trung tâm trong mảng IT của công ty, hỗ trợ
nhiều nhiệm vụ khác nhau gồm xử lý giao dịch, business intelligence (BI), và các
ứng dụng phân tích.

Hình 2.10. Oracle Database
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)
+ Lớp bộ nhớ (Memory)

25
25