Khảo sát một số phương pháp sinh bộ kiểm thử trong kiểm thử hộp đen

Tuy nhiên, trong thực tế hiện nay, các công ty phần mềm thường tập trung nguồn lực vào kiểm thử hộp đen do kỹ thuật kiểm thử hộp trắng rất tốn kém vì liên quan đến phân tích mã nguồn và

MAI THỊ KIM OANH

KHẢO SÁT MỘT SỐ PHƯƠNG PHÁP SINH BỘ KIỂM THỬ TRONG KIỂM THỬ HỘP ĐEN

LUẬN VĂN THẠC SĨ

Hà Nội - 2011

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

MAI THỊ KIM OANH

KHẢO SÁT MỘT SỐ PHƯƠNG PHÁP SINH BỘ KIỂM THỬ TRONG KIỂM THỬ HỘP ĐEN

Chuyên ngành : CÔNG NGHỆ PHẦN MỀM

LUẬN VĂN THẠC SĨ NGƯỜI HƯỚNG DẪN KHOA HỌC: TS Phạm Ngọc Hùng

Hà Nội - 2011

Lời cảm ơn

Trước tiên tôi xin bày tỏ lòng biết ơn sâu sắc tới TS Phạm Ngọc Hùng, giảng viên

Bộ môn Công nghệ phần mềm - Khoa Công nghệ thông tin - Trường Đại học Công nghệ - ĐHQGHN Trong thời gian học và làm luận văn tốt nghiệp, thầy đã dành nhiều thời gian quý báu và tận tình chỉ bảo, hướng dẫn tôi trong việc nghiên cứu, thực hiện luận văn Tôi xin được cảm ơn các GS, TS đã giảng dạy tôi trong quá trình học tập và làm luận văn Các thầy cô đã giúp tôi hiểu thấu đáo hơn lĩnh vực mà mình nghiên cứu để có thể vận dụng những kiến thức đó vào trong công tác của mình

Xin cảm ơn bạn bè, đồng nghiệp trong công ty đã tạo mọi điều kiện tốt nhất cho tôi trong suốt quá trình học tập và nghiên cứu để hoàn thành tốt bản luận văn tốt nghiệp này

Hà nội, tháng 5 năm 2011

Học viên thực hiện

Mai Thị Kim Oanh

LỜI CAM ĐOAN

Tôi xin cam đoan rằng, đây là kết quả nghiên cứu của tôi trong đó có sự giúp đỡ rất lớn của thầy hướng dẫn và các đồng nghiệp ở cơ quan Các nội dung nghiên cứu và kết quả trong đề tài này hoàn toàn trung thực

Trong luận văn, tôi có tham khảo đến một số tài liệu của một số tác giả đã được liệt kê tại phần tài liệu tham khảo ở cuối luận văn

Hà nội, tháng 5 năm 2011 Học viên thực hiện

Mai Thị Kim Oanh

MỤC LỤC

Lời cảm ơn ii

LỜI CAM ĐOAN iii

MỤC LỤC iv

BẢNG CÁC CHỮ VIẾT TẮT vi

DANH MỤC BẢNG VÀ HÌNH VẼ vii

Chương 1 Giới thiệu 1

1.1 Đặt vấn đề 1

1.2 Nội dung nghiên cứu 1

1.3 Cấu trúc luận văn 2

Chương 2 Tổng quan về kiểm thử phần mềm 3

2.1 Các khái niệm cơ bản về kiểm thử phần mềm 3

2.1.1 Định nghĩa kiểm thử phần mềm 3

2.1.2 Lý do kiểm thử phần mềm 3

2.1.3 Vai trò của kiểm thử phần mềm 4

2.1.4 Mục tiêu của kiểm thử phần mềm 4

2.2 Tiến trình thực hiện kiểm thử 4

2.3 Các phương pháp kiểm thử phần mềm 5

2.3.1 Kiểm thử hộp trắng 5

2.3.2 Kiểm thử hộp đen 6

2.4 Các cấp độ kiểm thử phần mềm 7

2.4.1 Kiểm thử đơn vị 8

2.4.2 Kiểm thử tích hợp 9

2.4.3 Kiểm thử hệ thống 11

2.4.4 Kiểm thử chấp nhận sản phẩm 12

Chương 3 Khảo sát các phương pháp sinh bộ kiểm thử 14

3.1 Phương pháp kiểm thử giá trị biên 14

3.1.1 Kỹ thuật cơ bản 14

3.1.2 Kiểm thử biên mở rộng 17

3.1.3 Kiểm thử trường hợp xấu nhất 18

3.1.4 Kết hợp kiểm thử trường hợp xấu nhất và kiểm thử biên mở rộng 19

3.1.5 Một số ví dụ về miền giá trị các kiểu biến 20

3.1.6 Nhận xét 22

3.2 Phương pháp kiểm thử dựa trên phân hoạch tương đương 23

3.2.1 Phân lớp tương đương yếu 25

3.2.2 Phân lớp tương đương mạnh 25

3.2.3 Phân lớp tương đương truyền thống 26

3.2.4 Nhận xét 27

3.3 Phương pháp kiểm thử dựa trên bảng quyết định 28

3.3.1 Định nghĩa bảng quyết định 28

3.3.2 Áp dụng bảng quyết định cho bài toán Tam giác 30

3.3.3 Áp dụng bảng quyết định cho bài toán Next Date 32

3.3.3.1 Phép thử đầu tiên cho bài toán NextDate 35

3.3.3.2 Phép thử thứ hai cho bài toán NextDate 36

3.3.3.3 Phép thử thứ ba cho bài toán NextDate 38

3.3.4 Nhận xét 42

3.4 So sánh các phương pháp 43

Chương 4 Ứng dụng 46

4.1 Đặc tả bài toán 46

4.2 Thiết kế ca kiểm thử cho bài toán có các biến độc lập 46

4.2.1 Bài toán 46

4.2.2 Áp dụng các phương pháp kiểm thử để sinh ca kiểm thử 47

4.2.2.1 Phương pháp phân tích giá trị biên cơ bản 47

4.2.2.2 Phương pháp phân tích giá trị biên mở rộng 49

4.2.2.3 Phương pháp phân lớp tương đương yếu 50

4.2.2.4 Phương pháp phân lớp tương đương mạnh 50

4.2.2.5 Phương pháp phân lớp tương đương truyền thống 51

4.3 Thiết kế ca kiểm thử cho bài toán có các biến phụ thuộc 54

4.3.1 Bài toán 54

4.3.2 Áp dụng các phương pháp kiểm thử để sinh ca kiểm thử 55

4.3.2.1 Phương pháp phân tích giá trị biên cơ bản 55

4.3.2.2 Phương pháp phân tích giá trị biên mở rộng 56

4.3.2.3 Phương pháp phân lớp tương đương yếu 56

4.3.2.4 Phương pháp phân lớp tương đương mạnh 57

4.3.2.5 Phương pháp phân lớp tương đương truyền thống 57

4.3.2.6 Phương pháp phân tích bảng quyết định 58

Chương 5 Kết luận 60

Tài liệu tham khảo 62

DANH MỤC BẢNG VÀ HÌNH VẼ

Hình 2.1 Tiến trình thực hiện kiểm thử 5

Hình 2.2 Sơ đồ các cấp độ kiểm thử 8

Hình 2.3 Kiểm thử bottom up 10

Hình 2.4 Kiểm thử top-down 11

Hình 3.1 Các cặp giá trị biên cơ bản 15

Hình 3.2 Mô tả các giá trị biên cơ bản 15

Bảng 3.1 Quy tắc tính tiền được vay thế chấp 16

Hình 3.3 Mã nguồn bài toán tính tiền được vay thế chấp 16

Bảng 3.2 Danh sách ca kiểm thử với phương pháp phân tích giá trị biên cơ bản 17

Hình 3.4 Phương pháp kiểm thử biên mở rộng 18

Bảng 3.3 Các ca kiểm thử với phương pháp kiểm thử biên mở rộng 18

Hình 3.5 Các biên kiểm thử trong trường hợp xấu nhất 19

Bảng 3.4 Các ca kiểm thử với phương pháp kiểm thử trong trường hợp xấu nhất 19

Hình 3.6 Kết hợp kiểm thử trường hợp xấu nhất và kiểm thử mở rộng 20

Hình 3.7 So sánh các kỹ thuật kiểm thử giá trị biên 20

Hình 3.8 Miền giá trị số nguyên 21

Hình 3.9 Miền giá trị kiểu tiền tệ 21

Hình 3.10 Miền giá trị kiểu nhiệt độ 21

Hình 3.11 Miền giá trị kiểu String 22

