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

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


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

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

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

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ộ

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

ứ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){

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

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.

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


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