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

ĐẠ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







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





Ngành : CÔNG NGHỆ THÔNG TIN
Chuyên ngành : CÔNG NGHỆ PHẦN MỀM
Mã số : 60 48 10

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





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

Viết tắt
Tên đầy đủ
AT
Acceptance Test
BVT
Boundary Value Testing
DT
Decision Table
EP
Equivalence Partitioning
ST
System Test
UT
Unit Test



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



1


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.


2


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.
3


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
4


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].

5



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.

6


Đố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.
7


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].
8



Hình 2.2. Sơ đồ các cấp độ kiểm thử.
2.4.1. Kiểm thử đơn vị
Một đơn vị (unit) là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được. Ví dụ,
các hàm, thủ tục, lớp hay phương thức đều có thể được xem là đơn vị. Các thành phần đơn

vị này sẽ được kiểm thử tại cấp độ kiểm thử mức đơn vị trong quy trình kiểm thử phần
mềm.
Kiểm thử đơn vị hay còn gọi là unit testing (UT), là cấp độ kiểm thử cho phép bạn
kiểm tra, tìm kiếm lỗi bên trong chức năng của chương trình phần mềm (ví dụ module, đối
tượng, lớp, ). Thông thường việc kiểm thử mức module đơn vị sẽ do lập trình viên thực
hiện trước khi nó được chuyển giao sang giai đoạn tích hợp với các module khác. Công
đoạn này cần được thực hiện càng sớm càng tốt trong giai đoạn viết mã nguồn và xuyên
suốt chu kỳ phát triển phần mềm.
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.
9


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.
2.4.2. Kiểm thử tích hợp
Kiểm thử tích hợp - intergration test là sự kết hợp các thành phần của một ứng dụng và kiểm
thử chúng như một ứng dụng đã hoàn thành. Trong khi UT kiểm tra các thành phần và đơn
vị riêng lẻ thì kiểm thử tích hợp kết hợp chúng lại với nhau và kiểm tra sự giao tiếp và tương
tác giữa chúng. Kiểm thử tích hợp là giai đoạn tiếp theo của kiểm thử đơn vị, nó được thực
hiện bởi nhóm kiểm thử viên và tập trung vào việc tích hợp các thành phần đơn vị của hệ
thống. Trước khi thực thi kiểm thử tích hợp chúng ta phải đảm bảo rằng các thành phần đơ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.
10

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
11

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
12


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.
13


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ẽ.





14


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
tập hợp thành các tập con.
Phương pháp kiểm thử giá trị biên có 04 kỹ thuật chính và các kỹ thuật này sẽ được lần
lượt trình bày chi tiết trong mục 3.1 của luận văn bao gồm.
Kỹ thuật cơ bản
Kiểm thử biên mở rộng
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.


15

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 >.