Khóa luận Nghiên cứu về mức bao phủ của kiểm thử
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Vương Thị Quỳnh Dương
NGHIÊN CỨU VỀ MỨC BAO PHỦ CỦA KIỂM THỬ
KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY
Ngành : Công Nghệ Thông Tin
HÀ NỘI - 2009
1
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Vương Thị Quỳnh Dương
NGHIÊN CỨU VỀ MỨC BAO PHỦ CỦA KIỂM THỬ
KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY
Ngành: Công Nghệ Thông Tin
Cán bộ hướng dẫn : TS. Trương Ninh Thuận
Cán bộ đồng hướng dẫn: ThS. Tô Văn Khánh
HÀ NỘI - 2009
2
LỜI CẢM ƠN
Bản thân em đạt được thành quả như ngày hôm nay là nhờ một phần không nhỏ
công lao dìu dắt của các thầy cô trong khoa Công Nghệ Thông Tin - Đại Học Công
Nghệ - Đại Học Quốc Gia Hà Nội. Em xin ghi nhận công lao của các thầy cô và em xin
gửi lời cảm ơn sâu sắc tới thầy cô.
Để hoàn thành được khoá luận này em xin gửi lời cảm ơn chân thành tới TS.
Trương Ninh Thuận và ThS. Tô Văn Khánh, hai thầy đã hướng dẫn, giúp đỡ, chỉ bảo rất
tận tình cho em.
Dù đã cố gắng rất nhiều trong quá trình làm khoá luận, nhưng cũng không thể
tránh khỏi những thiếu sót, em rất mong nhận được sự góp ý của các thầy, cô giáo để
em có thể hoàn thiện hơn.
Hà nội, ngày 23 tháng 5 năm 2009
Sinh viên: Vương Thị Quỳnh Dương
3
TÓM TẮT KHOÁ LUẬN
Trong thời đại công nghệ thông tin bùng nổ như hiện nay, phần mềm đóng một
vai trò cực kỳ quan trọng trong hầu hết các lĩnh vực của đời sống. Phần mềm là một sản
phẩm cần phải được đảm bảo về chất lượng. Đảm bảo chất lượng phần mềm (SQA-
Software Quality Assuarance) là một nhiệm vụ đặc biệt quan trọng trong phát triển
phần mềm và là vấn đề sống còn đối với tất cả các công ty phần mềm. Để đảm bảo chất
lượng phần mềm thì trong các dự án phần mềm phải tiến hành xác minh và thẩm định.
Một trong các hoạt động xác minh và thẩm định quan trọng là tiến hành kiểm thử phần
mềm. Kiểm thử cần được tiến hành ở nhiều mức và phối hợp nhiều kỹ thuật khác nhau.
Phần không thể thiếu trong kiểm thử là việc xây dựng các ca kiểm thử. Các ca kiểm thử
phải đủ tốt mới có thể phát hiện ra khiếm khuyết của phần mềm. Một vấn đề đặt ra ở
đây là làm thế nào để xác định được ca kiểm thử đó là tốt, những tiêu chí nào đánh giá
chất lượng của chính ca kiểm thử? Và công việc tiến hành kiểm tra khi nào thì dừng lại?
Nội dung của khoá luận sẽ đề cập đến hai phương pháp nhằm mục đích xây dựng
các ca kiểm thử tốt đó là kỹ thuật phân tích bao phủ code và kỹ thuật phân tích giá trị
điểm biên. Phân tích bao phủ code sẽ phải tiến hành xây dựng các ca kiểm thử tất cả các
luồng đường đi có thể qua chương trình, các luồng đường đi từ input tới output được
xác định dựa trên các nhánh rẽ của chương trình. Thông thường các lỗi về lập trình
thường hay xảy ra tại giá trị biên do vậy tại giá trị biên cần phải thiết kế ca kiểm thử
kiểm tra nó. Trong phạm vi của khoá luận chúng tôi sẽ tiến hành cài đặt một chương
trình nhằm tìm ra các câu lệnh điều khiển của file nguồn java và chỉ ra giá trị biên trong
các biểu thức so sánh nhằm mục đích chỉ ra để xuất các giá trị biên baseline và robust
cần được kiểm tra.
4
Mục lục
CHƯƠNG 1. MỞ ĐẦU...............................................................................................10
1.1 Bối cảnh nghiên cứu ..........................................................................................10
1.2 Nội dung bài toán ..............................................................................................11
1.3 Cấu trúc của khoá luận.......................................................................................12
CHƯƠNG 2. GIỚI THIỆU VỀ BAO PHỦ CODE ......................................................14
2.1 Bao phủ code là gì ?...........................................................................................14
2.2 Tại sao cần đo lượng code được bao phủ ?.........................................................14
2.3 Làm thế nào để xác định lượng code được bao phủ ?.........................................15
2.4. Trong tiến trình test thì bao phủ code hợp với kỹ thuật kiểm thử nào ? ............15
2.4.1 Kiểm thử hộp đen .......................................................................................15
2.4.2 Kiểm thử hộp trắng.....................................................................................15
2.4.3 Bao phủ code ..............................................................................................16
CHƯƠNG 3. GIỚI THIỆU MỘT SỐ PHƯƠNG PHÁP BAO PHỦ ............................17
3.1 Bao phủ câu lệnh (Statement coverage) .............................................................17
3.2 Bao phủ nhánh (Branch coverage) .....................................................................17
3.3 Bao phủ đường đi (path coverage) .....................................................................18
3.4 Bao phủ điều kiện (condition coverage).............................................................18
3.5 Bao phủ nhiều điều kiện (multiple condition coverage) .....................................18
CHƯƠNG 4. PHÂN TÍCH, ĐÁNH GIÁ CÁC PHƯƠNG PHÁP BAO PHỦ..............19
4.1 Phân tích phương pháp bao phủ câu lệnh (statement coverage)..........................19
4.2 Phân tích phương pháp bao phủ nhánh (branch coverage)..................................23
4.3 Phân tích phương pháp bao phủ đường đi (path coverage) .................................28
CHƯƠNG 5. PHÂN TÍCH GIÁ TRỊ ĐIỂM BIÊN......................................................33
5.1 Giới thiệu...........................................................................................................33
5.2 Phân hoạch tương đương(equivalence partitioning) ...........................................33
5.3 Phân tích giá trị biên (boundary value analysis) .................................................34
5.3.1 Tổng quan về phân tích giá trị điểm biên.....................................................34
5.3.2 Lựa chọn các ca kiểm thử sử dụng phân tích giá trị điểm biên.....................34
5.3.3 Phân tích giá trị biên đơn biến (Single-Variable BVA)................................35
5.3.4 Phân tích giá trị biên đa biến (Multi – Variable BVA).................................36
5.3.5 Kết luận ......................................................................................................40
CHƯƠNG 6. THỰC NGHIỆM ...................................................................................41
6.1 Ví dụ một chương trình đơn giản .......................................................................41
6.1.1 Xây dựng các ca kiểm thử cho chương trình trên ........................................42
6.1.2 Kết luận ......................................................................................................46
6.2 Chương trình cài đặt tìm kiếm các câu lệnh rẽ nhánh trong mã nguồn java. .......46
6.2.1 Giới thiệu về chương trình ..........................................................................46
6.2.2 Mô tả các chức năng chính..........................................................................46
6.2.3 Biểu đồ trình tự...........................................................................................47
6.2.4 Thuật toán đã sử dụng.................................................................................49
6.2.5 Các lớp cài đặt ............................................................................................51
6.2.5 Kết quả thao tác các chức năng giữa người dùng và chương trình như sau..51
6.3 Kết luận.............................................................................................................56
5
CHƯƠNG 7: KẾT LUẬN KHOÁ LUẬN ...................................................................57
7.1 Kết luận về khoá luận ........................................................................................57
7.2 Hướng nghiên cứu phát triển trong tương lai......................................................57
TÀI LIỆU THAM KHẢO ...........................................................................................59
6
DANH SÁCH CÁC HÌNH VẼ
Hình 1 : Kết quả kiểm tra mã nguồn được thực thi ......................................................20
Hình 2 : Kết quả đo bao phủ dòng lệnh........................................................................23
Hình 3 : Kết quả thực hiện test case 1..........................................................................26
Hình 4 : Kết quả đo bao phủ nhánh khi thực hiện test case 1 .......................................26
Hình 5 : Kết quả khi thực hiện test case 2....................................................................27
Hình 6 : Kết quả đo bao phủ nhánh khi thực hiện test case 2 ......................................27
Hình 7: Kết quả thực hiện test case 3...........................................................................30
Hình 8 : Kết quả đo bao phủ khi thực hiện test case 3..................................................31
Hình 9 : Kết quả thực hiện test case 4..........................................................................32
Hình 10 : Kết quả đo bao phủ khi thực hiện test case 4................................................32
Hình 11 : Tập hợp các giá trị biên baseline cho đơn biến trên một khoảng đầu vào .....35
Hình 12 : Đường các giá trị baseline và robust cho đơn biến trên một khoảng đầu vào 36
Hình 13 : Tập hợp các giá trị baseline và rubust trường hợp đơn biến trên hai khoảng
đầu vào........................................................................................................................36
Hình 14 : Tập giá trị baseline và robust của biến N trong trường hợp hai biến đầu vào
....................................................................................................................................37
Hình 15 : Tập hợp giá trị baseline và rubust trên hai khoảng của biến M
trường hợp hai biến đầu vào
trong
38
Hình 16 : Tổng hợp tất cả các giá trị của hai biến N và M trên hai khoảng đầu vào .....38
Hình 17 : Tổng hợp toán bộ giá trị baseline, robust trường hợp đa biến đầu vào trên hai
khoảng.........................................................................................................................39
Hình 18 : Ví dụ cấu trúc một chương trình đơn giản....................................................41
Hình 19 : Các công việc cần thực hiện (tô đậm)..........................................................42
Hình 20 : Test case 1 kiểm tra công việc A..................................................................42
Hình 21 : Test case 2 kiểm tra công việc B..................................................................42
Hình 22 : Test case 3 kiểm tra công việc C..................................................................43
Hình 23 : Hai điều kiện một và hai là độc lập nhau......................................................43
Hình 24 : Kiểm tra đồng thời công việc A và công việc C trong cùng 1 test case.........44
Test case 2 kiểm tra công việc B và công việc C: ........................................................44
Hình 25 : Test case kiểm tra đồng thời công việc B và C.............................................44
Hình 26 : Nhánh không được bao phủ .........................................................................45
Hình 27. Biểu đồ trình tự.............................................................................................47
Hình 28: Biều đồ trình tự khi tương tác câu lệnh if......................................................48
Hình 29: Biều đồ trình tự khi tương tác câu lệnh while................................................48
Hình 30: Biểu đồ trình tự khi tương tác câu lệnh for....................................................49
Hình 31: Kiến trúc lớp cài đặt Get_File_Name............................................................51
Hình 32: Kiến trúc lớp ReadContentFile......................................................................51
Hình 33: Giao diện yêu cầu nhập tên file cần đọc........................................................52
Hình 34: Nhập tên file không đúng định dạng *.java ...................................................52
Hình 35: Nhập vào một tên file đúng để đọc................................................................52
Hình 36 : Nội dung của file TestFile.java ....................................................................52
Hình 37: Kết quả tìm kiếm câu lệnh điều khiển ...........................................................53
Hình 38 : Nội dung của file chứa câu lệnh điều khiển được tìm kiếm ..........................53
7
Hình 39 : Kết quả khi người dùng muốn thao tác với câu lệnh if .................................54
Hình 40 : Kết quả khi người dùng muốn thao tác với câu lệnh while...........................55
Hình 41 : Kết quả khi người dùng muốn thao tác với câu lệnh for ...............................55
8
DANH MỤC CÁC THUẬT NGỮ
Khái niệm
Thuật ngữ
Statement coverage
Branch coverage
Path coverage
Condition coverage
Boundary value analysis(BVA)
Single-variable BVA
Multi-variable BVA
Equivalence partitioning
Test case
Bao phủ câu lệnh
Bao phủ nhánh
Bao phủ đường đi
Bao phủ điều kiện
Phân tích giá trị biên
Phân tích giá trị biên đơn biến
Phân tích giá trị biên đa biến
Phân hoạch tương đương
Ca kiểm thử
Valication
Xác minh
Verification
Thẩm định
Test entropy
Kiểm tra độ bất định trong cấu trúc của
hệ thống
Cyclomatic complextity
Số đường độc lập tuyến tính đi qua mã
nguồn
Baseline
Robust
đường cơ sở
mạnh mẽ
Module
Mô đun
9
CHƯƠNG 1. MỞ ĐẦU
1.1 Bối cảnh nghiên cứu
Trong thời đại công nghệ thông tin bùng nổ như ngày nay, phần mềm đóng vai
trò vô cùng quan trọng ở hầu hết các lĩnh vực của cuộc sống. Đặc biệt trong khối ngành
doanh nghiệp, dịch vụ, quảng cáo, nó đã trợ giúp đắc lực nhằm làm tăng chất lượng
nghiệp vụ. Mỗi bộ phận đều phụ thuộc vào phần mềm để hỗ trợ cho việc phát triển, sản
xuất, quảng cáo nhằm tiếp thị các sản phầm và dịch vụ của họ.
Phần mềm cũng được xem là một sản phẩm, nhưng là loại hình sản xuất đặc biệt.
Trong một quy trình sản xuất phần mềm, giai đoạn phát hiện, xác định và sửa các lỗi
phần mềm được xem là phần không thể thiếu nhằm đảm bảo chất lượng phần mềm.
Đảm bảo chất lượng phần mềm là một nhiệm vụ đặc biệt quan trọng trong phát triển
phầm mềm và là vấn đề sống còn đối với tất cả các công ty phần mềm. Ở mức cao, việc
đảm bảo chất lượng liên quan đến một loạt các vấn đề như chuẩn và qui trình quản lý
của công ty, môi trường và công cụ phát triển, mô hình phát triển phần mềm được lựa
chọn, kỹ năng của nhân viên…Ở mức thấp hơn, chất lượng phần mềm được đảm bảo
trên cơ sở hiểu đúng yêu cầu của khách hàng, đặc tả đúng yêu cầu, tạo ra các thiết kết
tốt và chuyển tải nó một cách đúng đắn thành mã nguồn của phần mềm. Chi phí bỏ ra
cho giai đoạn này thường chiếm không nhỏ trong tổng chi phí mà các tổ chức phát triển
phần mềm bỏ ra cho toàn bộ qui trình. Với tốc độ phát triển chóng mặt của lĩnh vực
công nghệ thông tin trên cả hệ thống phần cứng và phần mềm, khả năng xảy ra nhiều
lỗi, đặc biệt là những lỗi phức tạp là rất cao. Lỗi có thể gây thiệt hại to lớn cả về tiền
bạc, thời gian và công sức con người. Chính vì vậy, cần có phương pháp phát hiện ra lỗi
sớm nhằm giảm công sức để sửa chúng. Để phát hiện ra những lỗi phần mềm, phần
mềm cần phải được thẩm định (Valication) và kiểm chứng (Verification). Xác minh,
thẩm định giúp ta phát hiện và sửa lỗi phần mềm từ đó đánh tính dùng được của phần
mềm.
Con người không thể không mắc sai lầm, và phần mềm mà không được kiểm tra
sẽ làm việc không hiểu quả. Thông thường, có từ 20 đến 50 lỗi trên 1000 dòng lệnh
được tìm thấy trong suốt quá trình phát triển, và vẫn còn từ 1.5 đến 4 lỗi trên 1000 dòng
lệnh sau khi kiểm thử hệ thống [1]. Mỗi lỗi này đều có thể dẫn tới lỗi tổng thể hay
không đúng với đặc tả yêu cầu. Mục đích của kiểm thử phần mềm là làm giảm lỗi phần
mềm xuống mức có thể chấp nhận được, tuỳ thuộc vào mức độ phức tạp của dự án.
Chính vì vậy, kiểm thử phần mềm có vai trò vô cùng quan trọng trong toàn bộ quy trình
10
phát triền phần mềm, và trong công nghiệp phần mềm hiện nay, nó đang thu hút sự
quan tâm của nhiều nhà nghiên cứu.
Trong quy trình phát triển phần mềm hiện đại có giai đoạn kiểm thử phần mềm
dùng để kiểm tra tính đúng đắn của phần mềm. Mục tiêu chính của nhóm phát triển
phần mềm là phải làm sao tạo ra được những sản phầm phần mềm có chất lượng tốt
nhất.Việc viết tập hợp các ca kiểm thử (test cases) là một phần quan trọng không thể
thiếu trong phương pháp phát triển phần mềm linh hoạt. Tập hợp các ca kiểm thử đúng
đắn giúp chúng ta giảm thiểu tối đa các lỗi, giảm thời gian tìm kiếm lỗi, tạo ra được các
phần mềm tốt, tính ổn định cao. Một cách lý tưởng thì người kiểm tra (tester) phải kiểm
tra tất cả các giá trị của biến đầu vào, tuy nhiên điều này là không tưởng bởi vì thường
thì miền giá trị của biến đầu vào là rất lớn, thậm chí gần như dài vô hạn hoặc vô hạn.
Do đó người kiểm tra không thể kỉêm tra được tất cả mọi giá trị, mọi trường hợp mà chỉ
kiểm tra một số trường hợp đại diện mà thôi. Như vậy luôn xuất hiện câu hỏi: xây dựng
những ca kiểm thử nào là hợp lý ? Bao giờ có thể ngưng kiểm tra? Các ca kiểm thử tạo
ra liệu có tốt hay không? Giá trị được chọn để xây dựng ca kiểm thử là những giá trị
nào?... Để nhằm giải đáp các thắc mắc này và xây dựng lên các ca kiểm thử tốt, trong
tài liệu này chúng tôi sẽ phân tích một số đề xuất được đưa ra nhằm đánh giá chất lượng
của một ca kiểm thử: phân tích bao phủ code (code coverage analysis), kiểm tra các
điểm đặc biệt (particular point) cụ thể là phân tích đánh giá giá trị tại vị trí biên.
1.2 Nội dung bài toán
Kiểm thử là giai đoạn vô cùng quan trọng trong quá trình phát triển phần mềm.
Trong giai đoạn này thì công việc thiết kế các ca kiểm thử lại đóng vai trò cực kỳ quan
trọng. Nhằm giúp xây dựng các ca kiểm thử tốt, chiến lược kiểm thử tối ưu, trong tài
liệu này sẽ đề cập đến kỹ thuật phân tích code bao phủ và phân tích các giá trị biên. Kỹ
thuật phân tích bao phủ sẽ đánh giá độ bao phủ từ đó xác định quá trình kiểm tra có đạt
được độ bao phủ yêu cầu hay không, tỷ lệ yêu cầu đã được kiểm tra (tính trên các yêu
cầu của phần mềm và số lượng code đã viết). Trong phạm vi tài liệu sẽ phân tích các
cách bao phủ cơ bản nhưng chúng vô cùng mạnh mẽ. Thông thường, không thể kiểm
thử với mọi dữ liệu, chiến lược chung khi thiết kế ca kiểm thử là phân hoạch tương
đương (equivalence partitioning). Phân hoạch tương đương chia miền dữ liệu vào ra
thành các vùng, mà mỗi vùng chứa các dữ liệu có cùng hành vi. Do đó, đối với mỗi
vùng dữ liệu chỉ cần xây dựng một ca kiểm thử để đại diện. Theo kinh nghiệm, các sai
sót về lập trình thường xảy ra đối với dữ liệu biên nên cần thêm vào đó các ca kiểm thử
kiểm tra đối với biên của các vùng. Trong tài liệu này cũng sẽ tiến hành phân tích đánh
11
giá các giá trị biên sử dụng trong các ca kiểm thử. Đưa ra các giá trị biên đề xuất cần
phải được kiểm tra để đảm bảo phần mềm vẫn hoạt động tốt và ổn định trên các giá trị
đó. Luồng chương trình từ input đến output có các cách đi khác nhau chủ yếu được dựa
vào các câu lệnh điều khiển trong mã nguồn, chúng tôi sẽ tiến hành cài đặt một chương
trình tìm kiếm câu lệnh điều khiển trong file mã nguồn java và xuất ra giá trị biên trong
câu lệnh điều khiển có chứa toán tử so sánh. Tóm lại bài toán đưa ra ở đây là làm sao
xây dựng được ca kiểm thử tốt, các lỗi lập trình thường xảy ra ở các điểm biên của dải
giá trị đầu vào, vậy thì ca kiểm thử thiết kế để kiểm tra giá trị biên là gì? Giải quyết bài
toán này chúng tôi sẽ phân tích kỹ thuật bao phủ code và kỹ thuật phân tích giá trị biên,
sau cùng là cài đặt chương trình tìm kiếm câu lệnh điều khiển của mã file mã nguồn
java, xuất ra giá trị biên trong đó.
1.3 Cấu trúc của khoá luận
Phần còn lại của khoá luận được trình bày như sau:
Chương 2 giới thiệu về bao phủ code. Trong chương này sẽ giới thiệu về kỹ thuật bao
phủ code. Lý do, tầm quan trọng của bao phủ code. Cách tiếp cận để có thể đo code
được bao phủ. Phân loại bao phủ code vào kỹ thuật kiểm thử hộp trắng.
Chương 3 giới thiệu về một số phương pháp đo bao phủ code cơ bản nhưng vô cùng
mạnh mẽ đó là các phương pháp : bao phủ câu lệnh đo bao nhiêu câu lệnh được thực thi
trong tổng số câu lệnh mã nguồn, bao phủ nhánh đo bao nhiêu nhánh đã được thực thi
trong tổng số các nhánh rẽ của chương trình, bao phủ đường đi đo bao nhiêu luồng
đường đi được kiểm tra, bao phủ điều kiện tương tự như bao phủ nhánh nhưng nó có độ
nhạy tốt hơn, bao phủ nhiều điều kiện kết hợp các biểu thức điều kiện con trong các câu
lệnh rẽ nhánh.
Chương 4 phân tích, đánh giá các phương pháp bao phủ. Trong chương này sẽ tiến hành
phân tích cụ thể từng phương pháp : bao phủ câu lệnh, bao phủ nhánh, bao phủ đường
đi, đồng thời đánh giá ưu nhược điểm của từng phương pháp.
Chương 5 trình bày tổng quan về phân tích giá trị điểm biên, chiến lược phân hoạch
tương đương. Tiếp đó phân tích kỹ thuật phân tích giá trị biên đơn biến và đa biến.
Chương 6 thực nghiệm một chương trình đơn giản. Chúng tôi sẽ tiến hành phân tích bài
toán thực nghiệm, đề xuất các ca kiểm thử để đảm bảo kiểm tra code được bao phủ
chương trình. Thông thường để xây dựng các ca kiểm thử kiểm tra bao phủ các nhánh
và bao phủ đường đi ta phải xác định trong chương trình mã nguồn có bao nhiêu câu
12
lệnh rẽ nhánh, chúng tôi sẽ cài đặt một chương trình đơn giản giúp xuất ra toàn bộ câu
lệnh rẽ nhánh và giá trị biên trong các biểu thức điều kiện trong file nguồn cần kiểm tra.
File nguồn đầu vào đọc là file java.
Chương 7 kết luận về khoá luận và hướng nghiên cứu tiếp theo.
13
CHƯƠNG 2. GIỚI THIỆU VỀ BAO PHỦ CODE
2.1 Bao phủ code là gì ?
Bao phủ code là phần trăm code được phủ bằng cách kiểm tra (test) tự động. Đo
lượng code bao phủ đơn giản là xác định những câu lệnh nào được thực thi, những câu
lệnh nào không được thực thi thông qua việc kiểm tra. Nhìn chung, một hệ thống bao
phủ code sẽ thu thập thông tin về chương trình đang chạy và kết hợp với thông tin
nguồn để tạo ra báo cáo bao phủ code trên test suite [2].
Trong tiến trình phát triển thì bao phủ code là một phần của vòng lặp các thông
tin phản hồi. Khi các ca kiểm thử (test case) được thực thi, bao phủ code sẽ làm nổi bật
lên diện mạo của các dòng code không được kiểm tra thoả đáng và các dòng code này
yêu cầu cần phải được kiểm tra thêm. Quá trình kiểm tra code không được thực thi và
sau đó thêm vào các ca kiểm thử thích hợp để kiểm tra lại là một vòng lặp. Vòng lặp
này sẽ tiếp tục lặp đi lặp lại cho tới khi bao phủ đạt đến một vài chỉ tiêu đề ra.
2.2 Tại sao cần đo lượng code được bao phủ ?
Cần phải hiểu một cách đúng đắn rằng test unit giúp ta cải thiện chất lượng và
giúp ta dự đoán trước được chất lượng của phần mềm. Tuy nhiên liệu rằng ta có thể biết
được unit test nào tốt cho phần code của ta? Test bao nhiêu thì đủ? Có cần phải test
nhiều hơn? Đo độ bao phủ code sẽ tìm ra câu trả lời cho những câu hỏi này.
Việc đo code bao phủ giúp ta tránh được test entropy (kiểm tra độ bất định trong
cấu trúc của hệ thống)[3]. Khi code của ta trải qua nhiều chu trình phát hành, có thể có
khuynh hướng làm hao mòn các unit test. Khi có code mới được thêm vào thì có thể sẽ
không cần đến các test case chuẩn mà dự án đã sử dụng trong lần phát hành đầu tiên.
Đo bao phủ code có thể giữ cho các test của ta đạt đến các chuẩn mà ta mong muốn.
Code không pass toàn bộ nhưng ta có thể tự tin rằng nó đã được kiểm tra kỹ lưỡng.
Nói tóm lại, đo độ bao phủ code vì các lý do sau:
- Để biết phần kiểm của ta có thực sự kiểm tra được code.
- Để biết được kiểm tra đến khi nào là đủ.
- Để duy trì chất lượng các ca kiểm thử qua các vòng đời của dự án
Nhìn chung bao phủ code theo nguyên tắc 80 – 20. Tăng giá trị bao phủ sẽ dần
trở lên khó khăn, với việc thực hiện các kiểm tra mới sẽ càng ngày càng ít làm tăng giá
14
trị bao phủ. Nếu ta tuân theo các nguyên tắc lập trình, các điều kiện lỗi thường sẽ được
kiểm tra ở nhiều cấp độ trong phần mềm của ta, có những dòng code có thể rất khó để
đạt tới các mức kiểm tra thực tế. Đo bao phủ không phải là việc thay thế bằng code tốt
và phong cách lập trình hay.
2.3 Làm thế nào để xác định lượng code được bao phủ ?
Có nhiều phương pháp để đo độ bao phủ code. Đại thể có ba cách tiếp cận chính,
chúng có thể được kết hợp sử dụng với nhau.
Đo mã nguồn: Phương pháp này sẽ thêm các câu lệnh công cụ vào mã nguồn và
biên dịch lại mã nguồn với các công cụ biên dịch thông thường. Một điểm bất lợi của
phương pháp này là phải biên dịch hai lần do đó có thể làm chậm tiến trình, đặc biệt là
trong các dự án lớn.
Công cụ mã trung gian: các lớp biên dịch là công cụ, bằng việc thêm vào
bytecodes mới thì các lớp công cụ mới cũng được tạo ra.
Thu thập thông tin thực thi: phương pháp này thu thập thông tin từ môi trường
thực thi khi code thi hành để xác định thông tin bao phủ.
2.4. Trong tiến trình test thì bao phủ code hợp với kỹ thuật kiểm thử nào ?
2.4.1 Kiểm thử hộp đen
Kiểm thử hộp đen là sự kiểm thử sử dụng các ca kiểm thử được thiết kế dựa trên
đặc tả yêu cầu, tài liệu người dùng nhằm mục đích phát hiện ra các khiếm khuyết. Kiểm
thử hộp đen nhìn nhận mô đun (module) được kiểm tra như là một hộp đen, và chỉ quan
tâm đến chức năng (hành vi) của mô đun (module), tức là kiểm tra xem có hoạt động
đúng với đặc tả hay không. Các ca kiểm thử bao gồm các trường hợp bình thường và
không bình thường (dữ liệu không hợp lệ…) của mô đun[4].
2.4.2 Kiểm thử hộp trắng
Kiểm thử hộp trắng là sự kiểm thử dựa trên việc phân tích chương trình để xác
định các ca kiểm thử. Kỹ thuật chính ở đây là phân tích mã nguồn, xác định các luồng
điều khiển từ input đến output. Dựa trên việc xác định các đường đi người ta đưa ra các
ca kiểm thử nhằm mục đích kiểm tra tất cả các đường đi có thể. Tức là đảm bảo mọi tổ
hợp hai lệnh liên tiếp đều được thực hiện ít nhất một lần trong một ca kiểm thử nào đó.
Việc xác định các đường đi dựa trên việc phân tích các cấu trúc rẽ nhánh và các vòng
lặp[5].
15
2.4.3 Bao phủ code
Từ những đặc điểm về kỹ thuật kiểm thử hộp đen và kiểm thử hộp trắng như
trên ta có thế nói bao phủ code là một phương pháp kiểm thử hộp trắng, bao phủ code
cần phải hiểu về mã nguồn, có thể truy cập vào mã nguồn hơn là đơn giản sử dụng các
giao diện được cung cấp. Có thế nói bao phủ code là phương pháp hữu ích nhất trong
suốt giai đoạn kiểm thử mô đun (module), tuy nhiên nó cũng có những lợi ích trong
kiểm thử tích hợp và trong các lần kiểm thử khác nữa, phụ thuộc vào chúng ta kiểm tra
cái gì và kiểm tra như thế nào. Kiểm thử đệ quy thường là kiểm thử hộp đen do đó có
thể không phù hợp với bao phủ code.
16
CHƯƠNG 3. GIỚI THIỆU MỘT SỐ PHƯƠNG PHÁP BAO PHỦ
3.1 Bao phủ câu lệnh (Statement coverage)
Bao phủ câu lệnh còn được gọi là bao phủ dòng lệnh (line coverage), là một cách
đo số câu lệnh được thực thi khi ta áp dụng những ca kiểm thử thích hợp. Đối với mỗi
câu lệnh không được bao phủ, chúng ta sẽ tìm hiểu nguyên nhân tại sao nó không được
bao phủ. Những câu lệnh không được thực thi thì công cụ bao phủ sẽ dùng cờ đánh dấu,
những câu lệnh được thực thi sẽ được xuất ra thành bản báo cáo. Đo câu lệnh được bao
phủ gần như được xem là cách thực thi đơn giản nhất, nó có thể áp dụng thông qua
bytecode. Bao phủ câu lệnh thường hay được những người phát triển sử dụng bởi vì nó
dễ dàng kết hợp với các dòng mã nguồn. Để có thể tiến hành phân tích kết quả test ta
cần tính tỉ lệ phần trăm câu lệnh đã được kiểm tra. Tính được phần trăm số câu lệnh
được bao phủ cần tiến hành hai phép đo cốt yếu đó là : tổng số các câu lệnh trong mã
nguồn và số câu lệnh đã được kiểm tra bởi test suite. Công thức tính phần trăm dòng
lệnh được thực thi [6]:
Số câu lệnh được kiểm tra
Phần trăm dòng lệnh =
* 100%
Tổng số câu lệnh mã nguồn
3.2 Bao phủ nhánh (Branch coverage)
Bao phủ nhánh còn được biết đến là bao phủ quyết định (Decision coverage).
Bao phủ nhánh là một phép đo dựa trên các điểm quyết định như là các điểm quyết định
trong câu lệnh rẽ nhánh if, while…Một ví dụ đơn giản về lệnh rẽ nhánh if :
if (a>b)
System.out.println( a);
else
System.out.println(b);
Báo cáo của cách bao phủ nhánh là báo ra các biểu thức boolean đã được kiểm
tra trong các cấu trúc điều khiển, đánh giá cả giá trị “true” và “false”. Chẳng hạn một
câu lệnh if(a>b) trong ví dụ trên sẽ chia chương trình thành 2 nhánh. Nếu muốn cả 2
nhánh đều được thực hiện thì cần phải có những test case để cho a > b trong câu lệnh
trên mang cả hai giá trị “true” và “false” tại hai thời điểm nào đó. Nhưng cũng có
17
trường hợp chỉ một ca kiểm thử mà a > b đã có thể mang cả hai giá trị, chẳng hạn nếu
câu lệnh này nằm trong một vòng lặp thì có thể trong một lần lặp nào đó ta có a > b
mang giá trị “true”, nhưng lần lặp sau thì a > b mang giá trị “false”.Công thức tính phần
trăm nhánh được bao phủ [6]:
Số nhánh được thực thi
Phần trăm nhánh được bao phủ =
*100%
Tổng số nhánh trong chương trình
3.3 Bao phủ đường đi (path coverage)
Một đường đi thể hiện một luồng việc thực thi từ khi bắt đầu đến khi kết thúc
một chương trình, một phương thức có N quyết định sẽ có 2N cách đi, và nếu phương
thức có vòng lặp thì có thể sẽ có vô số cách đi. Bao phủ đường đi cũng là một trong số
các cách đo trong kiểm thử hộp trắng, nó sẽ kiểm tra trong từng hàm xem các đường đi
có được kiểm tra hay không. Kỹ thuật chính ở đây là phân tích mã nguồn, xác định các
luồng điều khiển hay đường đi của chương trình từ input đến output. Dựa trên việc xác
định các đường đi người ta đưa ra các ca kiểm thử nhằm kiểm tra tất cả các đường đi có
thể. Việc xác định các đường đi dựa trên việc phân tích các cấu trúc rẽ nhánh và các
vòng lặp.
3.4 Bao phủ điều kiện (condition coverage)
Bao phủ điều kiện tương tự như bao phủ nhánh nhưng nó có độ nhạy tốt hơn với
luồng điều khiển. Bao phủ điều kiện đo các biểu thức con độc lập với các biểu thức con
khác. Bao phủ điều kiện báo cáo kết luận logic “true” hoặc “false” của từng biểu thức
boolean con, các biểu thức boolean con được phân tách bằng các phép logic-and và
logic-or nếu chúng xảy ra.
3.5 Bao phủ nhiều điều kiện (multiple condition coverage)
Bao phủ nhiều điều kiện là bao phủ kết hợp đồng thời các biểu thức boolean con
xảy ra. Giống với bao phủ điều kiện (condition coverage) các biểu thức con được phân
tách bằng các phép logic-and và logic-or.
18
CHƯƠNG 4. PHÂN TÍCH, ĐÁNH GIÁ CÁC PHƯƠNG PHÁP
BAO PHỦ
Chúng ta đề xuất một số phương pháp bao phủ code nhằm đánh giá được chất
lượng của ca kiểm thử. Để nhìn nhận bên trong mỗi hàm, và xác định những câu lệnh
nào được thực thi, những câu lệnh nào không được thực thi thì yêu cầu ta cần phải phân
tích bao phủ code. Phân tích code sẽ giúp ta: làm rõ những code không được thực thi
nhờ test suite. Thêm vào các ca kiểm thử để kiểm tra lại. Nhận ra code dư thừa. Khi
chương trình thiết kế thay đổi thường sẽ dẫn đến code dư thừa. Code dư thừa nên được
loại bỏ vì nó có thể gây khó hiểu cho công việc của người bảo trì. Phân tích code bao
phủ còn được sử dụng để theo dõi các phần code đặc biệt. Với việc đếm từng dòng
code, bản phân tích bao phủ còn được sử dụng để sắp xếp có thứ tự các khối cơ bản
trong một hàm. Thông qua phân tích bao phủ code sẽ làm giảm số lỗi. Bao phủ code
không phải là phương thuốc chữa bách bệnh, bao phủ code sẽ không giúp nhận dạng
các loại điều kiện, các vần đề về sử dụng bộ nhớ, con trỏ lỗi, thẩm định kết quả chương
trình. Phân tích bao phủ code luôn sẵn có trong nhiều ngôn ngữ lập trình phổ biến như
C++, nhưng chúng thường là các sản phẩm thứ ba được tích hợp với bộ biên dịch, và
thường rất đắt. Như vậy phân tích bao phủ code là quá trình tạo ra các ca kiểm thử để
tìm ra các vùng chưa được thực thi, tạo thêm các ca kiểm thử để tăng bao phủ và xác
định lượng code bao phủ sẽ gián tiếp đo chất lượng code. Dưới đây ta sẽ lần lượt phân
tích một số đề xuất bao phủ nhằm đưa ra để đánh giá chất lượng của ca kiểm thử: bao
phủ câu lệnh (statement coverage), bao phủ nhánh (branch coverage) và bao phủ đường
đi (path coverage) .
4.1 Phân tích phương pháp bao phủ câu lệnh (statement coverage)
Trong thiết kế test case ta luôn cố gắng bao phủ tối đa câu lệnh trong mã nguồn
với số test case ít nhất có thể. Bao phủ câu lệnh sẽ nhận ra các câu lệnh trong một
phương thức hay trong một lớp đã được thực thi. Đây là một phương pháp đo đơn giản
là tìm ra số câu lệnh đã được thực thi trong tổng số các câu lệnh mã nguồn [7]. Do đó
lợi ích của bao phủ câu lệnh là khả năng tìm ra các dòng code không được thực thi. Xét
một ví dụ đơn giản. Mã nguồn của chương trình như sau:
public class StatementCoverage {
public void FunctionPrint ()
{
19
System.out.println("This is example about statement coverage"); }
public static void main (String [] args)
{
StatementCoverage hi=new StatementCoverage();
hi.FunctionPrint(); }
}
Trong chương trình mã nguồn trên ta nhận thấy có :
o Số lớp : 1 lớp (lớp StatementCoverage).
o Số phương thức : 3 phương thức :
Main()
FunctionPrint()
Println()
o Số dòng lệnh : 6 dòng.
Sử dụng công cụ EMMA (open source) đo bao phủ dòng lệnh,(phần giới thiệu và
cách cài đặt công cụ EMMA sẽ được giới thiệu ở phần phụ lục) kiểm tra các dòng mã
nguồn đã được thực thi ta được báo cáo kết xuất như sau :
Hình 1 : Kết quả kiểm tra mã nguồn được thực thi
20
Kết quả kết xuất ở trên thông báo có số gói được tìm thấy là một, tổng số lớp có
trong chương trình là một, tổng số phương thức trong lớp là ba, tổng số file thực thi là
một và tổng số dòng đã thực thi là sáu. Với kết quả báo cáo như trên ta nhận thấy 100%
mã nguồn đã được thực thi.
Tuy nhiên bao phủ dòng lệnh có nhược điểm là không thể nhận ra các lỗi xảy ra
từ cấu trúc luồng điểu khiển trong mã nguồn như là khi ghép các điều kiện hay các nhãn
switch liên tiếp. Điều này có nghĩa là báo cáo bao phủ của ta vẫn sẽ kết suất ra kết quả
báo cáo là 100% code đã được bao phủ nhưng thực tế thì các lỗi đã không được bắt. Ví
dụ ta xét hàm returnInput() sau:
public int returnInput(int x, boolean condition1, boolean condition2, boolean
condition3)
{
if (condition1)
x++;
if(condition2)
x--;
if(condition3)
x=x;
return x;
}
Trong phương thức returnInput() ở trên có 7 câu lệnh trong nó. Kết quả mong
muốn là giá trị đầu ra bằng với giá trị đầu vào. Ta sẽ kiểm tra hoạt động của hàm trên
bằng cách thiết lập ca kiểm thử với các giá trị truyền vào hàm :
int x=1;
boolean condition1=true;
boolean condition2=true;
boolean condition3=true;
Chương trình mã nguồn đầy đủ :
public class Path {
public int returnInput(int x, boolean condition1, boolean condition2, boolean
condition3)
21
{if (condition1)
x++;
if(condition2)
x--;
if(condition3)
x=x;
return x;
}
public static void main (String [] args)
{int x=0;
boolean condition1=true;
boolean condition2=true;
boolean condition3=true;
Path constructorInstance=new Path();
int
methodReturn=constructorInstance.returnInput
(x,condition1,
condition2,condition3); } }
Kiểm tra các câu lệnh đã được thực thi ta được có kết quả báo cáo: tổng số gói là
1, tổng số lớp là 1, tổng số file là 1, tổng số phương thức là 3, tổng số dòng đã thực thi
là 16. Minh hoạ kết quả báo cáo bao phủ câu lệnh như sau.
22
Hình 2 : Kết quả đo bao phủ dòng lệnh
Kết quả nhận được là chương trình được bao phủ 100% nhưng thực tế rõ ràng đã
có một lỗi trong hàm returnInput(). Nếu ta đánh giá nhánh đầu tiên hoặc nhánh thứ hai
là “true” thì kết quả trả lại của hàm không như mong muốn, giá trị trả lại không bằng
với giá trị đầu vào. Lỗi này thật nguy hiểm, nếu người quản lý xem kết quả bao phủ
100%, quyết định việc test đã hoàn thành thì sản phẩm phát hành sẽ có lỗi.
Như vậy có thể nói bao phủ dòng lệnh không báo cáo về các vòng lặp tới các
điều kiện lặp, nó chỉ báo cáo phần thân của vòng lặp có được thực thi hay không. Với
ngôn ngữ C, C++ và Java thì hạn chế này ảnh hưởng tới các vòng lặp. Đối với vòng lặp
“do-while” khối lệnh sau “do” được thực hiện ít nhất một lần, bao phủ dòng lệnh xem
chúng giống với các câu lệnh không rẽ nhánh. Bao phủ câu lệnh không thể phân biệt
các nhãn switch liên tiếp[6]. Nhìn chung các ca kiểm thử tương thích với các nhánh hơn
là với các câu lệnh. Ta sẽ không thể tạo ra 10 ca kiểm thử riêng biệt cho 10 câu lệnh
không rẽ nhánh mà ta sẽ tạo ra một ca để kiểm tra chúng. Ví dụ : xem xét câu lệnh “if-
else”. Có một câu lệnh theo sau mệnh đề “if” và có 99 câu lệnh theo sau mệnh đề
“else”. Sau khi áp dụng một trong hai đường đi có thể, bao phủ cậu lệnh cho ta kết quả
bao phủ hoặc 1% hoặc là 99 %. Bao phủ câu khối lệnh thường lờ đi vấn đề này. Trước
những hạn chế của bao phủ câu lệnh ta có thể tìm đến một kỹ thuật bao phủ khác tốt
hơn đó là bao phủ nhánh.
4.2 Phân tích phương pháp bao phủ nhánh (branch coverage)
Một nhánh là một kết luận logic của một quyết định, do vậy bao phủ nhánh đơn
giản là đo kết luận logic nào đã được kiểm tra. Phương pháp bao phủ này xem xét mã
nguồn sâu sắc hơn là phương pháp bao phủ câu lệnh. Xác định số nhánh có trong một
phương thức là một việc dễ làm. Kết luận kiểu boolean hiển nhiên có hai kết luận logic
là “true” hoặc “false” do đó chương trình có N quyết định sẽ có 2N nhánh. Phương pháp
bao phủ nhánh vẫn có những đơn giản như ở bao phủ câu lệnh tuy nhiên nó đã loại bỏ
được một số hạn chế có ở bao phủ câu lệnh. Tổng số quyết định tác động lên một
phương thức bằng với tổng số nhánh cần được bao phủ và nhánh entry trong phương
thức. Quay trở lại với ví dụ :
public class Path {
public int returnInput(int x, boolean condition1, boolean condition2, boolean
condition3)
23
{
if(condition1)
x++;
if(condition2)
x--;
if(condition3)
x =x;
return x; } }
Trong ví dụ này ta sẽ có 7 nhánh: 3 nhánh “true”, 3 nhánh “false” và một nhánh
entry. Nhận thấy rằng để bao phủ 7 nhánh này ta chỉ cần đến 2 test case như sau :
Test case 1 :
public void testReturnInputIntBooleanBooleanBoolean_Path1(){
int x=0;
boolean condition1=true;
boolean condition2=true;
boolean condition3=true;
Path contructorInstance=new Path();
Int methodReturn= constructorInstance.returnInput(x, condition1,
condition2,condition3);
}
Test case 2 :
public void testReturnInputIntBooleanBooleanBoolean_Path2(){
int x=0;
boolean condition1=false;
boolean condition2=false;
boolean condition3=false;
Path contructorInstance=new Path();
24
int methodReturn= constructorInstance.returnInput(x, condition1,
condition2,condition3);
}
Biên dịch chương trình đầy đủ kiểm tra với test case 1
public class Path {
public int returnInput(int x, boolean condition1, boolean condition2, boolean
condition3)
{
if(condition1)
x++;
if(condition2)
x--;
if(condition3)
x=x;
return x;
}
public static void main(String []args)
{
int x=0;
boolean condition1=true;
boolean condition2=true;
boolean condition3=true;
Path constructorInstance=new Path();
int methodReturn= constructorInstance.returnInput(x, condition1,
condition2,condition3);
System.out.println("Ket qua mong doi : output value = input value");
System.out.println("output value :"+methodReturn);} }
Kết quả test 1:
25
Hình 3 : Kết quả thực hiện test case 1
Cho chạy qua công cụ đo bao phủ ta được kết quả
Hình 4 : Kết quả đo bao phủ nhánh khi thực hiện test case 1
Biên dịch và chạy chương trình đầy đủ với test case 2
public class Path {
public int returnInput(int x, boolean condition1, boolean condition2, boolean
condition3)
{
if(condition1)
x++;
if(condition2)
x--;
if(condition3)
x=x;
return x;
}
26
public static void main(String []args)
{
System.out.println("Test case : false-false-false");
System.out.println("Cac cau lenh trong cac dieu kien se khong duoc thuc thi");
int x=0;
boolean condition1=false;
boolean condition2=false;
boolean condition3=false;
Path constructorInstance=new Path();
int methodReturn= constructorInstance.returnInput(x, condition1,
condition2,condition3);
System.out.println("Ket qua mong doi : output value = input value");
System.out.println("output value :"+methodReturn); } }
Kết quả test 2:
Hình 5 : Kết quả khi thực hiện test case 2
Cho chạy qua công cụ bao phủ ta được kết quả :
Hình 6 : Kết quả đo bao phủ nhánh khi thực hiện test case 2
27
Với 2 test case như trên thẩm định cả yêu cầu giá trị output bằng với giá trị input và
100% nhánh đã được bao phủ. Nhưng dễ dàng nhận thấy ngay cả khi 100% nhánh được
bao phủ thì chương trình vẫn có lỗi được tìm ra. Trong ví dụ vừa đề cập, ta đã không
kiểm tra các trường hợp : TRUE-FALSE-TRUE hay FALSE-TRUE-TRUE…Với 3
quyết định trong một phương thức như trên ta sẽ có 2^3=8 quyết định. Kiểm tra 8 cách
đi là một điều dễ dàng, nhưng có những phương thức có rất nhiều quyết định thì số
đường đi sẽ tăng theo hàm mũ. Ví dụ một phương thức có tới 10 quyết định kiểu
boolean như vậy ta sẽ có 210=1024 cách đi. Lúc này để đạt được mục tiêu bao phủ
100% câu lệnh và 100% nhánh là điều vô cùng khó khăn và không khả thi cho những
phương thức phức tạp[11].
4.3 Phân tích phương pháp bao phủ đường đi (path coverage)
Một đường đi thể hiện một luồng thực thi từ khi bắt đầu đến khi kết thúc một
hàm. Một phương thức với N quyết định sẽ có 2^N đường đi, và nếu phương thức có
chứa vòng lặp thì có thể có vô số đường đi. Nhưng may thay, ta có thể sử dụng phương
pháp được gọi là Cyclomatic Complexity [3] để làm giảm số đưòng đi mà chúng ta cần
kiểm tra. Cysclomatic complexity của một phương thức là tổng số quyết định duy nhất
trong phương thức. Cysclomatic complexity giúp ta định nghĩa số tuyến tính các đường
độc lập, được gọi là các thiết lập cơ sở qua một phương thức. Các thiết lập cơ sở là các
thiết lập các đường đi một cách ít nhất có thể. Giống như bao phủ nhánh, kiểm tra các
đường thiết lập đảm bảo kiểm tra từng quyết định nhưng không giống như bao phủ
nhánh, bao phủ đường đi đảm bảo kiểm tra tất cả các quyết định tác động động lập với
nhau. Nói một cách khác, mỗi đường đi mới “flips” chính xác nhánh đã thực thi trước
đó, các nhánh còn lại khác không thay đổi. Đây là nhân tố chủ yếu làm cho bao phủ
đường đi mạnh mẽ hơn bao phủ nhánh, đồng thời nó còn cho phép ta nhìn nhận được
những thay đổi khi một nhánh tác động lên hoạt động của một phương thức. Ta vẫn sẽ
sử dụng ví dụ trong bao phủ câu lệnh và bao phủ nhánh để minh hoạ.
public class Path {
public int returnInput(int x, boolean condition1, boolean condition2, boolean
condition3)
{
if(condition1)
x++;
28
if(condition2)
x--;
if(condition3)
x =x;
return x; } }
Để đạt được bao phủ 100% đường đi, chúng ta cần định nghĩa các đường cơ sở.
Cysclomatic complexity của phương thức này là bốn, do vậy ta cần định nghĩa bốn
tuyến đường độc lập nhau. Để thực hiện công việc này ta sẽ chọn bất kỳ đường đầu tiên
làm đường cơ sở và sau đó sẽ lật các quyết định một lần cho tới khi ta có các đường
thiết lập cơ sở.
Path 1: Chọn các giá trị “true” cho các quyết định, biểu diễn là TTT. Đây là đường đầu
tiên trong thiết lập cơ sở của ta.
Path 2 : Ta sẽ tìm đường cơ sở tiếp theo, lật quyết định đầu tiên trong đường cơ sở, đem
lại giá trị FTT, giá trị ta mong muốn quyết định tác động.
Path 3 : Lật quyết định thứ 2 trong đường cơ sở, đem lại cho ta giá trị TFT
Path 4 : Cuối cùng, lật quyết định thứ 3 trong đường cơ sở, ta được đường thứ 4 với giá
trị TTF.
Vậy đã có 4 đường là : TTT, FTT,TFT và TTF. Tiếp theo đây ta sẽ xây dựng các ca
kiểm thử và xem điều gì xảy ra. Hai đường đi TTT và FFF đã được kiểm tra trong bao
phủ nhánh.Tiến hành kiểm tra đường đi FTT và TFT:
Test case 3: Kiểm tra FTT. Thực thi đoạn code sau :
public class Path {
public int returnInput(int x, boolean condition1, boolean condition2, boolean
condition3)
{
if(condition1)
x++;
if(condition2)
x--;
if(condition3)
29
x=x;
return x; }
public static void main(String []args)
{
System.out.println("Test case : false-true-true");
System.out.println("Cac cau lenh trong cac dieu kien 1 se khong duoc thuc thi");
int x=0;
boolean condition1=false;
boolean condition2=true;
boolean condition3=true;
Path constructorInstance=new Path();
int methodReturn= constructorInstance.returnInput(x, condition1,
condition2,condition3);
System.out.println("Ket qua mong doi : output value = input value");
System.out.println("output value :"+methodReturn); } }
Kết quả :
Hình 7: Kết quả thực hiện test case 3
Đo bao phủ code ta được kết quả :
30
Tải về để xem bản đầy đủ
59 trang
21/04/2025
100
Bạn đang xem 30 trang mẫu của tài liệu "Khóa luận Nghiên cứu về mức bao phủ của kiểm thử", để tải tài liệu gốc về máy hãy click vào nút Download ở trên.
File đính kèm:
- khoa_luan_nghien_cuu_ve_muc_bao_phu_cua_kiem_thu.pdf
