Công nghệ thực phẩm - Kiểm chứng, thẩm định và kiểm thử

Nội dung text: Công nghệ thực phẩm - Kiểm chứng, thẩm định và kiểm thử

1. KiểmChứng, Thẩm Định và KiểmThử (Verification, Validation, and Testing)
2. Mục đích z Sau buổihọc sinh viên phảinắm được: − Hiểu các khái niệm: verification, valdation, và testing − Nắm được các nguyên lý về kiểmthử − Hiểu khái niệmca kiểmthử (test case) − Các phương pháp thiếtkế test case − Làm thế nào để kiểmthử chương trình − Làm thế nào để kiểmthử hệ thống 2
3. 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ử 3
4. Tài liệu z Pressman, Software Engineering, McGraw Hill (chapter 18 & 19) z Sommerville, Software Engineering, Addison-Wesley (chapter 22 & 23) z Giáo trình kỹ nghệ phầnmềm(chương 5) z Các tài liệu điệntử khác 4
5. Verification,Validation, và Testing z Kiểmchứng (Verification) − có đúng đặctả không, có đúng thiếtkế không − phát hiệnlỗilậptrình z Thẩm định (Validation) − có đáp ứng nhu cầungười dùng không − có hoạt động hiệuquả không − phát hiệnlỗi phân tích, lỗithiếtkế (lỗimứccao) z V&V = Verification and Validation − mụctiêulàpháthiệnvàsửalỗiPM, đánh giá tính dùng đượccủaPM z Thứ tự thựchiện: Verification -> Validation 5
6. Kiểmchứng/Thẩm định tĩnh và động z Kiểmchứng/Thẩm định tĩnh − không thựchiệnchương trình − xét duyệtyêucầu, thiếtkế, mã nguồn − tiến hành ở mọicôngđoạnpháttriển − khó đánh giá tính hiệuquả củasảnphẩm z Kiểmchứng/Thẩm định động (kiểmthử - Testing) − thựchiệnchương trình − cầncómãnguồn − phát hiệnlỗilậptrình − đánh giá tính hiệuquả phầnmềm − là cách duy nhất để kiểmtrayêucầuphi chứcnăng 6
7. Mô hình phát triển“V” Đặctả Đặctả hệ Thiếtkế hệ Thiếtkế chi yêu cầu thống thống tiết Kế hoạch Kế hoạch Kế hoạch kiểm Mã hóa mô kiểmthử kiểmthử thử tích hợp đun & kiểm chấpnhận tích hợpHT HT con thử mô đun Kiểmthử tích Kiểmthử Kiểmthử tích Dịch vụ hợpcáchệ chấpnhận hợphệ thống thống con 7
8. Kiểmthử phầnmềm(Testing) z Tập các hoạt động vớimục đích khám phá các lỗivàkhuyếttật/khiếmkhuyết z Mục đích củakiểmthử: − Thiếtkế các ca kiểmthử (test cases) vớikhả năng tìm kiếmcáclỗi/khuyếttật − Thựchiệnchương trình vớimục đích tìm các lỗi/khuyếttật z Mỗi phép kiểmthử (a test) chỉ thành công khi − mộtlỗi được phát hiện − mộtkếtquả chỉ ra sự thấtbạicủathủ tụckiểmthử đượctrả lại 8
9. Các loạikiểmthử phầnmềm z Kiểmthử tìm khuyếttật − tìm lỗilậptrình − tiến hành dựa trên phân tích đặctả chứcnăng, − phân tích mã nguồn z Kiểmthử thống kê − đánh giá tính dùng đượccủasảnphẩm − sử dụng dữ liệuthực(dựatrênthống kê) − số ngườitruycập − số giao tác − cơ sở dữ liệulớn 9
10. Yêu cầu đốivớikiểmthử z Tính lặplại − kiểmthử phảilặplại được(kiểmtraxemlỗi đã đượcsửa hay chưa) − dữ liệu/trạng thái phảimôtảđược z Tính hệ thống − đảmbảokiểmtrahếtcáctrường hợp (coverage) z Đượclậptàiliệu − kiểm soát tiếntrình/kếtquả 10
11. 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
12. 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
13. 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
14. 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
15. 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
16. 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
17. 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
18. 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
19. 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
20. Đườ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
21. 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
22. Start 0 1 2 11 3 End 6 4 7 8 5 9 10 22
23. 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
24. Đườ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
25. 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
26. Đườ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
27. Độ 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
28. 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
29. Độ 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
30. 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
31. 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
32. Tiếntrìnhgỡ rối Test Specification Test results cases Locate Design Repair Re-test error error repair error program 32
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ắ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
34. 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
35. 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
36. 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
37. 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
38. 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
39. 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
40. 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
41. 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
42. 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
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 > d; s = calc_day(d); cout << s << endl; } } 43
44. 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
45. 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
46. 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
47. 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
48. Ư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
49. 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
50. 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
51. Ư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
52. 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
53. 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
54. 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
55. 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
56. 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