Hình 3.12 Miền giá trị kiểu ngày tháng năm 22

Hình 3.13 Trực quan mô tả phân lớp tương đương 23

Bảng 3.5 Danh sách ca kiểm thử sinh ra theo phân lớp tương đương yếu 25

Bảng 3.6 Các ca kiểm thử sinh ra theo phân lớp tương đương mạnh 26

Bảng 3.7 Miền dữ liệu phân lớp tương đương yếu 27

Bảng 3.8 Danh sách ca kiểm thử sinh ra theo phân lớp tương đương truyền thống 27

Bảng 3.9 Các thành phần của một bảng quyết định 28

Bảng 3.10 Ví dụ một bảng quyết định 29

Bảng 3.11 Bảng quyết định cho bài toán “Tam giác” [6] 30

Bảng 3.12 Bảng quyết định được làm mịn cho bài toán “Tam giác” [6] 31

Bảng 3.13 Bảng quyết định với tổng số các luật [6] 31

Bảng 3.14 Các trường hợp kiểm thử cho bài toán “Tam giác” [6] 32

Bảng 3.15 Bảng quyết định với các loại trừ lẫn nhau 33

Bảng 3.16 Tổng số luật cho một bảng quyết định với các điều kiện loại trừ lẫn nhau 33

Bảng 3.17 Phiên bản mở rộng của bảng quyết định 3.16 [6] 34

Bảng 3.18 Các điều kiện loại trừ lẫn nhau với các luật không xảy ra [6] 34

Bảng 3.19 Một bảng quyết định dư thừa [6] 34

Bảng 3.20 Một bảng quyết định không nhất quán [6] 35

Bảng 3.21 Bảng quyết định cho thử nghiệm đầu tiên với 256 luật [6] 36

Bảng 3.22 Bảng quyết định phép thử thứ 2 với 36 luật [6] 38

Bảng 3.23 Bảng quyết định cho hàm “NextDate” [6] 40

Bảng 3.24 Bảng quyết định được thu gọn cho hàm “NextDate” [6] 41

Bảng 3.25 Các trường hợp kiểm thử cho bài toán “NextDate” [6] 42

Hình 3.14 So sánh tính hiệu quả của các phương pháp kiểm thử 44

Hình 3.15 So sánh tính hiệu quả của các phương pháp kiểm thử 44

Bảng 3.26 Lựa chọn các phương pháp kiểm thử 45

Hình 4.1 Giao diện bài toán “Nhập điểm cho sinh viên” 47

Bảng 4.1 Các giá trị biên cơ bản cho bài toán “Nhập điểm sinh viên” 48

Bảng 4.2 Các trường hợp kiểm thử biên cơ bản cho bài toán “Nhập điểm sinh viên” 48

Bảng 4.3 Các giá trị biên mở rộng cho bài toán “Nhập điểm sinh viên” 49

Bảng 4.4 Kết quả kiểm thử biên mở rộng cho bài toán “Nhập điểm sinh viên” 49

Bảng 4.5 Các trường hợp kiểm thử cho phân lớp tương tương yếu 50

Bảng 4.6 Kết quả kiểm thử theo phương pháp phân lớp tương đương mạnh 51

cho bài toán “Nhập điểm sinh viên” 51

Bảng 4.7 Các trường hợp kiểm thử cho phân lớp tương tương 52

truyền thống với bài toán “Nhập điểm sinh viên” 52

Bảng 4.8 So sánh các phương pháp sinh ca kiểm thử cho bài toán “Nhập điểm sinh viên” 53

Hình 4.2 Giao diện bài toán “NextDate” 55

Bảng 4.9 Các giá trị biên cơ bản cho bài toán “NextDate” 55

Bảng 4.10 Kết quả kiểm thử theo phương pháp phân tích giá trị biên cơ bản cho bài toán “NextDate” 56

Bảng 4.11 Các giá trị biên mở rộng cho bài toán “NextDate” 56

Bảng 4.12 Kết quả kiểm thử giá trị biên mở rộng cho bài toán “NextDate” 56

Bảng 4.13 Các trường hợp kiểm thử cho phân lớp tương tương yếu với bài toán “NextDate” 57

Bảng 4.14 Kết quả kiểm thử theo phương pháp phân lớp tương tương mạnh với bài toán

“NextDate” 57 Bảng 4.15 Kết quả kiểm thử theo phương pháp phân lớp tương truyền thống với bài toán

“NextDate” 58 Bảng 4.16 Các trường hợp kiểm thử cho phân lớp tương tương truyền thống với bài toán

“NextDate” 58 Bảng 4.17 Kết quả kiểm thử dựa theo bảng quyết định cho bài toán “NextDate” 58 Bảng 4.18 So sánh các phương pháp sinh ca kiểm thử cho bài toán “NextDate” 59

Chương 1 Giới thiệu

1.1 Đặt vấn đề

Kiểm thử phần mềm [1] là một trong những hoạt động quan trọng trong tiến trình phát triển phần mềm Nó góp một phần rất lớn trong việc đánh giá chất lượng của một phần mềm và là quy trình bắt buộc trong các dự án phát triển phần mềm Hiện nay, hai kỹ thuật chính đang được áp dụng rộng rãi trong kiểm thử phần mềm là kiểm thử hộp trắng và kiểm thử hộp đen [1] Tuy nhiên, trong thực tế hiện nay, các công ty phần mềm thường tập trung nguồn lực vào kiểm thử hộp đen do kỹ thuật kiểm thử hộp trắng rất tốn kém vì liên quan đến phân tích mã nguồn và yêu cầu người kiểm thử phải có hiểu biết sâu sắc về

hệ thống, có khả năng phân tích cấu trúc dữ liệu cũng như am hiểu nhất định các vấn đề

kỹ thuật của chương trình

Kiểm thử hộp đen là một phương pháp quan trọng trong kiểm thử phần mềm Để thực thi được hoạt động kiểm thử này chúng ta cần sinh bộ kiểm thử hay chính là tập hợp của các ca kiểm thử Chất lượng của hoạt động kiểm thử hoàn toàn phụ thuộc vào chất lượng của bộ kiểm thử này Tuy nhiên, các công ty phần mềm hiện nay chủ yếu sử dụng phương pháp phân hoạch tương đương để sinh bộ kiểm thử Phương pháp này sẽ rất tốn kém khi số lượng đầu vào của một chức năng cần kiểm thử là lớn Hơn nữa, phương pháp này chỉ hiệu quả với giả thiết là các đầu vào hoàn toàn độc lập nhau Với những bài toán

có đầu vào phụ thuộc lẫn nhau, phương pháp phân hoach tương đương khó phát hiện ra các lỗi gây ra bởi những phụ thuộc này Để giải quyết bài toán này, chúng ta cần khảo sát các phương pháp sinh bộ kiểm thử và đưa ra gợi ý cho các công ty trong việc lựa chọn hay kết hợp các phương pháp để đảm bảo chất lượng phần mềm

1.2 Nội dung nghiên cứu

Luận văn tập trung vào việc nghiên cứu và khảo sát một số phương pháp sinh bộ kiểm thử thường được sử dụng trong kiểm thử hộp đen như: kiểm thử giá trị biên, kiểm thử dựa trên phân hoạch tương đương và kiểm thử dựa trên bảng quyết định Với mỗi phương pháp, luận văn sẽ đưa ra các tiêu chí sinh bộ kiểm thử, đồng thời đánh giá được ưu điểm, nhược điểm và khả năng phát hiện lỗi của từng phương pháp theo bộ kiểm thử được sinh

ra Từ kết quả của quá trình khảo sát, luận văn sẽ đưa ra những được gợi ý cho từng loại bài toán, từng hệ thống phù hợp với phương pháp kiểm thử nào

Luận văn cũng sẽ tiến hành thử nghiệm các phương pháp kiểm thử nêu trên cho hai bài toán cụ thể và đưa ra các phân tích đánh giá cho các phương pháp kiểm thử đã khảo sát trong phạm vi luận văn này

1.3 Cấu trúc luận văn

Các phần còn lại của luận văn có cấu trúc như sau:

Chương 2 trình bày các kiến thức tổng quan nhất về kiểm thử phần mềm bao gồm: các khái niệm cơ bản về kiểm thử phần mềm (định nghĩa, lý do, vai trò và mục tiêu của kiểm thử), tiến trình thực hiện kiểm thử bao gồm những giai đoạn nào, các công việc cần thực hiện trong suốt quá trình kiểm thử là gì và các cấp độ kiểm thử trong kiểm thử phần mềm bao gồm: kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận sản phẩm Chương này cũng sẽ trình bày các phương pháp kiểm thử chính trong kiểm thử phần mềm bao gồm kiểm thử hộp trắng và kiểm thử hộp đen

