KIỂM THỬ PHẦN MỀM, KIỂM THỬ BI TESTING

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI
KHOA CÔNG NGHỆ THÔNG TIN
======***======

BÁO CÁO THÍ NGHIỆM/THỰC NGHIỆM
KIỂM THỬ PHẦN MỀM

KIỂM THỬ BI TESTING

GVHD:
Nhóm - Lớp:
Thành viên:

Hà Nội, Năm 2022

Hồng Quang Huy
09_KTPM02
Lê Đình Lâm
Võ Xuân Long


2

Lời Mở Đầu
Lời đầu tiên cho phép nhóm em gửi lời cảm ơn sâu sắc tới tồn
thể các thầy cơ giáo trong khoa Công nghệ thông tin – Trường Đại học
Cơng nghiệp Hà Nội, những người đã hết mình truyền đạt và chỉ dẫn
cho chúng em những kiến thức, những bài học quý báu và bổ ích
trong suốt năm học vừa qua. Để hoàn thành được bài tập lớn này,
đặc biệt nhóm em xin được bày tỏ sự tri ân và xin chân thành cảm ơn
giảng viên Hoàng Quang Huy người trực tiếp hướng dẫn, góp ý cho

chúng em trong suốt q trình học tập và nghiên cứu để hồn thành
bài tập lớn này.
Trong quá trình nghiên cứu và làm báo cáo do năng lực, kiến
thức, trình độ nhóm cịn hạn hẹp nên khơng tránh khỏi những thiếu
sót. Nhóm em kính mong nhận được sự thơng cảm và những ý kiến
đóng góp của q thầy cơ và các bạn.
Chúng em xin chân thành cảm ơn!

Nhóm thực hiện
Nhóm 10

Thiết kế phần mềm


3
1 Mục lục
CHƯƠNG 1. MỞ ĐẦU

4

1.1. Mục đích

4

1.2. Giới thiệu hệ thống BI

4

1.3. Một số phương pháp kiểm thử

4

1.4. Một số chương trình hỗ trợ kiểm thử

4

CHƯƠNG 2. KẾT QUẢ NGHIÊN CỨU

4

2.1. Giới thiệu về JUnit

4

2.2. Phương pháp kiểm thử ETL (BI testing)

4

2.3. Chương trình kiểm thử

4

CHƯƠNG 3. KẾT LUẬN VÀ BÀI HỌC KINH NGHIỆM

4

3.1. Nội dung đã thực hiện

4

3.2. Hướng phát triển

4

Thiết kế phần mềm


4

CHƯƠNG 1. MỞ ĐẦU
1.1.Mục đích
Tìm hiểu cơ sở lý thuyết về kiểm thử phần mềm, các công cụ hỗ trợ
trong quá trình kiểm thử và ứng dụng để kiểm thử một số chức năng
của website. Mục tiêu như sau:
- Trình bày và giải thích các hoạt động trong 1 chiến lược kiểm thử
- Trình bày vai trị, ý nghĩa và cách sử dụng công cụ JUnit trong kiểm thử
tự động.
- Vận dụng được công cụ JUnit trong kiểm thử chương trình quản lý
phịng học.

1.2.Giới thiệu hệ thống BI
1.2.1 Thử nghiệm BI là gì?
Business Intelligence (BI) là quá trình thu thập, làm sạch, phân tích,
tích hợp và chia sẻ dữ liệu để thu được những hiểu biết sâu sắc thúc
đẩy tăng trưởng kinh doanh. Kiểm tra thông minh kinh doanh hoặc
kiểm tra BI xác minh dữ liệu dàn dựng, quy trình ETL, báo cáo BI và
đảm bảo việc triển khai là chính xác. Kiểm tra BI đảm bảo độ tin cậy
của dữ liệu và độ chính xác của những hiểu biết sâu sắc có được từ
quy trình BI.
1.2.2 Các trường hợp thử nghiệm mẫu cho BI

Thiết kế phần mềm


5

Các tình huống thử
Các trường hợp kiểm tra
nghiệm
Xác minh ETL

