Tìm hiểu, nghiên cứu các kỹ thuật cho kiểm thử miền và cải tiến các kỹ thuật đó

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

TRẦN VĂN TRỌNG


TÌM HIỂU, NGHIÊN CỨU CÁC KỸ THUẬT CHO KIỂM
THỬ MIỀN VÀ CẢI TIẾN CÁC KỸ THUẬT ĐÓ






LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

HÀ NỘI - 2014







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

TRẦN VĂN TRỌNG


TÌM HIỂU, NGHIÊN CỨU CÁC KỸ THUẬT CHO KIỂM
THỬ MIỀN VÀ CẢI TIẾN CÁC KỸ THUẬT ĐÓ


Ngành: Công nghệ thông tin
Chuyên ngành: Kỹ thuật phần mềm
Mã số: 60480103


LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƢỜI HƢỚNG DẪN KHOA HỌC: TS. ĐẶNG VĂN HƢNG





HÀ NỘI - 2014

3


LỜI CAM ĐOAN
Tôi xin cam đoan kết quả đạt đƣợc trong luận văn là sản phẩm nghiên cứu, tìm
hiểu của riêng cá nhân tôi. Trong toàn bộ nội dung của luận văn, những điều đƣợc
trình bày hoặc là của cá nhân tôi hoặc là đƣợc tổng hợp từ nhiều nguồn tài liệu. Tất cả
các tài liệu tham khảo đều có xuất xứ rõ ràng và đƣợc trích dẫn hợp pháp.
Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định
cho lời cam đoan của mình.


Hà Nội, ngày 11 tháng 06 năm 2014
Ngƣời cam đoan




Trần Văn Trọng

4


LỜI CẢM ƠN
Sau thời gian học tập nghiên cứu và rèn luyện tại trƣờng Đại học Công nghệ - Đại
học Quốc gia Hà Nội, em đã học hỏi đƣợc thêm nhiều kiến thức cũng nhƣ những kỹ
năng góp phần hỗ trợ tốt trong công việc của mình. Đến nay em đã hoàn thành chƣơng
trình đào tạo và luận văn tốt nghiệp của mình.
Em xin chân thành cảm ơn Ban giám hiệu nhà trƣờng đã quan tâm tạo điều kiện
thuận lợi để chúng em học tập trong suốt quãng thời gian tại trƣờng.
Xin chân thành cảm ơn các Thầy, Cô giáo trong khoa Công nghệ thông tin nói
riêng và thầy cô giáo các khoa trong trƣờng nói chung đã luôn nhiệt tình giúp đỡ và
tạo điều kiện tốt nhất cho em trong suốt quá trình học tập tại trƣờng.
Em xin chân thành cảm ơn TS. Đặng Văn Hƣng là cán bộ giảng viên của trƣờng
Đại học Công Nghệ đã tận tình giúp đỡ em về cả chuyên môn, nghiên cứu và định
hƣớng phát triển trong suốt quá trình làm luận văn.
Xin chân thành cảm ơn các bạn học viên khóa K18 – những ngƣời bạn thân thiện,
nhiệt tình giúp đỡ và chia sẻ cho tôi kinh nghiệm trong công việc, học tập cũng nhƣ
trong cuộc sống trong suốt thời gian học tập cùng nhau.
Cuối cùng, với gia đình, con xin gửi lời biết ơn sâu sắc vì gia đình đã luôn ở bên
và ủng hộ con trên con đƣờng học tập và nghiên cứu khó khăn, vất vả của mình.

Hà Nội, ngày 11 tháng 06 năm 2014
Học viên

Trần Văn Trọng




5


MỤC LỤC

LỜI CAM ĐOAN 3
LỜI CẢM ƠN 4
MỤC LỤC 5
DANH MỤC CÁC BẢNG BIỂU 7
DANH MỤC CÁC HÌNH VẼ 9
LỜI MỞ ĐẦU 11
Chƣơng 1. LÝ THUYẾT VỀ KIỂM THỬ MIỀN 15
1.1 Khái quát kiểm thử đơn vị 15
1.1.1 Kiểm thử dòng điều khiển 15
1.1.2 Kiểm thử dòng dữ liệu 19
1.1.3 Kiểm thử miền 21
1.2 Kiểm thử miền 22
1.2.1 Khái niệm về lỗi miền 22
1.2.2 Xây dựng các miền kiểm thử từ chƣơng trình 25
1.2.3 Các kiểu xuất hiện của lỗi miền 29
1.2.4 Xây dựng các điểm kiểm tra ON và OFF trong kiểm thử miền 33
1.2.5 Xây dựng các chiến lƣợc lựa chọn ca kiểm thử 36
Chƣơng 2: CÁC KỸ THUẬT CẢI TIẾN KIỂM THỬ MIỀN 45
2.1 Cải tiến kỹ thuật lựa chọn điểm ON và OFF từ phƣơng pháp cơ bản 45

2.2 Xây dựng chiến lƣợc bổ sung cho kiểm thử miền 50
2.2.1 Phân tích lỗi tiềm ẩn của chiến lƣợc kiểm thử miền Nx1 50
2.2.2 Chiến lƣợc thay thế chiến lƣợc kiểm tra miền Nx1 51
2.3 Đơn giản hóa kỹ thuật kiểm thử miền 51
Chƣơng 3: THỰC NGHIỆM KIỂM THỬ MIỀN 60
3.1 Mô tả bài toán 60
3.2 Xây dựng các ca kiểm thử với phƣơng pháp kiểm thử miền 61
3.2.1 Xác định các miền từ mã nguồn chƣơng trình 61
6


3.2.2 Xây dựng các ca kiểm thử cho từng miền. 63
3.3 Ứng dụng các ca kiểm thử có đƣợc từ phƣơng pháp kiểm thử miền để kiểm
tra tính chính xác của phần mềm 67
3.3.1 Kiểm thử với mô-đun “Mô-đun xét trúng tuyển 01” 68
3.3.2 Kiểm thử với mô-đun “Mô-đun xét trúng tuyển 02” 68
3.4 Xây dựng các ca kiểm thử với phƣơng pháp dòng điều khiển 69
3.5 Ứng dụng các ca kiểm thử có đƣợc từ phƣơng pháp kiểm thử dòng điều khiển
để kiểm tra tính chính xác của phần mềm 72
3.5.1 Kiểm thử với mô-đun “Mô-đun xét trúng tuyển 01” 72
3.5.2 Kiểm thử với mô-đun “Mô-đun xét trúng tuyển 02” 72
3.6 Kết luận 73
KẾT LUẬN VÀ ĐỊNH HƢỚNG NGHIÊN CỨU 74
1. Các kết quả đạt đƣợc: 74
2. Định hƣớng phát triển: 74
TÀI LIỆU THAM KHẢO 76

7


DANH MỤC CÁC BẢNG BIỂU

