bài giảng xác minh thẩm định phần mềm

1  Ngày 28/06/1962, tàu Mariner I bay đến sao Kim nhưng đã bị phá hủy 293 giây sau khi phóng do bay chệch hướng so với dự kiến ban đầu. Những cuộc điều tra sau đó đã xác định nguyên nhân là phần mềm tính toán đường đi của tên lửa bị lỗi. Nguyên nhân sâu xa: việc xác minh/thẩm định phần mềm tính toán đường đi của tên lửa chưa được chú trọng đúng mức 2 XÁC MINH/THẨM ĐỊNH PHẦN MỀM 1. Giới thiệu chung 2. Kiểm thử phần mềm 3. Các kỹ thuật kiểm thử Kiểm thử hộp đen 3 1. GIỚI THIỆU  Xác minh/thẩm định:  Xác minh (verification): • kiểm tra xem sản phẩm có đúng đặc tả không  chú trọng phát hiện lỗi lập trình  Thẩm định (validation): • kiểm tra xem sản phẩm có đáp ứng nhu cầu người dùng không • hoạt động hiệu quả không  chú trọng phát hiện lỗi phân tích, lỗi thiết kế 4 1. GIỚI THIỆU  Xác minh/thẩm định là sự kiểm tra công việc phát triển phần mềm  công việc xuyên suốt quá trình phát triển  Mục đích: • phát hiện và sửa lỗi phần mềm • đánh giá tính dùng được của phần mềm  đảm bảo chất lượng phần mềm 5 1. GIỚI THIỆU  Xác minh /thẩm định tĩnh:  kiểm tra 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  có thể phát hiện được hầu hết các lỗi lập trình (lý thuyết)  không đánh giá tính hiệu quả của sản phẩm  Xác minh/thẩm định động:  kiểm tra thông qua thực hiện chương trình  tiến hành sau khi có mã nguồn  kỹ thuật kiểm tra phần mềm chính hiện nay Kết hợp cả 2 kỹ thuật 6 2. KIỂM THỬ PHẦN MỀM  Kiểm thử là gì ?  “Kiểm thử là tiến trình thực thi chương trình với mục đích tìm thấy lỗi” (Myer)  Phân biệt kiểm thử với gỡ rối (debug) ? 7 2. KIỂM THỬ PHẦN MỀM  Theo nghiên cứu của Boris Beizer và Van Nostrand Reinhold:  không có lập trình viên nào có thể lập trình không có lỗi  trung bình một lập trình viên loại tốt có từ 1 đến 3 lỗi/ 100 dòng lệnh  tìm ra các lỗi chiếm 50% công việc phải làm để có được một phần mềm hoạt động được 8 2. KIỂM THỬ PHẦN MỀM  Test case: dữ liệu kiểm tra  Mỗi testcase thường bao gồm:  dữ liệu đầu vào (input)  điều kiện  dữ liệu đầu ra kỳ vọng (expected output)  {input; điều kiện; expected output}  Thông dụng: xây dựng theo điều kiện 9 2. KIỂM THỬ PHẦN MỀM  Ví dụ: hàm tính trị tuyệt đối của số nguyên  Test case 1: {Input: a=5; Expected output: 5}  Test case 2: {Input: -5; Expected output: 5} 10 2. KIỂM THỬ PHẦN MỀM Thí dụ: chúng ta cần kiểm thử một thành phần phần mềm “quản lý nguồn nhân lực” với đặc tả chức năng như sau: mỗi lần nhận một hồ sơ xin việc, thành phần phần mềm sẽ ra quyết định dựa vào tuổi ứng viên theo bảng sau:  a [...]...2 KIỂM THỬ PHẦN MỀM  1 Test case 1:  {Input : 2 tuổi, Output : không thuê}  2 Test case 2:  {Input : 17 tuổi, Output : thuê bán thời gian}  3 Test case 3:  {Input : 35 tuổi, Output : thuê toàn thời gian}  4 Test case 4:  {Input : 90 tuổi, Output : không thuê} Ngày 25/06/2012 11 2 KIỂM THỬ PHẦN MỀM  Các bước kiểm thử:  Thiết kế các test case  Tạo . chú trọng đúng mức 2 XÁC MINH/ THẨM ĐỊNH PHẦN MỀM 1. Giới thiệu chung 2. Kiểm thử phần mềm 3. Các kỹ thuật kiểm thử Kiểm thử hộp đen 3 1. GIỚI THIỆU  Xác minh/ thẩm định:  Xác minh (verification):. đầu. Những cuộc điều tra sau đó đã xác định nguyên nhân là phần mềm tính toán đường đi của tên lửa bị lỗi. Nguyên nhân sâu xa: việc xác minh/ thẩm định phần mềm tính toán đường đi của tên lửa.  Xác minh/ thẩm định động:  kiểm tra thông qua thực hiện chương trình  tiến hành sau khi có mã nguồn  kỹ thuật kiểm tra phần mềm chính hiện nay Kết hợp cả 2 kỹ thuật 6 2. KIỂM THỬ PHẦN MỀM  Kiểm