Xác minh dữ liệu được ánh xạ chính xác từ nguồn
đến hệ thống đích
Xác minh tất cả các bảng và các trường của chúng
được sao chép từ nguồn sang đích
Xác minh các khóa được định cấu hình để được tạo
tự động được tạo đúng cách trong hệ thống đích
Xác minh rằng các trường rỗng không được điền
Xác minh dữ liệu không bị cắt xén hoặc cắt ngắn
Xác minh loại dữ liệu và định dạng trong hệ thống
đích có như mong đợi
Xác minh rằng khơng có dữ liệu trùng lặp trong hệ
thống đích
Xác minh các phép biến đổi được áp dụng đúng
cách
Xác minh rằng độ chính xác của dữ liệu trong các
trường số là chính xác
Xác minh xử lý ngoại lệ là mạnh mẽ

Dữ liệu dàn dựng

Kiểm tra đối chiếu - số lượng bản ghi giữa bảng STG
(dàn) và bảng mục tiêu giống nhau sau khi áp dụng
các quy tắc lọc
Chèn bản ghi khơng được tải vào bảng đích cho tổ
hợp phím đã cho

Thiết kế phần mềm


6

Sao chép các bản ghi, gửi các bản ghi giống nhau đã
được tải vào các bảng đích-khơng nên tải
Cập nhật bản ghi cho một khóa khi các cột giá trị
thay đổi vào day_02 tải
Xóa các bản ghi một cách hợp lý trong các bảng
mục tiêu
Các giá trị được tải bởi các bảng quy trình
Các giá trị được tải bởi các bảng tham chiếu

Tải dữ liệu trong BI

Kiểm tra xem cơ sở dữ liệu đích và nguồn có được
kết nối tốt và khơng có vấn đề gì về truy cập hay
khơng.
Để tải đầy đủ, hãy kiểm tra tùy chọn cắt bớt và đảm
bảo nó hoạt động tốt.
Trong khi tải dữ liệu, hãy kiểm tra hiệu suất của
phiên

Kiểm tra các lỗi không nghiêm trọng.
Xác minh rằng bạn có thể khơng thực hiện được tác
vụ mẹ đang gọi nếu tác vụ con không thành công.
Xác minh rằng các bản ghi đã được cập nhật
Xác minh ánh xạ và các thơng số quy trình làm việc
được định cấu hình chính xác
Xác minh số lượng bảng trong hệ thống nguồn và
hệ thống đích là giống nhau
So sánh các thuộc tính từ các bảng giai đoạn với các
thuộc tính của các bảng mục tiêu. Chúng phải được

Thiết kế phần mềm


7

khớp với nhau.

Báo cáo BI

Hiển thị ngày và giờ
Độ chính xác thập phân cho các số liệu quan trọng
Trong một trang nhất định, hiển thị số hàng và cột
Đặc điểm tự do trong báo cáo
Các giá trị / dữ liệu trống được hiển thị như thế nào
cho cả đặc điểm và số liệu chính trong báo cáo
Tìm kiếm đặc điểm có dựa trên khóa hoặc khóa và
văn bản nếu có
Tùy chọn tìm kiếm trên văn bản có phân biệt chữ
hoa chữ thường không - Trên, Dưới hoặc cả hai

1.2.3 Kiểm tra kho dữ liệu (DataWarehouse Testing)
Kiểm tra kho dữ liệu là một phương pháp kiểm tra trong đó dữ
liệu bên trong kho dữ liệu được kiểm tra về tính tồn vẹn, độ tin
cậy, độ chính xác và nhất quán để tn thủ khung dữ liệu của cơng
ty. Mục đích chính của thử nghiệm kho dữ liệu là để đảm bảo rằng
dữ liệu tích hợp bên trong kho dữ liệu đủ tin cậy để một công ty
đưa ra quyết định.

1.3.Một số phương pháp kiểm thử
Có ba phương pháp kiểm thử phần mềm
- Kiểm thử hộp trắng (white box testing)
- Kiểm thử hộp đen (black box testing)
- Kiểm thử hộp xám (gray box testing)
Thiết kế phần mềm


