Nhập môn Công nghệ phần mềm - Chương 3: Chiến lược kiểm thử phần mềm trình bày các nội dung: kiểm tra mức đơn vị (Unit Testing), kiểm tra tích hợp (Integration Testing), kiểm tra mức hệ thống (System Testing), kiểm tra chấp nhận sản phẩm (Acceptance Testing), kiểm tra hồi qui (Regression Testing).
Kiểm thử Phần mềm – Software Testing Chương 3: Chiến lược kiểm thử phần mềm Lương Trần Hy Hiến, Khoa CNTT, ĐH Sư phạm TpHCM Nội dung • Kiểm tra mức đơn vị (Unit Testing) • Kiểm tra tích hợp (Integration Testing) • Kiểm tra mức hệ thống (System Testing) • Kiểm tra chấp nhận sản phẩm (Acceptance Testing) • Kiểm tra hồi qui (Regression Testing) 3.1 Kiểm thử đơn vị Unit Test Unit Test gì? Những Lợi ích từ UT Assert, Mock Object, TDD Công cụ cho Unit Test Demo cơng cụ Unit Test gì? • Unit Test kỹ thuật kiểm nghiệm hoạt động đơn vị mã nguồn (unit of code) với quy trình tách biệt với quy trình phát triển phần mềm, giúp phát sai sót kịp thời • Unit Test phần mã nguồn dùng để kiểm tra phần mã nguồn khác • Unit Test kỹ thuật quan trọng Test Driven Development Unit Test gì? • Unit Test phương pháp bổ sung cho phương pháp kiểm thử khác, giúp phát lỗi từ sớm, từ ý tưởng thiết kế (reviews code, walkthroughs…) • Unit Test viết Developers Test “White Box”, “Black-Box” trình PTPM Các Khái Niệm: Unit of Code : Mỗi đơn vị mã nguồn individual program, function, Procedure, class, methods… White-Box, Black-Box : Unit Test gì? Unit Test có trạng thái: Fail (trạng thái lỗi) Ignore (tạm ngừng thực hiện) Pass (trạng thái làm việc đúng) Thực UT nào? Mỗi Unit Test tiết kế theo trình tự: • Thiết lập điều kiện cần thiết: khởi tạo đối tượng • Xác định tài nguyên cần thiết, xây dựng liệu giả • Triệu gọi phương thức cần kiểm tra • Kiểm tra hoạt động đắn phương thức • Dọn dẹp tài nguyên sau kết thúc kiểm tra How to write a Unit Test? My Unit Test is good? Tự động kiểm tra trạng thái (Pass/False/Ignore) Đầy đủ (phủ hết trường hợp) Tái sử dụng Tính độc lập (very important) Theo chuẩn code Khả thực thi nhanh Đơn giản để thực Unit Testing Still Not Mainstream http://www.telerikwatch.com/2008_05_01_archive.html Lợi ích từ Unit Test Đảm bảo chất lượng Unit phần mềm Phát lỗi sớm chỉnh sửa kịp thời Giảm chi phí bảo trì kiểm thử Dễ tích hợp Tài liệu hóa Giúp Thiết Kế Acceptance Testing •• Mục Mục tiêu: tiêu: Hệ Hệ thống thống sẵn sẵn sàng sàng sử sử dụng dụng –– Khách Khách hàng hàng thực thực hiện –– Có Có thể thể thực thực hiện ởở giai giai đoạn đoạn tích tích hợp hợp –– Lập Lập trình trình viên viên khơng khơng kiểm kiểm thử thử ởở giai giai đoạn đoạn này •• Phần Phần lớn lớn các bugs bugs trong phần phần mềm mềm do khách khách hàng hàng tìm tìm thấy thấy sau sau khi hệ hệ thống thống đưa đưa vào vào sử sử dụng dụng Vì Vì vậy có có 22 loại loại kiểm kiểm ởở giai giai đoạn đoạn •• Alpha Alpha test: test: –– Khách Khách hàng hàng kiểm kiểm ngay tại nơi nơi viết viết phần phần mềm mềm –– Lập Lập trình trình viên viên sẵn sẵn sàng sàng fix fix bugs bugs khi tìm tìm thấy thấy •• Beta Beta test: test: –– Khách Khách hàng hàng xài xài thử thử –– Phần Phần mềm mềm đang ởở trong môi môi trường trường thực thực –– Khách Khách hàng hàng tiềm tiềm năng có thể khơng khơng hài hài lịng lịng Kiểm thử có chu kì sống riêng Thiết lập mục tiêu kiểm Thiết kế test cases Viết test cases Kiểm test cases Thực thi the tests Đánh giá kết kiểm Thay đổi hệ thống Thực kiểm hồi qui Đội Test Professional Tester Programmer Analyst User Test Team Configuration Management Specialist System Designer too familiar with code 3.4 Kiểm tra chấp nhận • Mục tiêu – Xác nhận từ phía ngườisửdụng • Điềukiện – – – – – – – – Kiểm tra hồi hệ thống hồi quy hồn tất Người Quản lý cấu hình Test data Tài liệuhướng dẫncuối sẵn sàng Đã xét thủ tục kiểm thử Điều kiện thoát Các thủ tục đặc biệt Tiêu chuẩn chấp nhận phải lập tài liệu • Acceptance Testing • Người chịu trách nhiệm 48 3.4 Kiểm tra chấp nhận 49 3.4 Kiểm tra chấp nhận • Kỳ vọng: – Xác nhận từ phía ngườ isử dụng – Kiểm tra thực thi đánh giá lại – Kéo dài thời gian – Hướng dẫn cho người kiểm thử – Các u cầu khơng có khả kiểm thử – Rà soát người tài trợ NSD – Kế hoạch cho việc thực 50 Regression Test 3.5 KIỂM TRA HỒI QUY 51 3.5 Kiểm tra hồi qui • Tiến trình kiểm tra lại PM sau sửa chữa chương trình • Regression test thực mức kiểm tra 52 3.5 Kiểm tra hồi qui • Mục đích: – Định vị lỗi – Gia tăng tin cậy tính chương trình – Bảo đảm chất lượng – Bảo đảm hoạt động liên tục – Kiểm tra tính đắn “phần mới” – Đảm bảo phần không sửa thực 53 3.5 Kiểm tra hồi qui – Ví dụ • Một PM phát triển kiểm tra chạy tốt chức A, B C • Thay đổi code chức C: – Nếu kiểm tra chức C chưa đủ, cần phải kiểm tra lại tất chức khác liên quan đến chức C (A, B) – Lý C thay đổi, làm A B khơng cịn làm việc 54 3.5 Kiểm tra hồi qui • Rất tốn nhiều thời gian cơng sức • Khơng phép bỏ qua dẫn đến tình trạng phát sinh tái xuất lỗi nghiêm trọng, ta “tưởng rằng” lỗi khơng có kiểm tra sửa chữa 55 Tóm tắt • Kiểm thử vẩn ma thuật, có nhiều luật mẹo dùng • Kiểm thử bao gồm unit testing, integration testing system testing • Các mẫu thiết kế (Design Patterns) dùng để kiểm tích hợp • Kiểm thử có chu kì sống riêng Cảm ơn • Bài giảng tham khảo hiệu chỉnh từ: – Slide Kiểm định Phần mềm, Nguyễn Quốc Huy, ĐH Sài Gòn – Slide Lý thuyết Kiểm tra Phần mềm, Nguyễn Ngọc Tú, ĐH Hoa Sen – Slide Kiểm chứng Phần mềm, Lê Duy Hoàng, ĐH KHTN TpHCM 57 Câu hỏi thảo luận ? Thank you!!! ... trên chiến chiến lược lược tích tích hợp, hợp, chọn chọn một thành thành phần phần để để kiểm kiểm Kiểm Kiểm đơn đơn vị các lớp lớp trong thành phần thành phần 2 Đặt Đặt thành thành phần phần... giao giaodiện diệnthành thànhphần phần 3. 3 Kiểm thử hệ thống • • • • • Kiểm thử chức Kiểm thử cấu trúc Kiểm thử hiệu suất Kiểm thử chấp nhận Kiểm thử cài đặt 3. 3 Kiểm thử hệ thống Ảnh hưởng... lỗi lỗi trong cấu cấu hình hình thành thành phần phần Chiến lược tích hợp nên dùng? •• Các –– Các Cácyếu yếutố tốxem xemxét xét Cácthành thànhphần phần? ??ởtầng tầng –– Khối trênthường thườngquan