Với mục đích giúp các bạn sinh viên có thể hiểu được các khái niệm về verification, valdation, vàt esting; nắm được các nguyên lý về kiểm thử; hiểu khái niệm ca kiểm thử (test case); các phương pháp thiết kế test case; phương pháp kiểm thử chương trình và phương pháp kiểm thử hệ thống chúng tôi xin giới thiệu tới các bạn Bài giảng Kiểm chứng, thẩm định và kiểm thử.
(cid:122) Sau buổi học sinh viên phải nắm được:
− Hiểu các khái niệm: verification, valdation, và
− Nắm được các nguyên lý về kiểm thử − Hiểu khái niệm ca kiểm thử (test case) − Các phương pháp thiết kế test case − Làm thế nào để kiểm thử chương trình − Làm thế nào để kiểm thử hệ thống
2
testing
(cid:122) Giới thiệu
− Verification,Validation, và Testing
(cid:122) Các nguyên lý về kiểm thử (cid:122) Ca kiểm thử (test case) (cid:122) 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
(cid:122) Các giai đoạn và chiến lược kiểm thử
3
(cid:122) Pressman, Software Engineering, McGraw Hill (chapter 18 & 19)
(cid:122) Sommerville, Software Engineering, Addison-Wesley (chapter 22 & 23)
(cid:122) Giáo trình kỹ nghệ phần mềm (chương 5) (cid:122) Các tài liệu điện tử khác
4
(cid:122) 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 (cid:122) 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)
(cid:122) 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
(cid:122) Thứ tự thực hiện: Verification -> Validation
5
(cid:122) 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
(cid:122) 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
Đặc tả yêu cầu
Đặc tả hệ thống
Thiết kế hệ thống
Thiết kế chi tiết
Kế hoạch kiểm thử chấp nhận
Kế hoạch kiểm thử tích hợp HT
Kế hoạch kiểm thử tích hợp HT con
Mã hóa mô đun & kiểm thử mô đun
Dịch vụ
Kiểm thử chấp nhận
Kiểm thử tích hợp hệ thống
Kiểm thử tích hợp các hệ thống con
7
(cid:122) Tập các hoạt động với mục đích khám phá các
(cid:122) 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
(cid:122) 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
lỗi và khuyết tật/khiếm khuyết
(cid:122) 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
(cid:122) 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
(cid:122) Tính lặp lại
− kiểm thử phải lặp lại được (kiểm tra xem lỗi
− dữ liệu/trạng thái phải mô tả được
(cid:122) Tính hệ thống
− đảm bảo kiểm tra hết các trường hợp
đã được sửa hay chưa)
− kiểm soát tiến trình/kết quả
10
(coverage) (cid:122) Được lập tài liệu
(cid:122) Các phép kiểm thử phải tương ứng với các
(cid:122) Mỗi phép kiểm thử nên được lập kế hoạch từ
yêu cầu của HT
(cid:122) Qui luật Pareto hay qui luật 80/20 (qui luật thiểu số quan trọng và phân bố nhân tố) − khoảng 80% kết quả là do 20% nguyên nhân gây
ra
− “80% of all errors uncovered during testing will
likely be traceable to 20% of all program modules or classes”
11
rất sớm trước khi tiến hành kiểm thử
(cid:122) Ca kiểm thử: dữ liệu để kiểm tra hoạt
(cid:122) Ca kiểm thử tốt
− được thiết kế để phát hiện một lỗi của
(cid:122) Kiểm thử thành công: phát hiện ra lỗi (cid:122) Mục đích:
− Chứng minh được sự tồn tại của lỗi − Không chứng minh được sự không có lỗi
12
chương trình
(cid:122) Tên mô đun/chức năng muốn kiểm thử
(cid:122) Kết quả mong muốn
− thông thường: số, xâu kí tự, file,... − màn hình, thời gian phản hồi
(cid:122) Kết quả thực tế
13
(cid:122) 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
(cid:122) 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
14
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)
15
- 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,…
Equivalence partitioning
16
• 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
Input
100 -20 0
Expected Output 100 20 0
17
Hàm tính trị tuyệt đối - miền dữ liệu ≥ 0 - miền dữ liệu < 0
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)
18
- số không (0) - số âm, số thập phân - dữ liệu sai kiểu - dữ liệu ngẫu nhiên
Structural testing / White box testing
19
• 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
• 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
20
• Thiết kế các test case để kiểm thử mọi đườ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
21
kế tiếp
Start 0
1
2
11 3
End
4 6
5 8 7
9
22
10
1
đường đi: 1-2-3-8-1-9 1-2-4-6-7-8-1-9 2 9
4
3
5 6
7
23
8
• 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ó
24
• 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
1 Đường đi độc lập:
2 9
4
1-9 1-2-3-8-1-9 1-2-4-6-7-8-1-9 1-2-4-5-7-8-1-9 3
5 6
7
25
8
có thể tồn tại nhiều bộ đường đi độc lập
26
số đường đi tối thiểu cần kiểm tra = độ 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
27
P: số các nút điều kiện
1
2 Số cạnh E = 11 Số đỉnh N = 9 Số điều kiện = 3 Số miền = 4 9
4
3
5 6 Độ phức tạp: 4
7
28
8
Độ phức tạp lớn thì xác suất xuất hiện lỗi cao
29
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)
• 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
30
- đảm bảo mọi lệnh đều được kiểm tra - hiệu quả với các mô đun nhỏ, đơn lẻ
(cid:122) Kiểm thử và gỡ rối là hai công việc phân biệt (cid:122) Kiểm thử nhằm phát hiện sự tồn tại của lỗi (cid:122) Gỡ rối nhằm định vị và sửa chữa mã gây lỗi (cid:122) 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
31
Specification
Test results
Test cases
Repair error
Design error repair
Locate error
Re-test program
32
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
33
không có
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
34
+ phần tử đầu tiên, cuối cùng + phần tử ở vị trí bất kỳ
0 1 1 1 4 4 4 4 4 4
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
7 20 3 10 1 30 8 3 20 7
-1 -1 -1 0 -1 -1 -1 0 3 1
35
Số p.tử Mảng Khóa Kết quả
(cid:122) Giới thiệu
− Verification,Validation, và Testing
(cid:122) Các nguyên lý về kiểm thử (cid:122) Ca kiểm thử (test case) (cid:122) 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
(cid:122) Các giai đoạn và chiến lược kiểm thử
36
(cid:122) Kiểm thử đơn vị (cid:122) Kiểm thử tích hợp
− top-down − bottom-up
(cid:122) Kiểm thử chấp nhận − alpha, beta testing (cid:122) Kiểm thử hệ thống
37
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
38
điều kiện biên,... • Tài liệu thường sơ sài
giaogiao didiệệnn ccấấuu trtrúúcc ddữữ liliệệuu đđiiềềuu kikiệệnn biênbiên đưđườờngng đđii đđộộcc llậậpp xxửử lýlý llỗỗii
39
• 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.
đã phát triển, cần kiểm thử calender()
40
chưa phát triển calc_day()
Mô đun tính ngày trong tuần calc_day():
String calc_day(Date d) {
return "Sunday";
}
41
- 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) {
String s; cout << ”Enter day_of_week of ”<< d; cin >> s; return s;
}
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.
void calc_day_test_drive() {
Date d; String s; while (1) {
cout << ”Enter date: ”); cin >> d; s = calc_day(d); cout << s << endl;
}
}
43
Test drive để thử nghiệm calc_day()
• 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
Intergration testing
• 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ả
44
• Thường sử dụng kiểm thử chức năng • Được lập tài liệu
45
Kiểm thử trên xuống (top-down) Kiểm thử dưới lên (bottom-up) Kiểm thử quay lui (regression)
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
46
chuẩn
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
47
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)
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: 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
Nhược điểm
48
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, ...)
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
49
- 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
Thay thế các driver từng cái một
50
Các module mức thấp được tích hợp trước
• Ưu điểm
- 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
• Nhược điểm
51
- 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
(cid:122) Mỗi chiến lược đều có ưu nhược điểm
(cid:122) Chiến lược kiểm thử phải phù hợp với
(cid:122) Có thể phối hợp các chiến lược:
52
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
53
khách hàng được gọi là alpha testing
• 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
54
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
(cid:122) Mở rộng phạm vi kiểm thử, nhìn nhận
(cid:122) 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
55
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…
• Nghiên cứu:
(cid:131) 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)
(cid:131) 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,...
(cid:131) các tổ hợp điều kiện khiến hệ ngừng hoạt động
56
+ OS, phần mềm, phần cứng,...