8
1.3.1 Kiểm thử hộp trắng
1.3.1.1 Khái niệm
Là kỹ thuật kiểm thử mà kiểm thử viên biết được các cấu trúc
bên trong của chương trình (mã nguồn, xử lý dữ liệu, …). Việc
kiểm thử được dựa trên các phân tích về cấu trúc bên trong của
thành phần/hệ thống.
1.3.1.2 Đối tượng kiểm thử
Là 1 thành phần phần mềm. Thành phần phần mềm có thể là 1
hàm chức năng, 1 module chức năng, 1 phân hệ chức năng…
1.3.1.3 Các kỹ thuật kiểm thử hộp trắng
- Kiểm thử đường cơ bản – đồ thị dòng: là phương pháp kiểm thử
bao quát tất cả các dòng của source code, các nhánh và các

đường dẫn.
- Kiểm thử dựa trên luồng điều khiển: đồ thị luồng điều khiển là
một đồ thị có hướng gồm các đỉnh tương ứng với các câu
lệnh/nhóm câu lệnh và các cạnh là các dịng điều khiển giữa các
câu lệnh/nhóm câu lệnh.
1.3.1.4 ưu và nhược điểm
- Ưu điểm
o Test có thể bắt đầu ở giai đoạn sớm, không cần phải chờ đợi
cho giao diện hồn thành để có thể test
o Test kỹ càng hơn, có thể bao phủ hầu hết các đường dẫn
o Thích hợp trong việc tìm kiếm lỗi và các vấn đề trong mã lệnh
o Cho phép tìm kiếm các lỗi ẩn bên trong
o Các lập trình viên có thể tự kiểm tra
o Giúp tối ưu việc mã hoá
o Do yêu cầu kiến thức cấu trúc bên trong của phần mềm, nên
Thiết kế phần mềm


9
việc kiểm sốt lỗi tối đa nhất.
- Nhược điểm
o Vì các bài kiểm tra rất phức tạp, đòi hỏi phải có nhân lực tay
nghề cao, với kiến thức sâu rộng về lập trình và thực hiện.
o Vì phương pháp thử nghiệm này liên quan chặt chẽ với ứng
dụng đang được test, nên các công cụ để phục vụ cho mọi loại
triển khai / nền tảng có thể khơng sẵn có.
1.3.2 Kiểm thử hộp đen
1.3.2.1. Khái niệm
Là phương pháp kiểm thử tập trung vào yêu cầu về mặt chức
năng của phần mềm mà không xem xét đến cấu trúc bên trong

hoăc hoặc hoạt động của nó. Có thể tạo ra một bộ các input và
output để kiểm thử tất cả các chức năng của một chương trình
1.3.2.2. Đối tượng kiểm thử
Đối tượng được kiểm thử là 1 thành phần phần mềm. Thành
phần phần mềm có thể là 1 hàm chức năng, 1 module chức
năng, 1 phân hệ chức năng…
1.3.2.3. Các kỹ thuật kiểm thử hộp đen
• Phân vùng tương đương: là một kỹ thuật kiểm thử phần mềm
có liên quan đến phân chia các giá trị đầu vào thành các phân
vùng hợp lệ và khơng hợp lệ, sau đó chúng ta sẽ viết ra các test
case kiểm thử cho từng phần, chọn giá trị đại diện từ mỗi phân
vùng làm dữ liệu thử nghiệm.
• Phân tích giá trị biên: là một kỹ thuật kiểm thử phần mềm có
liên quan đến việc xác định biên của điều kiện mô tả cho các giá
trị đầu vào và chọn giá trị ở biên và bên cạnh giá trị biên làm dữ
liệu kiểm thử. Phương pháp phân tích giá trị biên sẽ đưa ra các
giá trị đặc biệt, bao gồm loại dữ liệu, giá trị lỗi, bên trong, bên
Thiết kế phần mềm


