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

 là cách thức miêu tả hành 
vi của TPPM dễ hiểu và dễ ₫ọc thì 1 dạng khác - bảng chuyển 
trạng thái — có thể miêu tả hành vi của TPPM hệ thống hơn và dễ 
xử lý tự ₫ộng hơn. 
 Bảng chuyển trạng thái gồm 4 cột : trạng thái hiện hành, sự 
kiện xảy ra, hành ₫ộng cần thực hiện/kết quả thu ₫ược, trạng thái 
kế tiếp. 
 Thí dụ lược ₫ồ chuyển trạng thái ở slide trước có thể chuyển 
thành bảng chuyển trạng thái : 
 Current State Event Action Next State 
null giveInfo startPayTimer Made 
null payMoney -- null 
null print -- null 
null giveTicket -- null 
null cancel -- null 
null PayTimerExpires -- null 
Made giveInfo -- Made 
 Current State Event Action Next State 
Made payMoney -- Paid 
Made print -- Made 
Made giveTicket -- Made 
Made cancel -- Can-Cust 
Made PayTimerExpires -- Can-NonPay 
Paid giveInfo -- Paid 
Paid payMoney -- Paid 
Paid print Ticket Ticketed 
Paid giveTicket -- Paid 
Paid cancel Refund Can-Cust 
Paid PayTimerExpires -- Paid 
Ticketed giveInfo -- Ticketed 
Ticketed payMoney -- Ticketed 
Ticketed print -- Ticketed 
Ticketed giveTicket -- Used 
Ticketed cancel Refund Can-Cust 
Ticketed PayTimerExpires -- Ticketed 
Used giveInfo -- Used 
Used payMoney -- Used 
Used print -- Used 
Used giveTicket -- Used 
Used cancel -- Used 
Used PayTimerExpires -- Used 
Can-NonPay giveInfo -- Can-NonPay 
Can-NonPay payMoney -- Can-NonPay 
Can-NonPay print -- Can-NonPay 
Can-NonPay giveTicket -- Can-NonPay 
Can-NonPay cancel -- Can-NonPay 
Can-NonPay PayTimerExpires -- Can-NonPay 
 Current State Event Action Next State 
Can-Cust givelnfo -- Can-Cust 
Can-Cust payMoney -- Can-Cust 
Can-Cust print -- Can-Cust 
Can-Cust giveTicket -- Can-Cust 
Can-Cust cancel -- Can-Cust 
Can-Cust PayTimerExpires -- Can-Cust 
 Dựa vào lược ₫ồ chuyển trạng thái, ta có thể dễ dàng ₫ịnh 
nghĩa các testcase. 
 1. Phủ cấp 1 : tạo các testcase sao cho mỗi trạng thái ₫ều 
 xảy ra ít nhất 1 lần. Thí dụ 3 tescase sau sẽ kiểm thử ₫ược 
 TPPM ₫ạt phủ cấp 1 : 
 2. Phủ cấp 2 : tạo các testcase sao cho mỗi sự kiện ₫ều xảy 
 ra ít nhất 1 lần. Thí dụ 3 tescase sau sẽ kiểm thử ₫ược 
 TPPM ₫ạt phủ cấp 2 : 
3. Phủ cấp 3 : tạo các testcase sao cho tất cả các path 
 chuyển ₫ều ₫ược kiểm thử. 1 path chuyển là 1 ₫ường 
 chuyển trạng thái xác ₫ịnh, bắt ₫ầu từ trạng thái nhập và 
 kết thúc ở trạng thái kết thúc. 
 Đây là phủ tốt nhất vì ₫ã vét cạn mọi khả năng hoạt ₫ộng 
 của TPPM, tuy nhiên không khả thi vì 1 path chuyển có 
 thể lặp vòng. 
4. Phủ cấp 4 : tạo các testcase sao cho mỗi path chuyển 
 tuyến tính ₫ều xảy ra ít nhất 1 lần. Thí dụ 5 tescase sau sẽ 
 kiểm thử ₫ược TPPM ₫ạt phủ cấp 4 : 
 Dựa vào bảng chuyển trạng thái, ta cũng có thể dễ dàng ₫ịnh 
nghĩa các testcase. 
 Current State Event Action Next State 