Các phương pháp sinh bộ kiểm thử trong kiểm thử hộp đen sẽ được khảo sát trong chương 3 của luận văn bao gồm ba phương pháp sau: phương pháp phân tích giá trị biên, phương pháp phân hoạch tương đương và phương pháp kiểm thử dựa trên bảng quyết định

Việc ứng dụng xây dựng các ca kiểm thử cho bài toán cụ thể, áp dụng các phương pháp đã khảo sát ở chương 3 sẽ được trình bày trong nội dung của chương 4

Chương 5 là chương cuối cùng với nội dung tóm tắt kết quả đã đạt được của luận văn, trình bày những hạn chế và hướng nghiên cứu phát triển trong tương lai

Chương 2 Tổng quan về kiểm thử phần mềm

2.1 Các khái niệm cơ bản về kiểm thử phần mềm

2.1.1 Định nghĩa kiểm thử phần mềm

Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới những điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khía cạnh nào đó của hệ

thống hay thành phần đó (Theo Bảng chú giải thuật ngữ chuẩn IEEE của Thuật ngữ kỹ

nghệ phần mềm- IEEE Standard Glossary of Software Engineering Terminology) [5]

Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm lỗi (Theo “The Art of Software Testing” – Nghệ thuật kiểm thử phần mềm) Kiểm thử phần mềm theo Glen Myers là quá trình vận hành chương trình để tìm ra lỗi [7]

Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho người có lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch vụ phầm mềm ấy Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khuyết điểm phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành khác nhau

Có thể định nghĩa một cách dễ hiểu như sau Kiểm thử phần mềm là một tiến trình hay một tập hợp các tiến trình được thiết kế để đảm bảo mã hóa máy tính thực hiện theo cái mà chúng đã được thiết kế để làm, và không thực hiện bất cứ thứ gì không mong muốn Đây là một pha quan trọng trong quá trình phát triển hệ thống, giúp cho người xây dựng hệ thống và khách hàng thấy được hệ thống mới đã đáp ứng yêu cầu đặt ra hay

chưa

2.1.2 Lý do kiểm thử phần mềm

Mặc dù kiểm thử phần mềm là một quy trình bắt buộc trong vòng đời phát triển phần mềm nhưng hầu hết các phần mềm hiện tại vẫn còn lỗi lọt đến khách hàng hoặc được chính người sử dụng tìm ra trong quá trình kiểm thử chấp nhận sản phẩm (acceptance test) Nguyên nhân một phần lớn là do kiểm thử viên chưa làm đúng quy trình trong quá trình xây dựng các ca kiểm thử Vì vậy chúng ta cần hiểu rõ lý do của việc kiểm thử để từ

đó thấy được ý nghĩa của việc xây dựng ca kiểm thử hiệu quả Có một số lý do chính của hoạt động kiểm thử phần mềm như sau Lý do thứ nhất, về khía cạnh xem xét sản phẩm, người phát triển muốn kiểm tra phần mềm như một phần tử của hệ thống hoạt động thì cần phải thực hiện thông qua hoạt động kiểm thử phẩn mềm Lý do quan trọng thứ hai là khi

thực hiện tốt hoạt động kiểm thử, chúng ta sẽ hạn chế được chi phí cho các thất bại do lỗi gây ra sau này Đây chính là hiệu quả của hoạt động kiểm thử mang lại và cũng chính là mục tiêu của người phát triển hệ thống khi thực hiện hoạt động kiểm thử phần mềm Ngoài ra còn có một lý do liên quan đến giải pháp phát triển, khi thực hiện hoạt động kiểm thử, đội phát triển sẽ có kế hoạch tốt nâng cao chất lượng suốt quá trình phát triển phần mềm [1]

2.1.3 Vai trò của kiểm thử phần mềm

Thực tế đã chứng minh hoạt động kiểm thử có vai trò vô cùng quan trọng trong tiến trình phát triển phần mềm Vai trò đó được thể hiện qua chi phí và hiệu quả của hoạt động kiểm thử mang lại Về mặt chi phí, hoạt động kiểm thử chiếm khoảng 40% tổng công sức phát triển phần mềm và chiếm tới hơn 30% tổng thời gian phát triển Ngoài ra với các phần mềm

có ảnh hưởng tới sinh mạng thì chi phí kiểm thử có thể gấp từ 3 đến 5 lần tổng các chi phí khác cộng lại [1] Vai trò của hoạt động kiểm thử phần mềm còn thể hiện ở hiệu quả mà nó mang lại, khi việc kiểm thử phần mềm đạt kết quả tốt sẽ có hiệu quả rất lớn trong việc giảm chi phí phát triển và làm tăng độ tin cậy của sản phẩm phần mềm

2.1.4 Mục tiêu của kiểm thử phần mềm

Có thể nói mục tiêu của hoạt động kiểm thử phần mềm là thiết kế được những trường hợp kiểm thử để có thể phát hiện một cách có hệ thống những loại lỗi khác nhau và thực hiện công việc đó với lượng thời gian và tài nguyên tối ưu nhất Tuy nhiên kiểm thử phần mềm không thể khẳng định rằng phần mềm không còn khiếm khuyết Như vậy ta có thể kết luận, mục tiêu đầu tiên và trước mắt của hoạt động kiểm thử phần mềm là tạo ra các ca kiểm thử

để tìm ra lỗi của phần mềm Mục tiêu cuối cùng và cũng là mục tiêu mà người phát triển hướng tới là kiểm thử phần mềm sẽ giúp cho người phát triển có một chương trình tốt, chi phí thấp nhưng vẫn đảm bảo được chất lượng phần mềm [1]

2.2 Tiến trình thực hiện kiểm thử

Trước khi tìm hiểu quá trình tạo và thực thi các ca kiểm thử được thực hiện như thế nào, chúng ta cần thấy được cái nhìn tổng quát nhất về tiến trình thực hiện kiểm thử như mô tả trong hình 2.1 [1]

Hình 2.1 Tiến trình thực hiện kiểm thử

Tiến trình này mô tả chi tiết quá trình thực hiện kiểm thử phần mềm bao gồm các giai đoạn như sau Trước tiên, chúng ta cần lập kế hoạch kiểm thử Thông thường kế hoạch kiểm thử bao gồm một số thông tin chính như phạm vi kiểm thử, các chức năng cần kiểm thử, phương pháp kiểm thử, mức độ kiểm thử, lịch biểu và nhân công tương ứng,… Sau khi hoàn thành kế hoạch kiểm thử, chúng ta tiến hành tạo các ca kiểm thử dựa vào đặc tả của hệ thống, song song với quá trình tạo ca kiểm thử thì các kiểm thử viên cũng cần chuẩn bị môi trường kiểm thử, dữ liệu đầu vào tương ứng với từng ca kiểm thử Dữ liệu kiểm thử sẽ được dùng trong giai đoạn tiếp theo khi kiểm thử viên tiến hành thực hiện hoạt động kiểm thử phần mềm dựa trên các ca kiểm thử đã được xây dựng từ giai đoạn trước đó Dựa vào kết quả thực tế khi chạy chương trình và so sánh với kết quả mong đợi, kiểm thử viên sẽ đưa ra được kết luận cuối cùng, tạo báo cáo kiểm thử để hoàn thành quá trình kiểm thử

2.3 Các phương pháp kiểm thử phần mềm

Hiện nay, có hai phương pháp chính đang được áp dụng rộng rãi trong kiểm thử phần mềm là kiểm thử hộp trắng và kiểm thử hộp đen Chúng ta sẽ đi vào tìm hiểu cụ thể hai phương pháp này trong mục 2.3.1 và 2.3.2

2.3.1 Kiểm thử hộp trắng

Kiểm thử hộp trắng (white box testing) là loại kiểm thử hướng logic nhằm mục đích khảo sát cấu trúc bên trong của chương trình Chiến lược này xuất phát từ dữ liệu kiểm thử bằng sự kiểm thử tính logic của chương trình Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chương trình và cả mã lệnh thực hiện chúng

Đối tượng của kiểm thử hộp trắng là mã nguồn chương trình, cụ thể là các mô đun đơn vị Kiểm thử hộp trắng tập trung vào việc kiểm tra các chi tiết thủ tục (logic xử lý, thuật toán), các con đường logic (luồng điều khiển) và các trạng thái của chương trình (dữ liệu cục bộ) [1] Hiện nay, có một số kỹ thuật hay được sử dụng trong kiểm thử hộp trắng như: đồ thị dòng (do Tom McCabe đưa ra đầu tiên), ma trận kiểm thử (số đường đi, trọng

số trên từng cạnh), điều khiển theo dòng dữ liệu, các cấu trúc chu trình – giá trị đặc trưng Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá sự hoàn thành của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thử hộp đen (sẽ trình bày trong mục 2.3.2) Điều này cho phép các nhóm phát triển phần mềm khảo sát các phần của một hệ thống ít khi được kiểm tra và đảm bảo rằng những điểm chức năng quan trọng nhất đã được kiểm thử