10
ngồi biên giá trị, lớn nhất và nhỏ nhất.
• Đồ thị nguyên nhân – kết quả: là một kỹ thuật thiết kế kiểm
thử phần mềm liên quan đến việc xác định các trường hợp (điều
kiện đầu vào) và các hiệu ứng (điều kiện đầu ra). Vì các hệ thống
hiện nay đều được phát triển trên nền tảng OOP, do đó, chúng
ta có thể có được một đồ thị các đối tượng mà hệ thống định
nghĩa và kết nối. Từ đồ thị này, chúng ta dễ dàng biết các mối
quan hệ của những đối tượng mà hệ thống xử lý, từ đó sẽ cho
chúng ta các kịch bản kiểm thử phù hợp.

• Đốn lỗi: là một kỹ năng quan trọng của tester dựa vào trực
giác. Phương pháp này đặc biệt dựa vào kinh nghiệm và kiến
thức của tester. Nhiều tester cố gắng đốn xem phần nào của
hệ thống mà có khả năng ẩn chứa lỗi. Với phương pháp này, họ
không cần một công cụ hay một kịch bản kiểm thử nào khi bắt
đầu vào việc.
1.3.2.4. Ưu và nhược điểm
● Ưu điểm
o Kiểm thử viên được thực hiện từ quan điểm của người
dùng và sẽ giúp đỡ trong việc sáng tỏ sự chênh lệch về
thông số kỹ thuật nên kiểm thử viên có thể khơng phải IT
chun nghiệp
o Kiểm thử hộp đen khơng có mối quan hệ nào liên quan
đến mã lệnh.
o Kiểm thử viên có thể được thực hiện bởi một cơ quan
độc lập từ các developer, cho phép một cái nhìn khách
quan và tránh sự phát triển thiên vị.
o Hệ thống thật sự với tồn bộ u cầu của nó được kiểm
thử chính xác.
Thiết kế phần mềm


11
o Thiết kế kịch bản kiểm thử khá nhanh, ngay khi mà các
yêu cầu chức năng được xác định.
● Nhược điểm
o Dữ liệu đầu vào yêu cầu một khối lượng mẫu khá lớn
o Nhiều dự án khơng có thơng số rõ ràng thì việc thiết kế
test case rất khó và do đó khó viết kịch bản kiểm thử do
cần xác định tất cả các yếu tố đầu vào, và thiếu cả thời

gian cho việc tập hợp này.
o Chỉ có một số nhỏ các đầu vào có thể được kiểm tra và
nhiều đường dẫn chương trình sẽ được để lại chưa được
kiểm tra.
1.3.3 Kiểm thử hộp xám
- 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ử hộp đen
và phương pháp kiểm thử 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 tốn của chương trình với
mục đích là để thiết kế test case, nhưng khi test thì test
như là người dùng cuối hoặc là ở mức hộp đen.

1.4.Một số chương trình hỗ trợ kiểm thử
1.4.1 Cơng cụ quản lý test(Test management tools).
Các tính năng được cung cấp bởi các cơng cụ quản lý test bao gồm các
tính năng được liệt kê dưới đây. Một số công cụ sẽ cung cấp tất cả các
tính năng này. Những cơng cụ khác cung cấp một hoặc nhiều tính
năng, tuy nhiên những cơng cụ này vẫn sẽ được phân loại như các
công cụ quản lý test.
Thiết kế phần mềm


12
Các tính năng hoặc đặc điểm của các cơng cụ test tập trung hỗ trợ cho:
● Quản lý các bài test: ví dụ: theo dõi các dữ liệu liên quan cho một bộ
các bài test, biết những kiểm tra nào cần phải chạy trong môi trường
chung, số lượng bài test đã được lên kế hoạch, viết, chạy, thông qua
hoặc thất bại.