null giveInfo startPayTimer Made 
null payMoney -- null 
null print -- null 
null giveTicket -- null 
null cancel -- null 
null PayTimerExpires -- null 
Made giveInfo -- Made 
Made payMoney -- Paid 
Made print -- Made 
Made giveTicket -- Made 
Made cancel -- Can-Cust 
Made PayTimerExpires -- Can-NonPay 
Paid giveInfo -- Paid 
 Current State Event Action Next State 
Paid payMoney -- Paid 
Paid print Ticket Ticketed 
Paid giveTicket -- Paid 
Paid cancel Refund Can-Cust 
Paid PayTimerExpires -- Paid 
Ticketed giveInfo -- Ticketed 
Ticketed payMoney -- Ticketed 
Ticketed print -- Ticketed 
Ticketed giveTicket -- Used 
Ticketed cancel Refund Can-Cust 
Ticketed PayTimerExpires -- Ticketed 
Used giveInfo -- Used 
Used payMoney -- Used 
Used print -- Used 
Used giveTicket -- Used 
Used cancel -- Used 
Used PayTimerExpires -- Used 
Can-NonPay giveInfo -- Can-NonPay 
Can-NonPay payMoney -- Can-NonPay 
Can-NonPay print -- Can-NonPay 
Can-NonPay giveTicket -- Can-NonPay 
Can-NonPay cancel -- Can-NonPay 
Can-NonPay PayTimerExpires -- Can-NonPay 
Can-Cust givelnfo -- Can-Cust 
Can-Cust payMoney -- Can-Cust 
Can-Cust print -- Can-Cust 
Current State Event Action Next State 
Can-Cust giveTicket -- Can-Cust 
Can-Cust cancel -- Can-Cust 
Can-Cust PayTimerExpires -- Can-Cust 
6.2 Kỹ thuật phân tích vùng (Domain Analysis) 
 Như ta ₫ã biết, 2 kỹ thuật kiểm thử phân lớp tương ₫ương và 
phân tích giá trị biên chủ yếu xử lý các biến dữ liệu ₫ộc lập, rời rạc. 
Tuy nhiên thường thì các biến dữ liệu có mối quan hệ với nhau, do 
₫ó cách tốt nhất là nên tổ hợp chúng ₫ể kiểm thử : 
 ƒ Nếu tạo các testcase cho từng biến dữ liệu ₫ộc lập thì số 
 lượng testcase sẽ quá nhiều. 
 ƒ Các biến dữ liệu thường tương tác nhau, giá trị của biến 
 này có thể ràng buộc giá trị của biến kia, do ₫ó nếu kiểm 
 thử chúng ₫ộc lập thì không thể phát hiện lỗi liên quan ₫ến 
 sự ràng buộc này. 
 Kỹ thuật phân tích vùng rất thích hợp trong việc xác ₫ịnh các 
testcase hiệu quả khi các biến dữ liệu có sự tương tác lẫn nhau. 
Nó ₫ược xây dựng trên 2 kỹ thuật kiểm thử ₫ược ₫ề cập ở trên và 
tổng quát hóa chúng ₫ể kiểm thử ₫ồng thời n biến dữ liệu. 
 Xét trường hợp 2 biến dữ liệu tương tác nhau, ta thấy có 4 loại 
lỗi sau : 
 1. Biên ngang bị dịch lên hay xuống 
 Đúng Sai
2. Biên nghiêng sai góc 
 Đúng Sai
3. Thiếu biên 
 Đúng Sai
4. Thừa biên 
 Đúng Sai
Ta ₫ịnh nghĩa 1 số thuật ngữ : 
1. Điểm on : là ₫iểm nằm trên biên 
 2. Điểm off : là ₫iểm không nằm trên biên 
 3. Điểm in : là ₫iểm thỏa mọi ₫iều kiện biên nhưng không 
 nằm trên biên. 
 4. Điểm out : là ₫iểm không thỏa bất kỳ ₫iều kiện biên. 
 Việc chọn ₫iểm on và off thường phức tạp hơn chúng ta nghĩ : 
 ƒ Nếu biên ₫óng (dùng toán tử so sánh có yếu tố =), thì 
 ₫iểm on nằm trên biên và thuộc vùng xử lý. Trong trường 
 hợp này, ta chọn ₫iểm off nằm ngoài vùng xử lý. 
 ƒ Nếu biên mở (dùng toán tử so sánh không có yếu tố =), thì 
 ₫iểm on nằm trên biên nhưng không thuộc vùng xử lý. 
 Trong trường hợp này ta chọn ₫iểm off nằm trong vùng xử 
 lý. 
 Thí dụ về các ₫iểm on, off, in và out : 
 Kỹ thuật phân tích vùng yêu cầu chúng ta chọn các tescase 
