Bài giảng Kiểm chứng, thẩm định và kiểm thử (Verification, validation, and testing)

Nội dung text: Bài giảng Kiểm chứng, thẩm định và kiểm thử (Verification, validation, and testing)

1. Các nguyên lý kiểmthử PM z Các phép kiểmthử phảitương ứng vớicác yêu cầucủaHT z Mỗi phép kiểmthử nên đượclậpkế hoạch từ rấtsớmtrướckhitiến hành kiểmthử z Qui luật Pareto hay qui luật 80/20 (qui luật thiểusố quan trọng và phân bố nhân tố) − khoảng 80% kếtquả 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
2. Ca kiểmthử (test case) z Ca kiểmthử: dữ liệu để kiểmtrahoạt động củachương trình z Ca kiểmthử tốt − đượcthiếtkếđểphát hiệnmộtlỗicủa chương trình z Kiểmthử thành công: phát hiệnralỗi z Mục đích: − Chứng minh đượcsự tồntạicủalỗi − Không chứng minh đượcsự không có lỗi 12
3. Nôi dung của test case z Tên mô đun/chứcnăng muốnkiểmthử dữ liệuvào − dữ liệuthôngthường: số, xâu kí tự, file, − môi trường thử nghiệm: phầncứng, OS, − thứ tự thao tác (khi kiểmthử giao diện) z Kếtquả mong muốn − thông thường: số, xâu kí tự, file, − màn hình, thờigianphảnhồi z Kếtquả thựctế 13
4. Các kỹ thuậtkiểmthử chương trình z Kiểmthử chứcnăng (functional testing) − dựatrênđặctả chứcnăng − phát hiệncácsaisótvề chứcnăng − không quan tâm đếncáchcàiđặt z Kiểmthử cấu trúc (structured testing) − kiểmthử có nghiên cứumãnguồn − phân tích thứ tự thựchiệncáclệnh 14
5. Kiểmthử chứcnăng Functional testing / Black box testing Dựatrênđặctả chứcnăng •Test case đượcthiếtkếđểkiểmtrachứcnăng •Pháthiệncáckhiếm khuyếtso với đặctả • Không quan tâm đếncáchcàiđặt (mã nguồn) -Pháthiện sai sót, thiếusótchứcnăng -Saisótvề giao diệncủamôđun -Kiểmtratínhhiệuquả -Pháthiệnlỗikhởitạo, lỗikết thúc, 15
6. Phân hoạch tương đương Equivalence partitioning • Không thể kiểmthử mọitrường hợp •Chiadữ liệu thành các miền có cùng hành vi •Tạomột test case cho từng miền •Tạo test case cho biên củacácmiền - nhiềulỗixuấthiệnvớigiátrị biên 16
7. Phân hoạch tương đương - Ví dụ Hàm tính trị tuyệt đối -miềndữ liệu ≥ 0 -miềndữ liệu< 0 Input Expected Output 100 100 -20 20 0 0 17
8. Mở rộng các test case Tạo test case cho các trường hợp đặcbiệt -biêncủasố trong máy tính (vd. 32767, -32768) -số không (0) -số âm, số thập phân -dữ liệusaikiểu -dữ liệungẫu nhiên 18
9. Kiểmthử cấutrúc Structural testing / White box testing • Xây dựng ca kiểmthử dựatrênphântíchmãnguồn •Xâydựng bộ test case để kiểmtramọidònglệnh • Phân tích các lệnh rẽ nhánh, vòng lặp •Phùhợpvớicácmôđun nhỏ •Làsự bổ sung cho kiểmthử chứcnăng 19
10. Đường đi trong mô đun • Phân tích mô đun để xác định đường đi • Đường đilàthứ tự thựchiệncáclệnh từđiểm bắt đầu đến điểmkết thúc củamôđun •Thiếtkế các test case để kiểmthử mọi đường đi 20
11. Xác định đường đi • Đánh số các khốilệnh - đánh số các khốilệnh, câu lệnh điềukiện - đánh số các hợp điểmcủaluồng lệnh •Rútgọn flow chart (đồ thị) -cáckhốituầntựđược tích hợpthànhmột khối - tích hợpkhốituầntự vào câu lệnh điềukiện kế tiếp 21
12. Start 0 1 2 11 3 End 6 4 7 8 5 9 10 22
13. 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
14. Đường đi độclập • Không thể chọnmọi đường đi -chọncácđường đi độclập • Đường đi độclập -cóítnhấtmộtcặpkhốilệnh (mộtcạnh của đồ thị) chưaxuấthiện trong các đường đi đãcó •Bộ các đường đi độclậplàmộttậphợpthỏamãn -mọikhốilệnh đều đượcthựchiệnítnhấtmộtlần -mọi điềukiện đều đượckiểmthử với hai trường hợp true và false 24
15. 1 Đường đi độclậ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
16. Đường đi độclập có thể tồntạinhiềubộđường đi độclập sốđường đitốithiểucầnkiểmtra = độ phứctạpthuậttoán 26
17. Độ phứctạpthuậttoán Độ phứctạpV(G) của flow chart G: 1. Số miềncủ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ềukiện 27
18. 1 Số cạnh E = 11 Sốđỉnh N = 9 Sốđiềukiện= 3 9 2 Số miền= 4 4 3 5 6 Độ phứctạp: 4 7 8 28
19. Độ phứctạpthuậttoán Độ phứctạplớnthìxácsuấtxuấthiệnlỗicao không nên tạocácmôđun có độ phứctạp> 10 phân rã mô đun (tạocácmôđun thứ cấp để giảm độ phứctạp) 29
20. Chứcnăng vs. Cấutrúc • Kiểmthử chứcnăng - kiểmtratínhhiệuquả củaphầnmềm -thuậntiệnvớicácmôđun lớn, tích hợp • Kiểmthử cấutrúc - đảmbảomọilệnh đều đượckiểmtra -hiệuquả vớicácmôđun nhỏ, đơnlẻ 30
21. Kiểmthử và gỡ rối z Kiểmthử và gỡ rối là hai công việc phân biệt z Kiểmthử nhằm phát hiệnsự tồntạicủalỗi z Gỡ rốinhằm định vị và sửachữamãgâylỗi z Gỡ rối bao gồmviệc sinh ra các giả thiếtvề hoạt động củachươngtrìnhvàkiểmthử chương trình để tìm lỗi 31
22. Tiếntrìnhgỡ rối Test Specification Test results cases Locate Design Repair Re-test error error repair error program 32
23. 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ắpxếp - khóa tìm kiếmk (số nguyên) output: vị trí củak trongmảng a[] nếu có, -1 nếu không có 33
24. Tạo test cases cho hàm tìm kiếmnhị phân Số phầntử củamảng: -0, 1 -lớnhơn1 Khóa tìm kiếm: - không có trong mảng + nhỏ hơn, lớnhơn + xen kẽ - có trong mảng + phầntửđầu tiên, cuối cùng + phầntửởvị trí bấtkỳ 34
25. Tạo test cases cho hàm tìm kiếmnhị phân Số p.tử Mảng Khóa Kếtquả 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
26. Nội dung z Giớithiệu − Verification,Validation, và Testing z Các nguyên lý về kiểmthử z Ca kiểmthử (test case) z Các kỹ thuậtkiểmthử chương trình − Kiểmthử chứcnăng − Kiểmthử cấutrúc z Các giai đoạnvàchiếnlượckiểmthử 36
27. Các giai đoạnkiểmthử z Kiểmthửđơnvị z Kiểmthử tích hợp − top-down − bottom-up z Kiểmthử chấpnhận − alpha, beta testing z Kiểmthử hệ thống 37
28. Kiểmthửđơnvị Unit testing • Kiểmthử các mô đun, chương trình riêng lẻ •Ngườitiến hành: thường là ngườilậptrình •Sử dụng các stubs và drivers •Phốihợpgiữakiểmthử cấutrúcvàkiểmthử chứcnăng -kiểmtracâulệnh điềukiện, cấutrúcdữ liệu điềukiện biên, •Tàiliệuthường sơ sài 38
29. Kiểmthửđơnvị driver giaogiao didiệệnn ccấấuu trtrúúcc ddữữ liliệệuu Module đđiiềềuu kikiệệnn biênbiên đưđườờngng đđii đđộộcc llậậpp xxửử lýlý llỗỗii stub stub test cases RESULTS 39
30. Ví dụ sử dụng stub •Kiểmthử mô đun calender() có gọi đếnmô đun tính ngày • trong tuần calc_day()chưa được phát triển. calender() đã phát triển, cầnkiểmthử calc_day() chưa phát triển 40
31. Ví dụ sử dụng stub 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"; } 41
32. Ví dụ sử dụng stub Để tăng độ thích nghi, có thể thay thế dữ liệucố định bằng cách nhậpkếtquả trựctiếptừ bàn phím. String calc_day(Date d) { String s; cout > s; return s; } 42
33. Ví dụ về test drive Test drive để thử nghiệm calc_day() void calc_day_test_drive() { Date d; String s; while (1) { cout > d; s = calc_day(d); cout << s << endl; } } 43
34. Kiểmthử tích hợp Intergration testing • Kiểmthử tích hợp các unit •Ngườitiến hành: ngườilập trình, ngườithiế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ệngiữa các unit -kiểmtratínhđúng đắnso với đặctả -kiểm tra tính hiệuquả •Thường sử dụng kiểmthử chứcnăng • Đượclậptàiliệu 44
35. Các chiếnlượctíchhợp Kiểmthử trên xuống (top-down) Kiểmthử dưới lên (bottom-up) Kiểmthử quay lui (regression) 45
36. Kiểmthử trên xuống Top-down testing Các mô đun mứctrênđượckiểmthử trước Các mô đun thuộccấp được thay bằng bằng các mô đun tạmthời(stub function) - có cùng tên vớimôđun thật - có cùng giao diện -trả lạikếtquả vớimộthoặcmộtvàibộ dữ liệu chuẩn 46
37. Kiểmthử trên xuống Top module được A kiểmthử trước với các stubs B F G Các stubs được thay C thế từng cái một Mỗikhimột module mới D E được tích hợp mộtsố ca kiểmthửđược thựchiệnlại (kiểmthử quay lui) 47
38. Ưunhược điểmcủa top-down Ưu điểm: Phát hiệnsớmcáclỗithiếtkế (lỗicấutrúc) -kiểmthử trên xuống kếthợpvới phát triểntrên xuống sẽ giúp phát hiệnsớmcáclỗithiếtkế và làm giảm giá thành sửa đổi Có sớm phiên bảnthựchiện được - phiên bảnthựchiệnvớicácchứcnăng chính có sớm -cóthể thẩm định tính dùng đượccủasảnphẩmsớm Nhược điểm Nhiềumôđun cấpthấprất khó mô phỏng -thao tácvớicấutrúcdữ liệuphứctạp -trả lạikếtquả phứctạp (con trỏ, ảnh, ) 48
39. Kiểmthử dưới lên - bottom-up testing Các mô đun cấpthấp đượckiểmthử trước Mô đun mứctrênđược thay thế bằng mô đun điềukhiển(test driver), có chứcnăng -gọimôđun cầnthử nghiệm -truyềndữ liệu -hiểnthị kếtquả Thay thế dầncácdrive 49
40. Kiểmthử dướilên A B F K Thay thế các driver từng cái một C G D E H I cluster cluster Các module mứcthấp được tích hợptrước 50
41. Ưunhược điểmcủa bottom up • Ưu điểm - Tránh xây dựng các mô đun tạmthời(stub) phứctạp - Tránh sinh các kếtquả nhân tạo(nhậptừ bàn phím) -Thuậntiện cho phát triểncácmôđun để dùng lại •Nhược điểm -Chậm phát hiệncáclỗikiếntrúc -Chậm có phiên bảnthựchiện 51
42. Top down vs. Bottom up z Mỗichiếnlược đềucóưunhược điểm riêng z Chiếnlượckiểmthử phải phù hợpvới chiếnlượ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ốihợpcácchiếnlược: Sandwich testing 52
43. Kiểmthử chấpnhận Acceptance testing •Cósự tham gia của khách hàng/ngườisử dụng •Dùngkiểmthử chứcnăng •Mục đích: thẩm định (validation) phầnmềm - sai sót, thiếusótso vớiyêucầungười dùng •Sử dụng các dữ liệuthực do user cung cấp •Kiểmthử chấpnhậntiến hành ở môi trường khách hàng đượcgọi là alpha testing 53
44. Kiểmthử beta •Mở rộng của alpha testing • Đượctiến hành vớimộtlượng lớnusers •User tiến hành kiểmthử không có sự hướng dẫncủangười phát triển; thông báo lạikếtquả cho người phát triển 54
45. Kiểmthử hệ thống z Mở rộng phạmvi kiểmthử, nhìn nhận phầnmềmlàmộtyếutố trong một HTTT phứctạp z Kiểmtracácyếutố − khả năng phụchồisaulỗi − độ an toàn − hiệunăng và giớihạncủaphầnmềm 55
46. Kiểmthử gây áp lực-Stress Testing Sử dụng các dữ liệulớn -số ngườisử dụng lớn, số giao dịch lớn, tệpkíchthướclớn •Nghiêncứu: ƒ mứctớihạncủahệ thống (mứctảikhiếnhệ thống ngừng hoạt động) ƒ phản ứng củahệ thống khi đạtmứctớihạn + biến thiên củathờigianphảnhồi + độ an toàn củadữ liệu, ƒ các tổ hợp điềukiệnkhiếnhệ ngừng hoạt động + OS, phầnmềm, phầncứng, 56