Bài giảng Công nghệ phần mềm nâng cao - Phạm Ngọc Hùng - Kiểm chứng, thẩm định và kiểm thử

− màn hình, thời gian phản hồi
z Kết quả thực tế
14
Các kỹ thuật kiểm thử chương trình
z Kiểm thử chức năng (functional testing)
− dựa trên đặc tả chức năng
− phát hiện các sai sót về chức năng
− không quan tâm đến cách cài đặt
z Kiểm thử cấu trúc (structured testing)
− kiểm thử có nghiên cứu mã nguồn
− phân tích thứ tự thực hiện các lệnh
15
Kiểm thử chức năng
Functional testing / Black box testing
Dựa trên đặc tả chức năng
• Test case được thiết kế để kiểm tra chức năng
• Phát hiện các khiếm khuyết so với đặc tả
• Không quan tâm đến cách cài đặt (mã nguồn)
- Phát hiện sai sót, thiếu sót chức năng
- Sai sót về giao diện của mô đun
- Kiểm tra tính hiệu quả
- Phát hiện lỗi khởi tạo, lỗi kết thúc,…
16
Phân hoạch tương đương
• Không thể kiểm thử mọi trường hợp
• Chia dữ liệu thành các miền có cùng hành vi
• Tạo một test case cho từng miền
• Tạo test case cho biên của các miền
- nhiều lỗi xuất hiện với giá trị biên
Equivalence partitioning
17
Phân hoạch tương đương - Ví dụ
Hàm tính trị tuyệt đối
- miền dữ liệu ≥ 0
- miền dữ liệu < 0
100
20
0
100
-20
0
Expected 
Output
Input
18
Tạo test case cho các trường hợp
đặc biệt
- biên của số trong máy tính
(vd. 32767, -32768)
- số không (0)
- số âm, số thập phân
- dữ liệu sai kiểu
- dữ liệu ngẫu nhiên
Mở rộng các test case
19
Kiểm thử cấu trúc
• Xây dựng ca kiểm thử dựa trên phân tích mã nguồn
• Xây dựng bộ test case để kiểm tra mọi dòng lệnh
• Phân tích các lệnh rẽ nhánh, vòng lặp
• Phù hợp với các mô đun nhỏ
• Là sự bổ sung cho kiểm thử chức năng
Structural testing / White box testing
20
Đường đi trong mô đun
• Phân tích mô đun để xác định đường đi
• Đường đi là thứ tự thực hiện các lệnh từ điểm
bắt đầu đến điểm kết thúc của mô đun
• Thiết kế các test case để kiểm thử mọi đường đi
21
Xác định đường đi
• Đánh số các khối lệnh
- đánh số các khối lệnh, câu lệnh điều kiện
- đánh số các hợp điểm của luồng lệnh
• Rút gọn flow chart (đồ thị)
- các khối tuần tự được tích hợp thành một
khối
- tích hợp khối tuần tự vào câu lệnh điều kiện
kế tiếp
22
1
2
3
4
5
6
7 8
9
10
11
Start
End
0
23
1
2
4
65
7
8
3
9
đường đi:
1-2-3-8-1-9
1-2-4-6-7-8-1-9
24
Đường đi độc lập
• Không thể chọn mọi đường đi
- chọn các đường đi độc lập
• Đường đi độc lập
- có ít nhất một cặp khối lệnh (một cạnh của đồ thị) 
chưa xuất hiện trong các đường đi đã có
• Bộ các đường đi độc lập là một tập hợp thỏa mãn
- mọi khối lệnh đều được thực hiện ít nhất một lần
- mọi điều kiện đều được kiểm thử với hai trường
hợp true và false
25
1
2
4
65
7
8
3
9
1-9
1-2-3-8-1-9
1-2-4-6-7-8-1-9
1-2-4-5-7-8-1-9
Đường đi độc lập:
26
Đường đi độc lập
có thể tồn tại nhiều bộ đường đi độc lập
số đường đi tối thiểu cần kiểm tra
= độ phức tạp thuật toán
27
Độ phức tạp thuật toán
Độ phức tạp V(G) của flow chart G:
1. Số miền của đồ thị G
2. V(G) = E - N + 2
E: số cạnh
N: số đỉnh
3. V(G) = P + 1
P: số các nút điều kiện
28
1
2
4
65
7
8
3
9
Độ phức tạp: 4
Số cạnh E = 11
Số đỉnh N = 9
Số điều kiện = 3
Số miền = 4
29
Độ phức tạp thuật toán
không nên tạo các mô đun có độ phức tạp > 
10 phân rã mô đun (tạo các mô đun thứ cấp
để giảm độ phức tạp)
Độ phức tạp lớn thì xác suất xuất hiện lỗi cao
30
Chức năng vs. Cấu trúc
• Kiểm thử chức năng
- kiểm tra tính hiệu quả của phần mềm
- thuận tiện với các mô đun lớn, tích hợp
• Kiểm thử cấu trúc
- đảm bảo mọi lệnh đều được kiểm tra
- hiệu quả với các mô đun nhỏ, đơn lẻ
31
Kiểm thử và gỡ rối
z Kiểm thử và gỡ rối là hai công việc phân biệt
z Kiểm thử nhằm phát hiện sự tồn tại của lỗi
z Gỡ rối nhằm định vị và sửa chữa mã gây lỗi
z Gỡ rối bao gồm việc sinh ra các giả thiết về
hoạt động của chương trình và kiểm thử
chương trình để tìm lỗi
32
Tiến trình gỡ rối
Locate
error
Design
error repair
Repair
error
Re-test
program
Test
results Specification
Test
cases
33
Mini test
Tạo test case (dựa trên phân hoạch tương đương)
cho hàm tìm kiếm sau:
input: - mảng số nguyên a[] đã sắp xếp
- khóa tìm kiếm k (số nguyên)
output: vị trí của k trong mảng a[] nếu có, -1 nếu
không có
34
Tạo test cases cho hàm tìm kiếm nhị phân
Số phần tử của mảng: 
- 0, 1
- lớn hơn 1
Khóa tìm kiếm: 
- không có trong mảng
+ nhỏ hơn, lớn hơn
+ xen kẽ
- có trong mảng
+ phần tử đầu tiên, cuối cùng
+ phần tử ở vị trí bất kỳ
35
Tạo test cases cho hàm tìm kiếm nhị phân
-1
-1
-1
0
-1
-1
-1
0
3
1
7
20
3
10
1
30
8
3
20
7
10
10
10
3 7 10 20
3 7 10 20
3 7 10 20
3 7 10 20
3 7 10 20
3 7 10 20
0
1
1
1
4
4
4
4
4
4
Kết quảKhóaMảngSố p.tử
36
Nội dung
z Giới thiệu
− Verification,Validation, và Testing
z Các nguyên lý về kiểm thử
z Ca kiểm thử (test case)
z Các kỹ thuật kiểm thử chương trình
− Kiểm thử chức năng
− Kiểm thử cấu trúc
z Các giai đoạn và chiến lược kiểm thử
37
Các giai đoạn kiểm thử
z Kiểm thử đơn vị
z Kiểm thử tích hợp
− top-down
− bottom-up
z Kiểm thử chấp nhận
− alpha, beta testing
z Kiểm thử hệ thống
38
Kiểm thử đơn vị
Unit testing
• Kiểm thử các mô đun, chương trình riêng lẻ
• Người tiến hành: thường là người lập trình
• Sử dụng các stubs và drivers
• Phối hợp giữa kiểm thử cấu trúc và kiểm thử
chức năng
- kiểm tra câu lệnh điều kiện, cấu trúc dữ liệu
điều kiện biên,...
• Tài liệu thường sơ sài
39
Kiểm thử đơn vị
Module
stub stub
driver
RESULTS
giao diện
cấu trúc dữ liệu
điều kiện biên
đường đi độc lập
xử lý lỗi
test cases
40
Ví dụ sử dụng stub
• Kiểm thử mô đun calender() có gọi đến mô
đun tính ngày
• trong tuần calc_day()chưa được phát triển.
calender()
calc_day()
đã phát triển, cần kiểm thử
chưa phát triển
41
Mô đun tính ngày trong tuần calc_day():
- input: ngày, tháng, năm
- output: trả xâu kí tự là thứ của ngày đã cho
String calc_day(Date d)
{
return "Sunday";
} 
Ví dụ sử dụng stub
42
Để tăng độ thích nghi, có thể thay thế dữ liệu cố
định bằng cách nhập kết quả trực tiếp từ bàn phím.
String calc_day(Date d)
{
String s;
cout << ”Enter day_of_week of ”<< d;
cin >> s;
return s;
}
Ví dụ sử dụng stub
43
Ví dụ về test drive
Test drive để thử nghiệm calc_day()
void calc_day_test_drive()
{
Date d;
String s;
while (1) {
cout << ”Enter date: ”);
cin >> d;
s = calc_day(d); 
cout << s << endl;
}
}
44
Kiểm thử tích hợp
Intergration testing
• Kiểm thử tích hợp các unit
• Người tiến hành: người lập trình, người thiết
kế...
• Các unit được thêm vào theo một trong 2 chiến
lược top-down hoặc bottom-up
• Mục đích:
- kiểm tra giao diện giữa các unit
- kiểm tra tính đúng đắn so với đặc tả
- kiểm tra tính hiệu quả
• Thường sử dụng kiểm thử chức năng
• Được lập tài liệu
45
Các chiến lược tích hợp
Kiểm thử trên xuống (top-down)
Kiểm thử dưới lên (bottom-up)
Kiểm thử quay lui (regression)
46
Kiểm thử trên xuống
Top-down testing
Các mô đun mức trên được kiểm thử trước
Các mô đun thuộc cấp được thay bằng bằng các
mô đun tạm thời (stub function)
- có cùng tên với mô đun thật
- có cùng giao diện
- trả lại kết quả với một hoặc một vài bộ dữ liệu
chuẩn
47
Kiểm thử trên xuống
A
B
C
D E
F G
Top module được
kiểm thử trước
với các stubs
Các stubs được thay
thế từng cái một
Mỗi khi một module mới
được tích hợp
một số ca kiểm thử được
thực hiện lại
(kiểm thử quay lui)
48
Ưu nhược điểm của top-down
Phát hiện sớm các lỗi thiết kế (lỗi cấu trúc)
- kiểm thử trên xuống kết hợp với phát triển trên
xuống sẽ giúp phát hiện sớm các lỗi thiết kế và
làm giảm giá thành sửa đổi
Có sớm phiên bản thực hiện được
- phiên bản thực hiện với các chức năng chính có sớm
- có thể thẩm định tính dùng được của sản phẩm sớm
Ưu điểm:
Nhược điểm
Nhiều mô đun cấp thấp rất khó mô phỏng
- thao tác với cấu trúc dữ liệu phức tạp
- trả lại kết quả phức tạp (con trỏ, ảnh, ...)
49
Kiểm thử dưới lên - bottom-up testing
Các mô đun cấp thấp được kiểm thử trước
Mô đun mức trên được thay thế bằng mô đun
điều khiển (test driver), có chức năng
- gọi mô đun cần thử nghiệm
- truyền dữ liệu
- hiển thị kết quả
Thay thế dần các drive
50
Kiểm thử dưới lên
A
B
C
D E
F K
cluster
G
H I
cluster
Các module mức thấp được tích hợp trước
Thay thế các driver
từng cái một
51
Ưu nhược điểm của bottom up
- Tránh xây dựng các mô đun tạm thời (stub) 
phức tạp
- Tránh sinh các kết quả nhân tạo (nhập từ
bàn phím)
- Thuận tiện cho phát triển các mô đun để
dùng lại
• Ưu điểm
- Chậm phát hiện các lỗi kiến trúc
- Chậm có phiên bản thực hiện
• Nhược điểm
52
Top down vs. Bottom up
z Mỗi chiến lược đều có ưu nhược điểm
riêng
z Chiến lược kiểm thử phải phù hợp với
chiến lược phát triển
− phát triển top-down = top-down testing
− phát triển bottom-up = bottom-up testing
z Có thể phối hợp các chiến lược: 
Sandwich testing
53
Kiểm thử chấp nhận
Acceptance testing
• Có sự tham gia của khách hàng/người sử
dụng
• Dùng kiểm thử chức năng
• Mục đích: thẩm định (validation) phần mềm
- sai sót, thiếu sót so với yêu cầu người
dùng
• Sử dụng các dữ liệu thực do user cung cấp
• Kiểm thử chấp nhận tiến hành ở môi trường
khách hàng được gọi là alpha testing
54
Kiểm thử beta
• Mở rộng của alpha testing
• Được tiến hành với một lượng lớn users
• User tiến hành kiểm thử không có sự hướng
dẫn của người phát triển; thông báo lại kết quả
cho người phát triển
55
Kiểm thử hệ thống
z Mở rộng phạm vi kiểm thử, nhìn nhận
phần mềm là một yếu tố trong một HTTT 
phức tạp
z Kiểm tra các yếu tố
− khả năng phục hồi sau lỗi
− độ an toàn
− hiệu năng và giới hạn của phần mềm
56
Kiểm thử gây áp lực - Stress Testing
Sử dụng các dữ liệu lớn
- số người sử dụng lớn, số giao dịch lớn, 
tệp kích thước lớn…
ƒ mức tới hạn của hệ thống (mức tải khiến hệ
thống ngừng hoạt động)
ƒ phản ứng của hệ thống khi đạt mức tới hạn
+ biến thiên của thời gian phản hồi
+ độ an toàn của dữ liệu,...
ƒ các tổ hợp điều kiện khiến hệ ngừng hoạt động
+ OS, phần mềm, phần cứng,...
• Nghiên cứu: