Chương 5

Kỹ thuật kiểm thử hộp ₫en
5.1 Tổng quát về kiểm thử hộp ₫en
Đối tượng ₫ược kiểm thử là 1 thành phần phần mềm (TPPM).
TPPM có thể là 1 hàm chức năng, 1 module chức năng, 1 phân hệ
chức năng… Nói chung, chiến lược kiểm thử hộp ₫en thích hợp
cho mọi cấp ₫ộ kiểm thử từ kiểm thử ₫ơn vị, kiểm thử tích hợp,
kiểm thử hệ thống, kiếm thử ₫ộ chấp nhận của người dùng.
Kiểm thử hộp ₫en (black-box testing) là chiến lược kiểm thử
TPPM dựa vào thông tin duy nhất là các ₫ặc tả về yêu cầu chức
năng của TPPM tương ứng.
Đây là chiến lược kiểm thử theo góc nhìn từ ngoài vào, các
người tham gia kiểm thử hộp ₫en không cần có kiến thức nào về
thông tin hiện thực TPPM cần kiểm thử (mã nguồn của thành phần
phần mềm, thuật giải ₫ược dùng, các dữ liệu ₫ược xử lý…).
Qui trình kiểm thử hộp ₫en tổng quát gồm các bước chính :
ƒ

Phân tích ₫ặc tả về các yêu cầu chức năng mà TPPM cần
thực hiện.

ƒ

Dùng 1 kỹ thuật ₫ịnh nghĩa các testcase xác ₫ịnh (sẽ giới
thiệu sau) ₫ể ₫ịnh nghĩa các testcase. Định nghĩa mỗi
testcase là xác ₫ịnh 3 thông tin sau :
à

Giá trị dữ liệu nhập ₫ể TPPM xử lý (hoặc hợp lệ hoặc
không hợp lệ).

à

Trạng thái của TPPM cần có ₫ể thực hiện testcase.

à

Giá trị dữ liệu xuất mà TPPM phải tạo ₫ược.

ƒ

Kiểm thử các testcase ₫ã ₫ịnh nghĩa.

ƒ

So sánh kết quả thu ₫ược với kết quả kỳ vọng trong từng
testcase, từ ₫ó lập báo cáo về kết quả kiểm thử.

Vì chiến lược kiểm thử hộp ₫en thích hợp cho mọi mức ₫ộ kiểm
thử nên nhiều người ₫ã nghiên cứu tìm hiểu và ₫ưa ra nhiều kỹ
thuật kiểm thử khác nhau, chúng ta sẽ chọn ra 8 kỹ thuật có nhiều
ưu ₫iểm nhất và ₫ược dùng phổ biến nhất, ₫ó là :
1. Kỹ thuật phân lớp tương ₫ương (Equivalence Class
Partitioning).
2. Kỹ thuật phân tích các giá trị biên (Boundary value
analysis).
3. Kỹ thuật dùng các bảng quyết ₫ịnh (Decision Tables)
4. Kỹ thuật kiểm thử các bộ n thần kỳ (Pairwise)
5. Kỹ thuật dùng bảng chuyển trạng thái (State Transition)
6. Kỹ thật phân tích vùng miền (domain analysis)
7. Kỹ thuật dựa trên ₫ặc tả Use Case (Use case)
8. Kỹ thuật dùng lược ₫ồ quan hệ nhân quả (Cause-Effect
Diagram)
5.2 Kỹ thuật phân lớp tương ₫ương
Tinh thần của kỹ thuật này là cố gắng phân các testcase ra
thành nhiều nhóm (họ) khác nhau : các testcase trong mỗi họ sẽ
kích hoạt TPPM thực hiện cùng 1 hành vi. Mỗi nhóm testcase thỏa
mãn tiêu chuẩn trên ₫ược gọi là 1 lớp tương ₫ương, ta chỉ cần xác
₫ịnh 1 testcase ₫ại diện cho nhóm và dùng testcase này ₫ể kiểm
thử TPPM. Như vậy ta ₫ã giảm rất nhiều testcase cần ₫ịnh nghĩa
và kiểm thử, nhưng chất lượng kiểm thử không bị giảm sút bao
nhiêu so với vét cạn. Điều này là dựa vào kỳ vọng rất hợp lý sau
₫ây :
ƒ

Nếu 1 testcase trong lớp tương ₫ương nào ₫ó gây lỗi
TPPM thì các testcase trong lớp này cũng sẽ gây lỗi như
vậy.

ƒ

Nếu 1 testcase trong lớp tương ₫ương nào ₫ó không gây
lỗi TPPM thì các testcase trong lớp này cũng sẽ không gây
lỗi.

Vấn ₫ề kế tiếp là có cần ₫ịnh nghĩa các lớp tương ₫ương ₫ại
diện các testcase chứa các giá trị không hợp lệ theo ₫ặc tả hay
không ? Điều này phụ thuộc vào tinh thần kiểm thử :
ƒ

Nếu ta dùng tinh thần kiểm thử theo hợp ₫ồng (Testing-byContract) thì không cần ₫ịnh nghĩa các lớp tương ₫ương
₫ại diện các testcase chứa các giá trị không hợp lệ theo
₫ặc tả vì không cần thiết.

ƒ

Còn nếu ta dùng tinh thần kiểm thử phòng vệ (Defensive
Testing), nghĩa là kiểm thử hoàn hảo, thì phải ₫ịnh nghĩa
các lớp tương ₫ương ₫ại diện các testcase chứa các giá trị
không hợp lệ theo ₫ặc tả ₫ể xem TPPM phản ứng như thế
nào với những testcase này.

Thí dụ ta cần kiểm thử 1 TPPM “quản lý nguồn nhân lực” với
₫ặc tả chức năng như sau : mỗi lần nhận 1 hồ sơ xin việc, TPPM
sẽ ra quyết ₫ịnh dựa vào tuổi ứng viên theo bảng sau :
Tuổi ứng viên
Kết quả
0-16
Không thuê
16-18
Thuê dạng bán thời gian
18-55
Thuê toàn thời gian
55-99
Không thuê
Lưu ý rằng bảng ₫ặc tả chức năng phía trên có lỗi ở các giá trị
₫ầu và/hoặc cuối trong từng luật, và giả sử chúng ta chưa phát
hiện lỗi này. Chúng ta sẽ thấy bằng cách nào sẽ phát hiện dễ
dàng lỗi này.
Phân tích ₫ặc tả chức năng của TPPM cần kiểm thử của slide
trước, ta thấy có 4 lớp tương ₫ương, mỗi lớp chứa các testcase ứng
với 1 chế ₫ộ xử lý của TPPM : không thuê vì quá trẻ, thuê dạng
bán thời gian, thuê toàn thời gian, không thuê vì quá già.

Ứng với mỗi lớp tương ₫ương, ta ₫ịnh nghĩa 1 testcase ₫ại
diện, thí dụ ta chọn 4 testcase sau :
1. Testcase 1 : {Input : 2 tuổi, Output : không thuê}
2. Testcase 2 : {Input : 17 tuổi, Output : thuê bán thời gian}
3. Testcase 3 : {Input : 35 tuổi, Output : thuê toàn thời gian}
4. Testcase 4 : {Input : 90 tuổi, Output : không thuê}
Trong thí dụ trên, thay vì phải kiểm thử vét cạn 100 testcase,
ta chỉ kiểm thử 4 testcase → chí phí giảm rất lớn, nhưng chất lượng
kiểm thử hy vọng không bị giảm sút là bao.
Tại sao chúng ta hy vọng chất lượng kiểm thử dùng lớp tương
₫ương không giảm sút nhiều ? Hãy xét ₫oạn code mà những người
lập trình bình thường sẽ viết khi xử lý TPPM cần kiểm thử của slide
trước :
if (applicantAge >= 0 && applicantAge <=16) qd ="NO";
if (applicantAge >= 16 && applicantAge <=18) qd ="PART";
if (applicantAge >= 18 && applicantAge <=55) qd ="FULL";
if (applicantAge >= 55 && applicantAge <=99) qd ="NO";
Ở góc nhìn kiểm thử hộp trắng, nếu dùng 4 testcase ₫ại diện
của 4 lớp tương ₫ương, ta sẽ kiểm thử ₫ược ở phủ cấp 3, cấp phủ
rất tốt vì ₫ã kiểm thử 100% các lệnh mã nguồn, 100% các nhánh
quyết ₫ịnh.
Tuy nhiên nếu người lập trình hiện thực như sau (rất cá biệt vì
₫ây là người lập trình rất yếu tay nghề) :
if (applicantAge == 0) qd ="NO";
…
if (applicantAge == 16) qd ="PART";
…
if (applicantAge == 53) qd ="FULL";
…
if (applicantAge == 99) qd ="NO";

Thì nếu dùng 4 testcase ₫ại diện của 4 lớp tương ₫ương, ta
mới kiểm thử ₫ược 4/100 lệnh mã nguồn của TPPM, mức ₫ộ phủ
này chưa thể nói lên gì nhiều về TPPM!
Làm sao chọn testcase ₫ại diện cho lớp tương ₫ương ? Điều
này phụ thuộc vào kiểu dữ liệu nhập. Ta hãy lần lượt xét 1 số kiểu
dữ liệu nhập phổ biến.
Thí dụ ta cần kiểm thử 1 TPPM “xét ₫ơn cầm cố nhà” với ₫ặc
tả chức năng như sau : mỗi lần nhận 1 ₫ơn xin cầm cố, TPPM sẽ
ra quyết ₫ịnh chấp thuận nếu 4 ₫iều kiện sau ₫ều thỏa mãn :
1. Thu nhập hàng tháng của ₫ương ₫ơn nằm trong khoảng từ
1000$ ₫ến 83333$.
2. số nhà xin cầm cố từ 1 ₫ến 5.
3. Đương ₫ơn phải là cá nhân, không ₫ược là hội, công ty hay
người ₫ược ủy nhiệm (partnership, trust, corporation).
4. Loại nhà cầm cố phải là loại nhà cố ₫ịnh (single family,
condo, townhouse), không xét loại nhà di ₫ộng (treehouse,
duplex, mobile home).
1. Nếu lớp tương ₫ương ₫ược xác ₫ịnh bởi các dữ liệu nhập là số
thực liên tục, thì ta chọn 1 testcase ₫ại diện có giá trị nhập hợp lệ
nằm trong khoảng liên tục các giá trị hợp lệ, và nếu muốn, 2
testcase miêu tả giá trị không hợp lệ nằm phía dưới và phía trên
khoảng trị hợp lệ (số testcase cho mỗi lớp tương ₫ương là từ 1 tới
3).
2000USD

300USD

1000USD

90000USD

83333USD

2. Nếu lớp tương ₫ương ₫ược xác ₫ịnh bởi các dữ liệu nhập là số
nguyên liên tục, trong trường hợp này ta chọn 1 testcase ₫ại diện
có giá trị nhập hợp lệ nằm trong khoảng liên tục các giá trị hợp lệ,
và nếu muốn, 2 testcase miêu tả giá trị không hợp lệ nằm phía
dưới và phía trên khoảng trị hợp lệ (số testcase cho mỗi lớp tương
₫ương là từ 1 tới 3).

-1 0

1

2

3

4

5

6

7

8

3. Nếu lớp tương ₫ương ₫ược xác ₫ịnh bởi các dữ liệu dạng liệt kê
rời rạc và không có mối quan hệ lẫn nhau gồm 1 trị hợp lệ và nhiều
trị không hợp lệ. Trong trường hợp này ta chọn 1 testcase có giá trị
nhập hợp lệ và nếu muốn, 2 testcase miêu tả 2 giá trị không hợp lệ
nào ₫ó, nhưng cho dù chọn 2 testcase nào cũng không ₫ại diện tốt
cho các trường hợp không hợp lệ còn lại (số testcase cho mỗi lớp
tương ₫ương là từ 1 tới 3).

4. Nếu lớp tương ₫ương ₫ược xác ₫ịnh bởi các dữ liệu dạng liệt kê
rời rạc và không có mối quan hệ lẫn nhau gồm n trị hợp lệ và m trị
không hợp lệ. Trong trường hợp này ta chọn 1 testcase có giá trị
nhập hợp lệ nào ₫ó và nếu muốn, 2 testcase miêu tả 2 giá trị
không hợp lệ nào ₫ó, nhưng cho dù chọn các testcase nào cũng

không ₫ại diện tốt cho các trường hợp hợp lệ và không hợp lệ còn
lại (số testcase cho mỗi lớp tương ₫ương là từ 1 tới 3).

Khi TPPM cần kiểm thử nhận nhiều dữ liệu nhập (thí dụ TPPM
xét ₫ơn cầm cố nhà ở slide trước có 4 loại dữ liệu nhập), ta ₫ịnh
nghĩa các testcase ₫ộc lập cho các dữ liệu hay testcase dựa trên
tổng hợp các dữ liệu nhập ?
Nếu ₫ịnh nghĩa các testcase ₫ộc lập trên từng loại dữ liệu
nhập, số lượng testcase cần kiểm thử sẽ nhiều. Trong TPPM xét
₫ơn cầm cố nhà, ta phải xử lý ít nhất là 3 testcase cho từng loại dữ
liệu * 4 loại dữ liệu = 12 testcase.
Để giảm thiểu số lượng testcase nhưng vẫn ₫ảm bảo chất
lượng kiểm thử, người ta ₫ề nghị chọn tescase như sau :
ƒ

1 testcase cho tổ hợp các giá trị hợp lệ.

ƒ

n testcase cho tổ hợp các giá trị trong ₫ó có 1 giá trị không
hợp lệ, các giá trị còn lại hợp lệ, nên thay ₫ổi các giá trị
hợp lệ trong tổ hợp cho mỗi testcase.

Thí dụ TPPM xét ₫ơn cầm cố nhà ở slide trước có 4 loại dữ liệu
nhập), ta ₫ịnh nghĩa các testcase dựa trên tổ hợp các dữ liệu nhập
như sau :
Thu nhập
/tháng
5.000
100

Số lượng nhà Đương ₫ơn Kiểu nhà
2
1

Person
Person

Condo
Single

Kết quả
Valid
Invalid

1.342
5.432
10.000

0
3
2

Person
Condo
Corporation Townhouse
Person
Treehouse

Invalid
Invalid
Invalid

5.3 Kỹ thuật phân tích các giá trị ở biên
Kỹ thuật kiểm thử phân lớp tương ₫ương là kỹ thuật cơ bản
nhất, nó còn gợi ý chúng ta ₫ến 1 kỹ thuật kiểm thử khác : phân
tích các giá trị ở biên.
Kinh nghiệm trong cuộc sống ₫ời thường cũng như trong lập
trình các giải thuật lặp cho chúng ta biết rằng lỗi thường nằm ở
biên (₫ầu hay cuối) của 1 khoảng liên tục nào ₫ó (lớp tương
₫ương). Do ₫ó ta sẽ tập trung tạo các testcase ứng với những giá
trị ở biên này.
Thí dụ xét ₫ặc tả TPPM “quản lý nguồn nhân lực” ở slide 8, ta
thấy ₫ặc tả các luật ₫ều bị lỗi ở các biên, thí dụ luật 1 qui ₫ịnh
không thuê những người có tuổi từ 0 — 16, còn luật 2 qui ₫ịnh sẽ
thuê bán thời gian những người từ 16-18 tuổi. Vậy người 16 tuổi
₫ược xử lý như thế nào bởi hệ thống ? Đã có nhặp nhằng và mâu
thuẩn trong các luật. Lỗi này do nắm bắt yêu cầu phần mềm sai.
Giả sử ta ₫ã chỉnh sửa lại yêu cầu phần mềm như sau :
Tuổi ứng viên
Kết quả
0-15
Không thuê
16-17
Thuê dạng bán thời gian
18-54
Thuê toàn thời gian
55-99
Không thuê
Và ₫oạn code hiện thực sau :
if (0 < applicantAge && applicantAge < 15) kq ="NO";
if (16 < applicantAge && applicantAge <17) kq ="PART";
if (18 < applicantAge && applicantAge <54) kq ="FULL";
if (55 < applicantAge && applicantAge <99) kq ="NO";

Đoạn code hiện thực ở slide trước bị lỗi ở các gía trị biên (₫úng
ra là phải dùng ₫iều kiện <= chứ không phải là <). Lỗi này thuộc về
người hiện thực chương trình.
Cách ₫ơn giản và hiệu quả ₫ể phát hiện lỗi ở slide trước là
thanh tra mã nguồn (code inspection), mà ta sẽ ₫ề cập trong
chương 7. Ở ₫ây ta chỉ trình bày kỹ thuật kiểm thử dựa trên các giá
trị biên ₫ể phát hiện các lỗi này.
Ý tưởng của kỹ thuật kiểm thử dựa trên các trị biên là chỉ ₫ịnh
nghĩa các testcase ứng với các giá trị ngay trên biên hay lân cận
biên của từng lớp tương ₫ương. Do ₫ó kỹ thuật này chỉ thích hợp
với các lớp tương ₫ương xác ₫ịnh bởi các giá trị liên tục (số
nguyên, số thực), chứ nó không thích hợp với lớp tương ₫ương
₫ược xác ₫ịnh bởi các giá trị liệt kê mà không có mối quan hệ lẫn
nhau.
Qui trình cụ thể ₫ể thực hiện kiểm thử dựa trên các giá trị ở
biên :
ƒ

Nhận dạng các lớp tương ₫ương dựa trên ₫ặc tả về yêu
cầu chức năng của TPPM.

ƒ

Nhận dạng 2 biên của mỗi lớp tương ₫ương.

ƒ

Tạo các testcase cho mỗi biên của mỗi lớp tương ₫ương :
- 1 testcase cho giá trị biên.
- 1 testcase ngay dưới biên.
- 1 testcase ngay trên biên.

ƒ

Ý nghĩa ngay trên và ngay dưới biên phụ thuộc vào ₫ơn vị
₫o lường cụ thể :
-

nếu là số nguyên, ngay trên và ngay dưới lệch biên 1
₫ơn vị.

-

nếu ₫ơn vị tính là “$ và cent” thì ngay dưới của biên 5$
là 4.99$, ngay trên là 5.01$.

-

nếu ₫ơn vị là $ thì ngay dưới của 5$ là 4$, ngay trên
5$ là 6$.

Thí dụ dựa vào ₫ặc tả của TPPM “quản lý nguồn nhân lực” :
Tuổi ứng viên
Kết quả
0-15
Không thuê
16-17
Thuê dạng bán thời gian
18-54
Thuê toàn thời gian
55-99
Không thuê
Ta sẽ ₫ịnh nghĩa các testcase tương ứng với các tuổi sau : {1,0,1}, {14,15,16}, {15,16,17}, {16,17,18}, {17,18,19}, {53,54,55},
{54,55,56}, {98,99,100}.
Có nhiều testcase trùng nhau, nếu loại bỏ các testcase trùng
nhau, ta còn : -1, 0, 1, 14, 15, 16, 17, 18, 19, 53, 54, 55, 56, 98,
99, 100 (16 testcase so với hàng trăm testcase nếu vẹt cạn).
Khi TPPM cần kiểm thử nhận nhiều dữ liệu nhập (thí dụ TPPM
xét ₫ơn cầm cố nhà ở slide trước có 4 loại dữ liệu nhập), ta ₫ịnh
nghĩa các testcase ₫ộc lập cho các dữ liệu hay testcase dựa trên
tổng hợp các dữ liệu nhập ?
Nếu ₫ịnh nghĩa các testcase ₫ộc lập trên từng loại dữ liệu
nhập, số lượng testcase cần kiểm thử sẽ nhiều. Trong TPPM xét
₫ơn cầm cố nhà, ta phải xử lý ít nhất là 6 testcase cho từng loại dữ
liệu * 4 loại dữ liệu = 24 testcase.
Để giảm thiểu số lượng testcase nhưng vẫn ₫ảm bảo chất
lượng kiểm thử, người ta ₫ề nghị chọn tescase như sau :
ƒ

1 số testcase cho các tổ hợp các giá trị biên.

ƒ

1 số testcase cho các tổ hợp các giá trị ngay dưới và ngay
trên biên.

TPPM xét ₫ơn cầm cố nhà ở slide trước có 2 dữ liệu nhập liên
tục là thu nhập hàng tháng và số lượng nhà. Tổng hợp 2 loại dữ
liệu này theo góc nhìn ₫ồ họa trực quan, ta thấy cần ₫ịnh nghĩa
các testcase cho các trường hợp sau :

Lớp tương ₫ương dựa trên tổ hợp
2 dữ liệu nhập

83333USD

1000USD
Thu nhập Số lượng nhà
/tháng
$1,000
$83,333
$1,000
$83,333
$1,000
$1,000
$83,333
$83,333
$999
$83,334
$999
$83,334

Kết quả

Diễn giải

Valid
Valid
Valid
Valid
Invalid
Invalid
Invalid
Invalid
Invalid
Invalid
Invalid
Invalid

Min Thu nhập, min SoLN
Max Thu nhập, min SoLN
Min Thu nhập, max SoLN
Max Thu nhập, max SoLN
Min Thu nhập, below min SoLN
Min Thu nhập, above max SoLN
Max Thu nhập, below min SoLN
Max Thu nhập, above max SoLN
Below min Thu nhập, min SoLN
Above max Thu nhập, min SoLN
Below min Thu nhập, max SoLN
Above max Thu nhập, max SoLN

1
1
5
5
0
6
0
6
1
1
5
5

