Kiểm thử phần mềm với JUnit
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (781.55 KB, 56 trang )
TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI
KHOA CÔNG NGHỆ THÔNG TIN
KIỂM THỬ PHẦN MỀM
Đề tài: Tìm hiểu kiểm thử phần mềm với JUnit
GIÁO VIÊN HƯỚNG DẪN
: NGUYỄN ĐỨC LƯU
NHÓM THỰC HIỆN
: NHÓM 20.
LỚP
: ĐH KHMT1- K9.
Hà Nội, 2017.
TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI
KHOA CÔNG NGHỆ THÔNG TIN
KIỂM THỬ PHẦN MỀM
Đề tài: Tìm hiểu kiểm thử phần mềm với JUnit
GIÁO VIÊN HƯỚNG DẪN
: NGUYỄN ĐỨC LƯU
NHÓM THỰC HIỆN
: NHÓM 20.
LỚP
: ĐH KHMT1- K9.
SINH VIÊN THỰC HIỆN:
1.
2.
3.
TRẦN VĂN SƠN
NGÔ VĂN KHÁNH
NGUYỄN VĂN HIỂN
Hà Nội, 2017.
Mục lục
LỜI CẢM ƠN
Trong suốt quá trình học tập và làm bài tập lớn, nhóm 20 đã nhận được sự
hướng dẫn, giúp đỡ nhiệt tình của quý thầy cô trong khoa Công nghệ thông tin trường
Đại học Công nghiệp Hà Nội và các bạn trong bộ môn để hoàn thành đề tài nghiên
cứu của nhóm. Với lòng kính trọng và sự biết ơn sâu sắc, nhóm 20 xin được bày tỏ lời
cảm ơn chân thành tới thầy Nguyễn Đức Lưu – người thầy đã hết lòng giúp đỡ, dạy
bảo, động viên và tạo mọi điều kiện thuận lợi cho nhóm trong suốt quá trình học tập
và hoàn thành bài tập lớn của nhóm, cùng tất cả các thầy cô trong khoa, trong trường
và bạn bè trong bộ môn đã giúp đỡ nhóm trong quá trình học tập.
Những đóng góp của mọi người là kinh nghiệm quý báu giúp cho các thành viên
trong nhóm sẽ có những dự tính sau này trong khi làm đồ án tốt nghiệp và sau khi tốt
nghiệp.
Chúng em xin chân thành cảm ơn!
Nhóm thực hiện
Nhóm 20
4
Phần 1: Mở đầu
1.
Tên đề tài
Tìm hiểu kiểm thử phần mềm với JUnit
2.
Lí do lựa chọn đề tài
Ngày nay công nghệ thông tin đang ngày càng phát triển
nhanh chóng, kéo theo đó là hệ thống mạng và các phần
mềm cũng gia tăng cả về số lượng theo quy mô rộng và cả
về chất lượng phần mềm theo chiều sâu. Nhưng cũng từ
đó đã nảy sinh ra nhiều vấn đề về lỗi hỏng hóc phần mềm
không đáng có gây ra các ảnh hưởng nghiêm trọng đến xã
hội, kinh tế,… Những lỗi này có thể do tự bản thân phần
mềm bị hỏng do không được kiểm duyệt kĩ lưỡng trước khi
đưa cho người dùng cuối hay cũng có thể do có người cố
tình phá hoại nhằm đánh cắp thông tin cá nhân như mã số
tài khoản ngân hàng, số điện thoại, danh bạ, tin nhắn,…
Những vấn đề nan giải và cấp thiết này càng có xu hướng
mở rộng trong các năm gần đây, điển hình như sự cố máy
tính Y2K năm 2000 làm tê liệt nhiều hệ thống máy tính lớn
hay như càng có nhiều loại virus phá hoại mới xuất hiện,
tấn công vào các lỗ hổng bảo mật phần mềm làm tê liệt
nhiều hệ thống phần mềm và phần cứng. Từ đây ta dễ
dàng nhận ra là mặc dù phần mềm phát triển ngày càng
phức tạp nhưng vấn đề chất lượng vẫn là một dấu hỏi lớn
cần xem xét cẩn thận. Tuy nhiên, việc kiểm thử chưa thực sự phổ
biến trong chương trình giảng dạy lập trình và công nghệ phần mềm tại
một số trường đại học ở nước ta. Người lập trình thường xem nhẹ việc
5
kiểm thử, đơn giản vì đó là một công việc nhàm chán, ít gây hứng thú.
Nhưng kiểm thử là một hoạt động quan trọng và không thể thiếu được
nhằm phát hiện lỗi trong chương trình, từ đó nâng cao năng suất và đảm
bảo chất lượng sản phẩm phần mềm. Beck và Gamma là những người
đầu tiên phát triển công cụ mã nguồn mở JUnit để hỗ trợ việc kiểm thử.
JUnit là một framework đơn giản dùng cho việc tạo các unit testing tự
động, và chạy các test có thể lặp đi lặp lại. Nó chỉ là một phần của họ
kiến trúc xUnit cho việc tạo các unit testing. JUnit là một chuẩn trên thực
tế cho unit testing trong Java và rất phổ biến hiện nay.Vì vậy, chúng em
chọn đề tài “Tìm hiểu kiểm thử phần mềm với JUnit” đề được nghiên cứu
và hiểu rõ hơn về JUnit.
3.
Mục đích
Tập chung nghiên cứu, tìm hiểu, kiểm thử tự động nói chung và kiểm
thử với JUnit nói riêng.
4.
Bố cục
Chia thành 3 chương:
• Chương 1: Lý thuyết về kiểm thử và kiểm thử tự động
• Chương 2: Kiểm thử tự động với JUnit
• Chương 3: Cài đặt JUnit và Test demo bằng JUnit.
5. Phương pháp
– Nghiên cứu, tìm hiểu các kỹ thuật nội dung của kiểm thử tự động JUnit
– Sử dụng kiến thức đã tổng hợp được để demo test cho chương trình cụ
thể.
6
Phần 2: Nội dung
Chương 1: Cơ sở lý thuyết
1.1 Tổng quan về kiểm thử phần mềm
1.1.1 Khái niệm Kiểm thử phần mềm
– là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ
phần mềm trong đúng môi trường chúng dự định sẽ được
triển khai nhằm cung cấp cho những người có lợi ích liên quan
những thông tin về chất lượng của sản phẩm hay dịch vụ
phần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra các
lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt
động tối ưu của phần mềm trong nhiều ngành khác nhau.
(Wikipedia) Software testing là một trong những kĩ thuật phần
mềm “ xác minh và xác nhận “ (verification and validation
hay gọi tắt là V&V). Verification (chữ V đầu tiên) là quá trình
đánh giá một hệ thống hoặc thành phần để xác định xem các
sản phẩm của một giai đoạn phát triển nhất định đáp ứng các
điều kiện áp đặt vào lúc bắt đầu của giai đoạn đó hay không.
Các hoạt động Verification bao gồm việc kiểm thử và đánh
giá. Ví dụ trong phần mềm chơi game Monopoly, chúng ta có
thể xác minh rằng hai người chơi không thể sở hữu cùng một
nhà. Validationis quá trình đánh giá một hệ thống hoặc một
thành phần trong hoặc ở cuối của quá trình phát triển để xác
định xem nó đáp ứng yêu cầu quy định Verification Validation
Thông qua Verification chúng ta muốn chắc chắn rằng phần
mềm có các hành vi đúng như chúng ta mong đợi. Ví dụ:
Trong game Monopoly, người chơi có thể được cộng 200 điểm
nếu họ hạ cánh trên sân hoặc đi qua Go nhưng người lập trình
7
lại cài đặt là người chơi phải đi qua Go(?!). Thông qua
Validation chúng ta sẽ xác nhận rằng những lỗi không đúng
với yêu cầu của khách hàng sẽ không được thực hiện tiếp
theo trong suốt quá trình xây dựng xây dựng phần mềm.
Validation luôn luôn liên quan tới việc so sánh với các yêu cầu
của khách hàng. Ví dụ khách hàng yêu cầu là làm cho họ
game Monopoly nhưng đội ngũ phát triển lại làm đưa cho
game Life vì họ nghĩ là game Life hay hơn game Monopoly
như yêu cầu ban đầu.
1.1.2 Vai trò của kiểm thử phần mềm
– Việc tạo ra 1 sản phẩm phần mềm phải trải qua nhiều
giai đoạn, người ta gọi là qui trình phát triển phần mềm, bắt
đầu từ khi bắt đầu có ý tưởng cho đến khi đưa ra sản phẩm
phần mềm thực thi. Khối lượng công việc trong từng giai đoạn
của quá trình sản xuất phần mềm cũng thay đổi theo thời
gian. Một sản phẩm phần mềm không chỉ đơn giản là các
đoạn mã chương trình mà còn rất nhiều phần ẩn đằng sau nó.
Vì vậy, việc mắc lỗi không chỉ xảy ra trong khi lập trình mà
còn xảy ra cao hơn trong các công đoạn khác của qui trình
phát triển một sản phẩm phần mềm. Việc kiểm thử cũng vì
thế phải được tiến hành trong tất cả các phần tạo nên một
sản phẩm phần mềm.
1.1.3 Các kĩ thuật kiểm thử phần mềm
Kiểm thử hộp đen (Black Box testing): Dùng để kiểm
tra chức năng mà không xem xét mã nguồn cũng như
cấu chúc chương trình bên trong. Thường kiểm thử
8
hộp đen quan tâm nhiều đến các bộ dữ liệu kiểm thử
đầu vào.
Kiểm thử hộp trắng (White Box testing): Khác với kiểm
thử hộp đen, kiểm thử hộp trắng xem xét mọi module
trong chương trình, các luồng thực hiện công việc để
từ đó đưa ra các chiến lược kế hoạch cụ thể cho việc
kiểm thử.
Kiểm thử hộp xám (Grey Box Testing): Đây là một kĩ
thuật kiểm thử mới dựa trên những đặc tính của cả
kiểm thử hộp đen và hộp trắng. Mục tiêu chính của
kiểm thử hộp xám là kiểm thử các ứng dụng trên nền
web (web based).
1.1.4 Các giai đoạn hay cấp độ kiểm thử phần mềm
Kiểm thử đơn vị (Unit test): kiểm thử từng module nhỏ
trong chương trình để tìm ra các lỗi và khắc phục.
Kiểm thử tích hợp: sau khi đã thực hiện thành công
kiểm thử đơn vị, ta sẽ tiến hành tích hợp các module
này với nhau và kiểm thử trên toàn bộ khối mã lệnh đã
tích hợp này.
Kiểm thử hệ thống (System test): kiểm thử trên toàn
bộ ứng dụng.
Kiểm thử chấp nhận (Acceptance Test): khâu này do
khách hàng trực tiếp đảm nhận trước khi bàn giao sản
phẩm chính thức
Kiểm thử hồi quy là hoạt động trợ giúp để đảm bảo
rằng các thay đổi không đưa ra những hành vi hoặc
những lỗi bổ sung không mong đợi.
1.1.5 Một số loại hình kiểm thử phổ biến
9
Hiện nay, do sự phát triển mạnh mẽ của công nghệm
phần mềm nên có một số loại hình kiểm thử tiêu biểu như:
Kiểm thử các phần mềm trên Desktop: đây là các ứng
dụng được cài đặt trực tiếp trên máy tính cá nhân
nhằm thực hiện các chức năng theo yêu cầu người
dùng. Đây vẫn đang là những ứng dụng phổ biến nhất.
Kiểm thử Web hay kiểm thử trên đám mây: với sự lớn
mạnh của Internet thì các ứng dụng web cũng ngày
càng phát triển và đang dần thay thế các ứng dụng
trên Desktop truyền thống như Google Document,
Microsoft web apps,…
Kiểm thử trên Mobile: ngày nay xã hội với sự phát triển
nhanh chóng, các thiết bị di động (điện thoại thông
minh, máy tính bảng,…) có số lượng người dùng cũng
đang tăng lên chóng mặt, cùng với đó là số lượng
phần mềm phục vụ cho nhu cầu cũng tăng cao vì vậy
đây là một lĩnh vực đầy tiềm năng và thách thức trong
công nghệ phần mềm.
1.2 Kiểm thử tự động
1.2.1 Kiểm thử tự động là gì?
Sử dụng một công cụ kiểm thử tự động để thực thi các
test cases thay cho con người được goi là kiểm thử tự
động. Công cụ kiểm thử tự động có thể lấy dự liệu từ file
bên ngoài (excel, csv, …) nhập vào ứng dụng, so sánh kết
quả mong đợi (từ excel, csv) với kết quả thực tế và xuất
ra báo cáo kết quả kiểm thử.
1.2.2 Ưu điểm và nhược điểm của kiểm thử tự động
10
Ưu điểm:
• Độ tin cậy cao(Reliability): Nhờ sự ổn định vượt trội của
công cụ kiểm thử tự động so với con người, đặc biệt
trong trường hợp có quá nhiều test cases cần được thực
thi, nên độ tin cậy của kiểm thử tự động thường cao
•
hơn so với kiểm thử thủ công.
Khả năng lặp (Repeatability): Hãy cùng xem xet một ví
dụ: Trong một ngày thời tiết xấu chúng ta phải thực thi
một test case với 50 bộ dữ liệu đầu vào khác nhau. Nếu
thực thi cách thủ công, ngồi trước màn hình, nhập dữ
liệu, click click .., check check … trong 50 lần có lẽ bạn
sẽ gục ngã sớm trên bàn làm việc của mình. NHƯNG,
nếu bạn thực thi bằng kiểm thử tự động, chỉ cần nhập
dữ liệu vào file excel ( or csv, …) cho script chạy và
ngồi rung đùi cho tới khi nhận được báo cáo. Với độ ổn
định cao, bạn hoàn toàn có thể tin tưởng vào kết quả
thực thi của công cụ kiểm thử tự động. Quả là một viễn
•
cảnh lý tưởng hơn nhiều.
Khả năng tái sử dụng (Reusability): Với một bộ kiểm thử
tự động, chúng ta có thể sử dụng cho nhiều phiển bản
•
ứng dụng khác nhau, đây được gọi là tính tái sử dụng.
Nhanh (Fast): Đây là điều không cần phải bàn cãi, nếu
cần 5 phút để thực thi một test case cách thủ công, có
thể bạn cần chưa đầy 30s để thực thi cách tự động.
•
Chi phí thấp (Cost Reduction): Nếu áp dụng kiểm thử tự
động đúng cách, chúng ta có thể tiết kiệm được rất
nhiều chi phí, thời gian và nhân lực.
Nhược điểm:
11
•
Khó mở rộng, khó bảo trì (Poor scalability and
maintainability): Trong cùng một dự án, để mở rộng
phạm vi cho kiểm thử tự động là khó hơn nhiều so với
kiểm thử cách thủ công. Số lượng công việc phải làm để
mở rộng phạm vi cho kiểm thử tự động là nhiều hơn và
khó hơn kiểm thử thủ công. Cũng vậy, để cập nhật một
test case thủ công, chúng ta chỉ cần mở ra và gõ, rất
đơn giản. Nhưng kiểm thử tự động lại không đơn giản
như vậy, cập nhật hay chỉnh sửa yêu cầu rất nhiều
công việc như debug, thay đổi dữ liệu đầu vào, và cập
•
nhật code mới.
Khả năng bao phủ thấp(Low coverage): Chính vì việc
khó ứng dụng, khó mở rộng, cũng như đòi hỏi quá nhiều
kỷ năng lập trình nên độ bao phủ của kiểm thử tự động
khá thấp (xét trên góc nhìn toàn dự án).
•
Vấn đề công cụ và nhân lực (Technology vs. people
issues): Cho đến nay công cụ hỗ trợ kiểm thử tự động
đã có những bước phát triển mạnh mẽ, chúng ta có các
công cụ rất tốt như QTP, Selenium, Test Complete,
LoadTest, Jmeter, Visual Studio, … Nhưng nhìn chung
vẫn còn rất nhiều mặt hạn chế. Ngoài ra nguồn nhân
lực đạt yêu cầu cũng không nhiều.
1.2.3
Vì sao cần kiểm thử tự động
• Tiết kiệm tiền bạc vời thời gian: Nhận định này đặc biệt
đúng nếu xét trong giai đoạn bảo trì của các dự án lớn.
Mỗi tuần chúng ta phải thực hiện regression test từ 1
đến 2 lần với số lượng test case rất lớn trong 1 đến 2
ngày. Gần như không thể thực hiện cách thủ công, trong
12
khi với kiểm thử tự động chúng ta hoàn toàn có thể với
•
nguồn nhân lực vô cùng khiêm tốn.
Chính xác hơn: Nhờ độ ổn định cao, kiểm thử tự động có
•
thể thực thi các test case với độ chính xác cao hơn.
Độ bao phủ cao: Như đã nói ở trên, khi sử dụng kiểm thử
tự động, chúng ta có thể thực thi số lượng lớn test case
trong một thời gian ngắn. Điều này giúp chúng ta tăng
độ bao phủ trong giai đoạn regression test (một ví dụ
•
điển hình).
Hoàn thành các công việc mà con người không thể làm
được:
Nếu
chúng
ta
muốn
thực
thi
load
test,
performance test, thì kiểm thử tự động là cách duy nhất.
1.2.4 Khi nào nên sử dụng kiểm thử tự động.
•
Lý do thường xuyên nhất dẫn đến quyết định sử dụng
kiểm thử tự động là thường xuyên phải thực thi
regression test. Từ khi DEV đưa ra bản build mới cho tới
khi phiên bản mới tới tay khách hàng chỉ từ 1 đến 2
ngày. Trong thời gian ngắn ngủi này, regression test sẽ
được thực thi, nghĩa là một số lượng test case lớn phải
được thực thi trong một khoảng thời gian ngắn. Đây là
•
lúc lý tưởng để sử dụng kiểm thử tự động.
Xây dựng một bộ kiểm thử tự động cho những function
chính, để thực thi smoke test mỗi khi có build mới cũng
là một ý tưởng hay. Đây là công việc rất thường xuyên
•
trước khi thực hiện regression test.
Như đã nhắc tới ở trên, khi chúng ta muốn thực thi
performance test hay load test, kiểm thử tự động gần
như là lựa chọn duy nhất.
13
•
Khi số lượng đầu vào của 1 test case quá nhiều (như ví
dụ 50 bộ dữ liệu test), chúng ta cũng nên xem xét khả
năng thực hiện kiểm thử tự động.
14
1.3
Kiểm thử đơn vị
1.3.1 Tổng quan về kiểm thử đơn vị
Mục đích:
o
o
o
o
Kiểm tra đơn vị thiết kế nhỏ nhất – Một module phần mềm.
Người tiến hành kiểm thử đơn vị
Lập trình viên và nhóm của mình.
Kỹ thuật kiểm thử đơn vị
Chủ yếu là kiểm thử hộp trắng, nhưng đôi khi người ta cũng có thể sử
dụng kiểm thử hộp đen.
1.3.2 Mô hình kiểm thử đơn vị
1.3.2 Kỹ thuật kiểm thử đơn vị
15
1.3.3 Nội dung của kiểm thử đơn vị
•
•
•
•
•
•
•
Kiểm
Kiểm
Kiểm
Kiểm
Kiểm
Kiểm
Kiểm
thử
thử
thử
thử
thử
thử
thử
giao diện
vào/ra
cấu trúc dữ liệu cục bộ
xử lý
điều kiện logic
sai tiềm ẩn
các giá trị biên
16
Chương 2: Kiểm thử với JUnit
2.1 Junit là gì?
•
Các ngôn ngữ lập trình như như ASP, C++, C, Delphi,
Perl, PHP, REBOL, Python,… đều có bộ hỗ trợ Unit Test
riêng của nó. JUnit là một framework được dùng cho Unit
Test trong Java. JUnit được xây dựng bởi Erich Gamma và
•
Kent Beck, hai người nổi tiếng nhất về lập trình XP.
Trong JUnit có các Test Case là các lớp của Java, các lớp
này bao gồm một hay nhiều các phương thức cần kiểm
tra, và Test Case này lại được nhóm với nhau để tạo
thành Test Suite. Mỗi phương thức thử trong JUnit phải
được thực thi nhanh chóng. Tốc độ ở đây là điều tối quan
trọng vì càng nhiều phép thử được viết và tích hợp vào
bên trong quá trình phần mềm thì càng tốn nhiều thời
•
gian để hơn cho việc chạy toàn bộ Test Suite.
Những người lập trình không muốn bị ngắt quãng trong
một thời gian dài trong khi các phép thử đang chạy, do
đó các phép thử mà càng chạy lâu thì sẽ có nhiều khả
năng là các lập trình viên sẽ bỏ qua bước này. Các phép
thử được thiết kế để khi chạy mà không cần có sự can
thiệp của con người.
•
Mỗi phép thử trong JUnit là một phương thức public,
không có đối số và được bắt đầu bằng chữ test
( testXXX()). Nếu chúng ta không tuân thủ theo qui tắc
này thì JUnit sẽ không xác định được các phương thức
test một cách tự động.
17
2.2 Lợi ích của Junit
JUnit tránh cho người lập trình phải làm đi làm lại những
việc kiểm thử nhàm chán bằng cách tách biệt mã kiểm thử
ra khỏi mã chương trình, đồng thời tự động hóa việc tổ chức
và thi hành các bộ số liệu kiểm thử.
Thoạt tiên, khi sử dụng JUnit, ta có thể có cảm giác là
JUnit chỉ làm mất thêm thời gian cho việc kiểm thử: Thay vì
phải viết thêm các lớp và phương thức mới phục vụ cho công
tác kiểm thử, ta có thể soạn nhanh một bộ số liệu rồi viết
ngay vào trong phương thức main() và quan sát ngay kết
quả kiểm thử. Vì quá trình soạn số liệu và quá trình kiểm thử
diễn ra đồng thời, nên ta sẽ dễ dàng nhận biết được ngay
chương trình đã chạy đúng trên bộ số liệu kiểm thử hay
không, mà không cần nhìn vào tín hiệu “xanh” mà JUnit có
thể hỗ trợ.
Nhưng khi tổ chức lại chương trình cho hợp lý hơn
(refactoring) hoặc khi phải thay đổi chương trình để phục vụ
cho nhu cầu mới, các bộ số liệu kiểm thử trước đây sẽ cần
được sử dụng lại để chắc chắn rằng những thay đổi trong
chương trình không làm phương hại đến những thành quả
trước đó, lúc này ta sẽ phải mất thời gian để tìm hiểu lại xem
bộ số liệu trước đây sẽ tương ứng với kết xuất gì vì ta không
thể nhớ hết mọi hoạt động kiểm thử đã diễn ra. Việc nhớ lại
những kiểm thử đã qua sẽ chẳng thú vị vì không đem đến
cho ta điều gì mới. Nếu phải kiểm thử trên những bộ số liệu
lớn thì gánh nặng của việc tổ chức kiểm thử sẽ chồng chất
thêm. JUnit giúp người lập trình tự động hóa các công việc
18
nhàm chán, và chỉ cần nhìn thấy tín hiệu “xanh” là người lập
trình có thể an tâm rằng module đã được lập trình đúng.
2.3 Cách sử dụng cơ bản
•
Tạo class
Tạo một lớp java để được kiểm tra, MessageUtil.java
trong C:\> JUNIT_WORKSPACE
/*
* This class prints the given message on console.
*/
public class MessageUtil {
private String message;
//Constructor
//@param message to be printed
public MessageUtil(String message){
this.message = message;
}
// prints the message
public String printMessage(){
19
System.out.println(message);
return message;
}
}
•
Tạo lớp kiểm tra
Tạo một lớp kiểm tra java, TestJunit.java.
Thêm một phương pháp thử nghiệm testPrintMessage ()
vào lớp kiểm tra của bạn.
Thêm Annotaion @Test to method testPrintMessage ().
Thực hiện điều kiện kiểm tra và kiểm tra điều kiện sử
dụng assertEquals API của JUnit.
Tạo một tên tệp java class TestJunit.java trong C:\>
JUNIT_WORKSPACE .
import org.junit.Test;
import static org.junit.Assert.assertEquals;
public class TestJunit {
String message = “Hello World”;
MessageUtil messageUtil = new MessageUtil(message);
20
@Test
public void testPrintMessage() {
assertEquals(message,messageUtil.printMessage());
}
}
•
Tạo lớp chạy thử
Tạo một lớp java TestRunner.
Sử dụng phương pháp runClasses của lớp JUnitCore của
JUnit để chạy trường hợp thử nghiệm của lớp test đã tạo ở
trên.
Nhận kết quả của các trường hợp thử nghiệm chạy trong
Đối tượng kết quả.
Nhận lỗi (s) bằng phương thức getFailures () của đối tượng
Result.
Nhận kết quả bằng cách sử dụng phương thức
wasSuccessful () của đối tượng Result.
Tạo tệp tin lớp java có tên TestRunner.java
trong C:\>JUNIT_WORKSPACE để thực hiện (các) trường
hợp kiểm tra.
import org.junit.runner.JUnitCore;
import org.junit.runner.Result;
21
import org.junit.runner.notification.Failure;
public class TestRunner {
public static void main(String[] args) {
Result result = JUnitCore.runClasses(TestJunit.class);
for (Failure failure : result.getFailures()) {
System.out.println(failure.toString());
}
System.out.println(result.wasSuccessful());
}
}
Biên dịch MessageUtil, Test case và Test Runner classes
sử dụng javac.
C:\JUNIT_WORKSPACE>javac MessageUtil.java
TestJunit.java TestRunner.java
Bây giờ chạy Runner thử nghiệm, mà sẽ chạy các trường
hợp thử nghiệm được xác định trong các lớp Test Case
được cung cấp.
C:\JUNIT_WORKSPACE>java TestRunner
22
Xác minh đầu ra.
Hello World
true
Bây
giờ,
hãy
cập
JUNIT_WORKSPACE để
nhật
thử
TestJunit
nghiệm
trong C:
không
\>
thành
công. Thay đổi chuỗi thông báo.
import org.junit.Test;
import static org.junit.Assert.assertEquals;
public class TestJunit {
String message = “Hello World”;
MessageUtil messageUtil = new MessageUtil(message);
@Test
public void testPrintMessage() {
message = “New Word”;
assertEquals(message,messageUtil.printMessage());
}
}
Hãy giữ phần còn lại của các lớp học như là, và cố gắng
để chạy Runner Test giống nhau.
23
import org.junit.runner.JUnitCore;
import org.junit.runner.Result;
import org.junit.runner.notification.Failure;
public class TestRunner {
public static void main(String[] args) {
Result result = JUnitCore.runClasses(TestJunit.class);
for (Failure failure : result.getFailures()) {
System.out.println(failure.toString());
}
System.out.println(result.wasSuccessful());
}
}
Bây giờ chạy Runner thử nghiệm, mà sẽ chạy các trường
hợp thử nghiệm được xác định trong các lớp Test Case
được cung cấp.
C:\JUNIT_WORKSPACE>java TestRunner
Xác minh đầu ra.
24
Hello World
testPrintMessage(TestJunit): expected:<[New Wor]d> but
was:<[Hello Worl]d>
false
2.4 Junit-API (Giao diện lập trình ứng dụng)
Phần quan trọng nhất trong JUnit là junit.framework , chứa
tất cả các lớp cốt lõi. Một số các lớp quan trọng như:
STT
Tên lớp
1
Assert
class
2
TestCase
Chức năng
Một tập hợp các phương pháp khẳng
định.
Xác định các vật cố định để chạy nhiều
bài kiểm tra.
3
TestResult
TestResult thu thập kết quả thực hiện
một trường hợp thử nghiệm.
4
TestSuite
TestSuite là một hỗn hợp các bài kiểm
tra.
•
2.4.1 Assert class
25
: NGUYỄN ĐỨC LƯUNHÓM THỰC HIỆN: NHÓM 20.LỚP: ĐH KHMT1- K9.SINH VIÊN THỰC HIỆN:1.2.3.TRẦN VĂN SƠNNGÔ VĂN KHÁNHNGUYỄN VĂN HIỂNHà Nội, 2017.Mục lụcLỜI CẢM ƠNTrong suốt quá trình học tập và làm bài tập lớn, nhóm 20 đã nhận được sựhướng dẫn, giúp đỡ nhiệt tình của quý thầy cô trong khoa Công nghệ thông tin trườngĐại học Công nghiệp Hà Nội và các bạn trong bộ môn để hoàn thành đề tài nghiêncứu của nhóm. Với lòng kính trọng và sự biết ơn sâu sắc, nhóm 20 xin được bày tỏ lờicảm ơn chân thành tới thầy Nguyễn Đức Lưu – người thầy đã hết lòng giúp đỡ, dạybảo, động viên và tạo mọi điều kiện thuận lợi cho nhóm trong suốt quá trình học tậpvà hoàn thành bài tập lớn của nhóm, cùng tất cả các thầy cô trong khoa, trong trườngvà bạn bè trong bộ môn đã giúp đỡ nhóm trong quá trình học tập.Những đóng góp của mọi người là kinh nghiệm quý báu giúp cho các thành viêntrong nhóm sẽ có những dự tính sau này trong khi làm đồ án tốt nghiệp và sau khi tốtnghiệp.Chúng em xin chân thành cảm ơn!Nhóm thực hiệnNhóm 20Phần 1: Mở đầu1.Tên đề tàiTìm hiểu kiểm thử phần mềm với JUnit2.Lí do lựa chọn đề tàiNgày nay công nghệ thông tin đang ngày càng phát triểnnhanh chóng, kéo theo đó là hệ thống mạng và các phầnmềm cũng gia tăng cả về số lượng theo quy mô rộng và cảvề chất lượng phần mềm theo chiều sâu. Nhưng cũng từđó đã nảy sinh ra nhiều vấn đề về lỗi hỏng hóc phần mềmkhông đáng có gây ra các ảnh hưởng nghiêm trọng đến xãhội, kinh tế,… Những lỗi này có thể do tự bản thân phầnmềm bị hỏng do không được kiểm duyệt kĩ lưỡng trước khiđưa cho người dùng cuối hay cũng có thể do có người cốtình phá hoại nhằm đánh cắp thông tin cá nhân như mã sốtài khoản ngân hàng, số điện thoại, danh bạ, tin nhắn,…Những vấn đề nan giải và cấp thiết này càng có xu hướngmở rộng trong các năm gần đây, điển hình như sự cố máytính Y2K năm 2000 làm tê liệt nhiều hệ thống máy tính lớnhay như càng có nhiều loại virus phá hoại mới xuất hiện,tấn công vào các lỗ hổng bảo mật phần mềm làm tê liệtnhiều hệ thống phần mềm và phần cứng. Từ đây ta dễdàng nhận ra là mặc dù phần mềm phát triển ngày càngphức tạp nhưng vấn đề chất lượng vẫn là một dấu hỏi lớncần xem xét cẩn thận. Tuy nhiên, việc kiểm thử chưa thực sự phổbiến trong chương trình giảng dạy lập trình và công nghệ phần mềm tạimột số trường đại học ở nước ta. Người lập trình thường xem nhẹ việckiểm thử, đơn giản vì đó là một công việc nhàm chán, ít gây hứng thú.Nhưng kiểm thử là một hoạt động quan trọng và không thể thiếu đượcnhằm phát hiện lỗi trong chương trình, từ đó nâng cao năng suất và đảmbảo chất lượng sản phẩm phần mềm. Beck và Gamma là những ngườiđầu tiên phát triển công cụ mã nguồn mở JUnit để hỗ trợ việc kiểm thử.JUnit là một framework đơn giản dùng cho việc tạo các unit testing tựđộng, và chạy các test có thể lặp đi lặp lại. Nó chỉ là một phần của họkiến trúc xUnit cho việc tạo các unit testing. JUnit là một chuẩn trên thựctế cho unit testing trong Java và rất phổ biến hiện nay.Vì vậy, chúng emchọn đề tài “Tìm hiểu kiểm thử phần mềm với JUnit” đề được nghiên cứuvà hiểu rõ hơn về JUnit.3.Mục đíchTập chung nghiên cứu, tìm hiểu, kiểm thử tự động nói chung và kiểmthử với JUnit nói riêng.4.Bố cụcChia thành 3 chương:• Chương 1: Lý thuyết về kiểm thử và kiểm thử tự động• Chương 2: Kiểm thử tự động với JUnit• Chương 3: Cài đặt JUnit và Test demo bằng JUnit.5. Phương pháp- Nghiên cứu, tìm hiểu các kỹ thuật nội dung của kiểm thử tự động JUnit- Sử dụng kiến thức đã tổng hợp được để demo test cho chương trình cụthể.Phần 2: Nội dungChương 1: Cơ sở lý thuyết1.1 Tổng quan về kiểm thử phần mềm1.1.1 Khái niệm Kiểm thử phần mềm- là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụphần mềm trong đúng môi trường chúng dự định sẽ đượctriển khai nhằm cung cấp cho những người có lợi ích liên quannhững thông tin về chất lượng của sản phẩm hay dịch vụphần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra cáclỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạtđộng tối ưu của phần mềm trong nhiều ngành khác nhau.(Wikipedia) Software testing là một trong những kĩ thuật phầnmềm “ xác minh và xác nhận “ (verification and validationhay gọi tắt là V&V). Verification (chữ V đầu tiên) là quá trìnhđánh giá một hệ thống hoặc thành phần để xác định xem cácsản phẩm của một giai đoạn phát triển nhất định đáp ứng cácđiều kiện áp đặt vào lúc bắt đầu của giai đoạn đó hay không.Các hoạt động Verification bao gồm việc kiểm thử và đánhgiá. Ví dụ trong phần mềm chơi game Monopoly, chúng ta cóthể xác minh rằng hai người chơi không thể sở hữu cùng mộtnhà. Validationis quá trình đánh giá một hệ thống hoặc mộtthành phần trong hoặc ở cuối của quá trình phát triển để xácđịnh xem nó đáp ứng yêu cầu quy định Verification ValidationThông qua Verification chúng ta muốn chắc chắn rằng phầnmềm có các hành vi đúng như chúng ta mong đợi. Ví dụ:Trong game Monopoly, người chơi có thể được cộng 200 điểmnếu họ hạ cánh trên sân hoặc đi qua Go nhưng người lập trìnhlại cài đặt là người chơi phải đi qua Go(?!). Thông quaValidation chúng ta sẽ xác nhận rằng những lỗi không đúngvới yêu cầu của khách hàng sẽ không được thực hiện tiếptheo trong suốt quá trình xây dựng xây dựng phần mềm.Validation luôn luôn liên quan tới việc so sánh với các yêu cầucủa khách hàng. Ví dụ khách hàng yêu cầu là làm cho họgame Monopoly nhưng đội ngũ phát triển lại làm đưa chogame Life vì họ nghĩ là game Life hay hơn game Monopolynhư yêu cầu ban đầu.1.1.2 Vai trò của kiểm thử phần mềm- Việc tạo ra 1 sản phẩm phần mềm phải trải qua nhiềugiai đoạn, người ta gọi là qui trình phát triển phần mềm, bắtđầu từ khi bắt đầu có ý tưởng cho đến khi đưa ra sản phẩmphần mềm thực thi. Khối lượng công việc trong từng giai đoạncủa quá trình sản xuất phần mềm cũng thay đổi theo thờigian. Một sản phẩm phần mềm không chỉ đơn giản là cácđoạn mã chương trình mà còn rất nhiều phần ẩn đằng sau nó.Vì vậy, việc mắc lỗi không chỉ xảy ra trong khi lập trình màcòn xảy ra cao hơn trong các công đoạn khác của qui trìnhphát triển một sản phẩm phần mềm. Việc kiểm thử cũng vìthế phải được tiến hành trong tất cả các phần tạo nên mộtsản phẩm phần mềm.1.1.3 Các kĩ thuật kiểm thử phần mềmKiểm thử hộp đen (Black Box testing): Dùng để kiểmtra chức năng mà không xem xét mã nguồn cũng nhưcấu chúc chương trình bên trong. Thường kiểm thửhộp đen quan tâm nhiều đến các bộ dữ liệu kiểm thửđầu vào.Kiểm thử hộp trắng (White Box testing): Khác với kiểmthử hộp đen, kiểm thử hộp trắng xem xét mọi moduletrong chương trình, các luồng thực hiện công việc đểtừ đó đưa ra các chiến lược kế hoạch cụ thể cho việckiểm thử.Kiểm thử hộp xám (Grey Box Testing): Đây là một kĩthuật kiểm thử mới dựa trên những đặc tính của cảkiểm thử hộp đen và hộp trắng. Mục tiêu chính củakiểm thử hộp xám là kiểm thử các ứng dụng trên nềnweb (web based).1.1.4 Các giai đoạn hay cấp độ kiểm thử phần mềmKiểm thử đơn vị (Unit test): kiểm thử từng module nhỏtrong chương trình để tìm ra các lỗi và khắc phục.Kiểm thử tích hợp: sau khi đã thực hiện thành côngkiểm thử đơn vị, ta sẽ tiến hành tích hợp các modulenày với nhau và kiểm thử trên toàn bộ khối mã lệnh đãtích hợp này.Kiểm thử hệ thống (System test): kiểm thử trên toànbộ ứng dụng.Kiểm thử chấp nhận (Acceptance Test): khâu này dokhách hàng trực tiếp đảm nhận trước khi bàn giao sảnphẩm chính thứcKiểm thử hồi quy là hoạt động trợ giúp để đảm bảorằng các thay đổi không đưa ra những hành vi hoặcnhững lỗi bổ sung không mong đợi.1.1.5 Một số loại hình kiểm thử phổ biếnHiện nay, do sự phát triển mạnh mẽ của công nghệmphần mềm nên có một số loại hình kiểm thử tiêu biểu như:Kiểm thử các phần mềm trên Desktop: đây là các ứngdụng được cài đặt trực tiếp trên máy tính cá nhânnhằm thực hiện các chức năng theo yêu cầu ngườidùng. Đây vẫn đang là những ứng dụng phổ biến nhất.Kiểm thử Web hay kiểm thử trên đám mây: với sự lớnmạnh của Internet thì các ứng dụng web cũng ngàycàng phát triển và đang dần thay thế các ứng dụngtrên Desktop truyền thống như Google Document,Microsoft web apps,…Kiểm thử trên Mobile: ngày nay xã hội với sự phát triểnnhanh chóng, các thiết bị di động (điện thoại thôngminh, máy tính bảng,…) có số lượng người dùng cũngđang tăng lên chóng mặt, cùng với đó là số lượngphần mềm phục vụ cho nhu cầu cũng tăng cao vì vậyđây là một lĩnh vực đầy tiềm năng và thách thức trongcông nghệ phần mềm.1.2 Kiểm thử tự động1.2.1 Kiểm thử tự động là gì?Sử dụng một công cụ kiểm thử tự động để thực thi cáctest cases thay cho con người được goi là kiểm thử tựđộng. Công cụ kiểm thử tự động có thể lấy dự liệu từ filebên ngoài (excel, csv, …) nhập vào ứng dụng, so sánh kếtquả mong đợi (từ excel, csv) với kết quả thực tế và xuấtra báo cáo kết quả kiểm thử.1.2.2 Ưu điểm và nhược điểm của kiểm thử tự động10Ưu điểm:• Độ tin cậy cao(Reliability): Nhờ sự ổn định vượt trội củacông cụ kiểm thử tự động so với con người, đặc biệttrong trường hợp có quá nhiều test cases cần được thựcthi, nên độ tin cậy của kiểm thử tự động thường caohơn so với kiểm thử thủ công.Khả năng lặp (Repeatability): Hãy cùng xem xet một vídụ: Trong một ngày thời tiết xấu chúng ta phải thực thimột test case với 50 bộ dữ liệu đầu vào khác nhau. Nếuthực thi cách thủ công, ngồi trước màn hình, nhập dữliệu, click click .., check check … trong 50 lần có lẽ bạnsẽ gục ngã sớm trên bàn làm việc của mình. NHƯNG,nếu bạn thực thi bằng kiểm thử tự động, chỉ cần nhậpdữ liệu vào file excel ( or csv, …) cho script chạy vàngồi rung đùi cho tới khi nhận được báo cáo. Với độ ổnđịnh cao, bạn hoàn toàn có thể tin tưởng vào kết quảthực thi của công cụ kiểm thử tự động. Quả là một viễncảnh lý tưởng hơn nhiều.Khả năng tái sử dụng (Reusability): Với một bộ kiểm thửtự động, chúng ta có thể sử dụng cho nhiều phiển bảnứng dụng khác nhau, đây được gọi là tính tái sử dụng.Nhanh (Fast): Đây là điều không cần phải bàn cãi, nếucần 5 phút để thực thi một test case cách thủ công, cóthể bạn cần chưa đầy 30s để thực thi cách tự động.Chi phí thấp (Cost Reduction): Nếu áp dụng kiểm thử tựđộng đúng cách, chúng ta có thể tiết kiệm được rấtnhiều chi phí, thời gian và nhân lực.Nhược điểm:11Khó mở rộng, khó bảo trì (Poor scalability andmaintainability): Trong cùng một dự án, để mở rộngphạm vi cho kiểm thử tự động là khó hơn nhiều so vớikiểm thử cách thủ công. Số lượng công việc phải làm đểmở rộng phạm vi cho kiểm thử tự động là nhiều hơn vàkhó hơn kiểm thử thủ công. Cũng vậy, để cập nhật mộttest case thủ công, chúng ta chỉ cần mở ra và gõ, rấtđơn giản. Nhưng kiểm thử tự động lại không đơn giảnnhư vậy, cập nhật hay chỉnh sửa yêu cầu rất nhiềucông việc như debug, thay đổi dữ liệu đầu vào, và cậpnhật code mới.Khả năng bao phủ thấp(Low coverage): Chính vì việckhó ứng dụng, khó mở rộng, cũng như đòi hỏi quá nhiềukỷ năng lập trình nên độ bao phủ của kiểm thử tự độngkhá thấp (xét trên góc nhìn toàn dự án).Vấn đề công cụ và nhân lực (Technology vs. peopleissues): Cho đến nay công cụ hỗ trợ kiểm thử tự độngđã có những bước phát triển mạnh mẽ, chúng ta có cáccông cụ rất tốt như QTP, Selenium, Test Complete,LoadTest, Jmeter, Visual Studio, … Nhưng nhìn chungvẫn còn rất nhiều mặt hạn chế. Ngoài ra nguồn nhânlực đạt yêu cầu cũng không nhiều.1.2.3Vì sao cần kiểm thử tự động• Tiết kiệm tiền bạc vời thời gian: Nhận định này đặc biệtđúng nếu xét trong giai đoạn bảo trì của các dự án lớn.Mỗi tuần chúng ta phải thực hiện regression test từ 1đến 2 lần với số lượng test case rất lớn trong 1 đến 2ngày. Gần như không thể thực hiện cách thủ công, trong12khi với kiểm thử tự động chúng ta hoàn toàn có thể vớinguồn nhân lực vô cùng khiêm tốn.Chính xác hơn: Nhờ độ ổn định cao, kiểm thử tự động cóthể thực thi các test case với độ chính xác cao hơn.Độ bao phủ cao: Như đã nói ở trên, khi sử dụng kiểm thửtự động, chúng ta có thể thực thi số lượng lớn test casetrong một thời gian ngắn. Điều này giúp chúng ta tăngđộ bao phủ trong giai đoạn regression test (một ví dụđiển hình).Hoàn thành các công việc mà con người không thể làmđược:Nếuchúngtamuốnthựcthiloadtest,performance test, thì kiểm thử tự động là cách duy nhất.1.2.4 Khi nào nên sử dụng kiểm thử tự động.Lý do thường xuyên nhất dẫn đến quyết định sử dụngkiểm thử tự động là thường xuyên phải thực thiregression test. Từ khi DEV đưa ra bản build mới cho tớikhi phiên bản mới tới tay khách hàng chỉ từ 1 đến 2ngày. Trong thời gian ngắn ngủi này, regression test sẽđược thực thi, nghĩa là một số lượng test case lớn phảiđược thực thi trong một khoảng thời gian ngắn. Đây làlúc lý tưởng để sử dụng kiểm thử tự động.Xây dựng một bộ kiểm thử tự động cho những functionchính, để thực thi smoke test mỗi khi có build mới cũnglà một ý tưởng hay. Đây là công việc rất thường xuyêntrước khi thực hiện regression test.Như đã nhắc tới ở trên, khi chúng ta muốn thực thiperformance test hay load test, kiểm thử tự động gầnnhư là lựa chọn duy nhất.13Khi số lượng đầu vào của 1 test case quá nhiều (như vídụ 50 bộ dữ liệu test), chúng ta cũng nên xem xét khảnăng thực hiện kiểm thử tự động.141.3Kiểm thử đơn vị1.3.1 Tổng quan về kiểm thử đơn vịMục đích:Kiểm tra đơn vị thiết kế nhỏ nhất – Một module phần mềm.Người tiến hành kiểm thử đơn vịLập trình viên và nhóm của mình.Kỹ thuật kiểm thử đơn vịChủ yếu là kiểm thử hộp trắng, nhưng đôi khi người ta cũng có thể sửdụng kiểm thử hộp đen.1.3.2 Mô hình kiểm thử đơn vị1.3.2 Kỹ thuật kiểm thử đơn vị151.3.3 Nội dung của kiểm thử đơn vịKiểmKiểmKiểmKiểmKiểmKiểmKiểmthửthửthửthửthửthửthửgiao diệnvào/racấu trúc dữ liệu cục bộxử lýđiều kiện logicsai tiềm ẩncác giá trị biên16Chương 2: Kiểm thử với JUnit2.1 Junit là gì?Các ngôn ngữ lập trình như như ASP, C++, C, Delphi,Perl, PHP, REBOL, Python,… đều có bộ hỗ trợ Unit Testriêng của nó. JUnit là một framework được dùng cho UnitTest trong Java. JUnit được xây dựng bởi Erich Gamma vàKent Beck, hai người nổi tiếng nhất về lập trình XP.Trong JUnit có các Test Case là các lớp của Java, các lớpnày bao gồm một hay nhiều các phương thức cần kiểmtra, và Test Case này lại được nhóm với nhau để tạothành Test Suite. Mỗi phương thức thử trong JUnit phảiđược thực thi nhanh chóng. Tốc độ ở đây là điều tối quantrọng vì càng nhiều phép thử được viết và tích hợp vàobên trong quá trình phần mềm thì càng tốn nhiều thờigian để hơn cho việc chạy toàn bộ Test Suite.Những người lập trình không muốn bị ngắt quãng trongmột thời gian dài trong khi các phép thử đang chạy, dođó các phép thử mà càng chạy lâu thì sẽ có nhiều khảnăng là các lập trình viên sẽ bỏ qua bước này. Các phépthử được thiết kế để khi chạy mà không cần có sự canthiệp của con người.Mỗi phép thử trong JUnit là một phương thức public,không có đối số và được bắt đầu bằng chữ test( testXXX()). Nếu chúng ta không tuân thủ theo qui tắcnày thì JUnit sẽ không xác định được các phương thứctest một cách tự động.172.2 Lợi ích của JunitJUnit tránh cho người lập trình phải làm đi làm lại nhữngviệc kiểm thử nhàm chán bằng cách tách biệt mã kiểm thửra khỏi mã chương trình, đồng thời tự động hóa việc tổ chứcvà thi hành các bộ số liệu kiểm thử.Thoạt tiên, khi sử dụng JUnit, ta có thể có cảm giác làJUnit chỉ làm mất thêm thời gian cho việc kiểm thử: Thay vìphải viết thêm các lớp và phương thức mới phục vụ cho côngtác kiểm thử, ta có thể soạn nhanh một bộ số liệu rồi viếtngay vào trong phương thức main() và quan sát ngay kếtquả kiểm thử. Vì quá trình soạn số liệu và quá trình kiểm thửdiễn ra đồng thời, nên ta sẽ dễ dàng nhận biết được ngaychương trình đã chạy đúng trên bộ số liệu kiểm thử haykhông, mà không cần nhìn vào tín hiệu “xanh” mà JUnit cóthể hỗ trợ.Nhưng khi tổ chức lại chương trình cho hợp lý hơn(refactoring) hoặc khi phải thay đổi chương trình để phục vụcho nhu cầu mới, các bộ số liệu kiểm thử trước đây sẽ cầnđược sử dụng lại để chắc chắn rằng những thay đổi trongchương trình không làm phương hại đến những thành quảtrước đó, lúc này ta sẽ phải mất thời gian để tìm hiểu lại xembộ số liệu trước đây sẽ tương ứng với kết xuất gì vì ta khôngthể nhớ hết mọi hoạt động kiểm thử đã diễn ra. Việc nhớ lạinhững kiểm thử đã qua sẽ chẳng thú vị vì không đem đếncho ta điều gì mới. Nếu phải kiểm thử trên những bộ số liệulớn thì gánh nặng của việc tổ chức kiểm thử sẽ chồng chấtthêm. JUnit giúp người lập trình tự động hóa các công việc18nhàm chán, và chỉ cần nhìn thấy tín hiệu “xanh” là người lậptrình có thể an tâm rằng module đã được lập trình đúng.2.3 Cách sử dụng cơ bảnTạo classTạo một lớp java để được kiểm tra, MessageUtil.javatrong C:\> JUNIT_WORKSPACE/** This class prints the given message on console.*/public class MessageUtil {private String message;//Constructor//@param message to be printedpublic MessageUtil(String message){this.message = message;// prints the messagepublic String printMessage(){19System.out.println(message);return message;Tạo lớp kiểm traTạo một lớp kiểm tra java, TestJunit.java.Thêm một phương pháp thử nghiệm testPrintMessage ()vào lớp kiểm tra của bạn.Thêm Annotaion @Test to method testPrintMessage ().Thực hiện điều kiện kiểm tra và kiểm tra điều kiện sửdụng assertEquals API của JUnit.Tạo một tên tệp java class TestJunit.java trong C:\>JUNIT_WORKSPACE .import org.junit.Test;import static org.junit.Assert.assertEquals;public class TestJunit {String message = “Hello World”;MessageUtil messageUtil = new MessageUtil(message);20@Testpublic void testPrintMessage() {assertEquals(message,messageUtil.printMessage());Tạo lớp chạy thửTạo một lớp java TestRunner.Sử dụng phương pháp runClasses của lớp JUnitCore củaJUnit để chạy trường hợp thử nghiệm của lớp test đã tạo ởtrên.Nhận kết quả của các trường hợp thử nghiệm chạy trongĐối tượng kết quả.Nhận lỗi (s) bằng phương thức getFailures () của đối tượngResult.Nhận kết quả bằng cách sử dụng phương thứcwasSuccessful () của đối tượng Result.Tạo tệp tin lớp java có tên TestRunner.javatrong C:\>JUNIT_WORKSPACE để thực hiện (các) trườnghợp kiểm tra.import org.junit.runner.JUnitCore;import org.junit.runner.Result;21import org.junit.runner.notification.Failure;public class TestRunner {public static void main(String[] args) {Result result = JUnitCore.runClasses(TestJunit.class);for (Failure failure : result.getFailures()) {System.out.println(failure.toString());System.out.println(result.wasSuccessful());Biên dịch MessageUtil, Test case và Test Runner classessử dụng javac.C:\JUNIT_WORKSPACE>javac MessageUtil.javaTestJunit.java TestRunner.javaBây giờ chạy Runner thử nghiệm, mà sẽ chạy các trườnghợp thử nghiệm được xác định trong các lớp Test Caseđược cung cấp.C:\JUNIT_WORKSPACE>java TestRunner22Xác minh đầu ra.Hello WorldtrueBâygiờ,hãycậpJUNIT_WORKSPACE đểnhậtthửTestJunitnghiệmtrong C:không\>thànhcông. Thay đổi chuỗi thông báo.import org.junit.Test;import static org.junit.Assert.assertEquals;public class TestJunit {String message = “Hello World”;MessageUtil messageUtil = new MessageUtil(message);@Testpublic void testPrintMessage() {message = “New Word”;assertEquals(message,messageUtil.printMessage());Hãy giữ phần còn lại của các lớp học như là, và cố gắngđể chạy Runner Test giống nhau.23import org.junit.runner.JUnitCore;import org.junit.runner.Result;import org.junit.runner.notification.Failure;public class TestRunner {public static void main(String[] args) {Result result = JUnitCore.runClasses(TestJunit.class);for (Failure failure : result.getFailures()) {System.out.println(failure.toString());System.out.println(result.wasSuccessful());Bây giờ chạy Runner thử nghiệm, mà sẽ chạy các trườnghợp thử nghiệm được xác định trong các lớp Test Caseđược cung cấp.C:\JUNIT_WORKSPACE>java TestRunnerXác minh đầu ra.24Hello WorldtestPrintMessage(TestJunit): expected:<[New Wor]d> butwas:<[Hello Worl]d>false2.4 Junit-API (Giao diện lập trình ứng dụng)Phần quan trọng nhất trong JUnit là junit.framework , chứatất cả các lớp cốt lõi. Một số các lớp quan trọng như:STTTên lớpAssertclassTestCaseChức năngMột tập hợp các phương pháp khẳngđịnh.Xác định các vật cố định để chạy nhiềubài kiểm tra.TestResultTestResult thu thập kết quả thực hiệnmột trường hợp thử nghiệm.TestSuiteTestSuite là một hỗn hợp các bài kiểmtra.2.4.1 Assert class25