2.3.2 Kiểm thử hộp đen

Kiểm thử hộp đen (black box testing) là một trong những phương pháp kiểm thử quan trọng nhất trong tiến trình kiểm thử phần mềm Kiểm thử hộp đen cũng được gọi là kiểm thử hướng dữ liệu hay hướng vào/ra Phương pháp này xem chương trình như là một “hộp đen”, kiểm thử viên chỉ quan tâm đến đầu vào và đầu ra của chương trình mà không hề biết cấu trúc nội tại bên trong hệ thống và các thành phần cúa nó hoạt động ra sao Thay vào đó, tập trung vào tìm các trường hợp mà chương trình không thực hiện theo các đặc tả của nó Hơn nữa, kiểm thử hộp đen còn bổ sung cho phương pháp kiểm thử hộp trắng để phát hiện ra các lỗi khác nhau mà kiểm thử hộp trắng không phát hiện ra được

Phương pháp này tập trung kiểm thử về mặt yêu cầu chức năng của sản phẩm Đối tượng của kiểm thử hộp đen là các module tích hợp, các hệ con và toàn bộ hệ thống Thông qua giao diện của chương trình và dựa vào các yêu cầu đặc tả, điều kiện vào/ra và cấu trúc

dữ liệu, kiểm thử viên sẽ kiểm tra xem các chức năng của chương trình đã đủ và vận hành đúng theo đặc tả hệ thống hay chưa

Với phạm vi giới hạn của đề tài, trong mục này, luận văn xin giới thiệu một số phương pháp kiểm thử hộp đen thông dụng hiện nay, tuy nhiên luận văn sẽ không đi vào trình bày chi tiết cho từng phương pháp

Phân lớp tương đương – Equivalence partitioning

Phân tích giá trị biên – Boundary value analysis

Kiểm thử mọi cặp – All-pairs testing

Kiểm thử fuzz – Fuzz testing

Kiểm thử dựa trên mô hình – Model-based testing

Ma trận dấu vết – Traceability matrix

Kiểm thử thăm dò – Exploratory testing

Kiểm thử dựa trên đặc tả – Specification-base testing [1]

Ƣu điểm và nhƣợc điểm của kiểm thử hộp đen

Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thử viên chỉ cần quan tâm đầu ra của chương trình có đúng theo đặc tả hay không Áp dụng các phương pháp sinh ca kiểm thử trong kiểm thử hộp đen sẽ giúp các kiểm thử viên tìm ra lỗi mà những lập trình viên đã không tìm thấy ở giai đoạn trước Tuy nhiên do kiểm thử viên không biết các phần mềm được kiểm tra thực sự được xây dựng thế nào nên sẽ có nhiều hạn chế trong việc tập trung vào kiểm thử cái gì Đó là lý do giải thích tại sao có nhiều trường hợp mà một kiểm thử viên hộp đen viết rất nhiều các ca kiểm thử để kiểm tra một thứ gì đó mà đáng lẽ

có thể chỉ cần kiểm tra bằng một ca kiểm thử duy nhất, hoặc một số phần của chương trình không được kiểm tra chu đáo

Do vậy, kiểm thử hộp đen có ưu điểm của “ một sự đánh giá khách quan”, không phụ thuộc vào quan điểm của người xây dựng chương trình mà thiên về cách nhìn của người sử dụng nhiều hơn, mặt khác nó lại có nhược điểm của “thăm dò mù” nên đôi khi hơi tốn thời gian và chi phí cho việc kiểm thử nếu không chọn được phương pháp/chiến lược kiểm thử phù hợp và hiệu quả

2.4 Các cấp độ kiểm thử phần mềm

Theo mô hình thác nước trình bày trong hình 2.2 thì kiểm thử phần mềm gồm có các cấp độ: kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận sản phẩm Mỗi cấp độ kiểm thử sẽ có một số đặc điểm riêng và phù hợp với từng giai đoạn của quá trình xây dựng và phát triển phần mềm

Dựa vào hình 2.2 bên dưới ta thấy tương ứng với mỗi giai đoạn phát triển phần mềm sẽ

có một cấp độ kiểm thử phù hợp với giai đoạn đó Mỗi cấp độ kiểm thử được thực hiện theo một thứ tự nhất định và có mục tiêu cụ thể cho từng giai đoạn Trong thực tế, để việc tạo và thực thi các ca kiểm thử đạt kết quả cao thì quá trình phân tích, thiết kế của hoạt động kiểm thử cần được làm song song và phù hợp với các giai đoạn phát triển phần mềm Hơn nữa, kiểm thử viên nên tham gia vào quá trình xem xét tài liệu càng sớm càng tốt để đưa ra kế hoạch và chiến lược kiểm thử phù hợp nhất cho hệ thống [4]

Trước khi thực hiện UT, kiểm thử viên nên xác định quan điểm thực hiện kiểm thử rõ ràng Quan điểm kiểm thử ở đây được hiểu là các tiêu chí cũng như các đối tượng sẽ được kiểm thử trong giai đoạn này Trong thực tế, UT nên kiểm tra được các đối tượng sau

Kiểm tra, xác minh hoạt động của các tham số với giá trị bình thường (norm) Kiểm tra, xác minh hoạt động của các tham số với giá trị biên

Kiểm tra, xác minh hoạt động của các tham số với giá trị không nằm trong miền giới hạn (abnormal)

Kiểm tra sự hoạt động của các vòng lặp

Kiểm tra sự hoạt động của các hàm đệ quy

Kiểm tra sự truy cập cấu trúc dữ liệu/truy cập file

Đảm bảo rằng tất các các câu lệnh, các nhánh lệnh được thực thi đúng

Vì đơn vị được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động đơn giản, chúng ta không khó khăn gì trong việc tổ chức kiểm thử, ghi nhận và phân tích kết quả kiểm thử Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể đang được kiểm tra Thực tế cho thấy thời gian tốn cho hoạt động kiểm thử đơn vị sẽ được đền bù bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm thử và sửa lỗi ở các mức kiểm thử sau đó

Thông thường, kiểm thử đơn vị đòi hỏi kiểm thử viên có kiến thức về thiết kế và mã nguồn của chương trình Mục đích của UT là đảm bảo thông tin được xử lý và xuất khỏi đơn

vị là chính xác trong mối tương quan với dữ liệu nhập và chức năng của đơn vị đó Điều này thường đòi hỏi tất cả các nhánh bên trong thành phần đơn vị đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi Một nhánh thường là một chuỗi các lệnh được thực thi trong một đơn vị Thực tế, việc chọn lựa các nhánh để đơn giản hóa quá trình kiểm thử và quét hết thành phần đòi hỏi kiểm thử viên phải có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa Cùng với các mức độ kiểm thử khác, kiểm thử đơn vị cũng đòi hỏi phải chuẩn bị trước các ca kiểm thử hoặc kịch bản kiểm thử, trong đó chỉ định rõ dữ liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn Các ca kiểm thử và kịch bản kiểm thử này nên được giữ lại để tái sử dụng

Thực tế đã chứng minh rằng, với kiểm thử mức đơn vị, chúng ta có thể thực thi việc kiểm thử với sự hỗ trợ của các công cụ phát triển như framework hoặc công cụ gỡ lỗi (debugging tool) [4] Thông thường, số lượng lỗi tìm ra ở giai đoạn kiểm thử mức đơn vị có thể chiếm hơn 25% tổng số lượng lỗi của toàn bộ dự án

vị đã thực hiện UT thành công

Mục tiêu chính của kiểm thử tích hợp là phát hiện lỗi giao tiếp xảy ra giữa các đơn vị, tích hợp các thành phần đơn vị đơn lẻ thành các hệ thống nhỏ và cuối cùng là tích hợp thành một hệ thống hoàn chỉnh chuẩn bị cho kiểm thử ở mức hệ thống Trong UT, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu trúc nội tại của đơn vị Có một số phép kiểm thử đơn giản trên giao tiếp giữa đơn vị với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến thành phần đơn vị chỉ thật sự được kiểm tra đầy đủ khi các đơn

vị này được tích hợp với nhau trong khi thực hiện kiểm thử tích hợp

