Professional Documents
Culture Documents
2
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ử
3
Tài liệu
4
Verification,Validation, và Testing
z Kiểm chứng (Verification)
− có đúng đặc tả không, có đúng thiết kế không
− phát hiện lỗi lập trình
z Thẩm định (Validation)
− có đáp ứng nhu cầu người dùng không
− có hoạt động hiệu quả không
− phát hiện lỗi phân tích, lỗi thiết kế (lỗi mức cao)
z V&V = Verification and Validation
− mục tiêu là phát hiện và sửa lỗi PM, đánh giá tính dùng
được của PM
z Thứ tự thực hiện: Verification -> Validation
5
Kiểm chứng/Thẩm định tĩnh và động
z Kiểm chứng/Thẩm định tĩnh
− không thực hiện chương trình
− xét duyệt yêu cầu, thiết kế, mã nguồn
− tiến hành ở mọi công đoạn phát triển
− khó đánh giá tính hiệu quả của sản phẩm
z Kiểm chứng/Thẩm định động (kiểm thử - Testing)
− thực hiện chương trình
− cần có mã nguồn
− phát hiện lỗi lập trình
− đánh giá tính hiệu quả phần mềm
− là cách duy nhất để kiểm tra yêu cầu phi chức năng
6
Mô hình phát triển “V”
7
Kiểm thử phần mềm (Testing)
z Tập các hoạt động với mục đích khám phá các
lỗi và khuyết tật/khiếm khuyết
z Mục đích của kiểm thử:
− Thiết kế các ca kiểm thử (test cases) với khả năng tìm
kiếm các lỗi/khuyết tật
− Thực hiện chương trình với mục đích tìm các
lỗi/khuyết tật
z Mỗi phép kiểm thử (a test) chỉ thành công khi
− một lỗi được phát hiện
− một kết quả chỉ ra sự thất bại của thủ tục kiểm thử
được trả lại
8
Các loại kiểm thử phần mềm
z Kiểm thử tìm khuyết tật
− tìm lỗi lập trình
− tiến hành dựa trên phân tích đặc tả chức năng,
− phân tích mã nguồn
z Kiểm thử thống kê
− đánh giá tính dùng được của sản phẩm
− sử dụng dữ liệu thực (dựa trên thống kê)
− số người truy cập
− số giao tác
− cơ sở dữ liệu lớn
9
Yêu cầu đối với kiểm thử
10
Các nguyên lý kiểm thử PM
11
Ca kiểm thử (test case)
12
Nôi dung của test case
14
Kiểm thử chức năng
15
Phân hoạch tương đương
Equivalence partitioning
16
Phân hoạch tương đương - Ví dụ
17
Mở rộng các test case
18
Kiểm thử cấu trúc
19
Đường đi trong mô đun
20
Xác định đường đi
21
Start 0
11 3
End
6 4
7 8 5
9
10 22
1
đường đi:
1-2-3-8-1-9
9 2 1-2-4-6-7-8-1-9
4
3
5 6
7
8
23
Đường đi độc lập
24
1 Đường đi độc lập:
1-9
9 2 1-2-3-8-1-9
1-2-4-6-7-8-1-9
4
1-2-4-5-7-8-1-9
3
5 6
7
8
25
Đường đi độc lập
26
Độ phức tạp thuật toán
27
1 Số cạnh E = 11
Số đỉnh N = 9
Số điều kiện = 3
9 2 Số miền = 4
4
3
5 6 Độ phức tạp: 4
7
8
28
Độ phức tạp thuật toán
Độ phức tạp lớn thì xác suất xuất hiện lỗi cao
29
Chức năng vs. Cấu trúc
30
Kiểm thử và gỡ rối
31
Tiến trình gỡ rối
32
Mini test
33
Tạo test cases cho hàm tìm kiếm nhị phân
34
Tạo test cases cho hàm tìm kiếm nhị phân
0 7 -1
1 10 20 -1
1 10 3 -1
1 10 10 0
4 3 7 10 20 1 -1
4 3 7 10 20 30 -1
4 3 7 10 20 8 -1
4 3 7 10 20 3 0
4 3 7 10 20 20 3
4 3 7 10 20 7 1
35
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ử
36
Các giai đoạn kiểm thử
37
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
38
Kiểm thử đơn vị
driver
giao diện
cấu trúc dữ liệu
Module điều kiện biên
đường đi độc lập
xử lý lỗi
stub stub
test cases
RESULTS
39
Ví dụ sử dụng stub
40
Ví dụ sử dụng stub
String calc_day(Date d)
{
return "Sunday";
}
41
Ví dụ sử dụng stub
String calc_day(Date d)
{
String s;
cout << ”Enter day_of_week of ”<< d;
cin >> s;
return s;
}
42
Ví dụ về test drive
void calc_day_test_drive()
{
Date d;
String s;
while (1) {
cout << ”Enter date: ”);
cin >> d;
s = calc_day(d);
cout << s << endl;
}
}
43
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
44
Các chiến lược tích hợp
45
Kiểm thử trên xuống
Top-down testing
46
Kiểm thử trên xuống
Top module được
A kiểm thử trước
với các stubs
B F G
49
Kiểm thử dưới lên
B F K
Thay thế các driver
từng cái một
C G
D E H I
cluster cluster
51
Top down vs. Bottom up
52
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
53
Kiểm thử beta
54
Kiểm thử hệ thống
55
Kiểm thử gây áp lực - Stress Testing
56