● Lập kế hoạch cho các bài test để thực thi( bằng tay hoặc bằng công cụ
thực thi).
● Quản lý các hoạt động kiểm thử (thời gian chi cho thiết kế test, thực
hiện test để xem liệu có hồn thành đúng kế hoạch và ngân sách).
● Giao diện với các công cụ khác, như là:
● Công cụ thực thi test (công cụ chạy test).
● Công cụ quản lý sự cố.
● Công cụ quản lý yêu cầu.
● Công cụ quản lý cấu hình.
● Truy xuất nguồn gốc của các bài test, kết quả test và các lỗi từ yêu cầu
hoặc từ nguồn gốc khác.
● Logging kết quả test.
● Báo cáo tiến độ dựa trên các chỉ số như: chạy test và test passed, sự
cố gia tăng, những lỗi đã sửa và những lỗi lớn.
Những thơng tin này có thể được sử dụng để giám sát quy trình kiểm thử và
quyết định những hành động nào sẽ kiểm sốt được. Cơng cụ cũng đưa ra
thông tin về thành phần hoặc hệ thống đang được test( đối tượng test). Các
công cụ quản lý test giúp thu thập, tổ chức và quản lý thông tin kiểm thử của
một dự án.
Một số công cụ hỗ trợ quản lý test:

Thiết kế phần mềm


13

JIRA (incl. Cloud)

FogBugz

Redmine

Bugzilla

1.4.2. Các công cụ quản lý sự cố (Incident management tools).
Loại cơng cụ này cịn được gọi là cơng cụ theo dõi thiếu sót, cơng cụ
quản lý thiếu sót hoặc là cơng cụ quản lý bug. Báo cáo sự cố thông qua
một số giai đoạn nhận biết ban đầu và ghi lại chi tiết, thơng qua phân
tích, phân loại, phân định, công việc sửa lỗi, sửa lỗi, test lại và đóng.
Cơng cụ quản lý sự cố giúp theo dõi các sự cố theo thời gian một cách
dễ dàng.
Các tính năng và đặc điểm của các cơng cụ quản lý sự cố hỗ trợ:
● Lưu trữ thông tin về các thuộc tính của sự cố (tính nghiêm trọng).
● Lưu trữ các tập tin đính kèm (chụp ảnh màn hình).
● Độ ưu tiên của các sự cố.
● Phân công hành động cho từng người(sửa chữa, xác nhận test…).
● Trạng thái (ví dụ: open, rejected, duplicate, deferred, ready for
confirmation test, closed).
● Báo cáo thống kê/ số liệu về các sự cố (thời gian mở trung bình, số
lượng các sự cố với mỗi trạng thái, tổng số gia tăng, mở hoặc đóng..).
Chức năng của cơng cụ quản lý sự cố có thể bao gồm trong các công cụ
quản lý test thương mại.
1.4.3 Kiểm thử đơn vị (unit testing)
Là một loại kiểm thử phần mềm trong đó thực hiện kiểm thử từng đơn
Thiết kế phần mềm


14
vị hoặc thành phần riêng lẻ của phần mềm. Mục đích của việc Kiểm
thử đơn vị là để xác nhận rằng của mỗi đơn vị hay mã code của phần

mềm thực hiện chức năng của chúng đúng như mong đợi. Kiểm thử
đơn vị được thực hiện trong quá trình phát triển (giai đoạn thực hiện
code) của một ứng dụng và được thực hiện bởi các kỹ sư phần mềm.
Kiểm thử đơn vị sẽ thực hiện kiểm thử độc lập một phần code và xác
minh tính chính xác của nó. Một đơn vị có thể là một chức năng, một
phương thức, thủ tục, mô-đun hoặc đối tượng riêng lẻ.
Trong SDLC (Software Development Life-cycle - Vòng đời phát triển
phần mềm), STLC (Software Testing Life Cycle - Quy trình kiểm thử
phần mềm), V Model (Mơ hình chữ V), kiểm thử đơn vị là cấp độ kiểm
thử đầu tiên được thực hiện trước khi kiểm thử tích hợp. Kiểm thử
đơn vị là một kỹ thuật kiểm tra WhiteBox thường được thực hiện bởi
kỹ sư phần mềm. Mặc dù, trên thực tế do giới hạn về thời gian mà
những kỹ sư phần mềm khó có thể thực hiện kiểm thử đơn vị, lúc này
việc Kiểm thử đơn vị được thực hiện bởi những QA (Quality
Assurance/Tester).
Công cụ kiểm thử đơn vị:
Junit: Junit là một công cụ kiểm tra sử dụng miễn phí, được sử dụng
cho ngơn ngữ lập trình Java. Nó cung cấp các xác nhận giúp xác định
được phương pháp kiểm thử. Công cụ này kiểm tra dữ liệu trước và
sau đó chèn vào các đoạn code.
NUnit: NUnit được sử dụng rộng rãi trong Kiểm thử đơn vị và với tất
Thiết kế phần mềm