Trừ một số ít trường hợp ngoại lệ, còn lại kiểm thử tích hợp chỉ nên thực hiện trên những đơn vị đã được kiểm tra cẩn thận trước đó bằng UT, và tất cả các lỗi mức đơn vị đã được sửa chữa Một số người hiểu sai rằng thành phần đơn vị một khi đã qua giai đoạn UT với các giao tiếp giả lập thì không cần phải thực hiện kiểm thử tích hợp nữa Thực tế việc tích hợp giữa các đơn vị dẫn đến những tình huống hoàn toàn khác Một chiến lược cần quan tâm trong kiểm thử tích hợp là nên tích hợp dần từng đơn vị Một thành phần đơn vị tại một thời điểm được tích hợp vào một nhóm các đơn vị khác đã tích hợp trước đó và đã hoàn tất các đợt kiểm thử tích hợp trước đó Lúc này, ta chỉ cần kiểm thử giao tiếp của đơn vị mới thêm vào với hệ thống các đơn vị đã tích hợp trước đó, điều này sẽ làm cho số lượng ca kiểm thử giảm đi rất nhiều, và sai sót sẽ giảm đáng kể Trong kiểm thử ở mức tích hợp, có

02 chiến lược cơ bản là kiểm thử từ dưới lên và kiểm thử từ trên xuống

Kiểm thử từ dưới lên (bottom up testing) là quá trình tích hợp và kiểm thử các

module ở mức thấp trước Thông thường người ta không thuần túy kiểm thử tất cả các module ở tầng dưới cùng mà nhóm các module này thành các nhóm chức năng, tích hợp và kiểm thử chúng theo từng nhóm như minh họa ở hình 2.3

Hình 2.3 Kiểm thử bottom up

Ƣu điểm: Chiến lược kiểm thử từ dưới lên sẽ giúp cho kiểm thử viên tránh

được việc phải tạo ra các bộ giả lập đầu vào phức tạp hay tạo các kết quả nhân tạo để thực hiện kiểm thử Hơn nữa, nó còn thuận tiện cho việc phát triển các module thứ cấp dùng lại được

Nhƣợc điểm: Song song với ưu điểm trên thì chiến lược kiểm thử bottom up

cũng tồn tại nhược điểm như: Phát hiện chậm các lỗi thiết kế và chậm chễ trong việc có được phiên bản thực thi của hệ thống

Kiểm thử từ trên xuống (top down testing) là quá trình tiến hành kiểm thử các module ở mức cao trước, các module ở mức thấp được tạm thời phát triển với các

chức năng hạn chế Thông thường để sớm có một phiên bản phần mềm để thực hiện người ta thường tiến hành tích hợp theo một nhánh cho đến các module cấp thấp nhất

Hình 2.4 Kiểm thử top-down

Ƣu điểm: Ngược lại với chiến lược bottom up, ưu điểm của kiểm thử top

down sẽ giúp cho người phát triển phát hiện sớm các lỗi thiết kế và có phiên bản thực thi hoạt động sớm

Nhƣợc điểm: Phương pháp này tồn tại hạn chế là khó có thể mô phỏng được

các chức năng của module cấp thấp phức tạp Ngoài ra, chúng ta không kiểm thử được đầy đủ các chức năng của hệ thống

2.4.3 Kiểm thử hệ thống

Kiểm thử hệ thống hay còn gọi là system test (ST) là cấp độ thực hiện việc kiểm thử toàn bộ các chức năng của hệ thống có phù hợp với yêu cầu đặc tả hay không Kiểm thử hệ thống được thực hiện sau khi giai đoạn kiểm thử đơn vị và kiểm thử tích hợp đã được thực hiện thành công cho tất cả các module Thông thường loại kiểm thử này tốn rất nhiều công sức

và thời gian Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị hỗ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng Ở mức độ hệ thống, người kiểm thử cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn bộ hệ thống

Điểm khác nhau then chốt giữa kiểm thử tích hợp và kiểm thử hệ thống là kiểm thử hệ thống chú trọng các hành vi và lỗi trên toàn hệ thống, còn kiểm thử tích hợp chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau Thông thường ta phải thực hiện kiểm thử đơn vị và kiểm thử tích hợp để đảm bảo mọi thành phần đơn vị và

sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện ST Sau khi hoàn thành

giai đoạn kiểm thử tích hợp thì một hệ thống phần mềm được hình thành cùng với các thành phần đã được kiểm tra đầy đủ Tại thời điểm này, lập trình viên hoặc kiểm thử viên bắt đầu kiểm thử phần mềm như một hệ thống hoàn chỉnh Việc lập kế hoạch cho ST nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu

Kiểm thử hệ thống làm nhiệm vụ kiểm tra các hành vi chức năng của phần mềm và các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi “tắc nghẽn” (deadlock) hoặc chiếm dụng bộ nhớ Sau giai đoạn ST, phần mềm thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng

kiểm thử chấp nhận sản phẩm (Acceptance test) hoặc dùng thử ( Alpha/Beta Test)

Kiểm thử hệ thống đòi hỏi nhiều công sức, thời gian, tính chính xác và khách quan nên cấp độ kiểm thử này thường được thực hiện bởi một nhóm kiểm thử viên hoàn toàn độc lập với nhóm phát triển dự án Bản thân ST lại gồm nhiều loại kiểm thử khác nhau, phổ biến nhất gồm kiểm thử chức năng (Function test), kiểm thử hiệu năng (Performance test), kiểm thử khả năng chịu tải (Stress test hay Load test), kiểm thử bảo mật (Security test), kiểm thử khả năng phục hồi (Recovery test) và kiểm thử cấu hình (Configuration test) Nhìn từ quan điểm người dùng, các loại kiểm thử trên rất quan trọng, chúng bảo đảm việc kiểm tra hệ thống đã đủ khả năng làm việc trong môi trường thực hay chưa

Một giai đoạn quan trọng trong kiểm thử hệ thống là việc tạo ra các ca kiểm thử trước khi thực hiện chúng Ca kiểm thử được xây dựng để xác minh các ứng dụng có phù hợp với yêu cầu được đưa ra trong tài liệu đặc tả hệ thống hay không Các ca kiểm thử cần phải được viết đủ chi tiết cho các hành vi hoặc chức năng được kiểm thử, các thông tin bắt buộc cần có trong ca kiểm thử bao gồm: mục đích của ca kiểm thử, môi trường thực thi kiểm thử, các bước chi tiết để tiến hành kiểm thử, dữ liệu đầu vào, dữ liệu đầu ra mong đợi,…

2.4.4 Kiểm thử chấp nhận sản phẩm

Thông thường sau giai đoạn kiểm thử hệ thống là giai đoạn kiểm thử chấp nhận sản phẩm - acceptance test (AT), được khách hàng thực hiện hoặc ủy quyền cho một nhóm thứ ba kiểm thử Mục đích của AT là để chứng minh phần mềm thỏa mãn tất cả các yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người sử dụng, thông thường sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha – Alpha test và kiểm thử Beta – Beta test Với Alpha test, người dùng kiểm thử phần mềm ngay tại nơi phát triển phần mềm và trong môi trường được quản lý, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi của khách hàng và lên kế hoạch sửa chữa Với Beta test, phần mềm sẽ được gửi tới cho người dùng để kiểm thử ngay trong môi trường thực, lỗi hoặc phản hồi cũng sẽ được gửi ngược lại cho lập trình viên để sửa chữa

Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình phát triển phần mềm thì kết quả AT sẽ sai lệch rất lớn, mặc dù phần mềm đã trải qua tất cả các kiểm thử trước đó Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong đợi của khách hàng Ví dụ đôi khi một phần mềm xuất sắc vượt qua các phép kiểm thử về chức năng được thực hiện bởi nhóm phát triển dự án, nhưng khách hàng khi kiểm thử sau cùng vẫn thất vọng vì bố cục màn hình nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng của khách hàng, của người sử dụng

Gắn liền với giai đoạn AT thường là một nhóm những dịch vụ và tài liệu đi kèm, phổ biến như tài liệu hướng dẫn cài đặt, sử dụng, Tất cả tài liệu đi kèm phải được cập nhật

và kiểm thử chặt chẽ

Chương 3 Khảo sát các phương pháp sinh bộ kiểm thử

3.1 Phương pháp kiểm thử giá trị biên

Kiểm thử giá trị biên - Boundary value testing (BVT) [6] là một trong những kỹ thuật kiểm thử chức năng phổ biến nhất trong tất cả các kỹ thuật dùng để kiểm thử hộp đen BVT là kỹ thuật mà các ca kiểm thử được tạo ra dựa trên lý thuyết phân hoạch tập hợp hay cụ thể hơn

