Vuong Thi Quynh Duong_K50CNPM_Khoa Luan Tot Nghiep Dai Hoc Dai Hoc

5/14/2018 Vuong Thi Quynh Duong_K50CNPM_Khoa Luan Tot Nghiep Dai Hoc Dai Hoc - slidepdf.com

http://slidepdf.com/reader/full/vuong-thi-quynh-duongk50cnpmkhoa-luan-tot-nghiep-dai-hoc-

1

ĐẠI HỌC QUỐC GIA HÀ NỘITRƯỜ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



2

ĐẠI HỌC QUỐC GIA HÀ NỘITRƯỜ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ậnCán bộ đồng hướng dẫn: ThS. Tô Văn Khánh

HÀ NỘI - 2009



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 để emcó 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ườnghay 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.

Mục lục

4



Vương Thị Quỳnh Dương ............................................................................................2CHƯƠNG 1. MỞ ĐẦU ..............................................................................................10

1.1 Bối cảnh nghiên cứu ..........................................................................................101.2 Nội dung bài toán ...............................................................................................111.3 Cấu trúc của khoá luận .....................................................................................12

CHƯƠNG 2. GIỚI THIỆU VỀ BAO PHỦ CODE ...................................................142.1 Bao phủ code là gì ? ...........................................................................................142.2 Tại sao cần đo lượng code được bao phủ ? ......................................................142.3 Làm thế nào để xác định lượng code được bao phủ ? .....................................152.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 ......................................................................................152.4.2 Kiểm thử hộp trắng ...................................................................................152.4.3 Bao phủ code ..............................................................................................16

CHƯƠNG 3. GIỚI THIỆU MỘT SỐ PHƯƠNG PHÁP BAO PHỦ .......................173.1 Bao phủ câu lệnh (Statement coverage) ...........................................................17

3.2 Bao phủ nhánh (Branch coverage) ...................................................................173.3 Bao phủ đường đi (path coverage) ...................................................................183.4 Bao phủ điều kiện (condition coverage) ...........................................................183.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Ủ ......... 194.1 Phân tích phương pháp bao phủ câu lệnh (statement coverage) ....................194.2 Phân tích phương pháp bao phủ nhánh (branch coverage) ...........................234.3 Phân tích phương pháp bao phủ đường đi (path coverage) ...........................28

............................................................................................................................. 32CHƯƠNG 5. PHÂN TÍCH GIÁ TRỊ ĐIỂM BIÊN ...................................................33

5.1 Giới thiệu ...........................................................................................................335.2 Phân hoạch tương đương(equivalence partitioning) .......................................335.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 .................................................345.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 ...............345.3.3 Phân tích giá trị biên đơn biến (Single-Variable BVA) ............................345.3.4 Phân tích giá trị biên đa biến (Multi – Variable BVA) ............................365.3.5 Kết luận ......................................................................................................40

CHƯƠNG 6. THỰC NGHIỆM ..................................................................................416.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 ...................................426.1.2 Kết luận ......................................................................................................45

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 ........................................................................466.2.2 Mô tả các chức năng chính .......................................................................466.2.3 Biểu đồ trình tự ...........................................................................................476.2.4 Thuật toán đã sử dụng ...............................................................................496.2.5 Các lớp cài đặt ............................................................................................51

5



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 ..............................................................................................................56CHƯƠ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 ................................................57TÀI LIỆU THAM KHẢO ...........................................................................................58

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.................................................20Hì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 .......................................................................25Hình 4 : Kết quả đo bao phủ nhánh khi thực hiện test case 1 .................................26Hình 5 : Kết quả khi thực hiện test case 2.................................................................27Hình 6 : Kết quả đo bao phủ nhánh khi thực hiện test case 2.................................27Hình 7: Kết quả thực hiện test case 3 ........................................................................30Hình 8 : Kết quả đo bao phủ khi thực hiện test case 3..............................................30Hình 9 : Kết quả thực hiện test case 4 .......................................................................31Hình 10 : Kết quả đo bao phủ khi thực hiện test case 4............................................32Hì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

.......................................................................................................................................35Hình 12 : Đường các giá trị baseline và robust cho đơn biến trên một khoảngđầu vào.........................................................................................................................35Hình 13 : Tập hợp các giá trị baseline và rubust trường hợp đơn biến trên haikhoảng đầu vào............................................................................................................36Hình 14 : Tập giá trị baseline và robust của biến N trong trường hợp hai biến đầuvào.................................................................................................................................37Hình 15 : Tập hợp giá trị baseline và rubust trên hai khoảng của biến M trongtrường hợp hai biến đầu vào.......................................................................................38Hì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

.......................................................................................................................................38Hình 17 : Tổng hợp toán bộ giá trị baseline, robust trường hợp đa biến đầu vàotrên hai khoảng............................................................................................................39Hình 18 : Ví dụ cấu trúc một chương trình đơn giản ...............................41Hì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................................................................42Hì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................................................................43Hình 23 : Hai điều kiện một và hai là độc lập nhau .................................................43Hì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:.......................................................44Hình 25 : Test case kiểm tra đồng thời công việc B và C..........................................44Hình 26 : Nhánh không được bao phủ.......................................................................45Hình 27. Biểu đồ trình tự............................................................................................47Hình 28: Biều đồ trình tự khi tương tác câu lệnh if..................................................48Hình 29: Biều đồ trình tự khi tương tác câu lệnh while...........................................48Hình 30: Biểu đồ trình tự khi tương tác câu lệnh for...............................................49Hình 31: Kiến trúc lớp cài đặt Get_File_Name ........................................................51Hình 32: Kiến trúc lớp ReadContentFile...................................................................51Hì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..............................................527



Hình 35: Nhập vào một tên file đúng để đọc ............................................................52Hình 36 : Nội dung của file TestFile.java..................................................................52Hình 37: Kết quả tìm kiếm câu lệnh điều khiển.......................................................53Hình 38 : Nội dung của file chứa câu lệnh điều khiển được tìm kiếm ...................53

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.....................55Hì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Ữ

Thuật ngữ Khái niệmStatement coverage Bao phủ câu lệnhBranch coverage Bao phủ nhánhPath coverage Bao phủ đường điCondition coverage Bao phủ điều kiệnBoundary value analysis(BVA) Phân tích giá trị biênSingle-variable BVA Phân tích giá trị biên đơn biếnMulti-variable BVA Phân tích giá trị biên đa biến

Equivalence partitioning Phân hoạch tương đươngTest case Ca kiểm thửValication Xác minhVerification Thẩm địnhTest entropy Kiểm tra độ bất định trong cấu trúc của hệ

thốngCyclomatic complextity Số đường độc lập tuyến tính đi qua mã