Bảng 1.1: Hàm tính trung bình cộng cho các số lẻ < 100 17
Bảng 1.2: Danh sách các ca kiểm thử cho ví dụ về kiểm thử dòng điều khiển 18
Bảng 1.3: Danh sách các ca kiểm thử cho ví dụ về kiểm thử dòng dữ liệu 21
Bảng 1.4: Mã chƣơng trình tính điểm trung bình toán và văn 23
Bảng 1.5: Mã chƣơng trình codedomain 25
Bảng 1.6: Hai giải thích của tuyên bố if() thứ 2 trong hình 1.7 27
Bảng 1.7: Hàm tính điểm tổng kết môn học trong ví dụ 05 29
Bảng 1.8: Các vị từ định nghĩa trong miền TT trong Hình 1.8. 29
Bảng 1.9: Phát hiện lỗi khi biên dịch chuyển làm giảm đi độ lớn miền xét (Closed
Inequality) 37
Bảng 1.10: Phát hiện lỗi khi biên dịch chuyển làm tăng độ lớn miền xét (Closed
Inequality) 39
Bảng 1.11: Phát hiện lỗi nghiêng biên (Closed Inequality) 40
Bảng 1.12: Phát hiện lỗi đóng biên (Closed Inequality) 40
Bảng 1.13: Phát hiện lỗi khi biên dịch chuyển làm giảm đi độ lớn miền (Open
Inequality) 41
Bảng 1.14: Phát hiện lỗi khi biên dịch chuyển làm tăng độ lớn miền xét (Open
Inequality) 42
Bảng 1.15: Phát hiện lỗi khi nghiêng biên (Open Inequality) 43
Bảng 1.16: Phát hiện lỗi khi xảy ra lỗi đóng biên (Open Inequality) 44
Bảng 2.1: Chƣơng trình mô tả Ví dụ 06 53
Bảng 2.2: Các ca kiểm thử cho kết quả tốt nghiệp trong trƣờng hợp điểm nghề <8. 55
Bảng 2.3: Quan hệ tƣơng tác giữa các biến của chƣơng trình. 56
Bảng 2.4: Các ca kiểm thử cho kết quả tốt nghiệp trong trƣờng hợp điểm nghề <8 với

hai biến X và Y. 57
Bảng 2.5: Các ca kiểm thử cho kết quả tốt nghiệp trong trƣờng hợp điểm nghề <8 với
biến Z. 58
Bảng 2.6: Các ca kiểm thử cho kết quả tốt nghiệp trong trƣờng hợp điểm nghề <8 với
phƣơng pháp mới. 58
Bảng 3.1: Chƣơng trình xét tuyển cấp 3 60
Bảng 3.2: Các ca kiểm thử cho miền D
1
tƣơng ứng với biên EK 65
Bảng 3.3: Các ca kiểm thử cho miền D
1
tƣơng ứng với biên KH 66
8


Bảng 3.4: Các ca kiểm thử cho miền D
1
tƣơng ứng với biên HE 66
Bảng 3.5: Danh sách các ca kiểm thử cho miền D
1
67
Bảng 3.6: So sánh kết quả thực nghiệm các ca kiểm thử trong mô-đun 1 68
Bảng 3.7: So sánh kết quả thực nghiệm các ca kiểm thử trong mô-đun 2 69
Bảng 3.8: Danh sách các đƣờng đi đảm bảo độ phủ cho độ đo cấp 3 của bài toán trong
Phần 3.1 71
Bảng 3.9: Danh sách các ca kiểm thử cho độ đo cấp 3 của bài toán trong Phần 3.1 71
Bảng 3.10: So sánh kết quả thực nghiệm các ca kiểm thử có đƣợc từ phƣơng pháp
kiểm thử dòng điều khiển trong mô-đun 1 72
Bảng 3.11: So sánh kết quả thực nghiệm các ca kiểm thử có đƣợc từ phƣơng pháp
kiểm thử dòng điều khiển trong mô-đun 2 72

9


DANH MỤC CÁC HÌNH VẼ

Hình 1.1: Các thành phần cơ bản của đồ thị chƣơng trình. 16
Hình 1.2: Các cấu trúc điều khiển phổ biến của chƣơng trình. 16
Hình 1.3: Ví dụ về biểu đồ cho kiểm thử dòng kiều khiển 18
Hình 1.4: Ví dụ biểu đồ cho kiểm thử dòng dữ liệu 20
Hình 1.5: Cấu trúc tổng quát của một chƣơng trình 24
Hình 1.6: Phân loại miền đầu vào của chƣơng trình 24
Hình 1.7: Đồ thị dòng điều khiển mô tả các chức năng trong Bảng 1.5 26
Hình 1.8: Các miền thu đƣợc từ các giải thích vị từ trong hình 1.7 28
Hình 1.9: Miền vào cho chƣơng trình ở Bảng 1.7 29
Hình 1.10: Các dạng miền và biên trong kiểm thử miền 30
Hình 1.11: Minh họa cho lỗi đóng biên 31
Hình 1.12: Minh họa cho lỗi dịch chuyển biên 32
Hình 1.13: Minh họa cho lỗi nghiêng biên 32
Hình 1.14: Điểm ON và OF 35
Hình 1.15: Biên dịch chuyển làm giảm đi độ lớn miền xét (closed inequality). 37
Hình 1.16: Biên dịch chuyển làm tăng độ lớn miền xét (closed inequality). 38
Hình 1.17: Biên nghiêng (closed inequality). 39
Hình 1.18: Lỗi đóng biên (closed inequality). 40
Hình 1.19: Biên dịch chuyển làm giảm đi độ lớn miền xét (open inequality). 41
Hình 1.20: Biên dịch chuyển làm tăng độ lớn miền xét (open inequality). 42

Hình 1.21: Lỗi nghiêng biên (open inequality). 43
Hình 1.22: Lỗi đóng biên (open inequality). 43
Hình 1.23: Biên bình đẳng 44
Hình 2.1: Các trƣờng hợp phỏng đoán của biên dự kiến 45
Hình 2.2: Lựa chọn điểm ON trong trƣờng hợp lỗi dịch chuyển biên 46
Hình 2.3: Lựa chọn điểm ON trong trƣờng hợp lỗi nghiêng biên 47
Hình 2.4: Lựa chọn điểm ON trong trƣờng hợp lỗi đóng biên 48
Hình 2.5: Lựa chọn điểm OFF trong trƣờng hợp lỗi dịch chuyển biên 49
Hình 2.6: Lựa chọn điểm OFF trong trƣờng hợp lỗi nghiêng biên 49
Hình 2.7: Lỗi nghiêng biên tạo ra miền lỗi vô hạn 50
Hình 2.8: Chiến lƣợc kiểm thử miền 2x2 51
Hình 2.9: Biểu đồ dòng điều khiển cấp 3 của Ví dụ 06 54
10