theo cách thức sau : 
 1. Ứng với mỗi ₫iều kiện , ≤, ≥, chọn 1 ₫iểm on và 1 ₫iểm 
 off. 
 2. Ứng với mỗi ₫iều kiện =, ≠, chọn 1 ₫iểm on, 2 ₫iểm off 
 ngay trên và ngay dưới ₫iểm on. 
Binder ₫ề nghị 1 bảng rất hữu ích — ma trận kiểm thử vùng : 
Thí dụ, TPPM xét kết quả ₫ậu ₫ại học theo tiêu chuẩn sau : 
ƒ 10*GPA + ACT >= 71 
ƒ GPA : ₫iểm trung bình tích lũy của lớp phổ thông (<=4.0) 
ƒ ACT : ₫iểm thi tuyển vào ₫ại học (<= 36). 
6.3 Kỹ thuật dùng thông tin trong use-case 
 Trong qui trình phát triển phần mềm hợp nhất, ta thực hiện 
nhiều workflows khác nhau : nắm bắt yêu cầu phần mềm, phân 
tích từng yêu cầu, thiết kế chi tiết ₫ể giải quyết từng yêu cầu, hiện 
thực từng phần bảng thiết kế, kiểm thử kết quả. 
 Mỗi workflows, thậm chí mỗi lần lập thực hiện 1 workflow, ta 
phải có kết quả, kết quả này phải ₫ược miêu tả ở dạng dễ ₫ọc, dễ 
hiểu bởi nhiều người và phải cố gắng ₫ơn nghĩa ₫ể tránh nhặp 
nhằng. 
 Ta dùng khái niệm mô hình ₫ể miêu tả hệ thống phần mềm 
theo một góc nhìn nào ₫ó. 
 UML diagrams provide 
 views into each model 
Requirements Use Case 
 Model 
 Analysis Analysis
 Model
 Design Design Depl.
 Model Model
Implementation Impl. 
 Model 
 Each workflow is 
 associated with one or 
 more models. 
 Test
 Test 
 Model 
 Về nguyên tắc, khi kiểm thử 1 thành phần phần mềm, ta có thể 
tận dụng bất kỳ thông tin nào trong bất kỳ mô hình nào. Kỹ thuật 
kiểm thử dùng thông tin trong use-case là kỹ thuật ₫ịnh nghĩa các 
testcase dựa vào các kịch bản thực hiện usecase. 
 Như chúng ta biết, mô hình usecase miêu tả hệ thống phần 
mềm theo góc nhìn bên ngoài : nó cung cấp các chức năng nào 
cho những “user” nào. Thành phần thiết yếu nhất của mô hình 
usecase là các lược ₫ồ usecase. 
 Mỗi lược ₫ồ usecsae thể hiện 1 bộ phận nhỏ của phần mềm : 
nó bao gồm nhiều chức năng và các chức năng này tương tác với 
các actor nào. 
 Thí dụ lược ₫ồ usecase liên quan ₫ến bộ phận chức năng 
quản lý khách hàng trong hệ thống thương mại ₫iện tử. 
 >
 User Maintenance POS Login
 Store Manager
 >
 >
 <<exten...
 Edit User Information
 Add New User
 Remove User
 Trong lược ₫ồ usecase, mỗi usecase thể hiện 1 chức năng mà 
bên ngoài có thể truy xuất, tuy nhiên mỗi usecase chỉ ₫ược miêu 
tả ở dạng tối giản : gồm 1 hình ellipse và tên gợi nhớ sơ bộ về 
chức năng của usecase. 
 Để hiểu ₫ầy ₫ủ hơn về usecase, người ta cần ₫ặc tả usecase 
