Bài giảng Kiểm thử phần mềm - Chương 5: Kỹ thuật kiểm thử hộp đen - Nguyễn Văn Hiệp

iề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 Số lượng nhà Đương ₫ơn Kiểu nhà Kết quả 
 /tháng 
 5.000 2 Person Condo Valid 
 100 1 Person Single Invalid 
 1.342 0 Person Condo Invalid 
 5.432 3 Corporation Townhouse Invalid 
 10.000 2 Person Treehouse 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 
 1000USD 83333USD 
Thu nhập Số lượng nhà Kết quả Diễn giải 
 /tháng 
 $1,000 1 Valid Min Thu nhập, min SoLN 
 $83,333 1 Valid Max Thu nhập, min SoLN 
 $1,000 5 Valid Min Thu nhập, max SoLN 
 $83,333 5 Valid Max Thu nhập, max SoLN 
 $1,000 0 Invalid Min Thu nhập, below min SoLN 
 $1,000 6 Invalid Min Thu nhập, above max SoLN 
 $83,333 0 Invalid Max Thu nhập, below min SoLN 
 $83,333 6 Invalid Max Thu nhập, above max SoLN 
 $999 1 Invalid Below min Thu nhập, min SoLN 
 $83,334 1 Invalid Above max Thu nhập, min SoLN 
 $999 5 Invalid Below min Thu nhập, max SoLN 
 $83,334 5 Invalid Above max Thu nhập, max SoLN 
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 Rule 2  Rule p 
Conditions 
 Condition-1 
 Condition-m 
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 
 TC1 TC2 TC3 TC4 
Conditions 
Married? Yes Yes No No 
Good Student? Yes No Yes No 
Actions 
Discount ($) 60 25 50 0 
 Rule 1 Rule 2 Rule 3 Rule 4 
Conditions 
 Cond 1 0—1 1—10 10—100 100—1000
 Cond 2 7 
Actions 
 Action-1 Do X Do Y Do X Do Z 
 TC1 TC2 TC3 TC4 
Conditions 
 Cond 1 0 5 50 500 
 Cond 2 3 5 7 10 
Actions 
 Action-1 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 
 1 1 1 1 
 2 1 2 2 
 3 2 1 2 
 4 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, Plug-
 in, 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ỉ 
 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.