Hình 2.10: Các miền đầu vào của chƣơng trình trong Ví dụ 06 khi điểm nghề <8. 55
Hình 2.11: Các miền đầu vào của chƣơng trình xét với hai biến X và Y trong Ví dụ 06
khi điểm nghề <8. 57
Hình 2.12: Các miền đầu vào của chƣơng trình xét với biến Z trong Ví dụ 06 khi điểm
nghề <8. 58
Hình 3.1: Biểu đồ dòng điều khiển của chƣơng trình xét tuyển cấp 3 62
Hình 3.2: Các miền đầu vào của chƣơng trình 63
Hình 3.3: Xác định điểm ON và OFF trên biên EK cho miền D
1
64
Hình 3.4: Xác định điểm ON và OFF trên biên KH cho miền D
1
65
Hình 3.5: Xác định điểm ON và OFF trên biên HE cho miền D
1

66
Hình 3.6: Giao diện chƣơng trình xét điểm tuyển sinh. 67
Hình 3.7: Tạo ra lỗi trong chƣơng trình xét tuyển cấp 3 ở Phần 3.1 68
Hình 3.8: Lỗi dịch chuyển biên tạo ra trong đoạn code của hình 3.7 69
Hình 3.9: Sơ đồ dòng điều khiển ứng với độ đo cấp 3 của bài toán 70







11


LỜI MỞ ĐẦU
Cơ sở khoa học và thực tiễn của đề tài
Ngày nay, cùng với xu hƣớng công nghệ thông tin toàn cầu hóa, không chỉ trên thế
giới mà ngay tại trong nƣớc, việc xuất hiện các công ty sản xuất phần mềm đã không
còn xa lạ. Tuy nhiên có thể đánh giá một cách khách quan rằng thị trƣờng công nghệ
phần mềm trong nƣớc ta còn chƣa cao, hệ thống phần mềm đƣợc xây dựng trong nƣớc
đã khá phong phú nhƣng hầu nhƣ chỉ tập trung ở việc phục vụ những nhu cầu dịch vụ
vừa và nhỏ cho hoạt động xã hội. Lý do rất đơn giản là sản phầm của chúng ta chƣa
thực sự đạt đƣợc chất lƣợng cũng nhƣ độ tin cậy cho khách hàng, một phần lớn cho lý
do này chính là ở việc các phần mềm đƣợc sản xuất ồ ạt tuy nhiên đều bị coi nhẹ khâu
kiểm thử.
Tại nƣớc ngoài, trong quá trình sản xuất phần mềm họ luôn coi trọng khâu kiểm
thử, có những phần mềm quan trọng chi phí cho việc kiểm thử có thể tăng lên gấp đôi
gấp ba so với chi phí cho việc thiết kế xây dựng phần mềm.
Một nghiên cứu đƣợc tiến hành bởi NIST trong năm 2002 cho biết rằng các lỗi

phần mềm gây tổn thất cho nền kinh tế Mỹ 59,5 tỷ đô mỗi năm, hơn một phần ba chi
phí này có thể tránh đƣợc nếu việc kiểm thử phần mềm đƣợc thực hiện tốt hơn. [4]
Đứng trƣớc thực trạng nhƣ hiện nay, việc cần làm nhất để cải thiện chất lƣợng
phần mềm trong nƣớc là phải chú trọng hơn vào khâu kiểm thử phần mềm. Tuy nhiên
việc đào tạo về kiểm thử phần mềm trong nƣớc còn chƣa thực sự đƣợc quan tâm.
Theo IEEE (Institute of Electrical and Electronics Engineers): kiểm thử là tiến
trình vận hành hệ thống hoặc thành phần dƣới những điều kiện xác định, quan sát hoặc
ghi nhận kết quả và đƣa ra đánh giá về hệ thống hoặc thành phần đó.
Tuy nhiên một trong những vấn đề với kiểm thử phần mềm là thực tế nó không thể
đạt đƣợc việc kiểm thử trọn vẹn hoặc toàn diện trên mọi khía cạnh. Việc kiểm thử toàn
diện hoặc trọn vẹn là không thể vì:
- Miền của đầu vào có thể là quá lớn.
- Có quá nhiều nhánh để kiểm tra trong chƣơng trình.
- Có quá nhiều sự kết hợp của dữ liệu để kiểm tra.
- Cõ lỗi giao diện ngƣời sử dụng, cấu hình và khả năng tƣơng thích thất bại, và
nhiều kích thƣớc khác nhau của việc phân tích.
Kiểm thử hiện nay vô cùng đa dạng cả về phƣơng pháp kiểm thử cũng nhƣ mức
kiểm thử. Xét về phƣơng diện mức kiểm thử cũng bao gồm nhiều mức khác nhau:
kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử mức chấp nhận.
12


Trong đó khâu kiểm thử đơn vị đóng vai trò vô cùng quan trọng và là khâu đầu tiên
trong quá trình kiểm thử.
Kiểm thử đơn vị hay còn đƣợc gọi là kiểm thử thành phần, đề cập đến việc kiểm
thử chức năng từng phần của mã, thƣờng ở mức độ chức năng. Trong một môi trƣờng
hƣớng về đối tƣợng thì điều này thƣờng là cấp độ lớp, và các kiểm thử đơn vị tối thiểu
bao gồm hàm dựng và hàm hủy. Nhiều loại kiểm thử đƣợc viết bởi các nhà phát triển
nhƣ họ làm việc trong mã (kiểu hộp trắng) để đảm bảo rằng từng hàm riêng biệt hoạt
động đúng nhƣ kỳ vọng. Một hàm có thể có nhiều kiểm thử từ đó giúp nắm bắt đƣợc