5.4 Kỹ thuật dùng bảng quyết ₫ịnh (decision table)
Bảng quyết ₫ịnh là 1 công cụ rất hữu ích ₫ể ₫ặc tả các yêu
cầu phần mềm hoặc ₫ể ₫ặc tả bảng thiết kế hệ thống phần mềm.
Nó miêu tả các qui tắc nghiệp vụ phức tạp mà phần mềm phải
thực hiện dưới dạng dễ ₫ọc và dễ kiểm soát :
Rule 1
Conditions
Condition-1
…
Condition-m

Rule 2

…

Rule p

Actions
Action-1
…
Action-n

Condition-1 tới Condition-m miêu tả m ₫iều kiện dữ liệu nhập
khác nhau có thể có. Action-1 tới Action-n miêu tả n hoạt ₫ộng
khác nhau mà hệ thống có thể thực hiện phụ thuộc vào tổ hợp ₫iều
kiện dữ liệu nhập nào. Mỗi cột miêu tả 1 luật cụ thể : tổ hợp ₫iều
kiện nhập cụ thể và các hoạt ₫ộng cụ thể cần thực hiện.
Lưu ý các hoạt ₫ộng cần thực hiện không phụ thuộc vào thứ tự
các ₫iều kiện nhập, nó chỉ phụ thuộc vào giá trị các ₫iều kiện
nhập.
Tương tự, các hoạt ₫ộng cần thực hiện không phụ thuộc vào
trạng thái hiện hành của TPPM, chúng cũng không phụ thuộc vào
các ₫iều kiện nhập ₫ã có trước ₫ó.
Chúng ta sẽ lấy 1 thí dụ cụ thể ₫ể làm rõ bảng quyết ₫ịnh. Giả
sử TPPM cần kiểm thử là phân hệ chức năng nhỏ của công ty bảo
hiểm : nó sẽ khuyến mãi cho những chủ xe (cũng là tài xế) nếu họ
thỏa ít nhất 1 trong 2 ₫iều kiện : ₫ã lập gia ₫ình / là sinh viên giỏi.
Mỗi dữ liệu nhập là 1 giá trị luận lý, nên bảng quyết ₫ịnh chỉ cần có
4 cột, miêu tả 4 luật khác nhau :
Rule 1
Rule 2
Rule 3
Rule 4
Conditions
Married?
Yes
Yes
No
No
Good Student?
Yes
No
Yes
No
Actions
Discount ($)
60
25
50
0
Qui trình cụ thể ₫ể thực hiện kiểm thử dùng bảng quyết ₫ịnh :
1. Tìm bảng quyết ₫ịnh từ ₫ặc tả về yêu cầu chức năng của
TPPM hay từ bảng thiết kế TPPM. Nếu chưa có thì xây
dựng nó dựa vào ₫ặc tả về yêu cầu chức năng hay dựa
vào bảng thiết kế TPPM.

2. Từ bảng quyết ₫ịnh chuyển thành bảng các testcase trong
₫ó mỗi cột miêu tả 1 luật ₫ược chuyển thành 1 ₫ến n cột
miêu tả các testcase tương ứng với luật ₫ó :
-

nếu ₫iều kiện nhập là trị luận lý thì mỗi cột luật ₫ược
chuyển thành 1 cột testcase.

-

nếu ₫iều kiện nhập là 1 lớp tương ₫ương (nhiều giá trị
liên tục) thì mỗi cột luật ₫ược chuyển thành nhiều
testcase dựa trên kỹ thuật lớp tương ₫ương hay kỹ
thuật giá trị biên.
Rule 1
Rule 2
Rule 3
Rule 4
Conditions
Cond 1
Yes
Yes
No
No
Cond 2
Yes
No
Yes
No
Actions
Action-1
60
25
50
0

Conditions
Married?
Good Student?
Actions
Discount ($)

Conditions
Cond 1
Cond 2
Actions
Action-1

TC1

TC2

TC3

TC4

Yes
Yes

Yes
No

No
Yes

No
No

60

25

50

0

Rule 1

Rule 2

Rule 3

Rule 4

0—1
<5

1—10
5

Do X

Do Y

10—100 100—1000
6 or 7
>7
Do X

Do Z

Conditions
Cond 1
Cond 2
Actions
Action-1

TC1

TC2

TC3

TC4

0
3

5
5

50
7

500
10

Do X

Do Y

Do X

Do Z