là các ca kiểm thử được định nghĩa dựa trên các khoảng giá trị của các biến đầu vào Như chúng ta đã biết các kỹ thuật kiểm thử đều dựa vào nguyên tắc toán học, các khái niệm toán học được áp dụng trong kiểm thử chúng ta có thể tham khảo tại các tài liệu về lý thuyết tập hợp, lý thuyết về hàm, ánh xạ, các phép toán logic, lý thuyết xác suất Kỹ thuật kiểm thử giá trị biên liên quan chặt chẽ tới lý thuyết tập hợp, các phép toán trên tập hợp, sự phân hoạch

Kiểm thử trường hợp xấu nhất

Kết hợp kiểm thử trường hợp xấu nhất và kiểm thử biên mở rộng

3.1.1 Kỹ thuật cơ bản

Kỹ thuật kiểm thử giá trị biên cơ bản hay còn gọi là basic idea Ý tưởng của phương pháp

này là kiểm thử viên lập ra các ca kiểm thử tại các giá trị biên và cận biên của các khoảng dữ liệu đầu vào Thực tế đã chứng minh rằng, các giá trị ở vùng biên, vùng tới hạn là những giá trị thường gây ra lỗi cao nhất Ví dụ, trong lập trình phần mềm, chúng ta khai báo biến x có kiểu là byte, biến này có giá trị nằm trong khoảng [0…255], trong quá trình thực thi nếu biến x nhận giá trị đầu vào x < 0 hoặc x > 255 thì chương trình sẽ gây ra lỗi nếu chúng ta không xử lý các trường hợp này Giả sử chúng ta cần kiểm tra các giá trị đầu ra ứng với các giá trị đầu vào trong hàm F = f(x1,x2), x1 [a,b], x2 [c,d] Các ca kiểm thử sẽ được lập

ra để phân tích kết quả tại các điểm giá trị biên dưới, cận trên của biên dưới, cận dưới của biên trên, biên trên của các biến đầu vào, tức là các điểm min, min+, max- và max Các trường hợp cần kiểm tra sẽ chính là các ca kiểm thử lần lượt tương ứng với các giá trị đầu vào là các điểm đặc biệt trên, cụ thể ta có các cặp giá trị sau được mô tả trong hình 3.1

Hình 3.1 Các cặp giá trị biên cơ bản

Để dễ hình dung hơn, kỹ thuật phân tích giá trị biên cơ bản được mô tả bằng hình 3.2, trong đó các giá trị biên nằm trên các đường biên của miền giá trị đoạn [a,b] và đoạn [c,d] là các đường biên của phân hoạch tập hợp

Hình 3.2 Mô tả các giá trị biên cơ bản

Như vậy việc tạo ra ca kiểm thử với ý tưởng của kỹ thuật kiểm thử giá trị biên cơ bản

là chúng ta chỉ việc lựa chọn các giá trị đầu vào tại các “góc cạnh”, điểm giá trị cuối của mỗi miền hay gọi là các giá trị biên Các giá trị biên cũng được kết hợp với các lân cận của nó hay các vùng biên-viền

Về phương pháp luận, cơ sở toán học của phương pháp này chính là phương pháp phân lớp tương đương tập hợp, kiểm thử giá trị biên giúp tạo ra các ca kiểm thử bổ sung thêm cho phân lớp tương đương, nó cho phép tìm lỗi trong mỗi miền là độc lập và khách quan như nhau Vậy việc khó khăn và quan trọng nhất trước tiên là cần phải tìm được các phân hoạch của miền giá trị đầu vào của các biến Sau khi xây dựng được các phân hoạch con, chúng ta sẽ tiến hành xác định các giá trị biên của mỗi miền giá trị được phân chia Để

dễ dàng hơn trong việc tạo ra các phân hoạch miền giá trị, ngoài các phương pháp toán học, các phép toán trên tập hợp, người ta đưa ra các khuyến cáo như sau dựa vào kinh nghiệm thực tế: Tiến hành mở rộng phân hoạch dựa trên các phân hoạch đã có Với mỗi lớp con của phân hoạch, chọn một giá trị tùy ý đại diện cho phân hoạch đó Ngoài ra cần chọn các giá trị chính xác ở biên trên và biên dưới của mỗi lớp Cuối cùng chọn các giá trị ngay lập tức ở dưới và trên mỗi biên Các giá trị được lựa chọn này sẽ được sử dụng như những ca kiểm thử cần được thực hiện

<x1nom; x2min >;< x1nom; x2min+ >;

<x1nom; x2nom >;< x1nom; x2max- >;

<x1nom; x2max >;< x1min; x2nom >;

<x1min+; x2nom >;< x1nom; x2nom >;

<x1max-; x2nom >;< x1max; x2nom >

Về cơ bản, số lượng các ca kiểm thử sinh ra theo kỹ thuật này phụ thuộc vào số biến

đầu vào, nếu hàm có n biến thì sẽ có 4n+1 ca kiểm thử Ngoài ra, việc sinh các ca kiểm thử

còn phụ thuộc vào loại dữ liệu đầu vào có tính phụ thuộc phức tạp hay không và còn phụ thuộc bản chất của dữ liệu Ví dụ, dữ liệu dạng số rời rạc và có tập xác định rõ ràng thì dễ dàng xác định được biên còn dữ liệu không có biên rõ ràng như biến kiểu Boolean mang giá trị True/False, không có giá trị thứ 3 nên không dùng được phương pháp này hoặc thường

phải tạo biên nhân tạo - "artificial bounds" để tiến hành kiểm thử

Kỹ thuật phân tích giá trị biên cũng tồn tại một số hạn chế như sự phụ thuộc vào các giá trị đo vật lý hoặc tính độc lập của các biến đầu vào Tính độc lập thể hiện ở việc phải giả thiết rằng các biến đầu vào là độc lập không có mối quan hệ ảnh hưởng qua lại với nhau Hơn nữa kỹ thuật kiểm thử này chỉ áp dụng tốt khi chương trình được kiểm thử là một hàm của các biến đầu vào được biểu diễn đại lượng vật lý có giới hạn

Phần dưới đây của luận văn sẽ trình bày một ví dụ thực tế của quá trình sinh ra các ca kiểm thử cho một chức năng tính tiền được vay thế chấp (Mortgage) trong chương trình quản lý của ngân hàng Đầu vào của bài toán gồm, ba biến với các miền giá trị tương ứng như sau: gender (boolean), age ([18-55]), salary ([0- 10000]) Đầu ra của bài toán yêu cầu tính tổng tiền được vay thế chấp cho mỗi người theo công thức: Mortgage = salary * factor Bảng 3.1 mô tả quy tắc tính toán tiền vay thế chấp như sau

Bảng 3.1 Quy tắc tính tiền được vay thế chấp

Young (18-35 years) 75 (18-30 years) 70 Middle (36-45 years) 55 (31-40 years) 50 Old (46-55 years) 30 (41-50 years) 35 Khi cài đặt mã nguồn như hình 3.3, ở lệnh Return đầu tiên do vô ý mà lập trình viên đã

để sai ở mệnh đề so sánh, đáng lẽ phải là mệnh đề (36≤ age <45) nhưng nhầm thành 31≤ age< 45), còn lệnh Return thứ hai đáng lẽ (18≤ age <30)? (70* salary) nhưng bị sai thành (18≤ age < 30) ? (75* salary)

Hình 3.3 Mã nguồn bài toán tính tiền được vay thế chấp

Các ca kiểm thử được lập ra dựa vào phương pháp phân tích giá trị biên cơ bản như mô

tả trong bảng 3.2

If (male) then

Return ((18 ≤ age< 35)?(75 * salary ) : (31≤ age < 45)?(55 * salary ) : (30 * salary ))

Else return ((18 ≤ age <30)?(75 * salary ) : (31≤ age < 40)?(50 * salary ) : (35 *

salary ))

Bảng 3.2 Danh sách ca kiểm thử với phương pháp phân tích giá trị biên cơ bản

Gender Age Salary Output Correct output Pass/Fail

Với bảng mô tả các ca kiểm thử trên ta thấy trường hợp kết quả ở dòng cuối cùng là sai

vì giá trị đầu ra của chương trình sai khác so với giá trị mong muốn Dựa vào kết quả này, kiểm thử viên có thể yêu cầu lập trình viên kiểm tra lại tính chính xác của thuật toán được cài đặt

3.1.2 Kiểm thử biên mở rộng