các trƣờng hợp góc hoặc các nhánh trong mã nguồn. Kiểm thử đơn vị một mình không
thể đảm bảo hết đƣợc từng chức năng của từng bộ phận trong phần phềm nhƣng nó
đƣợc sử dụng để đảm bảo rằng các khối kiến trúc của phần mềm hoạt động độc lập với
nhau.
Kiểm thử đơn vị là một quá trình phát triển phần mềm có liên quan đến ứng dụng
đồng bộ của một loạt các chiến lƣợc phòng ngừa phát hiện lỗi và để giảm thiểu rủi ro,
thời gian và chi phí. Nó đƣợc thực hiện bởi kỹ sƣ hay nhà phát triển trong suốt giai
đoạn xây dựng của vòng đời phát triển phần mềm. Không chỉ tập trung vào việc đảm
bảo chất lƣợng truyền thống mà phải gia tăng nó lên vì thế kiểm thử đơn vị có mục
đích loại bỏ những lỗi cấu trúc trƣớc khi mã hóa rồi mới thúc đẩy việc quản lý chất
lƣợng. Chiến lƣợc này nhằm nâng cao chất lƣợng cũng nhƣ hiệu quả của phần mềm
trong tiến trình quản lý và phát triển chung.
Hai phƣơng pháp phổ biến nhất áp dụng trong mức kiểm thử đơn vị là kiểm thử
dòng điều khiển và kiểm thử dòng dữ liệu, tuy nhiên hai phƣơng pháp này không xác
định các kiểu của lỗi một cách rõ ràng để xem xét và phát hiện. Một phƣơng pháp khá
phổ biến khác cũng áp dụng cho mức kiểm thử đơn vị là kiểm thử miền, trong kiểm
thử miền có cơ chế kiểm thử khá chi tiết, một loại lỗi đƣợc gọi là lỗi miền đƣợc định
nghĩa và sau đó dữ liệu kiểm tra đƣợc xác định để bắt những lỗi đó. Hiện nay kỹ thuật
kiểm thử miền trên thế giới đƣợc nghiên cứu khá nhiều, còn tại VN thì hầu nhƣ chƣa
có công trình chính thức nào nghiên cứu về kỹ thuật này.
Kiểm thử miền lần đầu tiên đƣợc đề xuất bởi White và Cohen vào năm 1978, sau
đó nó đã đƣợc phân tích và mở rộng theo nhiều cách. Năm 1982, Clarke, Hassell, và
Richardson [3] đƣa ra một số lỗi không bị phát hiện bởi chiến lƣợc của White và
Cohen. Sau đó họ đề xuất một chiến lƣợc có tên là chiến lƣợc V × V để cải thiện kiểm
thử miền, trong đó nếu một ranh giới miền đƣợc xem xét bao gồm V đỉnh thì chiến
lƣợc V × V chọn V điểm ON và V điểm OFF.
13


Bên cạnh đó cũng có một số công trình nghiên cứu xoay quanh việc phân tích các

vị từ đề tìm ra phƣơng pháp kiểm thử hiệu quả thông qua các kỹ thuật lựa chọn điểm
ON và điểm OFF hợp lý cho từng trƣờng hợp cụ thể.
Tại hội nghị VISTACON tổ chức vào năm 2010, kiểm thử miền cũng đƣợc giới
thiệu ở Việt Nam chính thức qua bài giới thiệu tổng quan của Cem Kaner [6]. Tuy
nhiên tại hội nghị cũng chỉ đề cập đến những vấn đề rất chung chung trong kiểm thử
miền chứ chƣa đi vào phân tích chi tiết và các kỹ thuật để nâng cao hiệu quả cũng nhƣ
đơn giản hóa trong quá trình tiến hành kiểm thử.
Mục tiêu luận văn
Khái niệm cơ bản về kiểm thử miền là bạn có một miền giá trị rất lớn có thể có
cho một biến của một chƣơng trình, do đó bạn cần chia nhỏ nó ra thành các tập con
tƣơng đƣơng theo nghĩa mỗi miền tƣơng ứng với một nhánh của chƣơng trình. Các
miền này đƣợc biểu diễn nhƣ các miền giới hạn bởi các đồ thị của các hàm số trong
không gian n chiều. Việc biểu diễn sai các hàm này dẫn đến lỗi miền, tức là dữ liệu
trong miền không tƣơng ứng với nhánh chƣơng trình mong muốn của miền. Tìm các
ca kiểm thử để phát hiện các lỗi miền là nhiệm vụ của kiểm thử miền.
Mục tiêu nghiên cứu:
- Đề tài tập trung vào việc nghiên cứu các kỹ thuật chia nhỏ miền giá trị cho các
biến số đầu vào của chƣơng trình và tìm các ca kiểm thử đối với các lỗi miền
hay gặp.
- Tìm hiểu, nghiên cứu các kỹ thuật sinh ca kiểm thử cho kiểm thử miền
- Từ các kỹ thuật đã có và đƣợc nghiên cứu, tìm hiểu đánh giá và cái tiến trong
các kỹ thuật phục vụ cho việc sinh ca kiểm thử tối ƣu hơn.
- Đề xuất ra chiến lƣợc phù hợp giúp đơn giản hóa kiểm thử miền và nâng cao
hiệu quả áp dụng kiểm thử miền trong quá trình kiểm thử
- Quá trình nghiên cứu hy vọng sẽ là một tài liệu tốt hỗ trợ cho việc đào tạo về
kiểm thử miền trong nƣớc.
Phƣơng pháp và phạm vi nghiên cứu của luận văn
Với tính chất luận văn là một đề tài thiên về nghiên cứu các kỹ thuật mới trong
kiểm thử. Luận văn sẽ tìm hiểu các kỹ thuật cơ bản nhất trong kiểm thử miền đƣợc đề
xuất từ các công trình nghiên cứu trên thế giới. Từ đó trích rút để xây dựng thành bộ

tài liệu tiếng việt cho ngƣời việt.
Bên cạnh đó cần tìm hiểu các kỹ thuật để giúp cải tiến chất lƣợng các ca kiểm thử
đƣợc tìm ra nhằm nâng cao khả năng ứng dụng của mỗi ca kiểm thử. Ngoài ra luận
14


văn cũng cần phải xây dựng đƣợc chiến lƣợc mới áp dụng kết hợp với kiểm thử miền
giúp giải quyết các trƣờng hợp phúc tạp của chƣơng trình.
Dựa vào số lƣợng các biến quan hệ trong một vị từ là một biến, hai biến hay ba
biến mà ta quy việc xác định các miền cho chƣơng trình trong không gian một chiều,
hai chiều hay ba chiều. Tuy nhiên khi số biến quan hệ nhau gia tăng lên đến hơn 4 biến
và các vị từ là các hàm phi tuyến tình thì việc xác định miền trở nên phức tạp hơn
trong không gian 4 chiều, năm chiều Do đó để đảm bảo chất lƣợng luận văn nên các
trƣờng hợp này không đề cập đến.
Luận văn nghiên cứu nên sau quá trình tìm hiểu cần xây dựng các ví dụ chƣơng
trình cụ thể ở mức cơ bản áp dụng lý thuyết để đảm bảo tính chất nắm vững kỹ thuật
giúp cho ngƣời đọc dễ hình dung tổng thể về kiểm thử miền.
Nội dung luận văn
Luận văn cần toát lên đƣợc mục tiêu của nó, lý do lựa chọn hƣớng nghiên cứu và
kết quả đã đạt đƣợc. Nội dung bao gồm:
- Mở đầu: đặt vấn đề, đƣa ra mục tiêu và các kết quả mong muốn cần đạt đƣợc
sau quá trình nghiên cứu.
- Chƣơng 1: Lý thuyết về kiểm thử miền: giới thiệu tổng quan về kiểm thử đơn
vị và tóm tắt ba phƣơng pháp kiểm thử đơn vị động. Nghiên cứu về các lý
thuyết kiểm thử miền cơ bản.
- Chƣơng 2: Các kỹ thuật cải tiến kiểm thử miền: nghiên cứu các cải tiến cho
kiểm thử miền nhằm nâng cao chất lƣợng của các ca kiểm thử cũng nhƣ đơn
giản hóa việc kiểm thử miền trong các trƣờng hợp phát sinh phức tạp.
- Chƣơng 3: Thực nghiệm kiểm thử miền: xây dựng ví dụ áp dụng các kỹ thuật
đã nghiên cứu về kiểm thử miền, và chứng minh thực nghiệm về hiệu quả của