5.5 Kỹ thuật kiểm thử các bộ n thần kỳ (pairwise)
Chúng ta hãy kiểm thử 1 website với ₫ặc tả yêu cầu như sau :
1. Phải chạy tốt trên 8 trình duyệt khác nhau : Internet
Explorer 5.0, 5.5, and 6.0, Netscape 6.0, 6.1, and 7.0,
Mozilla 1.1, and Opera 7.
2. Phải chạy tốt ở 3 chế ₫ộ plug-ins : RealPlayer,
MediaPlayer, none.
3. Phải chạy tốt trên 6 HĐH máy client : Windows 95, 98,
ME, NT, 2000, and XP.
4. Phải chạy tốt trên 3 web server khác nhau : IIS, Apache,
and WebLogic.
5. Phải chạy tốt trên 3 HĐH máy server : Windows NT, 2000,
and Linux.
Như vậy ₫ể kiểm thử ₫ầy ₫ủ ₫ặc tả yêu cầu, ta phải kiểm thử
website trên 8*3*6*3*3 = 1296 cấu hình khác nhau.
Một thí dụ khác : hãy kiểm thử 1 hệ thống xử lý dữ liệu ngân
hàng có ₫ặc tả yêu cầu như sau :
1. Phải xử lý tốt 4 loại khách hàng là consumers, very
important consumers, businesses, and non-profits.
2. Phải xử lý tốt 5 loại tài khoản : checking, savings,
mortgages, consumer loans, and commercial loans.

3. Phải chạy tốt ở 6 bang khác nhau với chế ₫ộ khác nhau :
California, Nevada, Utah, Idaho, Arizona, and New
Mexico.
Như vậy ₫ể kiểm thử ₫ầy ₫ủ ₫ặc tả yêu cầu, ta phải kiểm thử
hệ thống xử lý dữ liệu ngân hàng trên 4*5*6 = 120 cấu hình khác
nhau.
Một thí dụ khác : hãy kiểm thử 1 phần mềm hướng ₫ối tượng
có chi tiết thiết kế như sau : Đối tượng class A sẽ gởi thông ₫iệp
₫ến ₫ối tượng class X dùng tham số là ₫ối tượng class P.
1. Có 3 class con của A là B, C, D.
2. Có 4 class con của P là Q, R, S, T.
3. Có 2 class con của X là Y, Z.
Như vậy ₫ể kiểm thử ₫ầy ₫ủ ₫ặc tả thiết kế, ta phải kiểm thử
phần mềm trên với 4*5*3 = 60 trường hợp khác nhau.
Thông qua 3 thí dụ kiểm thử vừa giới thiệu, ta thấy số lượng
kiểm thử là rất lớn, thường ta không có ₫ủ tài nguyên về con người,
về trang thiết bị và thời gian ₫ể kiểm thử hết tất cả. Buộc lòng ta
phải tìm tập con các trường hợp cần kiểm thử, nhưng làm sao xác
₫ịnh ₫ược tập con cần kiểm thử thỏa ₫iều kiện là số lượng càng ít
càng tốt mà chất lượng kiểm thử không bị suy giảm nhiều.
Thật ra có nhiều chiến lược kiểm thử khác nhau :
1. Không kiểm thử bộ n nào cả (vì khiếp sợ số lượng quá
lớn).
2. Kiểm thử tất cả bộ n, như vậy sẽ delay dự án quá lâu và
làm mất thị trường.
3. Kiểm thử 1 hay 2 bộ n và hy vọng là ₫ủ.
4. Chọn các bộ n ₫ã kiểm thử rồi (cho project khác).
5. Chọn các bộ n dễ dàng tạo ra và kiểm thử nhất, mà không
₫ể ý chất lượng của chúng ra sao.

6. Tạo tất cả bộ n và chọn 1 ít bộ n ₫ầu tiên trong danh sách.
7. Tạo tất cả bộ n và chọn 1 ít bộ n theo cơ chế ngẫu nhiên.
8. Chọn 1 tập con ₫ủ nhỏ bộ n mà tạo ₫ược ₫iều kỳ diệu là
chất lượng kiểm thử không bị giảm sút. Bằng cách nào,
nếu có ?
Có 2 phương pháp xác ₫ịnh ₫ược tập con các bộ n thần kỳ cần
kiểm thử :
1. Dùng ma trận trực giao (orthogonal array).
2. Dùng tiện ích Allpairs.
Ma trận trực giao là 1 bảng 2 chiều gồm n hàng * m cột các giá
trị số nguyên với 1 ₫ặc tính rất ₫ặc biệt là : 2 cột bất kỳ trong ma
trận ₫ều chứa ₫úng các bộ ₫ôi xác ₫ịnh trước.
Thí dụ, xét ma trận trực giao sau 4 hàng * 3 cột sau :

