Bài giảng Kỹ thuật lập trình – Chương 9: Gỡ lỗi và kiểm thử. Những nội dung chính được trình bày trong chương này có thể giúp người học hiểu được: Gỡ rối là gì? Tìm kiếm và gỡ rối, hiểu các thông báo lỗi, tìm các lỗi tương tự, chia để trị,... Mời các bạn cùng tham khảo để biết thêm các nội dung chi tiết.
ng c om Trịnh Thành Trung (ThS) trungtt@soict.hust.edu.vn cu u du o ng th an co Bài GỠ LỖI VÀ KIỂM THỬ CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om ng cu u du o Gỡ lỗi Kiểm thử th an co ng Nội dung CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om th an co ng Gỡ lỗi cu u du o ng Debug CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om Gỡ rối Debug ng ▪ Gỡ rối gì? ng th an co ▫ Khi chương trình bị lỗi, gỡ rối cơng việc cần làm để làm cho chương trình dịch thơng, chạy thông ▫ Thật không may, gỡ rối thao tác phải làm lập trình, thao tác tốn du o ▪ Cách tốt phòng ngừa cu u ▫ Khi bắt đầu gỡ rối chương trình, bạn biết chương trình khơng chạy ▫ Nếu bạn biết lý chương trình khơng chạy, bạn sửa chương trình cho chạy ▫ Nếu bạn hiểu chương trình bạn, bạn có sai lầm dễ dàng sửa chữa sai sót Bí viết mã đơn giản, hiệu quả, thích hợp lý CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om Gỡ rối Debug co ng ▪ Đối với mã nguồn, tiêu chí quan trọng hơn: rõ ràng hay xác? du o ng th an ▫ Nếu mã nguồn rõ ràng, bạn làm cho chương trình trở nên xác ▫ Bạn có làm cho chương trình trở nên xác khơng rõ ràng hay khơng? cu u ▪ Nếu chương trình thiết kế với cấu trúc tốt, viết phong cách lập trình tốt áp dụng kỹ thuật viết chương trình hiệu quả, bẫy lỗi chi phí cho việc gỡ rối giảm thiểu CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om Tìm kiếm gỡ rối du o ng th an co ng ▪ Khi có lỗi, ta thường đổ cho trình dịch, thư viện hay nguyên nhân khách quan khác… nhiên, cuối lỗi lỗi chương trình, trách nhiệm gỡ rối thuộc LTV ▪ Phải hiểu vấn đề xuất phát từ đâu giải được: cu u ▫ Lỗi xảy đâu? Hầu hết lỗi thường đơn giản dễ tìm Hãy khảo sát đầu mối cố gắng xác định đoạn mã nguồn gây lỗi ▫ Lỗi xảy nào? Khi có số thơng tin lỗi nơi xảy lỗi, suy nghĩ xem lỗi xảy ▫ Đâu nguyên nhân gây lỗi? Suy luận ngược trở lại trạng thái chương trình để xác định nguyên nhân gây lỗi CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om ng co an th ng du o u cu “ Gỡ rối liên quan đến việc suy luận lùi, giỗng phá án Một số vấn đề khơng thể xảy có thông tin xác thực đáng tin cậy Phải ngược từ kết để khám phá nguyên nhân Khi có lời giải thích đầy đủ, ta biết vấn đề cần sửa phát số vấn đề khác CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om Debugging Heuristic ng Debugging Heuristic co (1) Hiểu thông báo lỗi (error messages) Áp dụng Build-time (dịch) an (2) Nghĩ trước viết lại chương trình (4) Divide and conquer ng th (3) Tìm kiếm lỗi (bug) hay xảy u du o (5) Viết thêm đoạn mã kiểm tra để chương trình tự kiểm tra Run-time (chạy) cu (6) Hiện thị kết (7) Sử dụng debugger (8) Tập trung vào lệnh viết / viết lại CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om Hiểu thông báo lỗi th an co ng ▪ Gỡ rối dịch (build-time) chương trình dễ gỡ rối chạy chương trình LTV hiểu thơng báo lỗi ▪ Một số thông báo lỗi đến từ preprocessor Gõ sai tên file cần gọi Thiếu dấu */ cu u du o ng #include int main(void) /* Print "hello, world" to stdout and return { printf("hello, world\n"); return 0; } $ gcc217 hello.c -o hello hello.c:1:20: stdioo.h: No such file or directory hello.c:3:1: unterminated comment hello.c:2: error: syntax error at end of input CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om Hiểu thông báo lỗi co ng ▪ Một số thơng báo lỗi đến từ compiler Sai từ khóa cu u du o ng th an #include int main(void) /* Print "hello, world" to stdout and return */ { printf("hello, world\n") retun 0; } $ gcc217 hello.c -o hello hello.c: In function `main': hello.c:7: error: `retun' undeclared (first use in this function) hello.c:7: error: (Each undeclared identifier is reported only once hello.c:7: error: for each function it appears in.) hello.c:7: error: syntax error before numeric constant CuuDuongThanCong.com https://fb.com/tailieudientucntt cu u du o ng th an co ng c om Các phương pháp kiểm thử CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om Các phương pháp kiểm thử cu u du o ng th an co ng ▪ Black-Box: Testing dựa việc phân tích yêu cầu requirements (unit/component specification, user documentation, v.v.) Còn gọi functional testing ▪ White-Box: Testing dựa việc phân tích logic bên - internal logic (design, code, v.v.) (Nhưng kết mong đợi đến từ requirements.) Còn đc gọi structural testing CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om Kiểm thử hộp trắng cu u du o ng th an co ng ▪ Còn gọi clear box testing, glass box testing, transparent box testing, or structural testing, thường thiết kế trường hợp kiểm thử dựa vào cấu trúc bên phần mềm ▪ WBT đòi hỏi kĩ thuật lập trình am hiểu cấu trúc bên phần mềm (các đường, luồng liệu, chức năng, kết quả) ▪ Phương thức: Chọn đầu vào xem đầu CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om Kiểm thử hộp trắng cu u du o ng th an co ng Đặc điểm ▪ Phụ thuộc vào cài đặt hệ thống phần mềm, có thay đổi test cần thay đổi theo ▪ Được ứng dụng kiểm tra cấp độ mơ đun (điển hình), tích hợp (có khả năng) hệ thống trình test phần mềm CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om Kiểm thử hộp đen cu u du o ng th an co ng ▪ Black-box testing sử dụng mơ tả bên ngồi phần mềm để kiểm thử, ,bao gồm đặc tả (specifications), yêu cầu (requirements) thiết kế (design) ▪ Khơng có hiểu biết cấu trúc bên phần mềm ▪ Các dạng đầu vào có dạng hàm khơng, hợp lệ không không hợp lệ biết trước đầu hợp lệ không không hợp lệ biết trước đầu ▪ Được sử dụng để kiểm thử phần mềm mức: mơ đun, tích hợp, hàm, hệ thống chấp nhận CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om Kiểm thử hộp đen cu u du o ng th an co ng ▪ Ưu điểm kiểm thử hộp đen khả đơn giản hoá kiểm thử mức độ đánh giá khó kiểm thử ▪ Nhược điểm khó đánh giá giá trị chưa kiểm thử hay không CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om Kiểm thử hộp đen cu u du o ng th an co ng Các kỹ thuật kiểm thử hộp đen ▪ Decision Table testing ▪ Pairwise testing ▪ State transition tables ▪ Tests of Customer Requirement ▪ Equivalence partitioning ▪ Boundary value analysis ▪ Failure Test Cases CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om Kiểm thử hộp xám cu u du o ng th an co ng ▪ Là kết hợp kiểm thử hộp đen kiểm thử hộp trắng mà người kiểm thử biết phần cấu trúc bên phần mềm • Khác với kiểm thử hộp đen ▪ Là dạng kiểm thử tốt có kết hợp kĩ thuật kiểm thử hộp đen kĩ thuật kiểm thử hộp đen hộp trắng CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om Ai kiểm thử gì? ng ▪ Programmers th an co ▫ White-box testing ▫ Ưu điểm: Người triển khai nắm rõ luồng liệu ▫ Nhược: Bị ảnh hưởng cách thức code đc thiết kê/viết ng ▪ Quality Assurance (QA) engineers cu ▪ Customers u du o ▫ Black-box testing ▫ Pro: Khơng có khái niệm implementation ▫ Con: Không muốn test logical paths ▫ Field testing ▫ Pros: Có cách sử dụng chương trình bất ngờ;dễ gây lỗi ▫ Cons: Không đủ trường hợp; khách hàng khơng thích tham gia vào q trình test ; CuuDuongThanCong.com https://fb.com/tailieudientucntt cu u du o ng th an co ng ▪ Sanity testing ▪ Smoke testing ▪ Software testing ▪ Stress testing ▪ Test automation ▪ Web Application Security Scanner ▪ Fuzzing ▪ Acceptance testing ▪ Sanwich Testing c om Các phương pháp khác CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om Các mức độ kiểm thử u du o ng th an co ng ▪ Unit: testing mẫu công việc nhỏ lập trình viên để lập kế hoạch theo dõi hợp lý (vd : function, procedure, module, object class,…) ▪ Component: testing tập hợp units tạo thành thành phần (vd: program, package, task, interacting object classes,…) ▪ Product: testing thành phần tạo thành sản phẩm (subsystem, application,…) ▪ System: testing toàn hệ thống ▪ Testing thường: cu ▫ Bắt đầu = functional (black-box) tests, ▫ Rồi thêm = structural (white-box) tests, ▫ Tiến hành từ unit level đến system level với vài bước tích hợp CuuDuongThanCong.com https://fb.com/tailieudientucntt cu u du o ng th an co ng c om Kiểm thử tất thứ? Chi phí cho 'exhaustive' testing: 20 x x x 10 x x 100 = 480,000 tests Nếu giây cho test, 8000 phút, 133 giờ, 17.7 ngày (chưa kể nhầm lẫn test test lại) 10 secs = 34 wks, = yrs, 10 = 40 yrs CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om Bao nhiêu testing đủ? cu u du o ng th an co ng ▪ Không đủ! ▪ Khi bạn thực test mà bạn lên kế hoạch ▪ Khi khách hàng / người sử dụng thấy thỏa mãn ▪ Khi bạn chứng minh / tin tưởng hệ thống hoạt động đúng, xác ▪ Phụ thuộc vào risks for your system ▪ Càng thời gian, nhiều để thời gian để test có giới hạn ▪ Dùng RISK để xác định: ▫ Cái phải test trước ▫ Cái phải test nhiều ▫ Mỗi phần tử cần test kỹ nào? Tức đâu trọng tâm ▫ Cái không cần test (tại thời điểm này…) CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om The Testing Paradox cu u du o ng th an co ng ▪ Mục đích testing: để tìm lỗi ▪ Tìm thấy lỗi làm hủy hoại tự tin => Mục đích testing: hủy hoại tự tin ▪ Nhưng mục đích testing: Xây dựng niềm tin, tự tin => Cách tốt để xây dựng niềm tin là: Cố gắng hủy hoại CuuDuongThanCong.com https://fb.com/tailieudientucntt .c om th an co ng Thanks! du o ng Any questions? cu u Email me at trungtt@soict.hust.edu.vn CuuDuongThanCong.com Presentation template by SlidesCarnival https://fb.com/tailieudientucntt ... hưởng đến hoạt động chương trình ▫ Dừng chương trình với điều kiện biết trước ▫ Khi chương trình bị dừng, kiểm tra xảy ▫ Thay đổi lệnh chương trình để LTV thử nghiệm gỡ rối lỗi CuuDuongThanCong.com... Phải gỡ rối ngay, không nên để sau c om Tập trung vào thay đổi ng th an co ▫ Khó: Viết tồn chương trình; kiểm tra tồn chương trình, gỡ rối tồn chương trình ▫ Dễ hơn: Viết đoạn, kiểm tra đoạn, gỡ. .. om Gỡ rối Debug ng ▪ Gỡ rối gì? ng th an co ▫ Khi chương trình bị lỗi, gỡ rối công việc cần làm để làm cho chương trình dịch thơng, chạy thơng ▫ Thật khơng may, gỡ rối thao tác phải làm lập trình,