các ca kiểm thử.
- Kết luận và định hƣớng: Tổng kết lại nội dung đã nghiên cứu. Đƣa ra hƣớng
phát triển trong tƣơng lai.

15


Chƣơng 1. LÝ THUYẾT VỀ KIỂM THỬ MIỀN
1.1 Khái quát kiểm thử đơn vị
Kiểm thử đơn vị [1] là việc kiểm thử các đơn vị của chƣơng trình một cách độc
lập. Trong đó một đơn vị chƣơng trình thƣờng là một đoạn mã nguồn có thể là hàm
hoặc phƣơng thức của một lớp nào đó, có thể đƣợc gọi từ ngoài, và cũng có thể gọi
đến các đơn vị chƣơng trình khác. Mỗi đơn vị chƣơng trình cần đƣợc kiểm thử riêng
biệt để phát hiện lỗi trong bên trong nó và khắc phục trƣớc khi đƣợc tích hợp với các
đơn vị khác. Kiểm thử đơn vị thƣờng đƣợc làm bởi chính tác giả của chƣơng trình.
Hai kỹ thuật kiểm thử phổ biến nhất đang đƣợc áp dụng cho kiểm thử đơn vị hiện
nay trong nƣớc là kiểm thử dòng điều khiển và kiểm thử dòng dữ liệu. Cả hai kỹ thuật
này đều đƣợc tiến hành theo phƣơng pháp kiểm thử hộp trắng. Chúng sử dụng các
chiến lƣợc cụ thể và mã nguồn để kiểm tra xem từng đơn vị phần mềm có thực hiện
đúng so với thiết kế và đặc tả hay không.
Trong khi các phƣơng pháp kiểm thử hộp đen hay kiểm thử hàm/chức năng chỉ
cho phép phát hiện các lỗi/khiếm khuyết có thể quan sát đƣợc, kiểm thử hộp trắng cho
phép phát hiện các lỗi/khiếm khuyết tiềm ẩn bên trong từng đơn vị chƣơng trình. Để
áp dụng các phƣơng pháp kiểm thử hộp trắng, ngƣời kiểm thử đòi hỏi cần phải hiểu rõ
giải thuật và cần có các kỹ năng, kiến thức tốt về ngôn ngữ lập trình đƣợc dùng để phát
triển phần mềm mới có thể hiểu rõ mã nguồn của chƣơng trình đƣợc kiểm thử.
1.1.1 Kiểm thử dòng điều khiển
Theo [1] thì Phƣơng pháp kiểm thử dòng điều khiển xây dựng dựa trên khái niệm
đồ thị dòng điều khiển (control flow graph). Trong đó đồ thị dòng điều khiển đƣợc xây
dựng từ mã nguồn của chƣơng trình. Đồ thị dòng điều khiển là một đồ thị có hƣớng

bao gồm các đỉnh đồ thị tƣơng ứng với các câu lệnh/nhóm câu lệnh và các cạnh chính
là các dòng điều khiển giữa các câu lệnh/nhóm câu lệnh. Ta giả sử nếu i và j là các
đỉnh của đồ thị dòng điều khiển thì khi đó sẽ tồn tại một cạnh từ i đến j nếu lệnh tƣơng
ứng với j có thể đƣợc thực hiện ngay sau lệnh tƣơng ứng với i.
Hình 1.1 mô tả các thành phần cơ bản của đồ thị dòng điều khiển bao gồm Điểm
xuất phát của đơn vị chƣơng trình, Khối xử lý (chứa các câu lệnh khai báo hoặc tính
toán), Điểm quyết định (ứng với các câu lệnh điều kiện trong các khối lệnh rẽ nhánh
hoặc lặp), Điểm nối (ứng với các câu lệnh ngay sau các lệnh rẽ nhánh), và Điểm kết
thúc (ứng với điểm kết thúc của đơn vị chƣơng trình).
16



Hình 1.1: Các thành phần cơ bản của đồ thị chương trình.
1

Hình 1.2 mô tả các cấu trúc điều khiển phổ biến của chƣơng trình. Chúng ta sẽ sử
dụng các thành phần cơ bản và các cấu trúc phổ biến này để dễ dàng xây dựng đồ thị
dòng điều khiển cho mọi đơn vị chƣơng trình viết bằng mọi ngôn ngữ lập trình.

Hình 1.2: Các cấu trúc điều khiển phổ biến của chương trình.
2

Kiểm thử dòng điều khiển cho phép phát hiện ra các lỗi tiềm ẩn trong chƣơng trình
bằng cách kiểm thử các đƣờng đi của chƣơng trình tƣơng ứng với các dòng điều khiển
có thể có. Kỹ thuật kiểm thử dòng điều khiển đƣợc phân cấp ra thành các độ đo khác
nhau từ đơn giản đến phức tạp tƣơng ứng với các đồ thị cụ thể. Từ đồ thị thu đƣợc sẽ
sinh ra các đƣờng đi của chƣơng trình. Thông qua mỗi đƣờng đi sẽ sinh ra một ca kiểm
thử đáp ứng đƣờng đi đó. Ngƣời kiểm thử cần phải chọn một bộ đầu vào thỏa mãn các
điểm quyết định có trong đƣờng đi tƣơng ứng của đồ thị. Giá trị đầu ra mong muốn

ứng với mỗi bộ đầu vào của mỗi ca kiểm thử cũng đƣợc tính toán. Việc này thƣờng đòi
hỏi ngƣời thực hiện phải có kỹ năng phân tích chƣơng trình mới thực hiện đƣợc. Khi
một lỗi đƣợc phát hiện bởi một ca kiểm thử nào đó, nó sẽ đƣợc thông báo tới lập trình
viên để tiến hành sửa lỗi đã phát hiện.
Các độ đo kiểm thử:
- Độ đo kiểm thử cấp 1 (C1): mỗi câu lệnh đƣợc thực hiện ít nhất một lần sau
khi chạy các ca kiểm thử.


1
Nguồn: [1]
2
Nguồn: [1]
17