ở 1 dạng chi tiết nào ₫ó. Rất tiết là hiện nay, mỗi nơi mỗi khác, 
chưa có 1 chuẩn nào ₫ược mọi người chấp thuận. 
 Ở ₫ây, ta hãy dùng khuôn mẫu chi tiết ₫ể ₫ặc tả usecase do 
Alistair Cockburn ₫ề nghị trong sách “Writing Effective Use 
Cases”. 
Use Case Component Description 
Use Case Number or Identifier A unique identifier for this use case 
 The name should be the goal stated as a short 
Use Case Name 
 active verb phrase 
 A more detailed statement of the goal if 
Goal in Context 
 necessary 
Scope Corporate | System | Subsystem 
Level Summary | Primary task | Subfunction 
Use Case Component Description 
Primary Actor Role name or description of the primary actor 
 The required state of the system before the use 
Preconditions 
 case is triggered 
 The state of the system upon successful 
Success End Conditions 
 completion of this use case 
 The state of the system if the use case cannot 
Failed End Conditions 
 execute to completion 
 The action that initiates the execution of the use 
Trigger 
 case 
Main Success Scenario Step Action 
 1 
 2 
 ... 
 Conditions under which the main success 
Extensions scenario will vary and a description of those 
 variations 
 Variations that do not affect the main flow but 
Sub-Variations 
 that must be considered 
Priority Criticality 
Response Time Time available to execute this use case 
Frequency How often this use case is executed 
Channels to Primary Actor Interactive | File | Database | ... 
 Other actors needed to accomplish this use 
Secondary Actors 
 case 
Channels to Secondary Actors Interactive | File | Database | ... 
Date Due Schedule information 
 Use Case identified (0.1)| Main scenario 
Completeness Level defined (0.5) | All extensions defined (0.8) | All 
 fields complete (1.0) 
Open Issues Unresolved issues awaiting decisions 
 Thí dụ bảng ₫ặc tả usecase “₫ăng ký môn học” trong phần 
mềm quản lý học vụ có nội dung chi tiết như sau : 
Use Case Component Description 
Use Case Number or SURS1138 
Identifier 
 Register for a course (a class taught by a faculty 
Use Case Name 
 member) 
Goal in Context 
Scope System 
Level Primary task 
Primary Actor Student 
Preconditions None 
 The student is registered for the course–the course 
Success End Conditions 
 has been added to the student's course list 
Failed End Conditions The student's course list is unchanged 
Trigger Student selects a course and "Registers" 
 Step Action 
 1 A: Selects "Register for a course" 
 2 A: Selects course (e.g. Math 1060) 
Main Success Scenario 
 3 S: Displays course description 
A: Actor 4 A: Selects section (Mon & Wed 9:00am) 
S: System 5 S: Displays section days and times 
 6 A: Accepts 
 S: Adds course/section to student's course 
 7 
 list 
 Course does not exist 
 2a
 S: Display message and exit 
 Section does not exist 
 4a 
 S: Display message and exit 
Extensions 
 Section is full 
 4b 
 S: Display message and exit 
 Student does not accept 
 6a 
 S: Display message and exit 
Use Case Component Description 
 Student may use 
Sub-Variations • Web 
 • Phone 
Priority Critical 
Response Time 10 seconds or less 
 Approximately 5 courses x 10,000 students over a 
Frequency 
 4-week period 
Channels to Primary Actor Interactive 
Secondary Actors None 
Channels to Secondary N/A 
Actors 
Date Due 1 Feb 
Completeness Level 0.5 
Open Issues None 
 Dựa vào ₫ặc tả về kịch bản chính và về các nới rộng của kịch 
bản, ta sẽ thiết kế các testcase theo ý tưởng như sau : 
 ƒ Ít nhất 1 testcase ₫ể kiểm thử kịch bản chính. 
 ƒ Ít nhất 1 testcase cho từng nới rộng có thể có. 
 ƒ Nếu kịch bản chính hay 1 nới rộng nào ₫ó bị loop thì 
 không cần thiết phải kiểm thử phần loop lại. 
6.4 Kỹ thuật dùng ₫ồ thị nhân quả (Cause-Effect Diagram) 
 Đồ thị nhân quả là 1 dạng khác của mạng luận lý tổ hợp mà 