nguồnBaseline đường cơ sở

Robust 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ểntả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ửalỗ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,10



kiểm thử phần mềm có vai trò vô cùng quan trọng trong toàn bộ quy trình 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ầnmề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ườikiể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

11



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 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 thitrong 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 lệnh rẽ12



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á trị

14



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ỗicâ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ó trường hợp chỉ

17



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ó 2 N 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ÁPBAO 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 ()

{

System.out.println("This is example about statement coverage"); }19



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;



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;




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áccâ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ó 2 N 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 {


condition3)

{ if(condition1)23



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;




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();

int methodReturn= constructorInstance.returnInput(x, condition1,

condition2,condition3);

}24



Biên dịch chương trình đầy đủ kiểm tra với test case 1

public class Path {


condition3)

{ if(condition1)

x++;

if(condition2)

x--;

if(condition3)

x=x;return x;

}

public static void main(String []args)

{

int x=0;





int methodReturn= constructorInstance.returnInput(x, condition1,


System.out.println("Ket qua mong doi : output value = input value");System.out.println("output value :"+methodReturn);} }

Kết quả test 1:

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ả25



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 {


condition3)

{

if(condition1)

x++;

if(condition2)

x--;

if(condition3)

x=x;

return x;

}


{ 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;

26






Path constructorInstance=new Path();int methodReturn= constructorInstance.returnInput(x, condition1,


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 2Vớ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ậy27



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ộthà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++;

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ến28



đườ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 cakiể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 {


condition3)

{ if(condition1)

x++;

if(condition2)

x--;

if(condition3)

x=x;

return x; }


{ 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 condition2=true;29





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ả :

Hình 8 : Kết quả đo bao phủ khi thực hiện test case 3

Test case 4 : Kiểm tra TFT.Thực thi đoạn code sau :

public class Path {

public int returnInput(int x, boolean condition1, boolean condition2, booleancondition3)

{

if(condition1)

x++;

30



if(condition2)

x--;

if(condition3)

x=x;

return x; }


{

System.out.println("Test case : true-false-true");

System.out.println("Cac cau lenh trong cac dieu kien 2 se khong duoc thuc thi");

int x=0;





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 9 : Kết quả thực hiện test case 4

Đo bao phủ code ta được kết quả :

31



Hình 10 : Kết quả đo bao phủ khi thực hiện test case 4

Với kết quả của test case 3 và 4 ta nhận được lỗi chương trình, các lỗi này không

nhận ra trong bao phủ câu lệnh và bao phủ nhánh. Kết quả mong đợi của chương trình là

giá trị đầu vào và giá trị đầu ra phải bằng nhau. Ở đây giá trị đầu vào là 0 nhưng ta đã

nhận được giá trị đầu ra là +1 và -1, vậy là lỗi đã được tìm ra. Tổng số đường cơ sở sẽ

tăng theo số quyết định nhưng lúc này đã không tăng theo hàm mũ mà vẫn đảm bảo được

yêu cầu bao phủ đầy đủ các nhánh. Ta nhận thấy rằng bao phủ đường đi bao gồm cả bao

phủ câu lệnh và bao phủ nhánh trong phương thức. Nó tác động gộp lên cả bao phủnhánh và bao phủ câu lệnh. Ta luôn nhớ rằng, mục đích kiểm tra của các đường cơ sở là

để kiểm tra tất cả các nhánh tác động độc lập với nhau. Kiểm tra 4 đường cơ sở nhằm đạt

được mục đích này. Ta có thể xây dựng các đường đi hoàn toàn khác nữa, nếu ta bắt đầu

với đường cơ sở FFF sau đó tiến hành “flips” như đã làm ở trên ta sẽ thiết lập được 4

đường cơ sở hoàn toàn khác là : FFF, TFF, FTF,FFT. Kết quả của bộ 4 đường mới này

với bộ 4 đường ở trên là như nhau, đều thoả mãn tiêu chuẩn tác động độc lập lên các

quyết định. Qua đây dễ dàng nhận thấy với Cyclomatic complexity (số đường độc lập

tuyến tính đi qua mã nguồn) giúp ta giảm một nửa số test case cần tiến hành.

32



CHƯƠNG 5. PHÂN TÍCH GIÁ TRỊ ĐIỂM BIÊN

5.1 Giới thiệu

Trong nhiều chương trình có nhiều hàm có vô số giá trị đầu vào do đó việc kiểm

tra từng giá trị là vô cùng khó khăn, không khả thi. Nhưng trong vô vàn giá trị đầu vào đóta nên chọn giá trị nào là tốt nhất cho kiểm tra ? Lấy bao nhiêu giá trị kiểm tra là

đủ ?...Một kỹ thuật được đề xuất phục vụ cho việc lựa chọn giá trị kiểm tra đó là kỹ thuật

phân hoạch tương đương (equivalence partitioning) và phân tích giá trị điểm biên

(boundary value analysis), với kỹ thuật này giúp ta giảm đáng kể số ca kiểm thủ cần thực

hiện.

Phân tích giá trị điểm biên là một kỹ thuật phổ biến và quan trọng nhất trong việc

thiết kế các ca kiểm thử. Nếu như đo bao phủ code là một kỹ thuật trong kiểm thử hộptrắng thì phân tích giá trị điểm biên lại là một kỹ thuật kiểm thử hộp đen. Trong kiểm thử

hộp đen, các ca kiểm thử không tập trung vào cấu trúc thực bên trong logic chương trình

mà nó được lựa chọn dựa trên các chức năng mong muốn có trong sản phẩm như trong

tài liệu yêu cầu đã mô tả. Chúng ta kiểm tra chương trình có làm việc chính xác hay

không trong một vài trường hợp đặc biệt, các trường hợp đặc biệt thường là các giá trị

biên hoặc các giá trị vô cùng của biến đầu vào. Thông thường các lỗi chương trình

thường hay xảy ra ở giá trị biên. Phân tích giá trị biên thường được kết hợp với phân

hoạch tương đương (equivalence partitioning). Phân hoạch tương đương và phân tích giátrị biên có mối quan hệ chặt chẽ với nhau, luôn đi liền với nhau, đôi khi thật khó để phân

biệt các ca kiểm thử được tạo bởi hai kỹ thuật này. Nói chung giá trị biên được nhận

dạng là giá trị viền của các lớp phân hoạch tương đương. Để hiểu được giá trị biên trước

hết ta đi tìm hiều về phân hoạch tương đương.

5.2 Phân hoạch tương đương(equivalence partitioning)

Phân hoạch tương đương là một kỹ thuật kiểm thử hộp đen. Phân hoạch tương

đương xác định số ca kiểm thử cho từng trường hợp cụ thể. Nhìn chung dùng phân hoạch

tương đương nhằm mục đích :

• Giảm số ca kiểm thử

• Lựa chọn các ca kiểm thử chính xác để bao hàm các trường hợp có thể.

Phân hoạch tương đương chia miền dữ liệu vào ra thành các vùng, mỗi vùng chứa

các dữ liệu có cùng hành vi. Đối với mỗi vùng dữ liệu do dữ liệu có cùng hành vi nên ta

33



chỉ cần xây dựng một ca kiểm thử để đại diện. Giá trị bên trong một vùng dữ liệu được

xem là “tương đương” do đó số ca kiểm thử sẽ giảm xuống. Dải dữ liệu đầu vào bao gồm

dải hợp lệ và dải không hợp lệ.

Ta có ví dụ : truyền tham số tháng cho ngày. Trong ví dụ này ta có các dải giá trị

hợp lệ và không hợp lệ như sau: Dải giá trị hợp lệ cho tháng là từ 1 đến 12 tương ứng từtháng 1 đến tháng 12, có hai dải giá trị không hợp lệ đó là nhỏ hơn hoặc bằng 0 và lớn

hơn hoặc bằng 13. Với 3 dải dữ liệu này sẽ có 3 ca kiểm thử được dề xuất tương ứng với

3 dải.

Phân hoạch tương đương không đơn thuần là phương pháp xác định các ca kiểm

thử một các đầy đủ. Kết hợp với phân tích các giá trị biên giới giữa các vùng, ta sẽ thêm

vào các ca kiểm thử ở giá trị biên, từ đó tìm ra các ca kiểm thử hiệu quả nhất cho từng

vùng[12].

5.3 Phân tích giá trị biên (boundary value analysis)

5.3.1 Tổng quan về phân tích giá trị điểm biên

Phân tích giá trị biên là một kỹ thuật thiết kế ca kiểm thử và được sử dụng để chỉ

ra dữ liệu kiểm tra từ đó xây dựng các ca kiểm thử. Theo kinh nghiệm, đa phần các sai

sót về lập trình thường xảy ra đối với các dữ liệu biên, những nơi diễn ra tính toán cơ học

hoặc sự thao tác dữ liệu phải thay đổi cho hợp lý để chương trình xuất ra kết quả chính

xác. Ý tưởng của phân tích giá trị biên là sử dụng giá trị biến đầu vào ở các vị trí : giá trị

nhỏ nhất, giá trị lớn nhất, giá trị ngay bên trong biên, giá trị ngay bên ngoài biên, giá trị

đại điện thông thường, và các giá trị lỗi. Kết quả mong đợi là khi chương trình làm việc

chính xác với các giá trị đặc biệt này thì nó sẽ làm việc chính xác với các giá trị thông

thường bên trong miền giá trị. Để kiểm tra một phương thức nào đó việc đầu tiên ta phải

xác định dải dữ liệu hợp lệ và không hợp lệ đầu vào cùng với các điều kiện cho chức

năng được xét[10].

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

Thiết lập các ca kiểm thử được chỉ ra bởi phân tích giá trị điểm biên phụ thuộc

vào cả sự yêu cầu về tính tin cậy của phần mềm và cả những giả thuyết có thể xảy ra

trong quá trình kiểm soát lỗi. Tiếp theo sau đây chúng ta sẽ thảo luận về phân tích giá trị

điểm biên của đơn biến (single-variable) và đa biến (multi-variable) dựa trên phân loại

phân tích giá trị biên.

5.3.3 Phân tích giá trị biên đơn biến (Single-Variable BVA)

34



Xem xét giá trị đầu vào để chỉ ra giá trị biên. Tất cả các giá trị biên này sẽ được

kết hợp chặt chẽ trong việc thiết lập các ca kiểm thử. Những giá trị gần biên sẽ được

thêm vào và sẽ được sử dụng để kiểm tra. Giá trị gần biên sẽ trợ giúp kiểm soát logic các

đường biên của chương trình. Ví dụ khi kiểm tra dải giá trị trong một nhánh hoặc câu

lệnh lặp người phát triển có thể sử dụng toán tử nhỏ hơn (<), toán tử nhỏ hơn hoặc bằng(≤ ), toán tử lớn hơn (>). Các đoạn code được biên dịch nhưng chạy không chính xác với

các điều kiện sẽ dẫn đến lỗi. Các giá trị gần giá trị biên phải có trong các ca kiểm thử để

kiểm tra các loại lỗi này [4].Trong các ca kiểm thử thêm vào đường biên các giá trị gần

biên, quá trình phân tích giá trị biên baseline sẽ gồm một vài giá trị đầu vào tồn tại trên

danh nghĩa. Ví dụ sau sẽ minh hoạ cho quá trình phân tích giá trị biên baseline: Xem xét

chương trình với một giá trị đầu vào N, dải giá trị của N là : a ≤ N ≤ c. Các ca kiểm thử

được chọn trong tập hợp giá trị baseline ={a, a+, b, c-, c}. a+ là giá trị lớn hơn a, c- là giá

trị nhỏ hơn c và b là một giá trị tồn tại trên danh nghĩa, b nằm trong khoảng a+ và c-.

Trong ví dụ này, quá trình phân tích giá trị biên baseline sẽ chỉ ra năm ca kiểm thử. Minh

hoạ bằng hình bên dưới.

baseline

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

Nếu như quản lý lỗi là một việc then chốt sau khi kiểm tra phần mềm thì cần phảităng thêm các ca kiểm thử kiểm tra một cách mạnh mẽ thông qua quá trình phân tích giá

trị biên baseline, cần thêm vào các giá trị bên ngoài dải cho phép. Các ca kiểm tra

baseline được chỉ ra ở trên sẽ được thêm vào giá trị {a-,c+}, giá trị a- là giá trị bên dưới

giá trị chấp nhận a và c+ là giá trị ngay trên giá trị chấp nhận c. Cả hai giá trị {a-,c+}

dùng trong các ca kiểm thử cần phải được thực thi để xử lý trường hợp ngoại lệ hoặc để

che dấu khuyết điểm code. Quay trở lại với ví dụ trên giá trị đầu vào đơn lúc này sẽ gồm

bẩy giá trị hết sức mạnh mẽ: robust={a-, a, a+, b, c-, c, c+}. Minh hoạ bằng hình bên

dưới :

baseline robust

Hình 12 : Đường các giá trị baseline và robust cho đơn biến trên một khoảng đầu vào

35



Quá trình phân tích giá trị biên baseline hay quá trình phân tích biên rubust đều có

thể được áp dụng cho giá trị đầu vào có nhiều dải giá trị. Xem xét biến đầu vào đơn M

với hai dải giá trị con liền nhau, dải 1 được là d ≤ M < f và dải 2 là f ≤ M ≤ h. Thiết lập

các ca kiểm thử lúc này là kết hợp tất cả các ca kiểm thử được chỉ ra khi cách áp dụng

quá trình phân tích giá trị biên đối với từng dải giá trị riêng lẻ. Do vậy kết hợp kết quả tấtcả các ca kiểm thử áp dụng cho từng dải riêng rẽ ta được :

Mbaseline= {d, d+, e, f-, f} {f, f+, g, h-, h}∪

= {d, d+, e, f-, f, f+, g, h-, h}

Áp dụng phân tích giá trị biên robust làm M baseline tăng thêm các giá trị {d-, h+} mang lại

kết quả Mrobust = {d-, d, d+, e, f-, f, f+, g, h-, h, h+} được minh hoạ bằng hình bên dưới

baseline robust augmentation

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

Thêm vào nhiều dải giá trị con hiển nhiên sẽ làm tăng số ca kiểm thử. Đối với hai dải giá

trị liền nhau của một biến đầu vào, phân tích giá trị biên baseline chỉ ra 9 ca kiểm thử và

phân tích giá trị biên rubust chỉ ra 11 ca kiểm thử.5.3.4 Phân tích giá trị biên đa biến (Multi – Variable BVA)

Đối với bài toán đa biến quá trình phân tích giá trị biên lựa chọn ca kiểm thử cần

phải xem xét lỗi có thể xảy ra, trong bài viết này ta sẽ đề cập đến lỗi tại biên với đa biến

đầu vào là một kiểu lỗi (ta sẽ gọi là multiple-fault). Đối với kiểu lỗi multiple-fault [4]

được cho rằng nhiều lỗi đồng thời xảy ra, do vậy ta sẽ thêm vào các ca kiểm thử để soát

lỗi trên đồng thời nhiều biến.

Lấy ra từ ví dụ đơn biến ở trên, xét bài toán với hai biến đầu vào N và M, với dảigiá trị của N: a ≤ N ≤ c và giá trị của M trải dài trên hai dải, dải #1:d ≤ M < f , dải #2: f

≤ M ≤ h. Như dã thảo luận ở trên, các ca kiểm thử đơn biến đã chỉ ra đối với N và M là :

Nbaseline= {a, a+, b, c-, c}

Mbaseline= {d, d+, e, f-, f, f+, g, h-, h}

Các ca kiểm thử phân tích giá trị biên đa biến sử dụng cách phân tích các đường

biên của một biến trong khi các biến khác được giữ là một giá trị danh nghĩa. Hợp tất cả

36



các ca kiểm thử áp dụng cho từng biến đầu vào ta được tập các ca kiểm thử áp dụng cho

đa biến đầu vào. Trong ví dụ trên ta sẽ áp dụng cho từng biến đầu vào trên từng dải giá trị

con. Bài toán có hai giá trị đầu vào, các ca kiểm thử sẽ gồm các cặp giá trị đầu vào (m,n)

trong đó n là thành phần của Nbaseline và m sẽ là thành phần của M baseline .

Quan sát sơ đồ dưới đây :

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

Trong hình biểu diễn trên ta biểu diễn giá trị m thay đổi(m thay đổi trong miền

M baseline), tại dải thứ nhất (d≤ m <f) m được biểu diễn bằng giá trị e, tại dải thứ hai (f ≤ m

≤ h) m được biểu diễn bằng g, giữ nguyên giá trị n, n được biểu diễn bằng giá trị b. Quan

sát sơ đồ ta nhận thấy có 9 ca kiểm thử được chỉ ra, tương ứng với các giá trị giao điểm

của đường thẳng qua b và giao với các đường trong miền giá trị thay đổi của m.

Tiếp theo cố định giá trị m tại hai dải giá trị, cho n thay đổi trong miền N baseline, biểu diễn

n bằng giá trị b, (a≤ b ≤ c). Quan sát sơ đồ biểu diễn dưới đây :

37



Hình 15 : Tập hợp giá trị baseline và rubust trên hai khoảng của biến M

trong trường hợp hai biến đầu vào

Trong trường hợp này ta nhận được 10 ca kiểm thử.

Tổng hợp cả 2 trường hợp ta nhận được sơ đồ sau :

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

Trường hợp 1 cho ta 9 ca, trường hợp 2 cho ta 10 ca, tổng hợp cả 2 trường hợp cho ta 19

ca, nhưng tại các vị trí (e,b) và (g,b) được lặp lại 2 lần, nên tổng cả 2 trường hợp ta có 17

ca kiểm thử.

38



Đối với việc kiểm tra mạnh mẽ (rubustness), áp dụng cách thức như ta đã làm với

từng biến trước đó, kết quả đã được chỉ ra trong Mrubust và Nrubust. Lưu ý rằng trong quá

trình phân tích baseline với từng biến thì đồng thời 6 giá trị rubust cũng đã được chỉ ra

(quan sát trên hình vẽ). Như vậy đến thời điểm này ta đã có tổng số 23 ca kiểm thử tất cả.

Các ca kiểm thử trên dải giá trị không hợp lệ cần phải được lựa chọn để kiểm soát đồngthời với cả hai biến. Quá trình phân tích giá trị biên multiple-fault sẽ được bắt đầu với tập

hợp giá trị trong M baseline và N baseline trong trường hợp các đường biên không được kiểm tra,

còn trong trường hợp việc kiểm tra các đường biên được ưu tiên cao thì ta sẽ sử dụng với

tập giá trị Mrubust và Nrubust . Tương ứng với hai trường hợp vừa nêu ta có ước lượng tích

đề-các (cartesian) M baselien x N baselien xác định số ca kiểm thử cho baseline multiple-fault,

và tích đề các Mrubust x Nrubust xác định số ca kiểm thử cho rubust multiple-fault.

Với hai tập giá trị M và N, tích đề-các của M và N được định nghĩa là :M x N = {(m,n) | m ε M^n ε N}

M x N là tập tất cả các cặp phần tử (m,n) được lấy ra từ tập M và tập N. Do đó, nếu tập

M có x phần tử và tập N có y phần tử, kết quả của tập M x N sẽ gồm x * y phần tử.

Trở lại bài toán ví dụ, hình dưới đây sẽ biểu diễn tổng hợp các ca kiểm thử phân tích giá

trị biên baseline và rubust được chỉ ra cho kiểu lỗi multiple-fault của bài toán.

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



Số lượng các ca kiểm thử tăng lên đáng kể, 45 ca baseline được chỉ ra và trong trường

hợp xấu nhất (worst-case) được thêm 32 ca rubust.

Tổng hợp các ca kiểm thử cho bài toán 2 biến với các mức yêu cầu về tính tin cậy ta có

bảng như sau :

Bảng 1 : Tổng hợp các ca kiểm thử theo mức tin cậy .

Nhận thấy rằng, giả thuyết tình huống bài toán có nhiều lỗi đồng thời xảy ra cùng một lúc

đã dẫn đến khá nhiều ca kiểm thử, đặc biệt nếu như bài toán xét trên nhiều dải giá trị thì

số lượng ca kiểm thử tăng lên là đáng kể.5.3.5 Kết luận

Từ những phân tích đã trình bày rõ ràng phân tích giá trị điểm biên có nhiều ưu

điểm quá trình phân tích giá trị điểm biên để chỉ ra các kiểm tra là một việc dễ sử dụng,

thậm chí có các giá trị biên đầu vào còn được mô tả một cách rõ ràng trong tài liệu yêu

cầu. Với phân tích giá trị biên, ta có thể điều chỉnh số ca kiểm thử do đó tài nguyên được

sử dụng cho nghiên cứu còn phụ thuộc vào đòi hỏi về tính chất mạnh của phần mềm.

Phân tích giá trị biên có lợi cho sự bắt đầu các kỹ thuật kiểm thử khác. Tài liệu thảo luậnvề phân tích giá trị biên thường hoà lẫn và có liên hệ với kỹ thuật kiểm thử hộp đen phân

hoạch tương đương.

Tuy nhiên phân tích giá trị điểm biên có thể ảnh hưởng tới việc nhận ra các lỗi. So

với việc kiểm tra giá trị ngẫu nhiên và giá trị phân hoạch tương đương thì phân tích giá

trị biên có số lần kiểm tra nhiều hơn 6 lần so với kiểm tra ngẫu nhiên và gấp 2 lần so với

kiểm tra theo phân hoạch tương đương. Giá cả để kiểm tra cũng tăng theo số ca kiểm thử.

Kỹ thuật phân tích giá trị biên cung cấp một quá trình có hệ thống cho việc đánhgiá mức độ hoàn thành và chất lượng của sản phẩm phần mềm. Đôi khi bằng cách phân

tích giá trị biên ta có thể tìm ra các ca kiểm thử dư thừa trong tập hợp ca kiểm thử được

chỉ ra. Phân tích giá trị biên cung cấp nền tảng cơ bản cho việc học các kỹ thuật khác, cụ

thể là kỹ thuật phân hoạch tương đương, trong việc chỉ ra lỗi phân tích giá trị biên có

hiệu quả như một kỹ thuật kiểm tra chức năng.

40



CHƯƠNG 6. THỰC NGHIỆM

6.1 Ví dụ một chương trình đơn giản

Nếu ta biết cấu trúc của chương trình ta có thể thiết kế các ca kiểm thử đảm bảo

bao phủ : câu lệnh, nhánh, đường đi và bao phủ các điều kiện.

Chúng ta sẽ xem xét một chương trình với cấu trúc đơn giản, phân tích chương trình và

đề xuất các ca kiểm thử để đảm bảo toàn bộ câu lệnh, toàn bộ nhánh, toàn bộ luồng đi

qua chương trình đều được bao phủ. Chương trình có hai điều kiện, theo sau điều kiện

một sẽ có hai nhánh rẽ. Nếu điều kiện một là “true” sẽ thi hành khối lệnh A thực hiện

công việc A. Nếu điều kiện một là “false” sẽ thi hành khối lệnh B thực hiện công việc B.

Xét đến điều kiện hai, nếu điều kiện hai “true” sẽ thực hiện khối lệnh C, còn nếu điều

kiện hai “false” sẽ kết thúc chương trình Mô tả ví dụ bằng sơ đồ dưới đây.

Hình 18 : Ví dụ cấu trúc một chương trình đơn giản

Khi chạy các unit test ta mong muốn kiểm tra được tất cả các công việc trong cáckhối lệnh trong chương trình. Cụ thể trong ví dụ đang xét cần phải kiểm tra việc thựchiện của các khối lệnh A, B, C xảy ra theo đúng điều kiện, khối lệnh trong từng công việc

phải hoạt động đúng. Hình vẽ sau mô tả nổi bật các công việc cần phải kiểm tra.

41



Hình 19 : Các công việc cần thực hiện (tô đậm)

6.1.1 Xây dựng các ca kiểm thử cho chương trình trên

Dựa vào cấu trúc của chương trình nguồn như trên đề xuất các ca kiểm thử kiểmtra code trong từng nhánh có được thực thi hay không.

Test case 1 :Công việc A được thực hiện khi điều kiện một “true” do đó để kiểm tra việc

thực thi công việc A chúng ta cần gán sao cho điều kiện một “true”.

Hình 20 : Test case 1 kiểm tra công việc A

Test case 2 :Khi điều kiện một “false” câu lệnh rẽ nhánh sẽ thực hiện công việc trong

khối lệnh B. Để kiểm tra việc thực thi công việc B ta cần gán cho điều kiện một là “false”

Hình 21 : Test case 2 kiểm tra công việc B

Tổng hợp lại đối với điều kiện một ta sẽ có hai ca kiểm thử để kiểm tra42



Testcase #1: Condition-1 là “true”.

Testcase #2: Condition-1 là “false“

Test case 3 :Xét đến điều kiện hai.Khi điều kiện hai là “true” thì khối lệnh C sẽ được

thực hiện. Do đó kiểm tra việc thực thi công việc C ta sẽ gán cho điều kiện 2 là “true”.

Hình 22 : Test case 3 kiểm tra công việc C

Testcase #3: condition-2 là “true”.

Để kiểm tra các công việc A, B, C ba test case đã được đề xuất. Tuy nhiên có thể

dễ dàng nhận thấy điều kiện 1 và là 2 bộ phận độc lập nhau.

Hình 23 : Hai điều kiện một và hai là độc lập nhau

Do đó bao phủ toàn bộ 3 công việc này ta chỉ cần dùng đến 2 test case là 100% câu lệnh

được bao phủ. Test case 1 kiểm tra đồng thời công việc A và công việc C

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

Test case 2 kiểm tra công việc B và công việc C:

Hình 25 : Test case kiểm tra đồng thời công việc B và C

Test case Condition - 1 Condition-2

#1 TRUE TRUE

#2 FALSE TRUE

Thiết kế 2 test case như trên thì 100% câu lệnh đã được kiểm tra. Mặc dù đã bao phủ 100% nhưng đã có một điều kiện không được bao phủ và một nhánh không được bao phủ. Cụ thể là trong điều kiện thứ 2 điều kiện “false” đã không được bao phủ. Và nhánhkhông được bao phủ là :

44



Hình 26 : Nhánh không được bao phủ

Thay một điều kiện của condition-2 là “false” ta được bảng tồng hợp các giá trị dùngtrong các ca kiểm thử như sau:

Test case Condition-1 Condition-2

#1 TRUE TRUE

#2 FALSE FALSE

Nếu xem như các biểu thức trong các điều kiện của ta là các biểu thức boolean

nguyên tử (tức là không chứa các phép toán logic như and, or, xor) thì lúc này ta nhậnthấy là toàn bộ nhánh và toàn bộ điều kiện đã được bao phủ.

Tuy nhiên mặc dù 100% câu lệnh và 100% nhánh đã được bao phủ thì vẫn có lỗiđược tìm ra. Chúng ta mới bao phủ được 2 đường đi, với 2 giá trị “true” “false” của haiđiều kiện. Tổ hợp các điều kiện với nhau ta có 4 cách đi có thể do đó sẽ có 4 ca kiểm thửđược đề xuất như sau :

Test case Condition-1 Condition-2

#1 TRUE TRUE#2 FALSE FALSE

#3 TRUE FALSE

#4 FALSE TRUE

6.1.2 Kết luận

45



Như vậy dựa vào việc phân tích từng mức bao phủ : bao phủ dòng lệnh, bao phủ

nhánh, bao phủ đường đi ta đã thiết kế được một bộ test case hoàn chỉnh, đảm bảo tất cả

các câu lệnh đã được kiểm tra, các nhánh, các đường đi có thể đều đã được bao phủ.

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.

Từ những phân tích về bao phủ code chúng tôi nhận thấy trong quá trình bao phủ

nhánh sẽ bao hàm kiểm tra bao phủ câu lệnh, đồng thời trong phương pháp bao phủ

đường đi tổ hợp các đường đi có thể cần dựa trên các nhánh rẽ trong chương trình. Bên

cạnh đó trong các câu lệnh điều kiện, câu lệnh lặp thường chứa các dải giá trị của biến

đầu vào. Do đó có thể nói việc nhận ra các câu lệnh rẽ nhánh, câu lệnh lặp là rất cần thiết.

Khi có tập các lệnh rẽ nhánh ta có thể tiến hành xây dựng các ca kiểm thử, dựa vào dải

giá trị trong nó ta có thể xác định giá trị biên cho biến đầu vào. Trong phần này chúng tôi

xây dựng chương trình tìm kiếm câu lệnh rẽ nhánh trong file nguồn java, chỉ ra giá trị

biên trong dải giá trị đầu vào của câu lệnh điểu khiển.

6.2.1 Giới thiệu về chương trình

Ngôn ngữ lập trình sử dụng : Java.

Công cụ lập trình sử dụng : eclipse.

Giao diện giao tiếp với người sử dụng qua màn hình console

6.2.2 Mô tả các chức năng chính

Cho phép người sử dụng nhập vào tên file cần đọc. Yêu cầu file đọc phải là file

có mở rộng *.java. Nếu người dùng nhập vào file không phải là file định

dạng .java chương trình sẽ hiển thị thông báo không phải là một file java.

Nhập vào tên file dùng để lưu câu lệnh điều khiển. Kiểm tra tên file vừa nhập

đã tồn tại hay chưa. Nếu tên file đã tồn tại yêu cầu người dùng phải nhập vàotên khác.

Chương trình xuất ra các thông báo nếu file được đọc thành công. Xuất ra tổng

số câu từng loại câu lệnh rẽ nhánh if, while, for đã tìm kiếm được.

Chương trình đưa ra lựa chọn hỏi người dùng có muốn tiếp tục thao tác. Nhập

vào “Yes’ để tiếp tục. Sau đó người dùng cần phải chọn loại câu lệnh rẽ nhánh

if hay while hay for để thao tác. Nhập vào tên file sẽ lưu những câu lệnh đó. Và

cuối cùng là chọn câu lệnh cần thao tác bằng cách nhập vào một số nguyên chỉ46



số thứ tự của câu lệnh. Chương trình sẽ xuất ra câu lệnh mà người dùng đã

chọn. Chỉ ra giá trị biên trong dải giá trị đầu vào.

6.2.3 Biểu đồ trình tự

Với các chức năng liệt kê ở trên trình tự tương tác giữa người dùng và hệ thống

như sau. Biểu đồ trình tự dưới đây mô tả tương tác của người dùng muốn tìm ra toàn bộcâu lệnh điểu khiển có trong file nguồn java, đếm từng loại câu lệnh điều khiển.

Hình 27. Biểu đồ trình tự

Biều đồ trình tự dưới đây thể hiện tương tác giữa người dùng và hệ thống khi

người dùng muốn thao tác trên từng câu lệnh if để chỉ ra giá trị biên của chính câu lệnh

đó

47



Hình 28: Biều đồ trình tự khi tương tác câu lệnh if

Biểu đồ trình tự dưới đây thể hiện tương tác giữa người dùng và hệ thống khi

người dùng muốn thao tác trên câu lệnh while và xuất ra giá trị biên của chính câu lệnh

đó.

Hình 29: Biều đồ trình tự khi tương tác câu lệnh while

48



Biểu đồ trình tự dưới đây thể hiện tương tác giữa người dùng và hệ thống khi

người dùng muốn thao tác trên câu lệnh for và xuất ra giá trị biên của chính câu lệnh đó

Hình 30: Biểu đồ trình tự khi tương tác câu lệnh for

6.2.4 Thuật toán đã sử dụng

Cài đặt chương trình thực hiện những chức năng trên chủ yếu dùng kiến thức về

java core. Sử dụng các thuộc tính và các phương thức của lớp vào ra chuẩn (java.io.*;) là

lớp (java.lang.String;).

Khi người dùng nhập vào tên file cần đọc, một đối tượng BufferedReader được

khởi tạo để lưu tên file nhập vào. Yêu cầu định dạng của file nhập vào phải là file *.java.

Kiểm tra phần mở rộng của file dùng hàm:

object. endsWith(“.java”)Yêu cầu tiếp theo người dùng cần nhập vào tên file sẽ lưu toàn bộ các câu lệnh

điều khiển của file cần đọc.

đối tượng BufferedReader để lưu tên file nhập vào

hàm createNewFile () để tạo file với tên vừa nhập

sử dụng boolean exist=fout.createNewFile() để kiểm tra tên file

vừa nhập vào đã tồn tại hay chưa.49



Đọc file : sử dụng các lớp FileInputStream, DataInputStream và

BufferedReader . Chúng tôi sẽ tiến hành đọc từng dòng trong file sử dụng hàm

readLine(). Duyệt toàn bộ file cho tới khi gặp dòng rỗng (null). Khi đọc từng dòng sẽ

tiến hành đọc từng ký tự lưu vào một mảng kiểu char (mảng token[]). Câu lệnh rẽ nhánh

if sẽ có dạng if(biểu thức logic boolean). Chúng tôi sẽ tiến hành so sánh phần tử thứ (i)trong mảng char token[], nếu như token[i] = = ‘i’ và token[i+1]= = ‘f’ thì sẽ thực hiện

vòng lặp để in cả câu lệnh if đó ra file lưu trữ. Để làm được điều này chúng tôi sử dụng

hàm charAt(i) để chuyển phần tử thứ (i) thành kiểu char, dùng đối tượng thuộc lớp

BufferedWriter để ghi ra file lưu trữ.Việc tìm kiếm câu lệnh while và for cũng tương tự

như thực hiện với câu lệnh if. Đối với câu lệnh while tiến hành so sánh nếu tất cả các

phần tử có dạng sau sẽ in ra câu lệnh while:

•

token[i]= = ‘w’• token[i+1]= = ‘h’

• token[i+2]= = ‘i’

• token[i+3]= = ‘l’

• token[i+4]= = ‘e’

Một dòng lệnh là câu lệnh for thì các phần tử trong dòng đang đọc phải có dạng như sau :

• token[i]= = ‘f’

• token[i+1]= = ‘o’

• token[i+2]= = ‘r’

Khai báo các biến đếm count_if, count_while, count_for, mỗi lần một câu lệnh điều khiển

được tìm thấy các biến đếm này sẽ được tăng lên một theo đúng loại câu if hay while hay

for.

Người dùng muốn tiếp tục thao tác. Cần phải nhập vào “Yes”, muốn thoát phải nhập vào“No”. Nếu xâu nhập vào là “Yes” sẽ thực thi khối lệnh tiếp theo: hỏi người dùng lựa

chọn loại câu lệnh điều khiển sẽ thao tác. Nếu người dùng muốn thao tác câu lệnh if thì

nhập vào if , khi muốn thao tác trên while nhập vào while và nếu là for thì cần nhập vào

for. Để biết người dùng đã nhập vào những lựa chọn nào sẽ dùng đến đối tượng lớp

BufferedReader để đọc, hàm so sánh xâu equals(String object) . Người dùng chọn câu

lệnh muốn thao tác bằng cách nhập vào một số nguyên (kiểu int). Để lấy ra đúng câu lệnh

50



là số thứ tự mà người dùng vừa nhập sẽ phải dùng đến đối tượng kiểu

LineNumberReader và gọi đến hàm getLineNumber().

Giá trị biên trong các dải giá trị của biến luôn nằm đằng sau các toán tử so sánh >, >=, <,

<= do đó thuật toán để lấy ra các giá trị biên trong các câu lệnh điều khiển sẽ là tiến hành

đọc qua file, đọc từng dòng một, xét câu lệnh đó có phải là câu lệnh điều khiển haykhông, nếu là câu lệnh điều khiển sẽ lấy ra xâu đằng sau các toán tử so sánh trên. Duyệt

qua file và đọc từng ký tự về cách làm tương tự như đã làm ở trên.

6.2.5 Các lớp cài đặt

Cài đặt lớp để lấy tên file cần đọc do người dùng nhập vào

Hình 31: Kiến trúc lớp cài đặt Get_File_Name

Cài đặt lớp ReadContenFile thực thi các chức năng của chương trình

Hình 32: Kiến trúc lớp ReadContentFile.

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



Giao diện yêu cầu nhập tên file cần đọc

Hình 33: Giao diện yêu cầu nhập tên file cần đọc

Nhập vào một file không phải là định dạng *.java, hệ thống sẽ xuất ra thông báo “This is

not a java file” đây không phải là một file java.

Hình 34: Nhập tên file không đúng định dạng *.java

Nhập vào một tên file đúng để đọc, chúng tôi thử nghiệm bằng cách đọc file“TestFile.java”.

Hình 35: Nhập vào một tên file đúng để đọc

Nội dung bên trong của file đã sử dụng (file TestFile.java) như sau

Hình 36 : Nội dung của file TestFile.java

52



Sau khi nhập vào tên file cần đọc, hệ thống sẽ yêu cầu nhập vào một tên file đểlưu toàn bộ câu lệnh điều khiển của file cần đọc. Kết quả sau khi tìm kiếm câu lệnh điềukhiển như sau

Hình 37: Kết quả tìm kiếm câu lệnh điều khiển

Mở file ghi câu lệnh điều khiển, nội dung file như sau

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



Sau khi tìm kiếm câu lệnh điều khiển, hệ thống sẽ hỏi người dùng có muốn tiếp

tục thao tác. Để tiếp tục thao tác người dùng phải nhập vào “Yes”. Có ba lựa chọn cho

người dùng, nhập vào “if” để thao tác với câu lệnh if, nhập vào “while” để thao tác với

câu lệnh while, nhập vào “for” để thao tác với câu lệnh for. Nhập vào tên file để lưu toàn

bộ lệnh điều khiển đã chọn. Sau đó người dùng phải nhập vào một số nguyên để chọncâu lệnh cần thao tác. Ví dụ khi muốn thao tác với câu lệnh if số “2” thì sẽ phải nhập vào

“2”. Kết quả khi người dùng tiếp tục muốn thao tác với câu lệnh if.

Hình 39 : Kết quả khi người dùng muốn thao tác với câu lệnh if

Trong tương tác trên, người dùng đã chọn câu lệnh điều khiển if để thao tác, dùngfile “if_save.txt” để lưu toàn bộ câu lệnh if trong đó. Nhập vào số nguyên “2” để thao tác

với câu lệnh if số 2. Hệ thống xuất ra nội dung của câu lệnh là “if(a>b)”. Giá trị biên

được chỉ ra ở đây là “b”.

Các thao tác cũng làm tương tự như câu lệnh if khi người dùng muốn thao tác trên lệnh

while. Kết quả khi người dùng tiếp tục muốn thao tác với câu lệnh while như sau.

54



Hình 40 : Kết quả khi người dùng muốn thao tác với câu lệnh while

Trong tương tác trên người dùng chọn tương tác với câu lệnh “while”, dùng file“while_save.txt” để lưu toàn bộ câu lệnh while, nhập vào số nguyên “3” để thao tác với

câu lệnh while số 3. Nội dung của câu lệnh while này là “while(a>b)”. Giá gị biên được

chỉ ra ở đây là “b”.

Các thao tác cũng làm tương tự như câu lệnh if khi người dùng muốn thao tác trên lệnh

for. Kết quả khi người dùng tiếp tục muốn thao tác với câu lệnh for

Hình 41 : Kết quả khi người dùng muốn thao tác với câu lệnh for

Trong tương tác trên, người dùng chọn tương tác với câu lệnh “for”, dùng file

“for_save.txt” để lưu toàn bộ câu lệnh for, nhập vào số nguyên “2” để thao tác với câu

lệnh for số 2. Nội dung của câu lệnh for này là “for(int i=0;a>121313;i++)”. Giá trị biên

được chỉ ra ở đây là “121313”.

55



6.3 Kết luận

Như vậy chúng tôi đã cài đặt thành công chương trình tìm kiếm toàn bộ câu lệnh

điểu khiển trong một file java bất kỳ. Xuất ra được giá trị biên trong các biểu thức đánh

giá của dải giá trị đầu vào. Danh sách những câu lệnh điều khiển này sẽ được dùng vào

mục đích tạo ra các ca kiểm thử nhằm đặt tới mục tiêu thiết kế các ca kiểm thử đủ tốt để

bao phủ tối đa mã nguồn. Chỉ ra giá trị biên giúp cho người kiểm tra đề xuất các giá trị

kiểm tra baseline và robust.

56



CHƯƠNG 7: KẾT LUẬN KHOÁ LUẬN

7.1 Kết luận về khoá luận

Trong quá trình thực hiện khoá luận này, chúng tôi đã tìm hiểu những kiến thức cơ

bản về kiểm thử phần mềm, giai đọan vô cùng quan trọng giúp phát triển và sửa lỗi nhằmđảm bảo chất lượng phần mềm. Đồng thời, chúng tôi đã nghiên cứu, phân tích hai kỹ

thuật phục vụ cho việc thành lập các ca kiểm thử tốt. Một kỹ thuật thuộc về kiểm thử hộp

trắng là : phân tích bao phủ code và một kỹ thuật thuộc về kiểm thử hộp đen là : phân

tích giá trị điểm biên. Trong phần phân tích về kỹ thuật bao phủ code chúng tôi đã chỉ ra

những ưu nhược điểm của các phương pháp bao phủ cơ bản là : bao phủ dòng lệnh, bao

phủ nhánh và bao phủ đường đi. Nhìn chung phương pháp bao phủ đường đi đã bao gồm

cả 2 phương pháp bao phủ câu lệnh và bao phủ nhánh. Với kỹ thuật phân tích bao phủ

code đòi hỏi chúng ta phải tìm hiểu sâu sắc về mã nguồn. Thiết kế các ca kiểm thử thích

hợp để tìm ra những dòng lệnh không được thực thi, những dòng lệnh dư thừa. Quá trình

này là một vòng lặp: từ kết quả của ca kiểm thử ta có thể đánh giá được mã nguồn, đồng

thời đánh giá được ca kiểm thử vừa xây dựng đã tốt, đã tối ưu hay chưa từ đó xây dựng

ca kiểm thử tiếp theo hay hơn, có mức bao phủ code nhiều hơn. Với việc phân tích giá trị

điểm biên chúng tôi cũng đã chỉ ra những giá trị cần phải được kiểm tra trong dải giá trị

đầu vào của các biến. Để khắc phục những sai sót về lập trình xảy ra tại những điểm biên

cần phải tiến hành các ca kiểm thử kiểm tra tập giá trị baseline và robust.Tuy nhiên, hai kỹ thuật đề xuất này cũng gặp phải những khó khăn. Với những

phương thức phức tạp với nhiều câu lệnh rẽ nhánh, nhiều biểu thức logic trong từng câu

lệnh rẽ nhánh thì số ca kiểm thử thiết kế để đảm bảo bao phủ 100% là một con số vô

cùng lớn, và đôi khi ngay cả khi báo cáo 100% code được bao phủ nhưng trên thực tế vẫn

có lỗi được tìm ra. Do đó bên cạnh kỹ thuật phân tích bao phủ code chúng ta cần phải

tiến hành các phương pháp kiểm thử khác, kiểm thử các mức khác nhau để sớm tìm ra

lỗi. Trong kỹ thuật phân tích giá trị điểm biên cũng gặp phải những khó khăn như nếu biến đầu vào có nhiều dải giá trị thì số lượng các ca kiểm thử robust cũng tăng lên đáng

kể. Và trước khi tiến hành phân tích giá trị điểm biên ta phải tiến hành phân hoạch tương

đương miền giá trị đầu vào, việc phân hoạch này không phải lúc nào cũng chính xác

tuyệt đối.

7.2 Hướng nghiên cứu phát triển trong tương lai

Từ những vấn đề còn tồn tại của khoá luận này, trong tương lai, chúng tôi sẽ tiếp

tục theo hướng nghiên cứu này nhằm xây dựng một công cụ đo bao phủ code cho ngôn57



ngữ java. Bên cạnh đó là xây dựng chương trình tự động tìm ra giá trị biên ngẫu nhiên

dùng trong các ca kiểm thử biên.

TÀI LIỆU THAM KHẢO

58



[1] Study of Average Error Rates for Censorware Programs – Bennett Haselton.

[2] Introduce to code coverage –Lasse K oskela Accenture Technology Solutions -2004

[6] Statement Coverage & Decision Coverage – Shailaja Kiran

[7] Statement, Branch, and Path Coverage Testing in Java – Joe Ponczak

[4] A Review of Boundary Value Analysis Techniques Dr. David J. Coe, The University

of Alabama in Huntsville

[5] http:// www. Wikipedia. Org

[6] Measuring the multiple-condition converage with test suites for AspectJ programs –

Arnold Zanderink

[3] Beizer, B.(1990). Software Testing Techniques. Boston, International Thompson

Comtuter Press.[4] Beizer, B.(1995). Black Box Testing. New York, John Wiley & Sons, Inc. IEEE(1987).

“ANSI/IEEE” Standard 1008-1987, IEEE Standard for Software Unit Testing.” IEEE

(1990). IEEE Standard 610.12 – 1990. IEEE Standard Glossary of Software Engineering

Terminology.

[5] Kaner, C., J. Falk, et al. (1999). Testing Computer Software. New York, Weley

Computer Publishing.

[10] Testing via Boundary Value Analysis – Craig Borysowich Chief Technology

Tactician.

[11] PathExpander: Architectural Support for Increasing the Path Coverage of Dynamic

Bug Detection - Shan Lu, Pin Xhou, Wei Liu, Yuanyuan Zhou and Josep Torrellas

Department of Computer Science.

[12] Equivalence partitioning and Boundary Value Analysis – IOTAP Quality Assurance

Team.

59

Documents

Vuong Thi Quynh Duong_K50CNPM_Khoa Luan Tot Nghiep Dai Hoc Dai Hoc