- Độ đo kiểm thử cấp 2 (C2): các điểm quyết định trong đồ thị dòng điều khiển
của đơn vị kiểm thử đều đƣợc thực hiện ít nhất một lần cả hai nhánh đúng và
sai.
- Độ đo kiểm thử cấp 3 (C3): các điều kiện con thuộc các điều kiện phức tạp
tƣơng ứng với các điểm quyết định trong đồ thị dòng điều khiển của đơn vị
cần kiểm thử đều đƣợc thực hiện ít nhất một lần cả hai nhánh đúng và sai
*) Ví dụ 01: Xây dựng hàm cho nhập vào một mảng n phần tử, tính trung bình cộng
các phần tử là số lẻ trong mảng nhỏ hơn 100 và trả lại kết quả cho giá trị hàm.
Bảng 1.1: Hàm tính trung bình cộng cho các số lẻ < 100
public double AVG_Sole(int[] s) {
double sum = 0;
int dem = 0;
int i=0;
while(i<s.Length){

if (s[i] % 2 != 0 && s[i]<100) {
sum += s[i];
dem++;
}
i++;
}
return sum / dem;
}

Ta xây dựng đƣợc sơ đồ dòng điều khiển ứng với độ đo cấp 3 nhƣ Hình 1.3.
Các trạng thái:
1,2,3,4,5,6,7,3,8
1,2,3,4,5,7,3,8
1,2,3,4,7,3,8
1,2,3,8

18



Hình 1.3: Ví dụ về biểu đồ cho kiểm thử dòng kiều khiển
Từ danh sách các trạng thái ta xác định đƣợc các ca kiểm thử nhƣ trong Bảng 1.2
Bảng 1.2: Danh sách các ca kiểm thử cho ví dụ về kiểm thử dòng điều khiển
Ca kiểm thử
Kết quả dự kiến
Error
{ 5, 7, 8,1, 9,105,4}
5,5

{ 2,4,6 }

…
Lỗi chia cho 0 tại vị trí 8
{}
…
Lỗi chia cho 0 tại vị trí 8
19


Việc áp dụng phƣơng pháp kiểm thử dòng điều khiển là khó và tốn kém hơn các
phƣơng pháp kiểm thử hộp đen khác (phân hoạch tƣơng đƣơng, phân tích giá trị biên,
bảng quyết định, ). Để áp dụng kỹ thuât này cần đội ngũ nhân lực về kiểm thử có
kiến thức, kỹ năng tốt. Ngoài ra cần chi phí lớn đầu tƣ cho các nguồn lực khác (tài
chính, thời gian, ) mới có thể thực hiện tốt phƣơng pháp này. Đây cũng có thể coi là
yêu cầu chung đối với các phƣơng pháp kiểm thử hộp trắng.
1.1.2 Kiểm thử dòng dữ liệu
Kỹ thuật kiểm thử dòng dữ liệu xem đơn vị chƣơng trình gồm các đƣờng đi tƣơng
ứng với các dòng dữ liệu, nơi mà các biến đƣợc khai báo, đƣợc gán giá trị, đƣợc sử
dụng để tính toán và trả lại kết quả mong muốn của đơn vị chƣơng trình ứng với
đƣờng đi này. Với mỗi đƣờng đi, ngƣời kiểm thử sẽ sinh một ca kiểm thử để kiểm tra
tính đúng đắn của nó. Cũng theo [1] thì quá trình kiểm thử dòng dữ liệu đƣợc chia
thành hai pha riêng biệt: kiểm thử dòng dữ liệu tĩnh (static data flow testing) và kiểm
thử dòng dữ liệu động (dynamic data flow testing). Với kiểm thử dòng dữ liệu tĩnh,
chúng ta áp dụng các phƣơng pháp phân tích mã nguồn mà không cần chạy chƣơng
trình nhằm phát hiện các vấn đề về khai báo, khởi tạo giá trị cho các biến và sử dụng
chúng. Còn trong trƣờng hợp với kiểm thử với dòng dữ liệu động, chúng ta sẽ phải
chạy các ca kiểm thử để nhằm phát hiện các lỗi tiềm ẩn mà kiểm thử tĩnh không phát
hiện đƣợc.
Tuy nhiên kiểm thử dòng dữ liệu tĩnh thƣờng không hiệu quả vì nó không đảm bảo
việc phát hiện tất cả các lỗi liên quan đến việc khởi tạo, gán giá trị mới và sử dụng các
biến (trong các câu lệnh tính toán và các biểu thức điều kiện nhƣ trong các lệnh rẽ

nhánh và lặp). Nên nó chỉ đƣợc xem nhƣ một bƣớc tiền xử lý mã nguồn trƣớc khi áp
dụng phƣơng pháp kiểm thử dòng dữ liệu động. Do đó ta sẽ chỉ tìm hiểu qua về kiểm
thử dòng dữ liệu động trong phạm vị của luận văn.
Định nghĩa về đồ thị dòng dữ liệu từ tài liệu [1]:
"Đồ thị dòng dữ liệu của một chương trình/đơn vị chương trình là một đồ thị có
hướng G = <N, E>, với:
- N là tập các đỉnh tương ứng với các câu lệnh def hoặc c-use của các biến
được sử dụng trong đơn vị chương trình. Đồ thị G có hai đỉnh đặc biệt là đỉnh
bắt đầu (tương ứng với lệnh def của các biến tham số) và đỉnh kết thúc đơn vị
chương trình.
- E là tập các cạnh tương ứng với các câu lệnh p-use của các biến."
Trong đó def (định nghĩa của một biến) là ký hiểu của một câu lệnh thực hiện việc
gán giá trị cho một biến và đƣợc gọi là câu lệnh định nghĩa của biến đó; c-use (biến
20


được sử dụng để tính toán) là ký hiệu của một câu lệnh sử dụng một biến để tính toán
giá trị của một biến khác; p-use (biến được sử dụng để kiểm tra các điều kiện): một
câu lệnh sử dụng một biến trong các biểu thức điều kiện (câu lệnh rẽ nhánh, lặp, )
đƣợc gọi là p-use với biến đó.
Sau khi xây dựng đồ thị dòng dữ liệu của chƣơng trình, chúng ta cần xác định các
đƣờng đi của chƣơng trình của mỗi biến dữ liệu ứng với các độ đo kiểm thử (all-defs,
all-c-uses, all-p-uses, all-p-uses/some-c-uses ). Trong mỗi đƣờng dẫn này, biến dữ
liệu đƣợc định nghĩa tại một đỉnh nào đó và đƣợc sử dụng tại các câu lệnh tiếp theo
ứng với các đỉnh hoặc các cạnh của đƣờng đi này.
*) Ví dụ 02: Xây dựng hàm cho nhập vào một mảng n phần tử, tính trung bình cộng
các phần tử là số lẻ trong mảng nhỏ hơn 100 và trả lại kết quả cho giá trị hàm. Bảng
1.1 mô tả mã chƣơng trình.
Ta xây dƣng đƣợc sơ đồ dòng dữ liệu nhƣ trong Hình 1.4:

Hình 1.4: Ví dụ biểu đồ cho kiểm thử dòng dữ liệu
21