15
cả các ngơn ngữ .net. Nó là một cơng cụ mã nguồn mở, cho phép viết
các kịch bản một cách thủ cơng. Nó cũng hỗ trợ việc test dựa trên các
dữ liệu macó thể chạy song song.
PHPUnit: PHPUnit là một cơng cụ kiểm thử đơn vị cho lập trình viên
PHP. Nó lấy một phần nhỏ của mã code mà được gọi là các đơn vị và

kiểm tra từng mã riêng biệt. Công cụ này cũng cho phép các nhà phát
triển phần mềm sử dụng các phương thức xác nhận được xác định
trước để khẳng định rằng một hệ thống phải được hoạt động theo
một cách nhất định.

CHƯƠNG 2. KẾT QUẢ NGHIÊN CỨU
2.1.Giới thiệu về JUnit
2.1.1 Định nghĩa JUnit
JUnit là một framework viết unit test cho ngơn ngữ lập trình Java, có
vai trị quan trọng trong phát triển các ứng dụng test-driven. Trong tài
liệu này trình bày JUnit 5 tương thích các phiên bản Java 8 hoặc mới
hơn. JUnit 5 bao gồm ba thành phần quan trọng sau:
JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage
JUnit Platform định nghĩa TestEngine API để phát triển các framwork
kiểm thử. JUnit Jupiter cung cấp các annotation mới và hiện thực
TestEngine để chạy test case với các annotation này. JUnit Vintage hỗ
trợ chạy các test case viết trong JUnit 3 và JUnit 4 trên nền JUnit 5.
Để sử dụng JUnit 5 trên các project maven ta thêm dependency của
Jupiter Engine trong file pom.xml.

Thiết kế phần mềm


16
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>5.8.1</version>
<scope>test</scope>
</dependency>

<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-params</artifactId>
<version>5.8.1</version>
<scope>test</scope>
</dependency>
Thêm surefire plugin vào pom.xml, plugin này để thực thi unit test
case trong q trình kiểm thử.
<dependency>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.2</version>
</dependency>
2.1.2 Các tính năng của JUnit
· JUnit là một framework mã nguồn mở, được sử dụng để viết và
chạy thử nghiệm.
· Cung cấp chú thích để xác định phương pháp thử nghiệm.
· Cung cấp xác nhận để kiểm tra kết quả mong đợi
· Cung cấp các trình chạy thử nghiệm để chạy thử nghiệm
· Các bài kiểm tra JUnit cho phép bạn viết mã nhanh hơn, làm
tăng chất lượng phần mềm
Thiết kế phần mềm


17
· JUnit rất đơn giản và tốn ít thời gian hơn
· Các bài kiểm tra JUnit có thể được chạy tự động và họ kiểm tra
kết quả của riêng họ và cung cấp phản hồi ngay lập tức. Không cần
phải tự tay thông qua một báo cáo kết quả kiểm tra.
· Các bài kiểm tra JUnit có thể được tổ chức thành các test suites