Kiểm thử biên mở rộng - Robustness testing là một sự mở rộng của kỹ thuật phân tích giá trị biên cơ bản bằng cách thêm vào tập các giá trị biên cơ bản các giá trị vượt ra ngoài biên, nằm ngoài tập giá trị đang xét Nếu một hệ thống được cài đặt đúng thì với các giá trị đầu vào nằm ngoài biên sẽ không dẫn tới các lỗi của chương trình, hệ thống không bị treo hay có những thông báo bất thường Ví dụ trong lập trình với ngôn ngữ C/C++ nếu chúng ta khai báo biến con trỏ *p và cấp phát bộ nhớ cho nó vượt quá bộ nhớ dùng để thực thi chương trình hoặc trỏ đến địa chỉ của các thanh ghi điều khiển thì chương trình sẽ bị treo Với các chương trình phần mềm nhúng thường được kiểm tra chặt chẽ sự liên kết với các đại lượng vật lý như giới hạn nhiệt độ, giới hạn về bộ nhớ,… nhằm đảm bảo chương trình thực thi đúng đắn

Hình 3.4 Phương pháp kiểm thử biên mở rộng

Kỹ thuật này đòi hỏi việc kiểm tra tính đáp ứng của hệ thống đối với cả những trường hợp ở cận dưới của biên dưới (min-) và cận trên của biên trên (max+) Với n biến đầu vào

thì sẽ có 6n+1 ca kiểm thử được sinh ra Các ca kiểm thử thêm mới trong trường hợp sử

dụng phương pháp kiểm thử giá trị biên mở rộng cho bài toán vay thế chấp ở mục 3.1.1 như

mô tả trong bảng 3.3

Bảng 3.3 Các ca kiểm thử với phương pháp kiểm thử biên mở rộng

Gender Age Salary Output Correct output Pass/Fail

Male 17 5000 30*5000 Age not valid F

Male 56 5000 75*5000 Age not valid F

Male 25 -1 75*-1 Invalid salary F

Male 25 10001 75*10001 75*10000(?) F

Các ca kiểm thử tại các giá trị đầu vào nằm ngoài miền ràng buộc là giá trị độ tuổi 17

và 56, giá trị lương là -1 và 10001 Kết quả của ca kiểm thử trả về giá trị Fail (F) cho thấy thuật toán cài đặt cho ra kết quả không như mong đợi

3.1.3 Kiểm thử trường hợp xấu nhất

Kiểm thử trường hợp xấu nhất - worst case testing là kỹ thuật giúp loại bỏ giả thiết “lỗi đơn” cho rằng hiếm khi xảy ra trường hợp lỗi đồng thời, nghĩa là chúng ta cần kiểm tra các tình huống khi mà hơn một biến đầu vào có giá trị không hợp lệ Ví dụ, với năm nhuận thì tháng

2 sẽ có 29 ngày, như vậy nếu thể hiện giá trị năm là nhuận và biến tháng bằng 2 xảy ra đồng thời thì kết quả của hàm tính ngày sẽ phải là 29

Ở kỹ thuật này, người ta cải tiến việc sinh các ca kiểm thử bằng cách kiểm tra các giá trị tại các điểm nút giao nhau, điểm chốt phân hoạch các tập giá trị Tập giá trị vẫn là (min, min+, nom, max-, max) nhưng cả 2 biến đều nhận những giá trị này chứ không phải là 1 biến nhận giá trị norm giống kỹ thuật phân tích giá trị biên cơ bản Kỹ thuật kiểm thử trường hợp xấu nhất cho ra số lượng ca kiểm thử theo hàm mũ, nếu có n biến sẽ cho 5n trường hợp kiểm thử, điều này được minh họa trong hình 3.5

Hình 3.5 Các biên kiểm thử trong trường hợp xấu nhất

Bảng 3.4 mô tả các trường hợp kiểm thử được sinh ra khi sử dụng kỹ thuật kiểm thử trường hợp xấu nhất cho bài toán tính tiền vay thế chấp Trong danh sách ca kiểm thử lần này được bổ sung thêm các giá trị tại các điểm nút giao nhau giữa biến Age = (18,35,45,55)

và Salary = 1 Bảng kết quả cho thấy tại các điểm nút cho kết quả đầu ra không đáp ứng với mong đợi chứng tỏ thuật toán của chương trình được cài đặt bị lỗi cần phải kiểm tra lại việc

xử lý rẽ nhánh tại các điểm nút này

Bảng 3.4 Các ca kiểm thử với phương pháp kiểm thử trong trường hợp xấu nhất

Gender Age Salary Output Correct output Pass/Fail

3.1.4 Kết hợp kiểm thử trường hợp xấu nhất và kiểm thử biên mở rộng

Để đảm bảo việc kiểm thử chương trình phát hiện được nhiều lỗi nhất có thể, đảm bảo chương trình thực thi một cách đúng đắn cũng như đảm bảo chất lượng phần mềm, người ta không chỉ dùng một kỹ thuật kiểm thử giá trị biên cơ bản hay mở rộng hoặc kiểm thử trường hợp xấu nhất mà có sự kết hợp giữa nhiều kỹ thuật với nhau Điển hình là sự kết hợp giữa kiểm thử biên trong trường hợp xấu nhất và kiểm thử mở rộng Trong kỹ thuật kết hợp này, chúng ta cần kiểm thử cả những giá trị ngoài biên (min-, min, min +, nom, max -, max, max+) Phương pháp này sinh ra một số lượng lớn các các ca kiểm thử, nếu có n biến đầu vào sẽ có 7n

ca kiểm thử được minh họa ở hình 3.6

Hình 3.6 Kết hợp kiểm thử trường hợp xấu nhất và kiểm thử mở rộng

Để dễ phân biệt và hình dung tổng quát lại các kỹ thuật trong phân tích giá trị biên, hình 3.7 dưới đây là sự so sánh các kỹ thuật đã trình bày ở trên Sự kết hợp của các kỹ thuật khác nhau trong kiểm thử giá trị biên còn được xem như là phương pháp kiểm thử giá trị đặc biệt và là kỹ thuật kiểm thử chức năng được dùng rộng rãi nhất Đây cũng là kỹ thuật trực quan và ít hình thức nhất, trong kỹ thuật này kiểm thử viên dựa vào hiểu biết về kỹ thuật, kinh nghiệm của chính họ với các chương trình tương tự (business domain) và các thông tin khác để có được các phân hoạch miền giá trị biến đầu vào để từ đó tạo ra các ca kiểm thử

Hình 3.7 So sánh các kỹ thuật kiểm thử giá trị biên

3.1.5 Một số ví dụ về miền giá trị các kiểu biến

Trong mục này, luận văn sẽ đưa ra một số ví dụ điển hình về miền giá trị của các kiểu biến đầu vào bao gồm: biến đầu vào có kiểu số nguyên dương, biến kiểu tiền tệ, biến kiểu nhiệt

độ, biến kiểu xâu kí tự và biến kiểu ngày tháng Hình 3.8 mô tả miền giá trị hợp lệ, không

hợp lệ và các giá trị biên của biến đầu vào với điều kiện biến đầu vào là một tập số nguyên dương có giá trị nhỏ hơn 100 Tiếp theo, hình 3.9 biểu diễn biến đầu vào kiểu tiền tệ có giá trị lớn hơn 0 và nhỏ hơn 1000 Ở đây khác với biến kiểu số nguyên, biến kiểu tiền tệ có thể nhận giá trị là một số thập phân Tương tự, hình 3.10 biểu diễn các giá trị biên của biến đầu vào kiểu nhiệt độ Hình 3.11 và 3.12 lần lượt mô tả các giá trị biên, miền giới hạn của các biến đầu vào kiểu xâu kí tự và kiểu ngày tháng năm

Ví dụ về nhập thông tin đầu vào là số nguyên dương nhỏ hơn 100:

Hình 3.8 Miền giá trị số nguyên

Biến đầu vào kiểu tiền tệ:

Hình 3.9 Miền giá trị kiểu tiền tệ

Biến đầu vào kiểu nhiệt độ:

Hình 3.10 Miền giá trị kiểu nhiệt độ

Biến đầu vào kiểu chuỗi mật khẩu:

Hình 3.11 Miền giá trị kiểu String

Biến đầu vào kiểu ngày tháng năm:

Hình 3.12 Miền giá trị kiểu ngày tháng năm

3.1.6 Nhận xét

Qua quá trình khảo sát các các kỹ thuật của phương pháp kiểm thử giá trị biên, ta thấy được một số ưu và nhược điểm của phương pháp này như sau

Ƣu điểm: Kiểm thử giá trị biên là phương pháp có tính trực quan, dễ hiểu, dễ áp

dụng Vì việc sinh ca kiểm thử chỉ tập trung tại các biên của miền dữ liệu đầu vào nên khi sử dụng phương pháp này sẽ làm giảm đáng kể số lượng ca kiểm thử cần tạo