Xây dựng dựa trên tiêu chí All-defs
Với biến dem ta có:
Global-def = {2,5}
Ta có một def-clear path: 2,3,4,5
Chọn một complete path: 1,2,3,4,5,6,3,7
Ta có đƣợc các ca kiểm thử tƣơng ứng trong Bảng 1.3
Bảng 1.3: Danh sách các ca kiểm thử cho ví dụ về kiểm thử dòng dữ liệu
Ca kiểm thử
Kết quả dự kiến
Error
{ 5, 7, 1, 9 }
5,5

1.1.3 Kiểm thử miền
Thông qua ý tƣởng và các ví dụ thực tế của hai phƣơng pháp trên ta có thể rút ra
một số nhận xét chung về hai phƣơng pháp này nhƣ sau:
- Cả hai kỹ thuật đều chỉ xây dựng ra các ca kiểm thử thỏa mãn các đƣờng đi
độc lập xây dựng ra theo một độ bao phủ nào đó của chƣơng trình. Có nghĩa
chúng ta mới chỉ kiểm thử đƣợc khả năng chấp nhận của chƣơng trình. Chƣa
có sự phân tích kỹ về các trƣờng hợp lỗi có thể xảy ra với một biến nào đó
trong chƣơng trình.
- Các ca kiểm thử đƣợc lựa chọn ngẫu nhiên chỉ để phù hợp cho việc thỏa mãn
một đƣờng đi nào đó đã định sẵn mà chƣa có sự lựa chọn các ca kiểm thử hợp
lý nhất (có nghĩa là có khả năng phát hiện lỗi lớn nhất).
- Việc lựa chọn các ca kiểm thử sẽ trở nên khó khăn khi số lƣợng các đỉnh trong
đồ thị (đồ thị dòng điều khiển và đồ thị dòng dữ liệu) tăng lên.

Là một trong số các kỹ thuật kiểm thử áp dụng vào mức kiểm thử đơn vị. Kiểm
thử miền đem đến một cách tiếp cận hoàn toàn mới trong việc kiểm thử so với hai kỹ
thuật kiểm thử dòng điều khiển và kiểm thử dòng dữ liệu. Trong kiểm thử miền ta có
cơ chế kiểm thử khá chi tiết: một loại lỗi đƣợc gọi là lỗi miền đƣợc định nghĩa và sau
đó các dữ liệu kiểm tra đƣợc định nghĩa để bắt các lỗi đó.
Trong kiểm thử miền cũng có xây dựng các cơ chế và cách thức rõ ràng giúp cho
ngƣời kiểm thử có thể chọn lựa các ca kiểm thử có khả năng kiểm soát lỗi cao nhất
làm tăng tính khả thi của các ca kiểm thử và giảm thiểu rủi ro một cách lớn nhất.


22


1.2 Kiểm thử miền
Nhƣ trên ta đã đề cập, trong kiểm thử dòng điều khiển và kiểm thử dòng dữ liệu
không hề xác định các kiểu lỗi một cách rõ ràng để xem xét và xây dựng các ca kiểm
thử, còn trong kiểm thử miền, một lại lỗi đƣợc gọi là lỗi miền sẽ đƣợc định nghĩa, sau
đó dữ liệu kiểm tra đƣợc xác định để bắt những lỗi đó.
Ý tƣởng của kiểm thử miền lần đầu tiên đƣợc nghiên cứu bởi White và Cohen vào
năm 1978. Sau đó nó đã đƣợc tổng hợp lại bởi Naik và Tripathy [2]. Trong chƣơng
này chúng ta sẽ đi tìm hiểu các khái niệm về lỗi miền; cách xác định các miền đầu vào
từ các đặc tả và mã nguồn của chƣơng trình; các kiểu xuất hiện của lỗi miền; trong
kiểm thử miền ta cũng sẽ đƣợc làm quen với khái niệm điểm ON và điểm OFF, đó là
những điểm có khả năng phát hiện ra lỗi cao nhất trong miền; và đặc biệt chúng ta sẽ
tìm hiểu về các chiến lƣợc để xác định các ca kiểm thử tốt nhất. Các nội dung đƣợc
tham khảo từ [2].
1.2.1 Khái niệm về lỗi miền
Hai phần tử cơ bản của một chƣơng trình máy tính là miền đầu vào và các đƣờng
đi của chƣơng trình. Miền đầu vào của chƣơng trình là danh sách của tất cả các dữ liệu
đầu vào cho chƣơng trình. Một đƣờng đi của chƣơng trình là một chuỗi tuần tự các chỉ

dẫn từ khi chƣơng trình bắt đầu tới một vài điểm quan trọng trong chƣơng trình. Ví dụ
điểm cuối cùng của chƣơng trình là một điểm quan trọng. Một điểm quan trọng khác là
khi chƣơng trình đợi để nhận một dữ liệu đầu vào từ môi trƣờng của nó để nó có thể
tiếp tục thực thi Nói cách khác, một đƣờng đi của chƣơng trình tƣơng ứng với một số
luồng của điều khiển trong chƣơng trình. Một con đƣờng đƣợc cho là khả thi nếu có
một dữ liệu đầu vào làm cho chƣơng trình thực thi theo đƣờng đi đó. Nếu không, con
đƣờng đó đƣợc cho là không khả thi.
Howden [5] đã xác định hai lớp lớn của các lỗi, cụ thể là lỗi tính toán và lỗi miền,
bằng cách kết hợp các khái niệm về dữ liệu đầu vào và đƣờng đi chƣơng trình. Tác giả
đƣa ra khái niệm về hai loại lỗi trên nhƣ sau:
- Lỗi tính toán: Một lỗi tính toán xảy ra khi một dữ liệu đầu vào cụ thể làm cho
chƣơng trình thực hiện đúng theo một con đƣờng mong muốn, nhƣng giá trị
đầu ra là sai. Chú ý rằng các giá trị đầu ra có thể sai ngay cả khi chƣơng trình
thực hiện theo đúng con đƣờng mong muốn. Điều này có thể xảy ra do một
chức năng thực hiện sai trong một trạng thái thực hiện trong chƣơng trình. Lỗi
này thƣờng xảy ra ở giai đoạn lập trình viên xây dựng mã chƣơng trình.
23


*) Ví dụ 03: Học sinh thi cấp 3 với 2 môn Toán và Văn. Điểm Toán có hệ số 3
và điểm Văn có hệ số 2. Học sinh có điểm trung bình ≥ 5 trúng tuyển vào
trƣờng. Chƣơng trình tính điểm trung bình nhƣ sau:
Bảng 1.4: Mã chương trình tính điểm trung bình toán và văn
Float diemtrungbinh(int toan, int van){
float trungbinh;
trungbinh = (float)(toan*2+van*3)/5;
return(trungbinh);
}

Từ đoạn mã chƣơng trình trong Bảng 1.4 ta thấy, chƣơng trình vẫn sẽ chạy