chứa các test case và thậm chí các test suites khác.
· JUnit cho thấy tiến trình thử nghiệm trong một thanh có màu
xanh lá cây nếu thử nghiệm chạy thành cơng và nó chuyển sang
màu đỏ khi thử nghiệm không thành công.
· Một trường hợp kiểm thử đơn vị là 1 phần của mã nguồn để
đảm bảo rằng một phần của mã nguồn hay còn gọi là phương thức
hoạt động như mong đợi. Để đạt được kết quả mong muốn một
cách nhanh chóng, cần có framewoke kiểm tra bắt buộc. JUnit là
một framewoke kiểm thử đơn vị hồn hảo cho ngơn ngữ lập trình
Java.
· Một trường hợp thử nghiệm đơn vị viết chính thức được đặc
trưng bởi một đầu vào được biết đến và một đầu ra dự kiến, được
thực hiện trước khi thử nghiệm được thực hiện. Đầu vào đã biết
nên kiểm tra điều kiện tiên quyết và đầu ra dự kiến sẽ kiểm tra điều
kiện sau.
· Phải có ít nhất hai trường hợp thử nghiệm đơn vị cho mỗi yêu
cầu - một thử nghiệm valid data và một thử nghiệm invalid data.
Nếu yêu cầu có yêu cầu phụ, mỗi yêu cầu phụ phải có ít nhất hai
trường hợp thử nghiệm là valid data và invalid data.
2.1.3 JUnit Annotation
JUnit 5 hỗ trợ các annotation để viết test case, các annotation thuộc
gói org.junit.jupiter.api (Bảng 2.3.1)
Bảng 2.3.1 Các annotation để viết test case trong JUnit 5
@BeforeEach
Chạy trước mỗi phương thức test case

Thiết kế phần mềm


18

@AfterEach
Chạy sau mỗi phương thức test case

@BeforeAll
Chạy trước tất cả các phương thức test case, phương thức có
annotation này phải là static

@AfterAll
Chạy sau tất cả các phương thức test case, phương thức có
annotation này phải là static

@Test
Phương thức đóng vai trò test case

@DisplayName
Cung cấp tên hiển thị ch phương thức test case hoặc test class

@Disable
Bỏ qua một phương thứ test case hoặc test class

@Nested
Dùng tạo các lớp test case lồng nhau

@Tag
Gán nhãn tag cho các phương thức test case hoặc test class để dễ tìm
kiếm và lọc test case.

Thiết kế phần mềm

19

@TestFactory
Đánh dấu phương thức là test factory cho kiểm thử động.

2.4.1 JUnit Assertion
Assertion dùng kiểm tra, đánh giá đầu ra mong muốn và đầu ra thực
sự của test case. JUnit cung cấp các phương thức assertion là các
phương thức tĩnh của lớp org.junit.jupiter.Assertions. (Bảng 2.4.1)
Bảng 2.4.1 Các phương thức tĩnh của org.junit.jupiter.Assertions
assertEquals()
Kiểm tra hai giá trị bằng nhau

assertNotEquals()
Kiểm tra hai giá trị không bằng nhau
assertFalse()
Kiểm tra một biểu thức điều kiện là false

assertTrue()
Kiểm tra một biểu thức điều kiện là true

assertNotNull()
Kiểm tra một đối tượng khác null

assertNull()
Kiểm tra một đối tượng là null
Thiết kế phần mềm

20

assertSame()
Kiểm tra hai biến tham chiếu tham chiếu đến cùng đối tượng

assertNotSame()
Kiểm tra hai biến tham chiếu không tham chiếu đến cùng đối tượng

assertThrows()
Kiểm tra chương trình có ném ra ngoại lệ mong muốn hay khơng

assertArrayEquals()
Kiểm tra hai mảng có bằng nhau không

2.1.5 Parameterized Test
Parameterized Test cung cấp cơ chết thực thi một phương thức test
nhiều lần với các tham số khác nhau.
Các cách thức truyển đối số cho phương thức test.
· @ValueSource: chỉ định mảng giá trị là danh sách các đối số
lần lượt được truyển phương thức kiểm thử.
· @MethodSource: chỉ định các phương thức của lớp kiểm thử
hoặc từ lớp ngoài, phương thức này phải là phương thức static
· @CsvSource: chỉ định danh sách các phần tử, mỗi phần tử là
chuỗi gồm nhiều giá trị cách nhau bằng dấu phẩy tương ứng là
các đối số truyền vào phương thức kiểm thử
· @CsvFileSource: đọc các đối số từ tập tin CSV, mỗi cột của
từng đòng tương ứng là danh sách các đối số truyền vào
phương thức kiểm thử.
2.1.6 Cách cài đặt
Thiết kế phần mềm