1
2
3
4

1
1
1
2
2

2
1
2
1
2

3
1
2
2
1

Ta thấy 2 cột bất kỳ trong ma trận ₫ều chứa ₫úng 4 bộ ₫ôi sau
₫ây (1,1), (1,2), (2,1), (2,2).
Ta miêu tả 1 ma trận trực giao như sau :

Số lượng các giá trị trong các cột không nhất thiết phải giống
nhau, chúng ta có thể trộn nhiều loại cột chứa phạm vi giá trị khác
nhau. Thí dụ ta dùng ký hiệu L18(21,37) ₫ể miêu tả ma trận trực
giao có 18 hàng, mỗi hàng chứa 1 cột 2 giá trị và 7 cột chứa 3 giá
trị.
Qui trình kiểm thử dùng các bộ n thần kỳ dựa vào ma trận trực
giao gồm các bước chính :
1. Nhận dạng các biến dữ liệu. Thí dụ bài toán kiểm thử
website trong các slide trước chứa 5 biến là Browser, Plugin, Client operating system, Web Server, và Server
operating system.
2. Xác ₫ịnh các giá trị cho từng biến. Thí dụ biến Browser có
8 giá trị lần lượt là : IE 5.0, IE 5.5, IE 6.0, Netscape 6.0,
6.1, 7.0, Mozilla 1.1, và Opera 7.
3. Tìm ma trận trực giao (trên mạng hay trong thư viện cá
nhân) có mỗi cột cho mỗi biến, và số giá trị trong cột tương
ứng với số giá trị của biến tương ứng. Thí dụ ta cần tìm ma
trận trực giao Lx (816133) cho bài toán kiểm thử website.
4. Nếu không có ma trận thỏa mãn chính xác yêu cầu thì
chọn ma trận trực giao có số cột tương ₫ương, nhưng số
lượng giá trị trong từng cột lớn hơn 1 chút cũng ₫ược. Cụ
thể chưa ai tạo ra ₫ược ma trận trực giao có kích thước Lx
(816133), do ₫ó ta có thể tìm ma trận trực giao với kích
thước L64(8243).
5. Ánh xạ bài toán kiểm thử vào ma trận trực giao bằng cách
thay thế giá trị số bằng giá trị ngữ nghĩa. Thí dụ ta dùng
cột 3 chứa 4 giá trị 1-4 ₫ể miêu tả biến Web Server, trong
trường hợp này ta thế các giá trị 1-4 thành 4 giá trị ngữ
nghĩa là IIS, Apache, WebLogic, Not used.
6. Xây dựng các test cases và kiểm thử chúng.

Thay vì dùng ma trận trực giao ₫ể nhận dạng các testcase, ta
có thể dùng 1 thuật giải ₫ể sinh tự ₫ộng các testcase.
Thí dụ James Bach ₫ã cung cấp 1 tool tạo tự ₫ộng tất cả các
tổ hợp bộ n, bạn có thể download tool này từ ₫ịa chỉ
http://www.satisfice.com và cái tiện ích này vào máy.
Để chuẩn bị dữ liệu nhập cho tiện ích, ta có thể Excel ₫ịnh
nghĩa các biến dữ liệu cùng tập các giá trị nhập có thể có của từng
biến theo dạng cột/hàng, sau ₫ó lưu kết quả dạng văn bản thô
*.txt. Chạy tiện ích theo dạng hàng lệnh như sau :
Allpairs input.txt > output.txt
Dùng 1 trình soạn trhảo văn bản mở file output.txt và xem kết
quả.
5.6 Kết chương
Chương này ₫ã giới thiệu những vấn ₫ề tổng quát về kiểm thử
hộp ₫en 1 TPPM.
Chúng ta ₫ã giới thiệu chi tiết cụ thể về 4 kỹ thuật kiểm thử
hộp ₫en ₫ược dùng phổ biến là kỹ thuật phân lớp tương ₫ương, kỹ
thuật phân tích các giá trị ở biên, kỹ thuật dùng bảng quyết ₫ịnh,
và kỹ thuật kiểm thử các bộ n thần kỳ.
Ứng với mỗi kỹ thuật kiểm thử, chúng ta cũng ₫ã giới thiệu 1
thí dụ cụ thể ₫ể demo qui trình thực hiện kỹ thuật kiểm thử tương
ứng.