theo đúng đƣờng dẫn hợp lý nhƣng kết quả cho ra là sai.
Tổng quát: Hãy xem xét một con đƣờng mong muốn có chứa các kết quả trả
về = f (a, b), trong đó a và b là các giá trị đầu vào. Một lỗi tính toán có thể xảy
ra nếu các báo cáo đƣợc thay thế bằng một lỗi không chính xác, chẳng hạn
nhƣ kết quả = f (b, a). Vì vậy, kết quả của thực hiện trên đƣờng đi có thể là sai
lầm vì một lỗi trong khi gán các biến hoặc thực hiện tính toán, và điều này có
thể xảy ra mặc dù chƣơng trình đã đi theo một đƣờng dẫn chính xác.
- Lỗi miền: Một lỗi miền có thể xảy ra khi việc xác định một dữ liệu đầu vào là
nguyên nhân để chƣơng trình thực thi sai, vì khi đó chƣơng trình sẽ thực thi
theo một con đƣờng không đúng với mong muốn của nó. Một con đƣờng
không chính xác có thể đƣợc lựa chọn bởi một chƣơng trình nếu có một lỗi
trong một hoặc một vài các báo cáo có điều kiện trong chƣơng trình.
Chúng ta hãy xem xét một câu lệnh điều kiện của mẫu if (p) then f1()
else f2(). Nếu có một lỗi trong việc xây dựng thuộc tính p, khi đó lời gọi của
một chức năng sai đƣợc gọi, do đó gây ra một đƣờng dẫn không chính xác
đƣợc thực thi.
Từ đó ta thấy, đối với mỗi giá trị đầu vào, chƣơng trình luôn chỉ định một con
đƣờng trong nó để thực hiện; tập những giá trị đầu vào thực hiện chƣơng trình theo
một con đƣờng giống nhau để thực thi đƣợc gọi là miền con. Vì có một số lƣợng lớn
các giá trị đầu vào của chƣơng trình và số lƣợng lớn các con đƣờng trong một chƣơng
trình, tác giả đã xem một chƣơng trình nhƣ việc phân vùng không gian đầu vào thành
một số hữu hạn các miền con và chỉ định một đƣờng dẫn chƣơng trình riêng biệt cho
mỗi miền con đó.
24


Từ Hình 1.5 ta có: tập D là toàn bộ miền đầu vào của chƣơng trình P. Ta gọi D là
miền của toàn bộ chƣơng trình. D có thể là một tập hợp vô hạn và P có thể chỉ có một
con đƣờng duy nhất cho toàn bộ giá trị trong miền D và mọi giá trị trong D đều có
hành vi tính toán trong P nhƣ nhau.

Hình 1.5: Cấu trúc tổng quát của một chương trình
Mặt khác, chƣơng trình P có thể thực hiện những cách khác nhau cho mỗi miền
con trong D (D1,D2,D3,D4,D5…), lƣu ý rằng các phân vùng con trong D có thể không
nhìn thấy từ bên ngoài. Khi đó trong P sẽ có cơ chế xây dựng khái niệm để quyết định
phƣơng pháp cũng nhƣ đƣờng đi cần thiết cho từng đầu vào cụ thể nhất định của các
giá trị thuộc D.
Việc phân loại đầu vào trong một chƣơng trình có thể không tồn tại tại một vị trí
hay theo một cách thức duy nhất và đƣợc xác định rõ ràng mà nó có thể nằm ở nhiều
vị trí khác nhau trong toàn bộ chƣơng trình (cụ thể thì việc phân loại các phần đầu vào
của chƣơng trình có thể tìm thấy trong các mô-đun khác nhau của chƣơng trình). Có
thể có 5 tính toán khác nhau cho 5 miền con tƣơng ứng trong D nhƣ trong Hình 1.6.
Một chức năng chứa trong P sẽ quyết định những gì sẽ tính toán cho một giá trị trong
D và đƣợc gọi là phân loại đầu vào. Chú ý cấu trúc của một chƣơng trình có thể không
giống với trƣờng hợp hiển thị bên trong vòng tròn lớn trong Hình 1.6. Chƣơng trình
thực hiện phân loại đầu vào thông qua trình tự của các thuộc tính, một phân loại đầu
vào có thể không tồn tại nhƣ một mô-đun duy nhất nhƣ trong đó.

Hình 1.6: Phân loại miền đầu vào của chương trình
25


Vì vậy, một chƣơng trình sẽ thực hiện các tính toán sai nếu có lỗi trong phần phân loại
đầu vào. Từ đó chúng ta có thể xác định hai khái niệm cơ bản nhƣ sau:
- Một miền là một tập hợp tất cả các giá trị đầu vào mà chƣơng trình thực hiện
việc tính toán tƣơng tự cho các phần tử trong đó (ở đây chúng ta quan tâm đến
miền lớn nhất mà chƣơng trình thực hiện các tính toán khác nhau trong các
miền liền kề)
- Một chƣơng trình có một lỗi miền nếu nó không thực hiện phân loại đầu vào
chính xác. Khi đó giả định rằng tại các miền liền kề sẽ thực hiện các tính toán

khác nhau, một lỗi miền sẽ làm cho chƣơng trình tạo ra các giá trị đầu ra
không chính xác.
Để thuận lợi cho quá trình nghiên cứu, các ví dụ sau đây về kiểm thử miền sẽ chỉ
tập trung vào trƣờng hợp chƣơng trình có nhiều nhất 2 biến đầu vào có quan hệ với
nhau, từ đó miền đầu vào cho các chƣơng trình sẽ dễ hình dung hơn trong môi trƣờng
không gian hai chiều.
1.2.2 Xây dựng các miền kiểm thử từ chƣơng trình
Dựa vào các tài liệu đặc tả chƣơng trình và mã nguồn tác giả chỉ ra việc xác định
các miền của một chƣơng trình theo các bƣớc sau:
- Bước 1: từ mã nguồn, vẽ một biểu đồ luồng điều khiển chƣơng trình;
- Bước 2: tìm tất cả các diễn giải khác nhau của các vị từ trong chƣơng trình.
Lƣu ý rằng một vị từ trong một chƣơng trình có thể có nhiều cách giải thích,
bởi vì điều khiển có thể đi đến một nút vị từ thông qua các con đƣờng khác
nhau.
- Bước 3: Phân tích những giải thích về các vị từ để xác định các miền.
*) Ví dụ 04: Tác giả đã đƣa ra một ví dụ đơn giản sau đây để minh họa cho việc xác
định các miền của một chƣơng trình: xây dựng một hàm codedomain() chấp nhận hai
yếu tố đầu vào là x và y và trả về một số nguyên.
Bảng 1.5: Mã chương trình codedomain

int codedomain(int x, int y){
int c, d, k;
c = x + y;
if (c > 5) d = c - x/2;
else d = c + x/2;