Bài giảng môn Công nghệ phần mềm - Chương 8: Kiểm trử phần mềm

Chia sẻ: Khánh Thành | Ngày: | Loại File: PDF | Số trang:49

Thêm vào BST

Báo xấu

33
lượt xem 7
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Sau khi học xong chương này người học có thể hiểu các khái niệm: verification, valdation, và testing; 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.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Bài giảng môn Công nghệ phần mềm - Chương 8: Kiểm trử phần mềm

Chương 8 KIỂM THỬ PHẦN MỀM 1
Mục đích  Sau buổi học sinh viên phải nắm được: — Hiểu các khái niệm: verification, valdation, và testing — 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
Nội dung  Giới thiệu — Verification,Validation, và Testing  Các nguyên lý về kiểm thử  Ca kiểm thử (test case)  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  Các giai đoạn và chiến lược kiểm thử 3
Tài liệu  Pressman, Software Engineering, McGraw Hill (chapter 18 & 19)  Sommerville, Software Engineering, Addison-Wesley (chapter 22 & 23)  Giáo trình kỹ nghệ phần mềm (chương 5)  Các tài liệu điện tử khác 4
Verification,Validation, và Testing  Verification –Kiểm chứng: "Are we building the product right": Chúng ta có xây dựng phần mềm một cách đúng đắn hay không?  Validation – Thẩm định: "Are we building the right product": Chúng ta có xây dựng đúng phần mềm được yêu cầu hay không? 5
Verification,Validation, và Testing  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  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)  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, tạo sự tự tin về phần mềm đạt được mục tiêu đề ra  Thứ tự thực hiện: Verification -> Validation 6
Kiểm chứng/Thẩm định tĩnh và động • 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  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 7
Mô hình phát triển “V” Đặc tả Đặc tả hệ Thiết kế hệ Thiết kế chi yêu cầu thống thống tiết Kế Kế hoạch Kế hoạch Mã hóa mô hoạch kiểm thử kiểm thử tích đun & kiểm kiểm thử tích hợp hợp HT con thử mô đun chấp HT nhận Kiểm thử tích Kiểm thử Kiểm thử tích Dịch hợp các hệ chấp nhận hợp hệ thống vụ thống con 8
Kiểm thử phần mềm (Testing)  Tập các hoạt động với mục đích khám phá các lỗi và khiếm khuyết  KTPM là quá trình thực thi một hệ thống phần mềm để xác định xem phần mềm đó có đúng với đặc tả không và thực hiện trong môi trường mong đợi không  KTPM thực hiện: - Sau mỗi chức năng hoặc module được phát triển - Hoặc thực hiện sau cùng, khi phần mềm đã phát triển hoàn tất 9
Kiểm thử phần mềm (Testing)  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  Mỗi phép kiểm thử 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 10
Yêu cầu đối với kiểm thử  Tính lặp lại — kiểm thử phải lặp lại được (kiểm tra xem lỗi đã được sửa hay chưa) — dữ liệu/trạng thái phải mô tả được  Tính hệ thống — đảm bảo kiểm tra hết các trường hợp  Được lập tài liệu — kiểm soát tiến trình/kết quả 10
Các nguyên lý kiểm thử PM  Các phép kiểm thử phải tương ứng với các yêu cầu của HT  Mỗi phép kiểm thử nên được lập kế hoạch từ rất sớm trước khi tiến hành kiểm thử 12
Ca kiểm thử (test case)  Ca kiểm thử: dữ liệu để kiểm tra hoạt động của chương trình  Ca kiểm thử tốt — Được thiết kế để phát hiện một lỗi của chương trình  Kiểm thử thành công: phát hiện ra lỗi  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 13
Kiểm thử và gỡ rối  Kiểm thử và gỡ rối là hai công việc phân biệt  Kiểm thử nhằm phát hiện sự tồn tại của lỗi  Gỡ rối nhằm định vị và sửa chữa mã gây lỗi  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 14
Nôi dung của test case  Tên mô đun/chức năng muốn kiểm thử dữ liệu vào — Dữ liệu thông thường: số, xâu kí tự, file,... — Môi trường thử nghiệm: phần cứng, OS,... — Thứ tự thao tác (khi kiểm thử giao diện)  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  Kết quả thực tế 15
Các kỹ thuật kiểm thử chương trình  Kiểm thử chức năng (functional testing)/ Kiểm thử hộp đen — 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  Kiểm thử cấu trúc (structured testing)/kiểm thử hộp trắng — 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 16
Các kỹ thuật kiểm thử chương trình 17
Kiểm thử hôp đen (Black box Testing) Người kiểm thử không quan tâm dến cấu trúc bên trong của chương trình Chỉ quan tâm tới dữ liệu đầu vào – đầu ra sau khi được xử lý Chỉ tập trung vào kiểm tra chức năng phần mềm Không quan tâm đến mã lệnh Black box testing Căn cứ vào tài liều đặc tả, phân tích thiết kế để Test Thường do các Tester thực hiện 18
Kiểm thử hôp đen (Black box Testing) So sánh với kết quả mong đợi xem chương trình có đáp ứng yêu cầu không 19
Kiểm thử hôp trắng (White box Testing) 20