phần cứng thường dùng. Các phần tử cấu thành ₫ồ thị nhân quả là 
: 
 ƒ các nút : mỗi nút miêu tả 1 hậu quả (1 hay nhiều hoạt 
 ₫ộng + 1 hay nhiều kết quả). 
 ƒ các ₫oạn thẳng : mỗi ₫oạn thẳng miêu tả 1 nguyên nhân 
 (1 ₫iều kiện dữ liệu nhập ở dạng nhị phân) 
 ƒ các ký hiệu : mỗi ký hiệu miêu tả 1 phép toán luận lý. 
 ƒ các phần tử ràng buộc, mỗi phần tử miêu tả 1 ràng buộc 
 xác ₫ịnh nào ₫ó. 
 Identify Not
 a b a b
 a Z b a Z b
 Ident Not 
 a
 b 
 And Or
 ∩ c 
 b ∪ d
 a 
 c
 a 
 c a d
 b
 b c 
 Giả sử ₫ặc tả 1 TPPM như sau : dữ liệu ₫ầu vào là tên file gồm 
2 ký tự, ký tự ₫ầu là A hay B, ký tự còn lại là ký số, TPPM sẽ cập 
nhật file, nếu ký tự ₫ầu không phải là A hay B thì TPPM báo lỗi X1, 
nếu ký tự thứ 2 không phải là số thì báo lỗi X2. 
 Duyệt ₫ọc ₫ặc tả và phân tích ₫ặc tả, ta tìm ₫ược các ₫iều 
kiện ₫ầu vào là : 
 1 : Ký tự ₫ầu là A. 
 2 : Ký tự ₫ầu là B. 
 3 : Ký tự thứ hai là ký số. 
 Và các hậu quả ở ₫ầu ra là : 
 101 : cập nhật file. 
 102 : báo lỗi X1. 
 103 : báo lỗi X2. 
 Đồ thị nhân quả của TPPM ở silde trước là : 
 102 
 1 Or 
 ∪ 11
 ∩ 101 
 2 
 3 103 
 Trong nhiều trường hợp, tồn tại tổ hợp ₫iều kiện nhập không 
thể xảy ra, thí dụ ở slide trước, ₫iều kiện 1 và 2 không thể xảy ra 
₫ồng thời vì ký tự ₫ầu không thể vừa là A vừa là B. Để miêu tả các 
ràng buộc này, ta dùng các ký hiệu ràng buộc sau : 
 1. E : không thể ₫ồng thời xảy ra. 
 a
 E
 b
 2. I : phải ít nhất 1 ₫iều kiện xảy ra. 
 a
 I b
 c
 3. O : 1 và chỉ 1 ₫iều kiện xảy ra. 
 a
 O
 b
 4. R : nếu a xảy ra thì b cũng xảy ra. 
 a
 R
 b 
 Đồ thị nhân quả của TPPM ở slide 34 ₫ược hoàn chỉnh là : 
 102 
 1 Or
 ∪ 11
 ∩ 101 
 2 
 3 103 
 Qui trình ₫ịnh nghĩa các testcase dùng kỹ thuật ₫ồ thị nhân 
quả gồm các bước : 
 1. Đặc tả của TPPM ₫ược chia nhỏ ra nhiều phần nhỏ ₫ể có 
 thể làm việc dễ dàng (nếu không thì ₫ồ thị nhân quả sẽ rất 
 phức tạp). 
 2. Nhận dạng các nguyên nhân và hậu quả của phần nhỏ 
 ₫ang xử lý. 
 3. Tìm mối quan hệ giữa các nguyên nhân và hậu quả, mỗi 
 mối quan hệ ₫ược vẽ thành 1 ₫ường nối. 
 4. Xác ₫ịnh các ràng buộc giữa các nguyên nhân và chú 
 thích chúng vào ₫ồ thị. 
 5. Chuyển ₫ồ thị nhân quả về bảng quyết ₫ịnh. 
 6. Chuyển bảng quyết ₫ịnh thành bảng các testcase. 
6.5 Kết chương 
 Chương này ₫ã tiếp tục 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 khác là kỹ thuật dùng lược 
₫ồ chuyển trạng thái, kỹ thuật phân tích vùng, kỹ thuật dùng thông 
tin trong use-case, và kỹ thuật dùng ₫ồ thị nhân quả. 
 Ứ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.