và thực thi Phương pháp này phù hợp với hầu hết các hệ thống có miền giá trị đầu vào của các biến được chia thành nhiều phân vùng con Hơn nữa, ưu điểm lớn nhất của phương pháp này là xác suất tìm ra lỗi cao vì một tỉ lệ lớn các lỗi xảy ra tại vị trí biên và cận biên

Nhược điểm: Tuy có khá nhiều ưu điểm nhưng kiểm thử giá trị biên vẫn tồn tại một

vài hạn chế nhất định như: Để áp dụng được phương pháp này cần yêu cầu các biến đầu vào là các đại lượng vật lý và thực sự độc lập với nhau về mặt logic

3.2 Phương pháp kiểm thử dựa trên phân hoạch tương đương

Việc thực thi kiểm thử tất cả mọi trường hợp trong kiểm thử hộp đen là điều khó có thể thực hiện được vì số lượng các ca kiểm thử vô cùng lớn và tăng lên theo hàm mũ tương ứng với

số lượng biến đầu vào của chương trình Vì vậy trong quá trình xây dựng ca kiểm thử, chúng ta cần lựa chọn ra những ca kiểm thử mà khả năng phát hiện lỗi cao nhất có thể Phân lớp tương đương - Equivalence partitioning (EP) hay còn gọi là phân hoạch tương đương là một phương pháp kiểm thử hộp đen dựa trên đặc tả hệ thống Nó có thể được áp dụng cho bất kỳ một cấp độ kiểm thử nào và là một kỹ thuật rất tốt thường được lựa

chọn đầu tiên [4] EP chia miền giá trị các biến đầu vào của một chương trình thành các lớp

dữ liệu con, từ đó suy dẫn ra các ca kiểm thử Phương pháp này cố gắng xác định ra một ca kiểm thử mà làm lộ ra một lớp lỗi, do đó làm giảm tổng số các trường hợp kiểm thử phải được xây dựng Hình 3.13 thể hiện một cách trực quan cho phân lớp tương đương [2]

Hình 3.13 Trực quan mô tả phân lớp tương đương

Cơ sở của việc phân chia miền dữ liệu đầu vào thành các lớp tương đương là vì dữ liệu trong một lớp tương đương tác động như nhau lên chương trình, tạo ra cùng một trạng thái đúng hay sai của chương trình, tức là các phần tử trong cùng một lớp tương đương sẽ có cùng tính chất và thuộc tính [1] Giả sử các tập con A1, A2, A3 … của tập X tạo nên một phân hoạch của X, nếu:

Công thức trên mô tả nguyên tắc phân hoạch tập hợp cho chúng ta thấy rằng, để tránh việc đưa ra các lớp tương đương không hợp lệ tức là thực hiện phân hoạch tương đương không chính xác, cần chú ý một số nguyên tắc sau: Các lớp phân hoạch con là những lớp hoàn toàn độc lập tức là hai lớp tương đương bất kì không được có phần tử chung giao nhau Khi chúng ta thực hiện phân lớp tương đương thì không để tồn tại một lớp con là tập rỗng Hợp của các lớp con phải chứa toàn bộ các phần tử của tập ban đầu để đảm bảo tính đầy đủ của dữ liệu sau khi phân lớp tương đương [2]

Việc thiết kế ca kiểm thử cho phân lớp tương đương dựa trên sự đánh giá về các lớp tương đương với một điều kiện vào Lớp tương đương biểu thị cho tập các trạng thái hợp lệ hay không hợp lệ đối với điều kiện vào Trong phân hoạch tương đương, dữ liệu được phân hoạch thành một trong hai lớp sau: Lớp tương đương hợp lệ (chứa dữ liệu nằm trong miền

hợp lệ) và lớp tương đương không hợp lệ (chứa dữ liệu nằm trong miền không hợp lệ) Để

xác định các lớp tương đương cho miền giá trị của các biến đầu vào, chúng ta có thể áp dụng

các nguyên tắc dưới đây [1]

Nếu điều kiện vào là phạm vi rộng giới hạn một miền hay những giá trị đặc biệt thì cần xác định một lớp tương đương hợp lệ (lớp tương đương này bao gồm các giá trị nằm trong phạm vi giới hạn của biến đầu vào) và hai lớp tương đương không hợp lệ (bao gồm một lớp tương đương chứa các giá trị nằm bên dưới cận dưới của phạm vi giới hạn biến và một lớp tương đương chứa các giá trị ở trên cận trên phạm vi giới hạn biến đầu vào)

Nếu điều kiện vào đặc tả một thành phần của một tập hoặc điều kiện bool thì cần xác định hai lớp tương đương bao gồm một lớp tương đương hợp lệ (lớp này chứa các giá trị nằm trong miền hợp lệ của biến đầu vào) và một lớp tương đương không hợp lệ (chứa toàn bộ các giá trị nằm trong miền không hợp lệ của biến đầu vào cần kiểm thử)

Kiểm thử theo phân lớp tương đương bao gồm ba phương pháp, phân lớp tương đương

yếu, phân lớp tương đương mạnh và phân lớp tương đương truyền thống Các phương pháp

này sẽ được lần lượt trình bày chi tiết trong các mục 3.2.1, 3.2.2 và 3.2.3 của chương 3 [6]

3.2.1 Phân lớp tương đương yếu

Phân lớp tương đương yếu [6] là một phương pháp hay được sử dụng khi lựa chọn phân lớp tương đương Phương pháp này vẫn dựa trên nguyên tắc chung của phân lớp tương đương, tức là chúng ta cũng chia miền dữ liệu của các biến đầu vào thành các lớp con tương đương Việc sinh các trường hợp kiểm thử trong phân lớp tương đương yếu phải đảm bảo mỗi lớp con được kiểm tra ít nhất một lần Điều này có nghĩa là trong tập ca kiểm thử sinh ra thì giá trị của phần tử đại diện cho mỗi lớp con phải được kiểm thử ít nhất một lần Như vậy, số trường hợp kiểm thử trong phân lớp tương đương yếu bằng giá trị lớn nhất của số phân hoạch biến đầu vào hay chính là lực lượng lớn nhất của phân hoạch Giả sử hàm cần kiểm thử có 3 biến đầu vào a,b,c và tập phân hoạch như sau:

3.2.2 Phân lớp tương đương mạnh

Với phương pháp này, sau khi phân hoạch miền giá trị của các biến đầu vào thành các lớp tương đương thì việc sinh các trường hợp kiểm thử thực hiện theo nguyên tắc mỗi ca kiểm thử là một phần tử của tích đề các của các phân hoạch con đó Do đó số lượng ca kiểm thử sinh ra chính là số phần tử của tích đề các này Áp dụng cho bài toán trong mục 3.2.1 ở trên với ba biến đầu vào a,b,c ta có 24 ca kiểm thử được sinh ra như trong bảng 3.6

Bảng 3.6 Các ca kiểm thử sinh ra theo phân lớp tương đương mạnh

3.2.3 Phân lớp tương đương truyền thống

Phân lớp tương đương truyền thống là phương pháp đơn giản nhất trong các kỹ thuật kiểm thử theo phân lớp tương đương Với phương pháp này thì việc phân lớp tương đương cho miền giá trị của các biến đầu vào chỉ cần quan tâm 02 lớp sau: Lớp tương đương hợp lệ (chứa dữ liệu của biến đầu vào nằm trong miền hợp lệ) và lớp tương đương không hợp lệ (chứa dữ liệu của biến đầu vào nằm trong miền không hợp lệ)

Ý tưởng của việc sinh ca kiểm thử cho phương pháp này thực hiện theo nguyên tắc: Khi chúng ta xây dựng ca kiểm thử cho trường hợp đúng thì chỉ cần lấy các giá trị biến đầu vào nằm trong miền hợp lệ Tức là ca kiểm thử sinh ra với điều kiện giá trị đầu vào của tất

cả các biến đều nằm trong miền hợp lệ Khi tạo ca kiểm thử cho trường hợp sai thì chỉ cần lấy một trong các biến đầu vào có giá trị không nằm trong miền hợp lệ Tức là với các biến đầu vào không hợp lệ, mỗi ca kiểm thử sẽ bao gồm một biến đầu vào có giá trị nằm trong miền không hợp lệ và các biến còn lại có giá trị nằm trong miền hợp lệ

Ví dụ, bài toán Commission dưới đây trình bày nguyên tắc tính tiền thưởng cho người bán hàng với ba biến đầu vào lock, stock và barrel với miền giá trị giới hạn như sau:

1<=lock<=70 1<=stock<=80 1<=barrel<=90 Theo phân lớp tương đương truyền thống, chúng ta xác định các miền dữ liệu hợp lệ

và không hợp lệ của các biến đầu vào như bảng 3.7